Ek-B. SMTP Komutlarının RFC 822 Başlıklarından Üretilmesi

Bazı sistemler posta teslimat protokolünde (sadece) RFC 822 başlıklarını kullanır, kullanamadığında da, örneğin bir ileti bir kullanıcı aracı (MUA) tarafından bir aktarım aracına (MTA) bırakıldığında, SMTP komutlarını RFC 822 başlıklarından üretir. MTA-MUA protokolü özel bir konu olduğundan ve hiçbir Genel Ağ standardınca kapsanmadığından, bu yaklaşımla ilgili sorunlar vardır. Örneğin, kavramsal olarak bir posta zarfına ait bir bilgi başlık bilgisinden önceden ayrılmadığında (ve ayrı olarak tutulmadığında) listelerin tekrar dağıtılmasıyla ve gizli ("bcc") kopyaların düzgün ele alınmasıyla ilgili yinelenen sorunlar yaşanmıştır.

Kullanıcı aracının (MUA) ilk aktarım aracına (MTA) postayı bırakırken ileti ve zarfı ayrı ayrı teslim etmesinin sağlanması önerilir. Bunula birlikte, eğer zarf ayrı olarak sağlanmıyorsa, SMTP komutları şöyle üretilmelidir *ÖNERİ*:

TO, CC veya BCC başlık alanındaki her alıcı adresi RCPT komutuna kopyalanmalıdır *ÖNERİ* (eğer kuyruklama veya teslimat için gerekliyse çok sayıda ileti kopyası üreterek). BCC alanları varsa başlıklardan kaldırılmalıdır. Bu işlem tamamlandıktan sonra, kalan başlıklar, To:, Cc: veya Bcc: başlıklarından en az birinin kaldığından emin olmak için sınanmalıdır *ÖNERİ*. Eğer hiçbiri yoksa, [32]'de belirtildiği gibi hiçbir ek bilgi olmaksızın bir Bcc: başlığı yerleştirilmelidir *ÖNERİ*.
MAIL komutundaki dönüş adresi, eğer mümkünse, postayı teslim eden (yerel) kullanıcının sistemdeki kimliğinden, mümkün değilse, "From:" başlığından türetilmelidir. Kullanılabilir sistem kimliği varsa ve From: başlığındaki adresten farklıysa, ayrıca Sender başlığına da kopyalanmalıdır *ÖNERİ*. (Bir Sender alanı zaten varsa silinmelidir *ÖNERİ*.) Sistemler zarf dönüş adresini değiştirmek için kullanıcılarına bir yöntem sunabilir, ama kullanımını ayrıcalıklı kullanıcılar için kısıtlamak isteyebilir. Bu, posta sahtekarlığını önlemeyecektir, ama görülme sıklığını düşürebilir; bkz, Posta Güvenliği ve Yanıltma.

Bir MTA bu yönde kullanıldığında, aktarılan iletinin geçerliliğinden emin olunması sorumluluğunu alır. Geçerliliği sınama ve geldiğinde geçersiz olan iletileri elden geçirme (veya almama) mekanizmaları MUA-MTA arayüzünün bir parçası olup bu belirtimin kapsamında değildir.

Standard RFC 822 bilgisine dayalı bir teslimat protokolü bir iletiyi yabancı (SMTP dışı) bir posta sisteminden SMTP ortamına geçirmek için tek başına kullanılmamalıdır *ZORUNLU*. Zarfı oluşturacak ek bilgi, ister ilave başlıklarla ister yabancı sistemin zarfıyla olsun, diğer ortamdaki bir kaynaktan gelmelidir.

İletilerin sadece "to" ve "cc" alanlarını kullanarak geçitleme çabaları, posta döngülerine ve Genel Ağ posta ortamının düzgün çalışmasını engelleyici başka davranışlara yol açtı. Bu sorunlar çoğunlukla yaygın olarak, ileti bir Genel Ağ posta listesinden kaynaklanıp zarf bilgisi kullanılarak yabancı ortama dağıtıldığında görüldü. Bu iletiler daha sonra bir salt-başlık posta göndericisi tarafından işlendiğinde, Genel Ağ ortamına (ve posta listesine) geri dönüşler nerdeyse kaçınılmazdır.