Avrupa'nın büyük ödeme işleyicilerinden biri, Google Workspace kullanıcılarına e-posta gönderemiyor

• Avrupa'nın büyük ödeme şirketlerinden Viva.com, doğrulama e-postalarını Message-ID başlığı olmadan gönderdiği için Google Workspace sunucuları bunları reddediyor
• RFC 5322'de (2008'de yayımlandı) Message-ID, zorunluya yakın bir başlık olarak tanımlanıyor ve Google bunu katı biçimde uyguluyor
• E-postalar kişisel Gmail adreslerine ulaşıyor; bu da Google Workspace ile Gmail arasındaki işleme farkını ortaya koyuyor
• Viva.com müşteri desteği teknik sorunu kabul etmiyor, yalnızca kullanıcının yaptığı geçici çözümün sonucunu doğrulayan profesyonellikten uzak bir yanıt veriyor
• En temel RFC uyumunun bile sağlanamadığı bu örnek, Avrupa fintech altyapısında kalite ve rekabet gücü sorununu gözler önüne seriyor

---

Doğrulama e-postasının ulaşmaması sorunu

• Viva.com hesap oluşturma sürecinde doğrulama e-postası hiç ulaşmadı
  • Google Workspace tabanlı özel alan adlı bir e-posta kullanıldı ve spam klasöründe de e-posta yoktu
• Google Workspace'in Email Log Search sonucunda durum “Bounced” olarak göründü
  • Geri dönüş nedeni: “Messages missing a valid Message-ID header are not accepted”
  • Google, RFC 5322 ihlali nedeniyle e-postayı reddetti
• Viva.com'un gönderdiği e-postada Message-ID başlığı eksikti; bu ise 2008'den beri zorunlu olarak istenen bir alan

Geçici çözüm

• Kişisel bir @gmail.com adresine geçildiğinde doğrulama e-postası normal şekilde alındı
  • Gmail'in alım altyapısının daha esnek davrandığı veya farklı bir yoldan işlediği anlaşılıyor
• Ancak iş amaçlı bir ödeme platformuna kayıt olmak için kişisel e-posta kullanmak zorunda kalınması başlı başına bir sorun olarak gösteriliyor

Müşteri desteğinin yanıtı

• Viva.com müşteri desteğine Google Workspace günlük ekran görüntüsü ve sorun açıklaması iletildi
• Destek ekibi, “Hesabınızda zaten doğrulanmış bir e-posta var, dolayısıyla sorun yok” diye yanıt verdi
  • Teknik sorunun farkına varıldığına veya bunun mühendislik ekibine iletildiğine dair bir işaret yoktu
  • Kullanıcının bizzat uyguladığı geçici çözümün sonucunu sorunsuzluk olarak değerlendiren bir yaklaşımdı

Sorunun özü

• Message-ID, tüm e-posta sistemlerinin varsayılan olarak ürettiği temel bir başlıktır
  • Bunun eksik olması, e-posta hattının ciddi biçimde yanlış yapılandırılmış olması gerektiğini gösterir
• RFC 5322, Message-ID için “SHOULD” ifadesini kullanıyor; ancak Google bunu fiilen zorunlu (MUST) olarak ele alıyor
• Viva.com buna uymadığı için e-postalar Google Workspace kullanıcılarına ulaşmıyor
• Avrupa genelinde ödeme işleyen bir şirketin temel RFC kurallarına uymaması, teknik güvenilirlik konusunda soru işaretleri yaratıyor

Avrupa fintech altyapısındaki yapısal sorun

• Avrupa'nın kurumsal API ve hizmetlerinde eksik dokümantasyon, yetersiz hata işleme ve profesyonellikten uzak destek tekrar tekrar görülüyor
• Bunun mühendislerin yetkinliğiyle değil, piyasadaki rekabet eksikliği ve önceliklendirme sorunlarıyla ilgili olduğu belirtiliyor
• Stripe geliştirici deneyimi için yüksek bir çıta koydu, ancak Avrupa bölgesel ödeme ağlarını (ör. IRIS) tam olarak desteklemiyor; bu yüzden alternatifler sınırlı
• Stripe düzeyinde bir rakip ortaya çıkmadıkça, bu tür kalite sorunlarının sürmesi muhtemel görünüyor

Önerilen teknik düzeltme

• Viva.com, gönderilen e-postalara Message-ID başlığını eklemeli
  • Örnek: Message-ID: <[e-mail]>
  • Çoğu e-posta kütüphanesi bunu otomatik üretir ve tek satırlık bir değişiklikle çözülebilir
• Google Workspace kullanıcılarının doğrulama e-postalarını normal şekilde alabilmesi için acil düzeltme gerekiyor

RFC terimlerinin ayrımı ve Google'ın politikası

• RFC 2119'a göre
  • MUST: mutlak gereklilik
  • SHOULD: yalnızca özel bir gerekçe varsa atlanabilir
  • MAY: tamamen isteğe bağlı
