2. nesil e-posta üzerine açık bir değerlendirme

Note: Bu yazı yalnızca düşüncelerimi toparlama amacı taşıyor. Derinlemesine düşünülmüş değil ve bunu iyi bir fikir olarak görmeniz gerekmiyor. Beklentiyi mümkün olduğunca düşük tutarak okumanızı tavsiye ederim.

E-postanın sorunları

• Hâlâ kullanılan birçok eski teknoloji var, ancak e-posta her kullandığımda beni sinirlendiriyor.
• Kullanıcı açısından e-posta oldukça iyi çalışıyor. Bazen spam yüzünden çok fazla e-posta geliyor ama e-posta eski, güvenilir, anlaşılması kolay ve araması da görece kolay.
• Ancak e-postanın backend'i berbat durumda.

E-posta backend'inin sorunları

• Birçok e-posta özelliğinin net bir spesifikasyonu yok. Örneğin, yanıt gönderirken mesajın üstüne mi yoksa altına mı yazılacağı açık değil.
• E-postaya hangi HTML'in konabileceği net değil. Microsoft Outlook bazen Microsoft Word HTML renderer'ını kötüye kullanıyor.
• E-postanın nasıl şifreleneceği de net değil. OpenPGP diye bir şey icat edildi ama neredeyse hiç kullanılmadı ve büyük kusurları var.
• E-postanın gerçekliği her zaman doğrulanamadı. Bu yüzden SPF icat edildi ama SPF de tüm sorunları çözmedi. Sonra DKIM icat edildi ama DKIM de tüm sorunları çözmedi. Ardından DMARC icat edildi ama DKIM'in kendisinde büyük kusurlar olduğu için DMARC da aşılabiliyor.
• BIMI diye bir katman daha eklendi, ama bu da DMARC'a bağlı; DMARC DKIM'e bağlı ve DKIM'de kusurlar var.
• DMARC olsa bile kayıtların %68,2'si p=none olarak ayarlı. Bu da DMARC'ın pratikte varsayılan olarak hiçbir şey yapmadığı anlamına geliyor.
• Yukarıdakilerin hepsi ve agresif anti-spam politikaları nedeniyle self-hosted e-posta çok zor.
• Son olarak IP itibarı yönetimi var. Bazı IP adresleri diğerlerinden daha "temiz" kabul ediliyor. Özellikle SendGrid ya da AWS SES gibi paylaşımlı sistemlerde. Bu, toplu posta hesapları açmayı karmaşık hale getiriyor ve meşru e-postaların sık sık spam olarak sınıflandırılmasına yol açıyor.

2. nesil e-posta hipotezi

• Yeni bir DNS kaydı olan MX2 oluşturuluyor. E-posta servislerinin çoğunda MX2 ve MX kayıtları bulunuyor. Eski servislerde ise yalnızca MX var.
• 20 yıllık eski bir e-posta istemcisi mesaj göndermeye çalıştığında MX kaydını arayıp mesajı gönderiyor. Modern istemciler ise MX2'ye bakıp mesaj gönderiyor.
• MX2'yi uygulayan e-posta servisleri bir yayın tarihi duyuruyor ve o tarihten sonra MX kayıtlarına gönderilen tüm mesajları otomatik olarak spam olarak sınıflandırıyor.

2. nesil e-postanın öncelikleri

1. E-posta için standartlaştırılmış bir HTML spesifikasyonu ve uygunluk test paketi sağlanıyor.
2. E-posta zinciri tercihleri veya diğer e-posta ile ilgili tercihler için header sağlanıyor.
3. HTML görünümünün yanında yalnızca metinden oluşan, HTML olmayan bir kopya sağlanıyor.
4. Tüm MX2 kayıtları açık anahtar içermeli.
5. E-postanın gerçekliğini ve bütünlüğünü doğrulamak için bir hash üretilip şifrelenerek header'a ekleniyor.
6. SPF, DKIM ve DMARC kaldırılıp tek bir MX2 kaydı etrafında standartlaştırılarak self-hosted e-posta yığını sadeleştiriliyor.
7. E-posta doğrulaması IP adreslerine değil alan adlarına göre yapılıyor.
8. MX2'yi uygulayan istemciler, OpenPGP'nin yerini alabilecek yeni bir şifreleme şeması seçebiliyor.

Ek düşünceler

• Büyük dosyaları paylaşmanın bir yolu gerekli.
• Google ve Microsoft katılmazsa MX2 hiçbir zaman hayata geçmeyecek.
• SMTP'yi HTTP, standartlaştırılmış bir REST API ve JSON gövdesi ile değiştirmek de düşünülebilir.
• HTML kullanımı başlı başına tartışmalı olabilir. E-posta aslında HTML için tasarlanmadı.
• Yeni standardı katı biçimde uygulama fırsatı var.

GN⁺'ın görüşü

• E-posta sisteminin karmaşıklığını ve güvenlik sorunlarını çözmeye yönelik bu girişim oldukça ilgi çekici. Özellikle e-postanın gerçekliğini ve bütünlüğünü garanti edecek yeni bir yöntem önermesi faydalı olabilir.
• Ancak yeni bir standardı devreye almak çok zor. Özellikle Google ve Microsoft gibi büyük oyuncuların katılımı şart.
• HTML kullanımına dair tartışma hâlâ sürüyor. Güvenlik sorunlarını çözmek için başka bir işaretleme dili düşünmek gerekebilir.
• Yeni standardı katı biçimde uygulamak ideal olsa da pratikte zor olabilir. Standardın kaymasını ve uygulama hatalarını önlemek için ek mekanizmalara ihtiyaç var.
• E-posta sisteminin merkezileşmesi yeni bir standardın benimsenmesine yardımcı olabilir, ancak aynı zamanda belirli şirketlere bağımlılığı artırabilir.

