4.5. Gerçeklenimle İlgili Ek Hususlar

4.5.1. Asgari Gerçeklenim

SMTP'yi tüm alıcılar için çalışır kılmak için, aşağıdaki asgari gerçeklenim gereklidir. Aşağıdaki komutların bu belirtimle uyumlu olmak için desteklenmesi gerekir *ZORUNLU*.

    EHLO
    HELO
    MAIL
    RCPT
    DATA
    RSET
    NOOP
    QUIT
    VRFY

Posta röleleme ve teslimatını destekleyen bir SMTP sunucusu içeren her sistemin harf büyüklüğüne duyarsız bir yerel isim olarak "postmaster" adına ayrılmış bir posta kutusunu desteklemesi gerekir *ZORUNLU*. Eğer sunucu bağlantı açılışında (Oturum İlklendirme bölümünde açıklandığı gibi) daima 554 döndürüyorsa, bu postmaster adresi mutlaka gerekli değildir. Postmaster için posta kabul etme gereksinimi, SMTP sunucusunun posta hizmeti verdiği her alan adı için bir postmaster posta kutusu belirtilen RCPT komutları ile "RCPT TO:<Postmaster>" şeklindeki (alan belirtilmeksizin) özel durumun desteklenmesi gerektiği *ZORUNLU*, anlamına gelir.

SMTP sistemlerinin, Genel Ağ üzerindeki herhangi bir sistemden postmaster'a doğrudan posta kabul edilmesi için makul her türlü çabayı göstereceği umulur. Bazı uç durumlarda, örneğin, bir hizmet reddi saldırısı veya diğer güvenliği kırma saldırılarının olduğu durumlarda, bir SMTP sunucusu postmaster'a gelen postayı engelleyebilir. Bununla birlikte, bu tür saldırıların bir parçası olmayan iletilerin de engellenmemesi için böyle düzenlemelerin kapsamı oldukça dar tutulmalıdır *ÖNERİ*.

4.5.2. Şeffaflık

Veri şeffaflığı için gerekli bazı önlemleri almaksızın "<CRLF>.<CRLF>" karakter dizisi posta metnini bitirir ve kullanıcı tarafından gönderilemez. Genelde, kullanıcıların bazı " yasaklanmış" dizilimlerden haberleri yoktur. Tüm kullanıcılarca oluşturulan metinlerin şeffaf olarak aktarılabilmesini mümkün kılmak için şu yöntemler kullanılır:

  • Posta metninin bir satırını göndermeden önce, SMTP istemcisi satırın ilk karakterine bakar. Bir nokta ise, onun yanına, satırın başına bir nokta daha konur.

  • SMTP sunucusu posta metninin bir satırını aldığında satıra bakar. Satırın tamamı tek bir noktadan oluşmuşsa, bu satır posta sonu belirteci olarak ele alınır. Eğer ilk karakter bir nokta olduğu halde satırın devamında başka karakterler varsa ilk karakter silinir.

Posta verisi, 128 ASCII karakterinin herhangi birini içerebilir. Boşluklar, dikey ve yatay sekmeler ile diğer kontrol karakterleri de dahil olmak üzere tüm karakterler alıcının posta kutusuna (bir yoruma konu edilmeksizin) teslim edilmek içindir. Eğer aktarım kanalı veri akımını 8 bitlik baytlarla (sekizli) sağlıyorsa, 7 bitlik ASCII kodları sekizlilerde sağa yanaştırılıp en anlamlı bitleri sıfır yapılarak iletilir. Bir röleleme işlevi sunan SMTP sistemlerinde bu durumlar Röleleme bölümünde özelikle ele alınmıştır.

Bazı sistemlerde veriyi alınıp saklanmış gibi dönüştürmek gerekli olabilir. Yerel karakter kümesi olarak ASCII'den farklı bir karakter kümesi kullanan, veriyi dizgeler halinde değil kayıtlar halinde saklayan veya posta kutularının içinde ayraç olarak özel karakter dizilimleri kullanan konaklar için bu gerekli olabilir. Eğer böyle dönüşümler gerekliyse, bunlar geri alınabilir olmalıdır *ZORUNLU*; özellikle de, rölelenen postaya uygulanmışsa.

4.5.3. Boyutlar ve Zamanaşımları

4.5.3.1. Boyut sınırları ve asgari değerler

