Sorun neye benzer ve neden önemlidir?
Kurumsal e-postada “Türkçe karakterler bozuk geliyor” şikâyeti çoğu zaman konu satırından (subject) değil, e-posta gövdesinden (body) kaynaklanır. Alıcı, mesaj içinde “ş, ğ, ü, ı, ö, ç” gibi karakterlerin soru işareti, kare kutu veya anlamsız semboller olarak göründüğünü söyler. Bazen sadece bazı cihazlarda (örneğin mobilde doğru, Outlook’ta bozuk) ortaya çıkar. Bu durum yalnızca okunabilirliği değil; müşteri iletişimini, destek süreçlerini, sözleşme/teklif metinlerinin doğruluğunu ve markaya olan güveni de etkiler.
Bu tip bozulmaların temelinde genellikle MIME içerik başlıkları (Content-Type, charset), içerik aktarım kodlaması (Content-Transfer-Encoding) ve sunucular arası SMTP yetenek pazarlığı (özellikle 8BITMIME) bulunur. Doğru teşhis için “Türkçe karakter var” demek yetmez; mesajın hangi aşamada hangi forma dönüştürüldüğünü anlamak gerekir.
Önce temel kavramlar: charset, 7bit/8bit ve MIME
Charset (karakter seti) nedir?
Charset, metindeki baytların hangi harflere karşılık geldiğini belirleyen kural setidir. Bugün pratikte en doğru ve en geniş uyumluluk sağlayan seçim UTF-8’dir. Ancak bazı sistemler hâlâ ISO-8859-9 veya Windows-1254 gibi kodlamalara düşebilir; bu da farklı istemcilerin farklı yorumlamasına yol açabilir.
7bit ve 8bit ne demektir?
Klasik SMTP dünyasında güvenli aktarım varsayımı 7-bit ASCII idi. Yani her baytın en üst biti sıfır kabul edilirdi. Türkçe karakterler gibi ASCII dışı karakterler UTF-8 ile gönderildiğinde metin 8-bit baytlar içerir. Eğer aktarım yolu 8-bit veriyi güvenle taşıyamıyorsa (veya arada 7-bit’e zorlayan bir bileşen varsa), metin bozulur.
MIME neden gerekli?
MIME, e-postanın sadece “düz ASCII metin” olmadığını anlatan standartların bütünü gibidir. MIME başlıkları; mesajın türünü (text/plain, text/html), charset bilgisini (utf-8) ve gövdenin nasıl kodlandığını (quoted-printable, base64 gibi) belirtir. İstemci, bu başlıklara bakarak metni doğru çözer.
8BITMIME: Sunucular arası “8-bit kabul ediyor musun?” pazarlığı
Bir posta sunucusu diğerine SMTP ile teslimat yaparken, karşı tarafın hangi yetenekleri desteklediğini EHLO yanıtında görür. Bu yeteneklerden biri 8BITMIME’dır. Karşı taraf 8BITMIME destekliyorsa, gönderici 8-bit gövdeyi (örneğin UTF-8 metin) 7-bit’e çevirmeden iletebilir.
8BITMIME yoksa ya da aradaki gateway “ben 8-bit taşımıyorum” diyorsa, gönderici genellikle gövdeyi 7-bit uyumlu hâle getirmek için MIME transfer encoding uygular. İşte bozulmaların önemli bir kısmı burada olur: bazı sistemler dönüşümü yanlış yapar, bazıları charset’i yanlış etiketler, bazıları da dönüşüm yapmadan 8-bit’i zorla geçirir ve yol üzerinde kırılma yaşanır.
Content-Transfer-Encoding: quoted-printable ve base64 ne işe yarar?
MIME dünyasında gövde verisini “taşınabilir” hâle getirmenin iki yaygın yolu vardır:
- quoted-printable: Metin ağırlıklı içerik için idealdir. ASCII karakterlerin büyük kısmı olduğu gibi kalır; 8-bit karakterler ve bazı özel baytlar =XX biçiminde kodlanır. Türkçe karakterli normal bir e-posta metninde genellikle en okunabilir ve verimli seçenektir.
- base64: İkili veriler (PDF, görsel) için çok uygundur. Metin için de kullanılabilir; ancak tüm içerik kodlandığı için insan gözüyle okunması zorlaşır ve bazı eski/yanlış yapılandırılmış sistemlerde satır katlama (line wrapping) hataları daha sık görülür.
Gövde bozulmalarında sık karşılaşılan senaryolar şunlardır: mesaj UTF-8’dir ama header’da charset yanlış yazılmıştır; quoted-printable uygulanmıştır ama satır sonları yanlış katlanmıştır; base64 uygulanmıştır ama alıcı tarafta yanlış çözülmüştür; ya da 8BITMIME desteklenmediği hâlde mesaj “8bit” olarak etiketlenip iletilmiştir.
En yaygın kök nedenler (ve nasıl ayırt edilir?)
1) Yanlış charset etiketi: UTF-8 içerik, ISO-8859-9 diye işaretlenmiş
Bu durumda aynı mesaj bazı istemcilerde “kısmen doğru” görünürken bazılarında tamamen bozulur. Çünkü istemcinin otomatik algılama davranışı farklı olabilir. Teşhis için e-posta header’ında Content-Type satırına bakılır: Content-Type: text/plain; charset=…. Mesaj gövdesi UTF-8 iken charset farklıysa bozulma kaçınılmazdır.
2) Transfer encoding yok veya hatalı: 8-bit veri 7-bit yolda kırılıyor
Eğer mesaj 8-bit karakterler içeriyor ama Content-Transfer-Encoding “7bit” ya da hiç yoksa, aradaki sistemler veriyi değiştirebilir. Bazı geçitler 8-bit’i “temizlemek” için karakterleri düşürür, bazıları soru işaretine çevirir.
3) Quoted-printable satır katlama hataları
Quoted-printable’da satır sonlarında “soft line break” için = işareti kullanılır. Bazı yanlış uygulamalar satır sonlarını hatalı ekler veya UTF-8 çok baytlı karakterin ortasında böler. Sonuç: özellikle uzun satırlarda Türkçe karakterler bozulur. Bu, “kısa mesajlarda sorun yok, uzun imza/şablonda bozuluyor” diye kendini gösterebilir.
4) HTML gövde ve yanlış meta/charset uyumsuzluğu
Mesaj Content-Type’ı text/html ve charset=utf-8 görünse bile, HTML içinde farklı bir meta etiketi (örneğin iso-8859-9) varsa bazı istemciler HTML meta’sını öncelikli kabul edebilir. Sonuç istemciye göre değişen bozulmalardır.
5) Şablon/uygulama tarafında yanlış kodlama
CRM, form, otomasyon veya özel bir uygulama e-posta üretirken metni aslında Windows-1254 olarak tutup “utf-8” diye etiketleyebilir (veya tam tersi). Bu tip sorunlar çoğu zaman sadece belirli bir kaynaktan gelen iletilerde görülür; insan kullanıcıların yazdığı normal e-postalar sorunsuzdur.
Pratik teşhis adımları: IT ekibi neye bakmalı?
1) Sorunu yeniden üret ve “ham kaynak” (raw) içeriği al
Bozuk gelen mesajın ham kaynağı olmadan kesin konuşmak zordur. Kullanıcıdan mesaj kaynağını (headers + body) paylaşmasını isteyin.
2) Header’larda üç satırı kontrol et
- Content-Type: text/plain mı text/html mı? charset ne?
- Content-Transfer-Encoding: quoted-printable mı base64 mü 8bit mi?
- MIME-Version: genellikle 1.0 olmalı; yoksa bazı istemciler farklı davranabilir.
3) Mesajın hangi aşamada değiştiğini bul
Gönderici uygulama mı, gönderici mail sunucusu mu, bir outbound relay/gateway mi, alıcı taraftaki antispam/AV mi, yoksa istemci mi dönüştürüyor? “Received:” header satırları ile mesajın geçtiği noktaları sıralayarak hangi hop’tan sonra bozulma ortaya çıkıyor anlaşılabilir.
4) İstemci farklarını test et
Aynı mesajı webmail, mobil ve masaüstü istemcide karşılaştırın. Eğer sadece bir istemcide bozuksa sorun o istemcinin kodlama yorumunda veya HTML meta/charset çakışmasında olabilir.
Doğru yapılandırma için önerilen yaklaşım
- Varsayılan charset olarak UTF-8 standardize edin. Şablonlar, imzalar ve otomasyon metinleri dahil.
- Text içeriklerde quoted-printable tercih edin. Metin ağırlıklı iletişimde hem uyumluluk hem okunabilirlik sağlar.
- HTML içerikte charset uyumunu koruyun: Content-Type charset ile HTML içindeki meta charset çelişmesin.
- Aradaki relay/gateway’leri en aza indirin veya her bileşenin 8BITMIME/MIME uyumlu çalıştığından emin olun.
- Şablon üreten uygulamaları kontrol edin: Uygulama katmanında string kodlaması, mail kütüphanesi ayarları ve çıktı header’ları tutarlı olmalı.
Sık yapılan hatalar: “Hızlı çözüm” diye sorunu büyütenler
Her şeyi base64 yapmak
Base64 metni her zaman “daha güvenli taşır” gibi düşünülse de, yanlış satır katlama uygulamaları ve bazı sistemlerdeki limitler nedeniyle sorunları gizleyip daha zor teşhis edilir hâle getirebilir. Metin için temel hedef doğru charset + doğru quoted-printable uygulamasıdır.
Charset’i rastgele değiştirmek
UTF-8 yerine “Türkçe charset” seçmek bazen geçici olarak bazı istemcilerde düzelmiş gibi görünür, ama global uyumluluk düşer. Modern e-posta ekosisteminde en sağlıklı ortak payda UTF-8’dir.
Bozulmayı kullanıcı hatası sanmak
Bu sorunların çoğu kullanıcıdan değil, sistemler arası dönüşüm ve yanlış etiketlemeden kaynaklanır. Kullanıcıya “farklı klavye dene” demek zaman kaybettirir.
Sonuç: Standartlaştırma ve izlenebilirlik bozulmaları bitirir
E-posta gövdesinde Türkçe karakter bozulması; çoğunlukla 7bit/8bit uyumsuzluğu, 8BITMIME desteği, yanlış charset etiketi veya hatalı quoted-printable/base64 dönüşümünden doğar. Kalıcı çözüm, mesaj üretim noktasından teslimata kadar MIME başlıklarının tutarlı olması ve her hop’ta aktarımın bozulmadan sürmesidir.
Kurumsal e-posta altyapınızı yönetirken, benzer karakter kodlama problemlerini hızlı teşhis edebilmek için ham mesaj inceleme ve log analizi süreçlerini standartlaştırmak faydalıdır. MX1Mail üzerinde e-posta akışıyla ilgili sorunları incelerken de aynı yöntemle (header + gövde + hop analizi) hangi aşamada dönüşüm yaşandığını tespit ederek kalıcı aksiyon planı oluşturabilirsiniz.