Ek-F. RFC 821'in Önerilmeyen Özellikleri
RFC 821'in bir kaç özelliğinin sorunlu olduğu kanıtlanmıştır ve Genel Ağ postasında kullanılmaması gerekir *ÖNERİ*.
TURN
Komutu
RFC 821'de açıklanan bu komut, istemci ve sunucunun rol değiştirmesini talep eden konağın kimliğinin kesinlikle kanıtlanması gereği yerine getirilmedikçe bu durum, postayı kolayca doğru hedefinden saptırmak için kullanılabileceğinden önemli güvenlik kaçaklarını arttırır. Kullanımı önerilmez; sunucu tarafından istemci kimliğinin kanıtlanması sağlanmadıkça SMTP sistemlerinin bu komutu kullanmaması gerekir *ÖNERİ*.
Kaynak Yönlendirme
RFC 821, postanın bir konaktan diğerine bir röleleme silsilesinden sonra aktarılması anlamına gelen doğrudan kaynak yönlendirme kavramından yararlanır. Sıradan posta trafiğinde kaynak rotalardan yararlanma gereksinimi, alan adı sistemine "MX
" kaydının girişiyle ve bunların son derece önemli bir ayarlaması da, RFC 1123'e, adreslerde "@
" imini izleyen kısmın tamamen nitelenmiş alan isimleri içermesi şeklindeki açık gereksinimin girişiyle ortadan kalkmıştır.
Netice olarak, kaynak rota kullanımı için sadece hizalamanın kalması, çok eski SMTP istemcileri ile kullanıcı postalama araçları ve posta sistemi hata ayıklaması için desteklenmektedir. Bunlar yine de, son durumla ilgili olarak ve maksada uygun DNS kayıtları gibi ciddi ama geçici sorunların çevresinden dolanarak posta yönlendirme için hala kullanışlıdır.
Bu belgenin ana gövdesinde ve RFC 1123'te belirtildiği gibi SMTP sunucuları kaynak rota sözdizimini kabul etmeye devam etmelidir *ZORUNLU*. Bunlar gerekirse rotaları yoksayarak sadece adresteki hedef alandan yararlanabilir *SEÇİMLİK*. Eğer kaynak rotadan yararlanırlarsa, iletinin adreste gösterilen ilk alana gönderilmesi gerekir *ZORUNLU*. Özellikle bir sunucu kaynak rota içindeki kısayollarda tahmin yapmamalıdır *ZORUNLU*.
Posta sistemi yapılandırma hataları veya güvenlik duvarı etrafından dolaşmak için röleleme olasılığı veya hata ayıklama gibi olumsuz durumlar haricinde istemcilerin doğrudan kaynak yönlendirmeden yararlanmamaları gerekir *ÖNERİ*.
HELO
Komutu
Oturum İlklendirme ve Komut Sözdizimi ve Anlamlandırma bölümünde bahsedildiği gibi, sunucu EHLO
komutunu kabul edebilecekse, EHLO
komutu daima/mutlaka HELO
komutuna tercih edilir. Sunucuların eski istemcileri desteklemek için HELO
komutunu kabul etmeye ve işleme sokmaya devam etmesi gerekir.
#
imli sabitler
RFC 821, bir Genel Ağ adresinin, bir "#
" imi ile başlayan ve konak numarasını ifade eden bir ondalık tamsayı ile belirtilmesine izin verir. Uygulamada, TCP/IP'ye geçildiğinden beri, bu biçim artık kullanılmamaktadır ve kullanılmamalıdır *ZORUNLU*.
Tarihler ve Yıllar
SMTP istemcileri ve sunucuları tarafından iletilere tarih yerleştirilmek istendiğinde (örn, izleme alanlarına), dört rakamlı yıl gösterimi kullanılmalıdır *ZORUNLU*. İki rakamlı yıllar önerilmemektedir; üç rakamlı yıllara ise Genel Ağ posta sisteminde hiçbir zaman izin verilmemiştir.
Postalamayıp Gönderivermek
İletilerin kullanıcıların posta kutularına teslimatı için bir mekanizma belirtilmesine ek olarak, RFC 821, iletileri doğrudan kullanıcının uçbirim ekranına teslim eden isteğe bağlı ek komutlar sağlamıştır. Bu komutlar (SEND
, SAML
, SOML
) nadiren gerçeklenmiş, iş istasyonu teknolojisindeki değişiklikler ve diğer protokollerin devreye girmesiyle gerçeklendikleri yerlerde bile kullanılmayarak atıl olmuşlardır.
İstemciler hizmet olarak SEND
, SAML
, SOML
komutlarını bulundurmamalıdır *ÖNERİ*. Bunlar sunucular tarafından gerçeklenirse, RFC 821'de belirtilen gerçeklenim modeli kullanılmalı *ZORUNLU* ve komut isimleri EHLO
komutunun yanıtında yayınlanmalıdır *ZORUNLU*.