Azami ve/veya asgari boyutları olması gereken bazı nesneler vardır. Her gerçeklenimin nesneleri en azından bu boyutlarda almasının mümkün olması gerekir *ZORUNLU*. Bu boyutlardan daha büyük nesnelerden olabildiğince kaçınılmalıdır *ÖNERİ*. Bununla birlikte, kodlanmış X.400 adresleri [16] gibi sıklıkla daha geniş nesneler gerektiren bazı Genel Ağ posta oluşumları vardır: istemciler bunları aktarmaya çalışabilir *SEÇİMLİK*, fakat onları işleme alamıyacak bir sunucu tarafından reddedilmelerine karşı da hazırlıklı olmalıdır *ZORUNLU*. Azami genişleme olasılığı için, bu nesnelerin uzunluğu ile ilgili bir sınır koymayan gerçeklenim teknikleri kullanılmalıdır.

yerel-kısım

Bir kullanıcı isminin veya bir yerel-kısım'ın toplam uzunluğu en çok 64 karakter olabilir.

alan

Bir alan isminin veya numarasının toplam uzunluğu en çok 255 karakter olabilir.

yol

Bir dönüş veya sevk yolunun toplam uzunluğu en çok 256 karakter olabilir (noktalama imlerini ve bileşen ayraçlarını içererek).

komut satırı

Komut sözcüğünü ve <CRLF>'yi içererek bir komut satırının toplam uzunluğu en çok 512 karakter olabilir. Bu sınırı arttırmak için SMTP eklentileri kullanılabilir.

yanıt satırı

Yanıt kodunu ve <CRLF>'yi içererek bir yanıt satırının toplam uzunluğu en çok 512 karakter olabilir. Daha fazla bilgi çok satırlı yanıtlarla taşınabilir.

metin satırı

<CRLF>'yi içererek bir metin satırının toplam uzunluğu en çok 1000 karakter olabilir (şeffaflık açısından uçlardaki nokta tekrarları sayılmaz). Bu miktar SMTP Hizmet Eklentileri kullanarak arttırılabilir.

ileti içeriği

Bir ileti içeriğinin (ileti başlıklarını da içererek ileti gövdesinin) toplam uzunluğu hiç olmazsa (bari, en azından) [at least] 64K sekizli olmalıdır *ZORUNLU*. Çoklu ortam postası Genel Ağ standartlarına [12] girdiğinden beri, Genel Ağ'da ileti uzunlukları çarpıcı biçimde büyümektedir. Bu bakımdan ileti boyu sınırlamalarından mümkün olduğunca kaçınılmalıdır. Sınırlamaları zorlamak isteyen SMTP sunucu sistemleri "BOYUT" hizmet eklentisini [18] gerçeklemelidir *ÖNERİ*.

alıcılar tamponu

Tamponlanması gereken alıcıların toplam sayısı en az 100 olabilir. 100 RCPT komutundan daha azından sonraki alıcılar için iletilerin reddedilmesi bu belirtime uyulmadığı anlamına gelir. Genelde prensip olarak, röleleyen SMTP sunucuları için zorunlu olarak *ZORUNLU* ve teslimat SMTP sunucuları için öneri olarak *ÖNERİ*, bir iletinin alıcılarının toplam sayısına bağlı olarak reddildiğini ima eden ileti başlıkları üzerinde doğrulama denemeleri yapılmaması gerekir. Alıcı sayısına bir sınır koyan bir sunucu alıcıları sıralı bir tarzda ele almalı, örneğin, sınırı aşan adresleri reddetmeli ama evvelce kabul edilmiş adresleri sonraya kalmış gibi reddetme yoluna gitmemelidir *ZORUNLU*. Eğer sunucu tek bir iletide 100 alıcıdan fazlasını kabul etmeyi tavsatıyorsa, istemci, 100'den fazla RCPT komutu gerektiren bir iletinin teslimatını 100 alıcılık iletiler halinde yapmak için hazırlıklı olmalıdır.

Bu sınırların aşılmasından dolayı oluşan hatalar yanıt kodları kullanılarak raporlanabilir. Bazı yanıt kodu örnekleri:

500 Satır çok uzun.

veya

501 Yol çok uzun

veya

452 Alıcılar çok fazla (aşağıya bakınız)

ya da

552 Posta verisi çok fazla.

