Bu eşittir (=) işaretleri de ne böyle?

 (lars.ingebrigtsen.no)
3 puan yazan GN⁺ 2026-02-04 | 1 yorum | WhatsApp'ta paylaş
  • Kısa süre önce Twitter’da eski e-posta alıntıları yayılırken, cümle sonlarında görülen eşittir (=) işaretlerinin neden ortaya çıktığına dair sorular gündeme geldi
  • Bu işaret, ‘quoted-printable’ kodlama sürecinde oluşur ve uzun satırlar zorla bölündüğünde satırın devam ettiğini göstermek için kullanılır
  • E-posta iletiminde satır sonu olarak CRLF (carriage return + line feed) kullanılır; bu yapı Unix’in NL biçimine dönüştürülürken çözme algoritması yanlış çalışırsa eşittir işaretleri kalabilir ya da karakter kaybı yaşanabilir
  • Eşittir işareti yalnızca satır sonları için değil, ASCII dışı karakterleri (ör. =C2=A0) göstermek için de kullanılır; hatalı çözücüler bunu basit bir ikame olarak ele alıp hataya yol açar
  • Sorunun kaynağı, hatalı çözme mantığı ve uygunsuz dönüştürme işlemleri olup, e-postayı işleyen kişinin teknik olarak yetersiz olduğunu gösterir

E-posta alıntılarındaki eşittir (=) işaretinin aslı

  • Son birkaç gündür Twitter’da çok sayıda eski e-posta alıntısı paylaşılırken, cümle sonlarındaki eşittir işaretleri dikkat çekti

    • Yazar, bunun kod ya da OCR (optik karakter tanıma) hatası olduğu yönündeki iddialara karşı çıkıyor
    • Gerçekte bu durum, e-postayı daha okunur hale getirme sürecinde ortaya çıkan bir kodlama işleme hatası

  • E-postalar geçmişte yalın metinden ibaretti; ancak uzun satırları ve özel karakterleri işlemek için ‘quoted-printable’ kodlama kullanılmaya başlandı

    • Uzun satırlar bölünürken satır sonuna eşittir (=) eklenerek “bu satır devam ediyor” anlamı verilir
    • Bu durumda eşittir işaretini CRLF (carriage return + line feed) izler

Satır sonu kodlaması ve çözme hataları

  • E-posta sunucuları standart olarak CRLF satır sonunu kullanır, ancak Unix sistemleri yalnızca NL kullanır

    • Dönüştürme sürecinde bir bayt eksilir; çözücü bunu yanlış ele alırsa eşittir işareti kalabilir ya da karakterler kaybolabilir
    • Örneğin “non- =CRLF cloven” yanlış işlendiğinde, “non- loven” gibi c harfi kaybolabilir

  • Bazı uygulamalar satır sonundaki eşittir işaretini gördüğünde iki karakteri silerek işlem yapar

    • Bu algoritma Unix biçimli dosyalarda hatalı çalıştığı için eşittir işaretinin olduğu gibi kalması gibi bir sonuç doğar

Eşittir işaretinin bir başka kullanımı: ASCII dışı karakter kodlaması

  • Eşittir işareti, satır sonlarının dışında ASCII dışı karakter kodlamasında da kullanılır

    • Örneğin =C2=A0, non-breaking space (satır sonu olmayan boşluk) anlamına gelir
    • E-posta gövdesinde girinti veya özel karakter gösteriminde sıkça görülür

  • Yazar, bazı dönüştürücülerin =C2, =A0 gibi dizileri yalnızca basit bir arama-değiştirme ile işlediğini ve doğru bir çözücü kullanmadığını tahmin ediyor

Teknik arka plan ve standart

  • RFC 2045 standardı, quoted-printable kodlamayı iletim (transport) amaçlı olarak tanımlar

    • Alındıktan sonra çözülüp temiz metin olarak saklanması esastır
    • Ancak pratikte bu adım atlandığı için satır sonu işleme hataları sık görülür

  • Örnek kodda (quoted-printable-decode-string "he=\nllo") ifadesi normal biçimde "hello" sonucunu verir

    • Bunun nedeni, SMTP sunucusu bağlamında CRLF varsayan algoritmanın yeniden kullanılmış olmasıdır
    • Windows tabanlı dosyalarda doğru çalışsa da Unix tabanlı ortamlarda başarısız olur