[cometkim]

En azından render tarafındaki iyileştirmeler konusunda Google ve Microsoft zaten yatırım yaptı... çünkü ikisi de AMP Email projesine katıldı ve onu destekledi.

[coremaker]

JSON gibi veri standartları oluşturmak iyi ama,
rendering spesifikasyonunun da birlikte tartışılması gerektiği için kolay olmayacak gibi görünüyor.

HTML'in seçilmesinin nedeni de
HTML+CSS rendering spesifikasyonuna bedavadan eklemlenmek değil miydi?

[ldmsys]

Yukarıda bazıları zaten uç örnek olarak ShopMail’den bahsetmiş. Kişisel olarak, hâlihazırda gayet iyi çalışan bir protokolü açıkça deprecated olarak sınıflandırıp yalnızca onunla uyumlu olmayan yeni bir protokol standardıyla uyumlu sistemler üretme fikrine oldukça şüpheyle yaklaşıyorum.

[unsure4000]

4. Tüm MX2 kayıtları bir açık anahtar içermeli.
   Bu bana biraz tuhaf geliyor; hizmet sağlayıcıları bu açık anahtarı kullanıcının gönderdiği açık anahtar yerine, sanki kendilerinin oluşturduğu açık anahtar yapacakmış gibi görünüyor...

[iolothebard]

Bu yüzden biz de Ssappmail'i yaptık… (Ha? Yok, o değil…)

[xguru]

E-posta sistemi kullanışlı ve iyi, ama gerçekten de protokolde kademeli iyileştirmelere ihtiyaç olduğunu düşündürüyor.
Önümüzdeki birkaç on yıl sonra da bu yöntemi kullanmak biraz...

[GN⁺]

Hacker News görüşü

Hacker News yorumları özeti

• E-posta sisteminin karmaşıklığı ve birlikte çalışabilirliği

  • İnternet e-posta hizmeti işletme deneyimine dayanarak, e-posta sistemi karmaşıktır ancak evrensel olarak benimsenmiş ve birlikte çalışabilirliği yüksektir.
  • Yeni bir sistemin devreye alınması, mevcut sistemin devasa Ar-Ge yatırımıyla rekabet etme zorluğunu taşır.
  • Yeni bir e-posta sistemi önermek istiyorsanız, bunu IETF veya M3AAWG gibi yerlerde önermek daha uygun olur.

• E-postanın belirsizlikleri ve sorunları

  • E-posta başlıklarındaki yinelenen veya birbiriyle çelişen değerler kafa karışıklığına yol açabilir.
  • Yalnızca ASCII kullanılması gereken başlıklara 8 bit değerlerin dahil edilmesi gibi çeşitli sorunlar vardır.
  • E-posta ileti dizilerinin yönetim biçimi de standartlaşmış değildir ve sorunlara neden olur.

• E-postada merkezileşme sorunu

  • E-postanın merkezileşmesi arzu edilir bir şey değildir. Şirketler, insanlık için en iyiden ziyade kendileri için avantajlı olan yönde hareket etmeye eğilimlidir.
  • Kendi barındırdığınız e-posta zor değildir; güvenilir bir sağlayıcı üzerinden de kolayca barındırılabilir.

• HTML e-postanın sorunları

  • HTML e-posta, phishing, dolandırıcılık gibi sorunlara yol açabilir.
  • E-posta yeniden tasarlanacaksa HTML dışarıda bırakılmalı ve Markdown benzeri bir biçim kullanılmalıdır görüşü öne çıkıyor.

• E-postanın asenkron yapısının korunması gereği

  • E-posta asenkron kalmalıdır; bu, 24 saat çalışmayı engelleyen son teknik savunma hattıdır.
  • İnsanların daha iyi bir sistemi benimsememesinin nedeninin bu olduğu belirtiliyor.

• E-posta sunucusu işletmenin zorlukları

  • E-posta sunucusu işletmek giderek zorlaşıyor. Bunun nedeni, büyük sağlayıcıların gereksinimlerini karşılamak zorunda olunması.
  • Küçük sunucular, büyük sağlayıcılar veya spam gönderenler tarafından sistem dışına itiliyor.

• Meşru e-postanın tanımı

  • Meşru e-postanın tanımı özneldir. Spam interneti bozuyor ve bunu engellemek için maliyet yükleyen bir yönteme ihtiyaç var.

• E-posta sisteminin iyileştirilmesi gereği

  • E-posta sistemi yeniden tasarlansa bile, mevcut e-posta sistemini koruyarak iyileştirmek daha tercih edilir.
  • Modern şifreleme sistemlerinin ve gönderici doğrulama sisteminin devreye alınması gerekir.

• Spam önleme kontrol listesi

  • Spam önlemek için bazı uygulama düzeltmeleri gereklidir.
  • Mail forwarder ve SMTP sunucuları iletmeyi mümkün olduğunca hızlı yapmalı, spam filtreleme ise SMTP düzeyinde reddetme yoluyla gerçekleştirilmelidir.

Spam önleme fikri kontrol listesi