RFC 821 [30] bir hatayı yanlış listelemiştir: RCPT komutlarının miktarıyla ilgili gerçeklenim sınırından dolayı yetersiz kalan bir SMTP sunucusunun hatayı ("Alıcılar çok fazla") '552 yanıt koduyla' bildireceği belirtilmiştir. Doğrusu '452 yanıt koduyla' olacaktır. İstemciler bu durumda bir 552 yanıt kodunu kalıcı değil geçici bir hata durumu olarak ele almalıdır *ÖNERİ*, başarısızlık durumunda aşağıdaki mantık yürütülür.

Belirtimle uyumlu bir SMTP sunucusu bu durumu saptadığında, alıcılar tamponunda en azından 100 başarılı RCPT komutu var demektir. Sunucu iletiyi kabul edebilecekse, en azından 100 adres SMTP istemcisinin kuyruğundan silinmiş olacaktır. 452 yanıtı almış adresleri istemci yeniden aktarmaya çalışırsa, bunların en azından 100 tanesi SMTP sunucusunun alıcılar tamponuna sığabilecektir. Teslim edilecek ne varsa yeniden her aktarma çabasında bu alıcıların en azından 100 tanesinden kurtulmak mümkün olacaktır.

Bir SMTP sunucusunun RCPT komutlarının sayısına bağlı bir gerçeklenim sınırı varsa ve bu sınıra ulaşılmışsa, sunucu 452 yanıt kodunu kullanmalıdır *ZORUNLU* (fakat, istemci yukarıda belirtildiği gibi bir 552 yanıtına karşı da hazırlıklı olmalıdır *ÖNERİ*). Eğer sunucu RCPT komutlarının sayısı ile ilgili kural olarak konmuş bir sınırlamaya (gerçeklenimin desteklediğinden az) göre hareket ediyorsa bir 5XX yanıt kodu da kullanabilir *SEÇİMLİK*. Eğer belli bir ileti gövdesi çok sayıda posta aktarımı ile gönderilmiş olsa bile o ileti için bir toplam alıcı sayısı sınırı uygulanabiliyorsa, böyle bir sınırlama en iyisi olurdu.

4.5.3.2. Zamanaşımları

Her SMTP istemcisi bir zamanaşımı mekanizması sağlamalıdır *ZORUNLU*. Bu mekanizma posta aktarımının tamamına bir şekilde uygulanabilen bir zamanaşımı değil her komut için ayrı ayrı uygulanabilen zamanaşımları kullanmalıdır *ZORUNLU*. Zamanaşımları, tercihan SMTP kodunu yeniden derlemek gerekmeksizin, yeniden yapılandırılabilir olmalıdır *ÖNERİ*. Bunu gerçeklemek için, her SMTP komutu ve her veri aktarım tamponu için bir zamanlayıcı tahsis edilir. Sonuncusu, aktarımın bütününü kapsayan zamanaşımının ister istemez iletinin boyutuyla orantılı olduğu anlamına gelir.

Meşgul posta röleleme konakları ile gerçekleştirilen kapsamlı deneyimlere dayanarak, komut başına asgari zamanaşımı değerleri şöyle olmalıdır *ÖNERİ*:

İlk 220 İletisi: 5 dakika

Bir SMTP istemci sürecinin, başarısız bir TCP bağlantısı ile ilk 220 karşılama iletisinin gecikmesi arasındaki farkı ayrımsamaya ihtiyacı vardır. Çoğu SMTP sunucusu bir TCP bağlantısını kabul eder ama sistem yükü başka postaları da işleme almayı mümkün kılana kadar 220 iletisinin teslimatını geciktirir.

MAIL Komutu: 5 dakika
RCPT Komutu: 5 dakika

Postalama listelerinin ve takma adların işlenmesi iletinin kabulü sonrasına ertelenmiyorsa, daha uzun bir zamanaşımı gerekir.

DATA ilklendirme: 2 dakika

Bu, DATA komutuna "354 Girdiyi Başlat" yanıtı beklenirken geçen süredir.

Veri Bloku: 3 dakika

Veri kısım kısım aktarılırken her TCP GÖNDER çağrısının tamamlanması için geçmesi beklenecek süredir.

DATA sonlandırma: 10 dakika.