• Message-ID'nin SHOULD olmasının nedeni, bazı istemcilerin bunu sunucuya bırakabilmesidir
• Google, spam'i önlemek için bunu zorlayıcı bir gereklilik olarak uyguluyor ve RFC'nin ötesinde fiili bir standart rolü üstleniyor
• Viva.com bunu bilinçli olarak dışarıda bıraktıysa, en azından “Google Workspace ile uyumlu değil” uyarısı vermesi gerekir
  • Hiçbir yönlendirme olmadan hizmeti işletmek, SHOULD ifadesinin ruhuna da aykırı

[GN⁺]

Hacker News görüşleri

• Sorunun, Viva.com’un doğrulama e-postalarında Message-ID başlığı bulunmaması olduğu belirtiliyor
  RFC 5322’nin 3.6. bölümü’ne göre “every message SHOULD have a Message-ID field” deniyor; ancak SHOULD, MUST olmadığı için bunun gerçekten bir “gereklilik” sayılıp sayılamayacağı sorgulanıyor

  • SHOULD ifadesinin fiilen zorunlu bir gereklilik olduğu açıklanıyor
    Özel bir gerekçe olmadıkça buna uyulması gerektiği, sadece “üşenmek”in istisna sayılamayacağı söyleniyor
    Geçmişte MUA, Message-ID olmadan posta gönderirse sunucunun bunu otomatik eklediği için SHOULD olarak yazıldığı belirtiliyor
    Bununla ilgili açıklama RFC 6409 bölüm 8.3’te yer alıyor
  • RFC2119’a göre SHOULD, “belirli durumlarda göz ardı edilebilir, ancak bunun sonuçları tam olarak anlaşılmalı ve dikkatle değerlendirilmelidir” anlamına geliyor
    Google’ın bunu nasıl yorumladığının bilinmediği söyleniyor
  • Bir barındırma şirketinde postmaster olarak çalışan biri, gerçek üretim ortamında Message-ID’nin kesinlikle gerekli olduğunu vurguluyor
    Test e-postaları bir yana, canlı servis postalarında bunun olmaması spam filtreleme gibi konularda sorun çıkarıyor
    Message-ID’nin olmaması genelde özensiz bir özel gönderim sisteminin işareti olarak görülüyor
  • Message-ID zorunlu değil ama Amazon SES gibi mevcut Message-ID’yi ezip geçen servislerin de sinir bozucu olduğu söyleniyor
  • Teknik olarak olmadan da olabilir, ancak normal bir e-posta olarak sınıflandırılmak için fiilen gerekli olduğu düşünülüyor
    Özellikle bir ödeme servisinin Google Workspace gibi büyük bir e-posta hizmetinde bunu hiç test etmemiş olması saçma bulunuyor

• Bir ESP’de (Email Service Provider) çalışmış biri, sunucu yazılımlarının çoğunun Message-ID’siz postaları reddettiğini söylüyor
  Google gibi büyük alıcılardan gelen bounce mesajlarını görmezden gelmenin hayal bile edilemeyeceği belirtiliyor

  • Pratikte standartlardan çok kullanıcı sorunlarını önlemenin daha önemli olduğu söyleniyor
    Karşı tarafın sistemi mantıksız olsa bile, kullanıcı mağduriyetini önlemek için uyum sağlamak daha iyi görülüyor
  • Google Workspace’e posta göndermek istiyorsan Message-ID fiilen bir MUST sayılıyor
    Bunu eklemek istemiyorsan “Google Workspace kullanıcılarına hizmet verilemez” diye açıkça belirtilmesi gerektiği savunuluyor
  • Ancak çoğu şirketin bu tür teknik ayrıntılarla ilgilenmediği, “yeter ki hızlıca çalışsın” yaklaşımında olduğu söyleniyor
    Hem Viva’nın hem de Google’ın çok büyük olduğu ve bazı müşterilerin sorunlarını umursamadıkları düşünülüyor
  • Avrupa merkezli şirketler ağırlıklı olduğu için Google Workspace kullanım oranının o kadar yüksek olmayabileceği de belirtiliyor

• E-postaların text/plain alternatif bölümünü berbat gönderen servislerden de şikâyet ediliyor
  Bağlantıların çıkarıldığı metin sürümleri ya da sadece “bu bir plain text e-postadır” gibi işe yaramaz içerikler gönderen örnekler veriliyor

  • Bildirimde sadece “şirin bir cümle” gösteren plain text sürümlerinin en sinir bozucu olanı olduğu söyleniyor
    E-posta istemcisinin HTML’yi yapay zekayla özetlemesi gerektiğine dair şaka da yapılıyor
  • Bir servis, plain text bölümüne başka müşterilerin rezervasyon bilgilerini ekleyip göndermiş (Avis örneği)
  • HTML’yi Lynx tarayıcısıyla döküp text/plain oluşturan bir uygulama görüldüğü, bunun gerçekten değerli olup olmadığının merak edildiği söyleniyor
  • text/plain kısmına doğrudan HTML kaynağı ya da CSS koyan örnekler de görüldüğü belirtiliyor

