Bir SMTP sunucusu teslim etmek veya işleme koymak için bir ileti aldığında, Posta Verisi (DATA komutu) bölümünde açıklandığı gibi ileti içeriğinin başlangıcına bir izleme bilgisi ("zaman damgası" veya "Received" satırı) yerleştirmelidir.
Bu satır şöyle yapılandırılmalıdır *ZORUNLU*:
- Bir SMTP ortamından kaynaklanması gereken FROM alanı *ZORUNLU*, şunların ikisini birden içermelidir *ÖNERİ*: (1) EHLO komutunda sunulduğu gibi kaynak konağın ismi ve (2) TCP bağlantısından saptanan, kaynak IP adresiyle kodlanmış adres.
- RFC 822'de tavsiye edildiği gibi ID alanı "@" içerebilir *SEÇİMLİK*, fakat bu gerekli değildir.
- Çok sayıda RCPT komutu verildiğinde FOR alanı <yol> girdilerinden oluşmuş bir liste içerebilir *SEÇİMLİK*. Bu bazı güvenlik sorunlarını arttırabilir ve genellikle de istenen bir şey değildir; bkz, "Gizli" Kopyalar.
Bir Genel Ağ posta programı, evvelce ileti başlığına eklenmiş bir "Received:" satırını değiştirmemelidir *ZORUNLU*. SMTP sunucuları "Received:" satırlarını iletilerin başlarına eklemeli *ZORUNLU*; mevcut satırların sırasını değiştirmemeli *ZORUNLU* veya "Received:" satırlarını başka bir yerlere yerleştirmemelidirler *ZORUNLU*.
Genel Ağ'ın büyümesiyle, Received alanlarının karşılaştırılabilirliği, sorunları, özellikle de yavaş röle sorunlarını saptamada önem kazanmaktadır. Received alanlarını oluşturan SMTP sunucuları zaman dilimi isimlerinden ziyade doğrudan doğruya saat farklarını (-0800 gibi) kullanmalıdırlar *ÖNERİ*. Uygulanabilir olduğunda, yerel zamanı evrensel zamana (UT) göre saat farkıyla belirtmek tercih edilmelidir. Bu yöntem, belirtilecek yerel durumlar hakkında biraz daha fazla bilgiyi mümkün kılar. Evrensel zaman (UT) gerekliyse, alıcının değer dönüşümü için sadece basit işlemler yapmaya ihtiyacı olur. Evrensel zaman (UT) kullanımı, sunucunun yeri-zaman dilimi hakkındaki bilgiyi kaybeder. Bir zaman dilimi ismi sağlanması isteniyosa, ismin bir açıklamanın içinde bulunması gerekir *ÖNERİ*.
Teslimatçı SMTP sunucusu bir iletinin "son teslimat"ını yaparken, posta veririnin başına bir "Return-Path" (Dönüş Yolu) satırı yerleştirir. Bu "Return-Path" satırı kullanımı gereklidir ve posta sistemleri bunu desteklemelidir *ZORUNLU*. "Return-Path" satırı MAIL komutundaki <dönüş-yolu> bilgisinin korunmasını sağlar. Burada, "son teslimat" ile iletinin SMTP ortamında kaldığı anlatılmak istenmektedir. Normalde, bu, postanın hedef kullanıcıya veya posta ile ilişkili bir yere teslim edileceği, ancak bazı durumlarda başka bir posta sistemine aktarılabileceği ve orada işleme sokulacağı anlamına gelirdi.
Dönüş yolundaki posta kutusunun asıl göndericininkinden farklı olması olasıdır, örneğin, hata yanıtlarının ileti göndericisinden ziyade özel bir hata iletileri alıcısı posta kutusuna teslimi gerekiyorsa, bu yararlıdır. Olaya postalama listeleri karıştığında bu düzenleme sıradandır ve hataların iletiyi yazana değil de listeyi yönetene yönlendirilmesi anlamında yararlıdır.
Yukarıdaki metinde ima edilen, son posta verisinin dönüş yolu satırı ile başladığı, bir ya da daha fazla zaman damgası satırı ile devam ettiğidir. Bu satırları posta verisi başlıkları ve gövdesi izler [32].
Sevk ve diğer işlemler ileti teslimat için kabul edildikten sonra yapıldığından teslimatın ne amaçla yapıldığının tespiti bir SMTP sunucusu için bazan zor olur. Sonuç olarak, ilgili (sevk, ağgeçidi, röle) sistemler dönüş yolunu silebilir *SEÇİMLİK* ve MAIL komutunu, teslim edilen iletide tam olarak böyle tek bir satırın görünmesini temin edecek şekilde yeniden kurgulayabilirler.
İletinin kaynaklandığı SMTP sistemi, iletiyi, başlığında bir "Return-Path" satırı mevcut olarak göndermemelidir *ÖNERİ*. Bir röleleme işlemi uygulayan SMTP sunucuları ileti verisini incelememeli *ZORUNLU* ve özellikle de bir "Return-Path" satırı mevcut mu, diye bakmamalıdırlar. Son teslimatı yapan SMTP sunucuları ise, kendilerininkini eklemeden önce "Return-Path" satırlarını silebilirler *SEÇİMLİK*.
Dönüş yolunun birincil amacı, yapılmayan teslimatı belirten iletinin veya gönderilecek başka bir posta sistemi başarısızlık bildiriminin adresini tayin etmektir. Bir belirsizlik oluşturmaması için, iletinin teslimatı sırasında sadece ve sadece bir dönüş yolu mevcut olmalıdır *ÖNERİ*. SMTPdışı aktarımlarda RFC 822 sözdizimini kullanan sistemler hataların (örn, teslim edilmeyen iletiler) raporlanması gerektiğinde, aktarım zarfıyla ilişkili ve belirsizlik oluşturmayan bir adres tayin etmelidirler *ÖNERİ*.
 | Tarihsel Bilgi |