Bu, "250 OK" yanıtı beklenirken geçen süredir. Alıcı ileti verisini sonlandıran son noktayı aldığında, genellikle iletinin kullanıcının posta kutusuna teslimini gerçekleştirir. Bu noktada taklit bir zamanaşımı, ileti gönderilmiş ve sunucu teslimatın sorumluluğunu zaten kabul etmiş olduğundan çok yıkıcı olurdu ve genelde aynı iletinin çok sayıda kopyasının teslimi ile sonuçlanırdı. Bu konu ile ilgili olarak Güvenilir Teslimat ve Eposta Yanıtları bölümüne de bakınız.

Bir SMTP sunucusu göndericiden gelecek bir sonraki komutu en az 5 dakika beklemelidir *ÖNERİ*.

4.5.4. Yanıt Stratejileri

Bir konak SMTP gerçekleniminin bilinen yapısı kullanıcı posta kutuları, gelip geçen iletileri kuyruğa almak için bir veya daha fazla alan ile posta alımı ve gönderimi için çalışan bir veya daha fazla artalan sürecinden oluşur. Kesin yapı konak üzerindeki kullanıcıların ihtiyaçları ile konak tarafından desteklenen posta listelerinin boyutlarına ve sayısına bağlı olarak değişir. Özellikle yüksek trafik seviyelerini destekleyen postacılar için yardımcı olduğu kanıtlanmış çeşitli eniyilemeleri açıklayacağız.

Her kuyruklama stratejisi her türlü etkinliğin zamanaşımını her komuta özel olarak ele almalıdır *ZORUNLU*. Bir kuyruklama stratejisi ne olursa olsun hata iletilerine yanıt olarak hata iletileri göndermemelidir *ZORUNLU*.

4.5.4.1. Gönderme Stratejisi

Bir SMTP istemcisinin genel modeli giden postayı aktarmaya çalışan bir veya daha fazla süreçten oluşur. Ortalama bir sistemde, bir iletiyi oluşturan program, hemen aktarılamayıp kuyruğa alınıp belirli aralıklarla tekrar gönderilmeye çalışılmalıyken *ZORUNLU*, giden postanın yeni bir parçasının hemen dikkate alınmasını talep eden bir yönteme sahiptir. Bir posta kuyruğu girdisi iletinin kendisinden başka zarf bilgisini de içerecektir.

Belli bir hedef için bir çaba başarısız olduktan sonra çabayı yinelemek için bir süre beklenmelidir *ZORUNLU*. Genelde, yineleme aralığı en azından 30 dakika olmalıdır *ÖNERİ*; bununla birlikte, SMTP istemcisi teslimat yapılmaması için sebep saptayabildiği zaman, daha karmaşık ve değişken stratejilerin yararı olacaktır.

İleti aktarılana veya gönderici vazgeçene kadar yineleme devam eder; vazgeçme süresinin genelde en azından 4-5 gün olması gerekir. Yineleme algoritmasının bağımsız değişkenleri yapılandırılabilir olmalıdır *ZORUNLU*.

Bir istemci kuyruklu posta öğelerini salt tekrar göndermeye çalışmaktan çok, ulaşamadığı konakların ve ilgili bağlantı zamanaşımlarının bir listesini tutması gerekir *ÖNERİ*.

Deneyimler bu başarısızlıkların genellikle geçici olduğunu (hedef sistem ya da bağlantı çökmüştür), kuyruktaki iletiyi göndermek için ilk saatte iki, daha sonra ise iki veya üç saatte bir bağlantı kurmaya çalışmak şeklinde bir kuralın lehte olacağını göstermiştir.

SMTP istemcisi, SMTP sunucusu ile anlaşarak kuyruklama gecikmesini kısaltabilir. Örneğin, posta belli bir adresten alınmışsa, posta onu hemen gönderebilecek konak için kuyruğa alınmış gibi ele alınabilir. Bu prensibin uygulaması, çoğu durumda, ETRN [9] gibi apaçık bir "kuyruktakileri hemen gönder" işlevi için gereksinimi ortadan kaldırabilir.

Strateji, çok sayıda adresin her konak başına özkaynak kullanımını (teslimat zamanı gibi) eniyileme gereğinin bir sonucu olarak böyle değiştirilmiş olabilir.

Bir SMTP istemcisinin erişilemeyen hedef konakların her biri için dev bir ileti kuyruğu olabilir. Bu iletilerin tümü her yineleme döngüsünde yineleniyorsa, Genel Ağ'a haddinden fazla yük bindirebilir ve gönderen sistem uzun bir süre boyunca engellenebilir. Bir SMTP istemcisinin, bir teslimat çabasının başarısız olacağını, aynı konak için kuyruklanmış iletilerin düzinelerce hatta yüzlercesinin tekrar tekrar yinelenmesi halinde bağlantı başına bırakın bir kaç dakikalık sadece tek bir dakikalık zamanaşımının bile çok büyük bir gecikmeyle sonuçlanacağını saptayabileceğine dikkat ediniz.

