3.7. Röleleme
Genelde, alan adı sistemindeki [22, 27] posta aktarımcı (MX
) kayıtlarının varlığı, Genel Ağ posta sisteminde doğrudan kaynak rotası kullanımını gereksiz kılar. Geçmişte yorumlanmalarıyla ilgili yaşanan bir çok sorun kullanımlarının istenmemesine yol açtı. Olağanüstü durumlar müstesna, SMTP istemcileri doğrudan kaynak rotaları üretmemelidir *ÖNERİ*. SMTP sunucuları kaynak rotası belirten adresleri kabul etmeyi veya posta rölesi olarak davranmayı reddedebilir *SEÇİMLİK*. Rota bilgisinin mevcudiyeti saptandığında SMTP sunucuların rota bilgisini yoksayma hakkı vardır ve basitçe, postayı rotada son eleman olarak belirtilmiş son varış noktasına gönderebilir ve böyle de yapmalıdır *ÖNERİ*. Kaynak rotada ara konaklar olarak belirtilmiş konaklardaki kullanıcıların sorunlarını çözmekle ilgili olarak, DNS'lerde varış noktası olarak görünmeyen isim kullanımı ile ilgili geçersiz bir uygulama olmuştur. Kaynak rotalardaki ara konaklar yoksayıldığında bu uygulama hatalara yolaçar. Bu, SMTP istemcilerinin neden geçersiz kaynak rotaları veya seriye çözünür isimler üretmemeleri gerektiğinin *ZORUNLU* sebeplerinden biridir.
Kaynak rotaları kullanılmadığında, RFC 821'de açıklanan, sevk yolundan bir dönüş yolu oluşturmaya yarayan işlem uygulanabilir değildir ve dönüş yolu, teslim anında basitçe MAIL
komutunda görünen adrestir.
Bir röle SMTP sunucusu genelde son teslim sisteminden ziyade kendisini işaret eden DNS MX
kaydının hedefidir. Röle SMTP sunucusu röleleme işini yerel bir kullanıcının postasını kabul veya red ettiği şekilde kabul veya red edebilir. Rölelemeyi kabul ederse bir SMTP istemcisi haline gelir, DNS'de belirtilen sıradaki SMTP sunucuya bir aktarım kanalı oluşturur (Adres Çözümleme ve Posta Yönetimi bölümündeki kurallar dahilinde) ve postayı ona yollar. Kurallar gereği belli bir adrese postayı rölelemeyi redderse, geriye bir 550 yanıtı göndermelidir *ÖNERİ*.
Birçok posta gönderme istemcisi vardır ve bunlar genellikle POP3 veya IMAP üzerinden posta da alabilmekte olup bu belirtimdeki gereksinimlerin bazılarını (peşpeşe teslimat gerektiğinde iletileri kuyruğa almak gibi) sınırlı olarak desteklemektedir. Bu istemciler için bilinen uygulama, işleme sokulmak veya ardışık olarak dağıtılmak üzere tüm iletileri tek bir sunucuya gönderecek düzenlemeleri yapmaktır. Burada belirtildiği gibi SMTP bu role uygun değildir ve bu iş mevcut uygulamalar için standart hale gelmiş posta teslim etme protokolleri ile fevkalade yoluna girmiş durumdadır. Her halükarda, bu düzenlemeler bu uygulamalara özeldir ve bu belirtimin kapsamına girmediklerinden burada açıklanmayacaklardır.
Bir konu önemlidir: MX
kayıtları, sadece SMTP rölelerini ve son teslimat sistemlerini değil, başka ortamlara ağ geçidi rolü oynayan SMTP sunucularını da işaret edebilir; Postanın Ağ geçitlerinden Geçirilmesi ve Adres Çözümleme ve Posta Yönetimi bölümlerine bakınız.
Bir SMTP sunucusu posta röleleme görevini kabul eder ve daha sonra hedefin yanlış olduğunu veya herhangi bir sebepten dolayı posta teslimatının yapılamadığını görürse, bir "teslimatı yapılamayan posta" uyarısı iletisi oluşturmalı ve bunu o postayı oluşturana (geri dönüş yolunda belirtilene) göndermelidir. Teslimatı yapılamayan postalarla ilgili raporlar için başka standartlar (örn, [24, 25]) tarafından belirtilmiş biçimler mümkün olduğunca kulllanılmalıdır *ÖNERİ*.
Bu uyarı iletisi röle konağındaki veya teslimatın gerçekleşmediğinin ilk olarak saptandığı konaktaki SMTP sunucusundan gelmelidir. Şüphesiz, SMTP sunucuları bir de uyarı iletilerinin teslimat sorunlarıyla ilgili uyarı iletileri göndermemelidir *ZORUNLU*. Hata raporlarken kısır döngüleri engellemenin bir yolu, bir uyarı iletisinin MAIL
komutunda boş geri dönüş yolu belirtmektir. Böyle bir ileti aktarılırken, dönüş yolu boş bırakılmalıdır *ZORUNLU* (ek bilgi için bkz, Dönüş yolu boş olan iletiler). Boş geri dönüş yolu içeren bir MAIL
komutu:
MAIL
FROM:<>
Düzensizliklerin Giderilmesi[75] bölümünde bahsedildiği gibi, bir röle SMTP kendi "Received:
" başlığını eklemek dışında, ileti gövdesini veya başlıklarını inceleme veya işlemi sokma gereği duymamalıdır *ZORUNLU* ve posta sistemindeki kısır döngüyü saptamaya çalışmamalıdır *SEÇİMLİK* (bkz, Döngü Algılama).
[75] Ç.N. - Bu bağ özgün metinde 2.4.1 numaralı bölümü göstermektedir. http://www.mhonarc.org/archive/html/ietf-smtp/2002-07/msg00053.html adresindeki iletide belgenin yazarı bu atıfların aslında 6.3 numaralı bölümü göstermesi gerektiğini belirtmektedir. Bu bağ ve belgedeki böyle diğer iki bağ bu açıklamaya göre düzeltilmiştir.