Acil tıp literatüründe "Cafe Coronary" (Restoran Koroneri) olarak bilinen çok çarpıcı ve ölümcül bir vaka vardır. Lokantada yemek yiyen bir kişi, iyi çiğnemediği koca bir biftek parçasını tek hamlede yutmaya kalkar. O devasa et parçası yemek borusunun (özofagus) üst kısmında takılır, esnekliğini kaybeden doku kilitlenir ve hemen önündeki nefes borusuna (trakea) dışarıdan şiddetli bir mekanik bası uygular. Hasta bir anda nefessiz kalır, morarır, ellerini boğazına götürür. Masadakiler hastanın kalp krizi geçirdiğini zannedip panikler; oysa sorun kalpte değil, insan anatomisinin taşıma kapasitesini aşan şuursuz bir lokmanın hava yolunu tıkamasında yatar. Heimlich manevrası yapılmaz veya acil laringoskopiyle o lokma çıkarılmazsa hasta dakikalar içinde asfiksiden hayatını kaybeder.

İnternet protokolleri ve kurumsal e-posta altyapılarında da sistem yöneticilerinin boğazını sıkan en yaygın ve inatçı sendrom, tam olarak bu dijital restoran koroneridir: 50 megabaytlık bir PDF dosyasını SMTP protokolünün boğazından geçirmeye çalışmak.

Cuma Akşamı 17:45: İhale Dosyası Gönderilemiyor

Cuma akşamı mesai bitimine on beş dakika kala destek merkezinin telefonu acı acı çalar. Hattın diğer ucunda tanınmış bir mimarlık veya inşaat firmasının proje müdürü vardır. Sesindeki stres seviyesi tansiyonu 200'e fırlatacak düzeydedir:

"Kardeşim siz ne biçim bir hosting şirketisiniz! Yarım saattir belediyenin ihale komisyonuna mimari projeyi ve şartnameyi gönderemiyorum! Outlook 'Gönder/Al Hatası' verip duruyor. İhale saat 18:00'de kapanıyor, 10 milyon liralık işimiz yanacak sizin yüzünüzden! Sunucunuzun mail motoru bozuk, derhal düzeltin şunu!"

Destek mühendisi hemen SMTP giden posta loglarını (Exim / Postfix) canlı olarak izlemeye (tail -f) alır:

2026-03-29 17:42:11 H=mail-client.firma.com.tr [195.175.xx.xx]:49812 
rejected after DATA: message size 68241920 exceeds size limit 26214400 
of server mail.firma.com.tr

Log satırı her şeyi haykırmaktadır: Gönderilmeye çalışılan e-posta boyutu tam 68 Megabayt'tır ve sunucunun maksimum kabul sınırı olan 25 Megabayt limitine toslamıştır.

1982 Yılından Kalan Telgraf: SMTP ve Base64 Matematik Tuzağı

Müşteriye sakin bir sesle durum izah edilir: "Ahmet Bey, mailinize eklediğiniz dosya 50 MB civarında görünüyor. Küresel e-posta protokolü sınırları gereği sunucumuz ve alıcı sunucu en fazla 25 MB büyüklüğündeki iletileri kabul edebilir. Dosyanızı WeTransfer, Google Drive veya OneDrive linki olarak paylaşmanız gerekiyor."

Müşterinin yanıtı değişmez:

"Ne 68 megabaytı kardeşim, benim dosyam bilgisayarda tam 48 megabayt! Hem 48 MB ne ki? Çağımızda 48 MB dosya mı kaldı, internette gigabaytlarca film izliyoruz! Bana ne küresel kuraldan, açın sunucunun limitini 100 megabayt yapın, gitmesi lazım bu mailin!"