|---|---|
Hata iletileri için hedef olarak "Return-Path" başlığının (veya MAIL komutundaki zarf dönüş yolu adresinin) kullanımını yalanlar görünen RFC 822'deki metin Genel Ağ'da uygulanabilir değildir. Dönüş yolu adresi (Return-path içine kopyalanmış olanı), teslimat hatalarını içeren hata iletilerinin hedefi olarak kullanılmalıdır *ZORUNLU*.
|
Özellikle:
- SMTP'den bir "başka yere" ağgeçidi olan bir konağın, bu "başka yer" aktarımının Genel Ağ alan adreslerini kullanıp zarf göndericisi adresini de ayrıca sağladığı bilinmedikçe bir dönüş yolu başlığı yerleştirmesi gerekir *ÖNERİ*.
- bir "başka yerden" SMTP'ye ağgeçidi olan bir konak, iletide mevcut bir dönüş yolu başlığı varsa silmeli ve bilgiyi ya SMTP zarfına kopyalamalı ya da SMTP zarfındaki MAIL komutunun dönüş yolu argümanını oluşturacak diğer aktarım sisteminin zarfındaki mevcut bilgiyle biraraya getirmelidir *ÖNERİ*.
Sunucu, posta verisi sonu belirtecini izleyen işlemlerin sadece kısmen başarılı olduğu durumlarda özel muamele yapmalıdır. Bu, bir miktar alıcı ve posta verisi kabul edildikten sonra SMTP sunucunun posta verisini alıcıların tamamına olmasa bile, bir kısmına başarıyla teslim edebileceğini saptarsa olur. Bu durumlarda, DATA komutuna OK yanıtı verilmelidir *ZORUNLU*. Bununla birlikte, SMTP sunucusu iletinin oluşturucusuna bir "teslim edilemeyen posta" uyarı iletisi oluşturup göndermesi gerekir *ZORUNLU*.
Başarısız olunmuş her alıcı için ya ayrı ayrı uyarı iletileri ya da bunları listeleyen tek bir uyarı iletisi gönderilmelidir *ZORUNLU*. İşlemin gönderici açısından ekonomik olması için mümkün olduğunca ikincisi tercih edilir. Tüm teslim edilemeyen posta uyarı iletileri Röleleme bölümünde açıklandığı gibi boş dönüş yollu MAIL komutu kullanılarak gönderilir (artık kullanılmayan SEND, SOML veya SAML komutlarının işleme sokulmasının sonucu olsalar bile).
Zaman damgası ve dönüş yolu satırları biçimsel olarak şöyle tanımlanır:
Dönüş-yolu-satırı = "Return-Path:" KBOŞ Dönüş-yolu <CRLF> Zaman-damgası-satırı = "Received:" KBOŞ Damga <CRLF> Damga = Kimden-alanı Tarafından-alanı İstemlik-bilgi ";" KBOŞ tarih-saat ; buradaki "tarih-saat" [32]'de açıklandığı gibidir. ; fakat "atıl-" biçimler, özellikle iki haneli yıllar ; SMTP'de yasaklanmıştır ve kullanılmamalıdır *ZORUNLU*. Kimden-alanı = "FROM" KBOŞ Genişletilmiş-alan AKBOŞ Tarafından-alanı = "BY" KBOŞ Genişletilmiş-alan AKBOŞ Genişletilmiş-alan = Alan / ( Alan KBOŞ "(" TCP-bilgisi ")" ) / ( IP-kodlu-ad KBOŞ "(" TCP-bilgisi ")" ) TCP-bilgisi = IP-kodlu-ad / ( Alan KBOŞ IP-kodlu-adı ) ; Bilgi sunucu tarafından TCP bağlantısından üretilir, ; istemci EHLO komutundan değil. İstemlik-bilgi = [Üzerinden] [İle] [Kimlik] [İçin] Üzerinden = "VIA" KBOŞ Bağ AKBOŞ İle = "WITH" KBOŞ Protokol AKBOŞ Kimlik = "ID" KBOŞ Dizge / İleti-kimliği AKBOŞ İçin = "FOR" KBOŞ 1*( Yol / Posta-kutusu ) AKBOŞ Bağ = "TCP" / Ek-Bağ Ek-Bağ = Atom ; Bağlarla ilgili ek standart isimler Genel Ağ Atanmış ; Numaralar Yetkilisi (IANA) tarafından kayıt altına ; alınır. SMTP sunucularının kayıtdışı isimler kullanmaması ; gerekir *ÖNERİ*. "Üzerinden" değeri asıl olarak, ; Genel Ağ dışı aktarımlarla ilgilidir. Protokol = "ESMTP" / "SMTP" / Ek-Protokol Ek-Protokol = Atom ; Protokollerle ilgili ek standart isimler Genel Ağ Atanmış ; Numaralar Yetkilisi (IANA) tarafından kayıt altına ; alınır. SMTP sunucularının kayıtdışı isimler ; kullanmaması gerekir *ÖNERİ*.