Sonuç

  • E-posta alıntılarındaki eşittir işaretleri, quoted-printable kodlamanın kalıntısıdır ve
    satır sonu işleme ile ASCII dışı karakter çözümlemesindeki kusurların birleşik sonucudur
  • Sorunun temel nedeni, hatalı çözücü uygulaması ve kodlama dönüştürme yanlışlarıdır
  • Yazar bunu “teknik bir sorun ve hatalı işlemenin sonucu” olarak özetlerken,
    e-posta dönüştürme sürecinde standartlara titizlikle uyulması gerektiğini vurguluyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-04
Hacker News görüşleri

  • Bu yazının baş kahramanı, Emacs’in e-posta/Usenet okuyucu paketi Gnus’un kılavuzunu yazan Lars Ingebrigtsen. Kılavuzu hem nükteli hem bilgilendirici ve e-posta ayrıştırma konusunda çoğu insandan çok daha derin bir anlayışa sahip. Kılavuza buradan bakılabilir, başka bir sürümü de bu bağlantıda yer alıyor.

    • O yalnızca kılavuzun yazarı değil, Gnus’un geliştiricilerinden de biri. Oslo Üniversitesi’nde (UiO) onun Gnus’u ilk yaptığı dönemi hatırlıyorum. Biz bilgisayar bilimi öğrencileri arasında küçük bir yıldız geliştiriciydi ve herkes Emacs ile Gnus kullanıyordu.

  • Bu olay, “tehlikeli derecede bilgili biri”nin tipik bir örneği. E-postanın basit metin olmadığını biliyordu ama quoted-printable çözmeyi basit bir değiştirme işlemi gibi ele almamanız gerektiğini bilmiyordu. Bu, HTML’i doğrudan regex ile ayrıştıran hatalarla aynı türden; başta çalışıyor gibi görünüyor, sonra da kongre delillerinde bir sürü ‘=’ işareti kalıyor.

    • Bununla ilgili ünlü Stack Overflow yanıtını paylaşıyor. HTML’in neden regex ile ayrıştırılmaması gerektiğini mizahi bir dille anlatıyor.
    • Çıktı genel olarak okunabilir olduğu için kimse sorunu fark etmiyor; ancak yıllar sonra kongreye delil olarak sunulunca ortaya çıkıyor.
    • Sonunda da “şu anda en iyi beyinler bunun üzerinde çalışıyor” esprisiyle bitiriyor.

  • “Mail sunucuları neden uzun satırlardan hoşlanmıyor?” diye bir soru vardı.

    • SMTP, satır tabanlı bir protokol olduğu için mesaj gövdesi de satır satır iletilir. Sunucu başlıkları ayrıştırmak zorunda olduğundan bunu basit bir ikili blob gibi ele alamaz. IMAP’te sunucunun tam ayrıştırma yapması gerekir, POP3 ise tek cihaz dönemi için tasarlanmıştır ve bugün artık pek uygun değildir.
    • Eskiden e-posta satırlar hâlinde, sabit uzunluklu tamponlarla işlenirdi. RFC 821 satır uzunluğunu en fazla 1000 baytla sınırlandırıyordu ve uyumluluk için 80 karakterin altında bölmek yaygındı. Bu yüzden Base64 kodlaması da her 76 karakterde bir satır sonu ekler.
    • SMTP tasarlandığında bellek son derece kısıtlıydı. Örneğin PDP-11 yaklaşık 512KB, VAX-11 ise yaklaşık 2MB belleğe sahipti ve programcılar belleği bayt bayt hesaplıyordu.
    • SMTP komut akışını doğrudan göstererek HELO, MAIL FROM, RCPT TO, DATA gibi komutlarla çalışan yapıyı açıklıyor.
    • 1980’lerdeki üniversite ağı BITNET’ten de söz edip o dönemde de satır uzunluğu sınırları olduğunu hatırlatıyor. İlgili belgeler IBM resmî dokümantasyonunda ve Wikipedia’da görülebilir.

  • İlk başta bu yazının = == === .=. <== ==> <<== ==>> (==) => =~= gibi operatör anlamları hakkında olacağını sanmıştım.

    • “Bu karıncalar için Haskell mi?” diye bir şaka yapılmış.
    • Ama asıl içeriğin çok daha ilginç olduğu söyleniyor.

  • Ben de kişisel olarak kendi e-posta arşivleme yazılımımı yazdım. 20 yılı aşkın birikmiş .eml dosyalarındaki uç durumları ele almak en zor kısımdı. Kavram basit görünse de e-posta şaşırtıcı derecede karmaşık.

    • E-posta standartları sıfırdan temizce tasarlanmadı; mevcut sistemlerin zorla birbirine eklenmesiyle oluşmuş lanetli bir standart. E-posta adresi geçerliliğini doğrulamak da pratikte neredeyse imkânsız.
    • Konsol tabanlı bir posta istemcisi yaptım; bunun %25’i C++, %75’i ise arayüz ve işlem mantığını tanımlayan Lua idi. Birkaç yıl boyunca az sayıda kullanıcısı oldu ama en büyük acı MIME işleme kısmıydı.

  • Bana ilginç gelen, ‘=’ işaretinin kendisinden çok onun çevresindeki karakterlerin kaybolması oldu. Bu, bir off-by-one hatası gibi; sanki ‘=’ silineceğine gerçek metnin bir kısmı silinmiş. Muhtemelen CRLF/LF dönüşümüyle ilgili olabilir.

    • Asıl makale bunun nedenini tam olarak açıklıyor.
    • Böylece delillerde karakterlerin kaybolduğu gizemli bir durum ortaya çıkıyor.

  • Bu sorunun neden şimdi ortaya çıktığını merak etmiştim. Son birkaç gündür insanlar eski e-postaları Twitter’da paylaşıyor; nedenini merak ettim.

    • Muhtemelen Epstein ile ilgili e-postaların açıklanması yüzündendir deniyor.
    • Gerçekten de DOJ’un Epstein e-postalarından ek yayın yaptığı söyleniyor.

  • Bazı kişiler, sorunun kaynağının Gmail değil arada dönüşüm yapan bir sunucu olabileceğini öne sürüyor. CRLF→LF dönüşümüne ek olarak quoted-printable iki kez uygulanırsa ‘=’ işaretleri kalabilir; yani işin içinde iki posta sunucusu olmuş olabilir.

    • Bazı PDF’lerde Apple Mail.app’in plist metadata’sı görünüyor; bu da verinin iç formatından çıkarılmış olabileceğini düşündürüyor.
    • Hukuki delil toplama sürecinde bu tür şeyler sık yaşanıyor. Gerçekte çoğu zaman uzman olmayan bir stajyer basit araçlarla veriyi topluyor, veri birkaç kez dönüştürülüyor ve format bozuluyor. Orijinal veri çoktan yok edilmiş oluyor ve geriye sadece biçimi kalmış parçalı veri kalıyor.
    • Bazen bu sorun e-postalar MS Outlook’un PST dosyasına içe aktarılırken ortaya çıkıyor.
    • Bu, tek bir Gmail dökümünden ziyade, birkaç sistemin “yardım ederken” veriyi değiştirip bozduğu bir çıktı gibi görünüyor.
    • Bunun en ikna edici açıklama olduğu görüşü de vardı.

  • archive.today üzerindeki makale de aynı quoted-printable bozulması sorununu gösteriyor. İlgili bağlantılar pastes.io/correspond ve HN başlığı.

  • Outlook’tan indirilen e-postaları görüntülerken quoted-printable’ı otomatik çözen bir .eml görüntüleyicisi olsa iyi olurdu.