Aynı zamanda, SMTP istemcileri sunuculardan gelen olumsuz yanıtları arabelleğe alırken büyük dikkat sarfetmelidir *ÖNERİ*. Çok uç bir durumda, aynı SMTP bağlantısı sırasında EHLO komutu defalarca kullanılmışsa, sunucudan farklı yanıtlar dönebilir. Daha manidar olarak, MAIL komutuna verilen 5yz yanıtları arabelleğe alınmamalıdır *ZORUNLU*.

Bir posta iletisi çok sayıda alıcıya teslim edilecekse ve bunlardan bir kısmı tek bir SMTP sunucusundaysa, bu sunucuya iletinin sadece tek bir kopyası aktarılmalıdır *ÖNERİ*. Yani, SMTP istemcisi böyle bir komut dizisi yerine:

MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA

böyle bir komut dizisini kullanmalıdır:

MAIL, RCPT, RCPT,... RCPT, DATA.

Yine de, çok fazla adres varsa, MAIL komutu başına RCPT komutu sayısına bir sınırlama getirilebilir *SEÇİMLİK*. Bu verimli özelliğin gerçeklenmesi kesinlikle önerilmektedir.

Benzer şekilde, teslimatlarda tam zamanındalığın sağlanması için, SMTP istemcisi aynı anda çok sayıda giden posta aktarımını destekleyebilir *SEÇİMLİK*. Bununla birlikte, bütün kaynakların postaya tahsis edilmesinden korunmayı sağlayacak bir sınırlama uygun olabilir.

4.5.4.2. Alım Stratejisi

SMTP sunucusu her zaman SMTP portunu dinlemeyi sürdürmeye çalışmalıdır *ÖNERİ*. Bu, SMTP için gelen çok sayıda TCP bağlantısının desteklenmesini gerektirir. Bazı sınırlar konulabilir *SEÇİMLİK*, fakat aynı anda birden fazla SMTP aktarımını kabul edemeyen sunucular bu belirtimin amacıyla uyumlu değildir.

Yukarıda bahsedildiği gibi SMTP sunucu postayı belli bir konak adresinden almaktayken bu konak adresi için bekleyen bir postayı yineleyebilmek için kendi SMTP kuyruklama mekanizmasını etkinleştirebilir.

4.5.5. Dönüş yolu boş olan iletiler

Mevcut standartlardan başka standart adayı belirtimlerin de gerektirdiği boş dönüş yolu ile gönderilecek çeşitli uyarı türleri vardır. Bunlar arasında Röleleme bölümünde açıklanan "teslimatı yapılamayan posta" uyarısı iletisi, Teslimat Durum Bildirimleri (Delivery Status Notifications - DSN'ler) [24] ve İleti Elverişlilik Bildirimleri (Message Disposition Notifications - MDN'ler)[10] başlıcalarıdır. Tüm bu ileti çeşitleri önceki bir posta iletisi hakkında birer bildirimdir ve önceki posta iletisinin dönüş yoluna gönderilir. (Eğer böyle bir bildirim iletisi teslim edilemezse, bu, bildirim iletisinin adreslendiği konağın posta sistemi ile ilgili bir sorunun olduğunu gösterir. Bu sebeple bazı konaklarda MTA, böyle başarısız bildirim iletilerinin sevkedileceği, posta sistemi ile ilgili sorunları giderebilen birilerine, örneğin, postmaster takma adı kullanılarak, yönlendirilmiş bir posta kutusuna sahiptir. )

Tüm diğer ileti türleri (yani, boş bir dönüş yoluna sahip olması standartlaşma aşamalarındaki bir RFC tarafından gerekli görülmemiş her ileti), boş olmayan geçerli bir dönüş yolu ile gönderilmelidir *ÖNERİ*.

Özdevinimlileştirilmiş eposta işlemcilerinin gerçeklenimcileri boş dönüş yolu içeren ileti çeşitlerini işleme sokarken dikkatli olmalı, özellikle de böyle sistemler boş dönüş yolu içeren iletileri yanıtlamamalıdır *ÖNERİ*.