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ı reddedebilirler *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önderebilirler ve
böyle de yapmalıdırlar *Ö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 desteklemektedirler. 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 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öndermemelidirler *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:
Düzensizliklerin Giderilmesi[144] 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).