• Finans kuruluşlarının teknik yetersizliği ile dalga geçen yorumlar da var
  “Major European Payment Processor” ifadesinin aslında “Major European Incompetence Center” olduğu söyleniyor

  • Başka bir kullanıcı bunun abartı gibi dursa da finans kurumlarının güvenlik seviyesinin gerçekten korkunç olduğunu anlatıyor
    Örneğin Harland Financial Systems’ın 2 baytlık XOR şifreleme kullandığı ve anahtarı bağlantının başında düz metin olarak gönderdiği söyleniyor
  • Bir başka kullanıcı da ABD’deki finans kurumlarının yolsuzluk örneklerine (hatalı onaylar, izinsiz hesap açılışları vb.) değinip Avrupa’da da benzer olup olmadığını soruyor

• Gmail’den Fastmail’e geçen bir kullanıcı, Google’ın katı spam filtrelemesine bir ölçüde hak veriyor
  Fastmail’de daha fazla spam ve phishing e-postası geldiği söyleniyor

  • Başka bir kullanıcı, Message-ID’nin otomatik e-postalarda fiili sektör standardı olduğunu ve Google’ın bu konuda aşırıya kaçmadığını söylüyor
    Startup’ların varsayılan şablonları aynen kullanıp phishing sanıldığı durumlar olduğu belirtiliyor
  • Fastmail’in spam filtresinin zamanla öğrenip iyileştiği tavsiye ediliyor
  • Uzun süreli bir Fastmail kullanıcısı, bazen spam sızsa da yalnızca LinkedIn e-postalarının sürekli geçtiği şeklinde şaka yapıyor
  • Fastmail’in dönem dönem spam’e karşı yavaş kaldığı ama genel olarak memnuniyet verdiği söyleniyor

• RFC açısından Viva.com’un hatalı olduğu, ancak Google’ın da SHOULD maddesine dayanarak postayı reddetmesinin uygun olmadığı görüşü de var
  Yine de yüksek spam ihtimali varsa bunun spam klasörüne atılması gerektiği, doğrudan reddin fazla olduğu söyleniyor

  • Müşteri destek ekiplerinin sorunu teknik ekibe iletmek yerine biçimsel yanıtları tekrarlaması eleştiriliyor
  • Destek çalışanlarının sorunu kabul etmeleri halinde performans değerlendirmelerinde zarar görebilecekleri için böyle davrandıklarına dair içeriden bir deneyim de paylaşılıyor
  • E-posta standartlarının pratikte kusursuz işlemediği ve bütün kuralların aslında “SHOULD” seviyesinde olduğu yönünde alaycı bir yorum da var

• En ciddi sorunun, Viva.com’un Google Workspace’e e-posta gönderme sorununu hiç test etmemiş olması olduğu belirtiliyor

  • Kullanıcı kayıtlarının başarısız olması üzerinden fiilen “canlı test” yapıldığı şeklinde alay ediliyor
    Sorunun Google tarafındaki bir değişiklikten kaynaklanmış olabileceği, ama izleme eksikliğinin daha büyük problem olduğu söyleniyor
  • Buna karşılık “dünyadaki her şirket Google Workspace kullanmıyor ki” şeklinde bir itiraz da geliyor

• Viva.com’un bu sorunun ne kadar zamandır farkında olmadığının merak edildiği söyleniyor
  Normal bir posta yazılımı kullanılsaydı bunun yaşanmayacağı, bir yanlış yapılandırma olasılığı bulunduğu belirtiliyor
  SHOULD’un MAY anlamına gelmediği ve bunu uygulamayanların sonuçlarına katlanması gerektiği söyleniyor
  Google’ın hata mesajında sebebi belirtmiş olmasının ise en azından iyi olduğu düşünülüyor

• Message-ID’nin aslında Usenet’ten gelen zorunlu bir alan olduğu,
  e-postada threading, yanıt ve arşivleme için gerekli olduğu açıklanıyor
  Message-ID olmamasının “yanıt da istemiyorum, kayıt da kalmasın” anlamına geldiği ve bu yüzden şüpheli bir davranış gibi göründüğü söyleniyor

• Avrupa şirketlerinin API kalitesini eleştiren asıl gönderiye karşılık,
  bunun bölgesel değil dünya genelindeki startup’lar ve finans kurumlarında görülen ortak bir örüntü olduğu söyleniyor
  Büyük şirketlerin API’yi ya yan iş olarak gördüğü ya da regülasyon gereği isteksizce işlettiği belirtiliyor
  Buna karşılık Stripe gibi şirketlerde API’nin işin can damarı olduğu için kalitenin yüksek olduğu söyleniyor
  Startup’ların ise kaynak yetersizliği nedeniyle “kullanımı güzel API” yerine “çalışan API” üretmeye öncelik vermek zorunda kaldığı ekleniyor