Türkçe karakterler neden “bozulur”?
Kurumsal e-postalarda en sık görülen şikayetlerden biri şudur: Konu satırı doğru yazılmıştır ama alıcıda “Ä°ÅŸ teklifiniz”, “=?UTF-8?B?…?=” gibi garip ifadeler görünür, bazen de tamamen “???“ olur. Benzer bozulmalar From/To görünen adlarında, otomatik bildirimlerde, imza satırlarında veya bazı sistemlerin eklediği özel header alanlarında da yaşanabilir.
Bu sorun çoğu zaman “kullanıcının klavyesi” veya “Outlook/Tarayıcı hatası” değildir. Kök neden genellikle e-posta ekosisteminde hâlâ bir arada çalışan farklı dönemlerin standartlarının, yanlış yapılandırmaların ve hatalı kodlama (encoding) varsayımlarının çakışmasıdır. E-postanın gövdesi (body) çoğu zaman UTF-8’dir ve doğru görünür; sorun daha çok konu satırı ve header alanlarında ortaya çıkar çünkü header’ların nasıl kodlanacağı ayrı kurallara tabidir.
Temel kavramlar: ASCII, UTF-8 ve iki farklı dünya
1) SMTP’nin tarihsel sınırlaması: 7-bit
SMTP uzun süre 7-bit ASCII odaklı tasarlandı. Bu, güvenli varsayımın “yalnızca İngilizce karakterler” olması demekti. Türkçe karakterler (Ç, Ş, İ, ğ vb.) ASCII dışıdır. Bu yüzden “8-bit veri” veya “UTF-8 adres/başlık” gibi ihtiyaçlar zamanla ek mekanizmalarla çözüldü.
2) UTF-8 içerik başka, header başka
E-postanın gövdesi genellikle MIME ile tanımlanır ve UTF-8 olarak taşınabilir. Ancak konu satırı (Subject) ve bazı header alanları uzun yıllar doğrudan “ham UTF-8” olarak yazılamazdı. Bunun yerine “encoded-word” denen MIME başlık kodlaması kullanılır: =?charset?encoding?encoded-text?= biçimiyle karakter seti ve kodlama açıkça belirtilir.
SMTPUTF8 ve 8BITMIME: Ne işe yararlar, neyi çözmezler?
SMTPUTF8 (EAI) nedir?
SMTPUTF8, e-posta adreslerinde ve SMTP oturumunda UTF-8 karakterleri desteklemeyi hedefleyen genişletmedir. Uluslararası karakterli e-posta adresleri (ör. ad.soyad@şirket.tld gibi) için kritik bir parçadır. Ancak pratikte şunu bilmek gerekir: SMTPUTF8 desteklemek, tek başına konu satırının her yerde sorunsuz görüneceği anlamına gelmez. Çünkü konu satırı bir header alanıdır ve header tarafında hâlâ MIME encoding kuralları devrededir. Ayrıca aradaki her MTA/MDA/antispam/archiver bileşeninin bu uzantıyı düzgün işlemesi gerekir.
8BITMIME nedir?
8BITMIME, mesaj gövdesinin (body) 8-bit içeriği bozmadan taşınabilmesini kolaylaştırır. Özellikle quoted-printable veya base64’e zorunlu dönüşüm ihtiyacını azaltabilir. Fakat 8BITMIME de “header sorunlarını” otomatik çözmez. Header’larda uygun RFC uyumlu kodlama yapılmıyorsa, alıcı sistemler ya yanlış yorumlar ya da olduğu gibi “kodlanmış” ifadeyi kullanıcıya gösterir.
Asıl kritik konu: MIME header encoding (Subject ve görünen adlar)
Subject satırı nasıl doğru kodlanır?
Subject bir header alanıdır ve ASCII dışı karakter içeriyorsa, doğru yöntem “encoded-word” kullanmaktır. İki yaygın yol vardır:
- Base64 (B): UTF-8 byte’larını base64’e çevirir. Uzun ve karmaşık başlıklarda sık kullanılır.
- Quoted-Printable (Q): Daha okunabilir olabilir; boşluk ve özel karakterler belirli biçimde kaçışlanır.
Önemli nokta şudur: Başlığı üreten uygulama (CRM, helpdesk, web uygulaması, yazıcı/cihaz, script) doğru header encoding yapmıyorsa, mail sunucusu her zaman bunu “sonradan düzeltemez”. Bazı geçitler (gateway) veya güvenlik katmanları “yeniden yazma” yapabilir ama bu riskli olabilir; çünkü yanlış müdahale imzaları (DKIM) bozabilir veya mesajın bütünlüğüne zarar verebilir.
From/To görünen adları neden bozulur?
“Görünen ad” kısmı (display name) da header’larda taşınır. Örneğin “Muhasebe Şefi” gibi bir ifade de ASCII dışı içerir ve aynı şekilde MIME encoded-word ile kodlanmalıdır. Bazı uygulamalar bunu atlar, bazıları yanlış charset yazar (ISO-8859-9 sanıp UTF-8 göndermek gibi), bazıları da iki kez kodlar (double-encoding). Sonuç alıcıda bozuk görüntüdür.
Tipik kök nedenler ve teşhis yaklaşımı
1) Yanlış charset beyanı
Mesaj UTF-8’dir ama header’da ISO-8859-1/9 yazıyordur (veya tersi). Alıcı “beyan edilen” charset’e göre çözdüğü için karakterler çorba olur.
2) Uygulama ham UTF-8 header yazıyordur
Bazı eski kütüphaneler, Subject’i doğrudan UTF-8 koyar ama encoded-word üretmez. Bazı alıcılar toleranslıdır, bazıları değildir; bir noktada bozulma kaçınılmaz hale gelir.
3) Ara sistem header’ı “temizler” veya yeniden biçimler
Antispam/AV, arşivleme, DLP, ticketing entegrasyonu gibi sistemler bazen header alanlarını normalize eder. Bu süreçte kodlama bozulabilir. Özellikle “folding” (satır bölme) kuralları yanlış uygulanırsa base64 blokları kırılabilir.
4) Double-encoding
Subject zaten =?UTF-8?B?…?= iken bir katman bunu tekrar kodlar. Alıcı bu sefer “kodlanmış metni” kodlanmış kabul eder ve kullanıcıya garip bir görünüm çıkar.
5) Test/otomasyon e-postalarında kötü pratik
Script’lerle SMTP üzerinden mail atan birçok otomasyon, header kodlamasını doğru yapmaz. “Ç” gibi karakterler çıplak halde header’a yazılır. Bu e-postalar bir ortamda doğru görünürken başka bir ortamda bozulabilir.
Sistematik kontrol listesi (IT ekipleri için)
Mesaj kaynağını belirleyin
- Bozuk görünen e-posta hangi sistemden çıkıyor? Kullanıcı istemcisi mi, web uygulaması mı, cihaz mı, CRM mi?
- Bozulma her alıcıda mı, belirli alıcılarda mı görülüyor?
Ham header incelemesi yapın
Bozuk bir örnek mesajın ham kaynağını açın. Özellikle Subject, From, To, Content-Type ve Content-Transfer-Encoding alanlarına bakın. Aradığınız işaretler:
- Subject satırında ASCII dışı karakter var mı ve encoded-word var mı?
- Content-Type içinde charset doğru mu (örn. UTF-8)?
- Subject birden fazla satıra bölünmüşse (folding) kurala uygun mu?
Gönderim kütüphanesi/uygulama ayarlarını düzeltin
Çoğu modern mail kütüphanesinde (uygulama tarafında) “UTF-8 header encoding” ayarı vardır. Hedef, Subject ve görünen adların otomatik olarak RFC uyumlu şekilde kodlanmasıdır. Burada yapılacak düzeltme, mail sunucusunda yapılacak geçici yamalardan genellikle daha kalıcı ve daha güvenlidir.
İçerik transfer kodlamasını doğru seçin
Gövde için quoted-printable/base64/8bit seçenekleri vardır. Büyük oranda kütüphane doğru seçim yapar. Ancak bazı sistemlerde 8bit gövde, aradaki eski bir geçitte sorun çıkarabilir; bu durumda quoted-printable daha uyumlu bir seçenek olabilir. Bu karar “tüm yol” (end-to-end) uyumlulukla verilmelidir.
Aradaki güvenlik katmanlarını gözden geçirin
Bir güvenlik gateway’i veya arşiv sistemi header’ları değiştiriyorsa, “header normalization” veya “MIME repair” benzeri özellikler dikkatle incelenmelidir. Düzeltmeye çalışırken daha fazla bozulmaya yol açabilir.
Kalıcı çözüm stratejisi: Standartlara yakın kalın
Pratikte en sağlıklı yaklaşım şudur: Header alanlarında ASCII dışı içerik üretilecekse, bunu mesajı üreten uygulama doğru şekilde MIME encoded-word ile kodlamalıdır. Gövdede UTF-8 ve uygun Content-Transfer-Encoding kullanılmalıdır. SMTPUTF8 ve 8BITMIME destekleri ise uçtan uca uyumluluğu artırır ama “yanlış header üreten uygulamayı” otomatik olarak düzeltmez.
Kurumsal ortamda önerilen test senaryoları
- Türkçe karakterli Subject (İ, ı, Ş, ş, Ğ, ğ, Ç, ç, Ö, ö, Ü, ü) içeren kısa ve uzun başlık testleri
- From görünen adında Türkçe karakter testleri
- Farklı alıcı sistemlere (harici domainler, farklı istemciler) gönderim
- İmza (DKIM) kullanılan ve kullanılmayan örneklerde karşılaştırma
- Güvenlik/antispam katmanı açıkken ve bypass testleri
Sonuç: Bozuk konu satırı “küçük” görünür, büyük sorunların habercisi olabilir
Konu satırı veya header bozulması, çoğu zaman sadece kullanıcı deneyimi problemi gibi algılanır. Oysa arka planda standarda aykırı header üretimi, yanlış charset beyanı veya ara sistemlerin MIME’ı hatalı yeniden yazması gibi daha geniş uyumluluk problemlerini işaret edebilir. Bu tip hatalar; bilet sistemlerinde hatalı eşleşme, arşivlemelerde yanlış indeksleme ve bazı durumlarda teslim edilebilirlik sorunlarına kadar uzanabilir.
MX1Mail gibi kurumsal e-posta altyapısı kullanan ekipler için en doğru yol, sorunu “sunucu her şeyi düzeltir” beklentisiyle değil; mesajı üreten kaynak uygulamayı RFC/MIME kurallarına uygun hale getirerek ve yol üzerindeki bileşenleri uyumluluk açısından kontrol ederek çözmektir. Böylece Türkçe karakterler yalnızca gövdede değil, konu satırında ve tüm header alanlarında da tutarlı görünür.