Müşterinin anlamadığı iki devasa gerçek vardır: Birincisi Base64 kodlaması, ikincisi ise SMTP protokolünün felsefesi.

  1. Base64 Şişmesi (%33 Kuralı): SMTP (Simple Mail Transfer Protocol), 1982 yılında RFC 821 ile tanımlandığında sadece 7-bit ASCII metin (yani daktilo yazısı) taşımak üzere tasarlanmıştı. E-postanın içine resim, PDF veya Word belgesi gibi 8-bit ikili (binary) bir dosya eklediğinizde (MIME standardı), bu ikili veri 7-bit ASCII karakterlere dönüştürülür. Bu dönüştürme işlemi (Base64), dosya boyutunu matematiksel olarak tam %33 oranında büyütür. Yani bilgisayarınızda 48 MB olan bir PDF dosyası, e-posta paketinin içine girdiği an 64 ila 68 MB arasına fırlar!
  2. Posta Sunucusu Kargo Kamyonu Değildir: E-posta, anlık haberleşme ve resmi yazışma protokolüdür; devasa dosya dağıtım şebekesi (CDN / FTP) değildir. Bir e-posta gönderildiğinde hafızada işlenir, antivirüs ve antispam tarayıcılarından (ClamAV, SpamAssassin) geçirilir, kuyruğa (mail queue) yazılır ve alıcı sunucuya aktarılır. Eğer her kullanıcı 100 MB'lık dosyalar eklemeye kalkarsa, sunucunun RAM'i dakikalar içinde tükenir ve posta kuyruğu felç olur.

Karşı Tarafın Duvarı: Alıcı Sunucu Reddi

Diyelim ki destek ekibi müşterinin aşırı ısrarına dayanamadı ve kendi sunucusundaki limiti message_size_limit = 104857600 (100 MB) yaptı. Mail müşterinin giden kutusundan başarıyla çıktı.

Sorun çözüldü mü? Hayır, felaket daha yeni başlıyor!

Mail alıcı tarafın (örneğin belediyenin veya kurumsal şirketin kullandığı Microsoft 365, Google Workspace veya özel posta sunucusu) kapısına varır. Microsoft 365 varsayılan sınırı 25 MB'tır, Gmail sınırı 25 MB'tır. Alıcı sunucu kapıda bekleyen o 68 MB'lık devi görür görmez kapıyı yüzüne çarpar:

Remote server returned: 552 5.3.4 Message size exceeds fixed maximum message size

Ve mail geri teper (bounce). Müşteri bir kez daha feryat eder: "Sizin sunucunuz yine beceremedi!" Oysa dünya standartları bir konsensüstür; otobanda hız limitini siz kendi aracınızda kaldırsanız bile gişelerden geçemezsiniz.

Bolus Tıkanmasına Karşı Modern Mimari Çözümler

Yemek borusuna takılan koca lokmayı tek parçada yutamazsınız; bıçakla kesip küçük lokmalara bölmeniz gerekir. Dosya paylaşımında da modern internetin kuralı budur:

  • Bulut Depolama ve Bağlantı Paylaşımı (Cloud Links): 10 MB'ı aşan her türlü dosya için kurumsal OneDrive, Google Drive, Dropbox veya WeTransfer gibi araçlar kullanılmalıdır. E-postaya dosyanın kendisi değil, şifreli ve güvenli indirme linki eklenmelidir.
  • Otomatik Büyük Ek Eklentileri: Modern Outlook ve Thunderbird sürümlerinde bulunan "Mail-Drop" veya bulut eklentileri sayesinde kullanıcı büyük bir dosya eklediğinde istemci bunu otomatik olarak buluta yükleyip e-postaya link olarak iliştirebilir.
  • Şirket İçi Dosya Transfer Portalları: Kurumlar için OwnCloud, Nextcloud gibi şirket içi güvenli sunucularda çalışan self-hosted dosya paylaşım ağları kurulmalıdır.

SMTP borusundan 50 MB'lık inşaat projesini geçirmeye çalışmak, itfaiye hortumundan kum püskürtmeye benzer; ne su akar ne yangın söner, sadece boru patlar. E-posta bir telgraftır; kütüphaneyi telgraf tellerinden taşımaya çalışmak teknolojiye değil, fizik kurallarına meydan okumaktır.