SMTP

SMTP (Türkçe: Basit Posta Aktarım Protokolü), bir e-posta göndermek için sunucu ile istemci arasındaki iletişim şeklini belirleyen protokoldür. Farklı işletim sistemleri için geliştirilmiş e-posta protokolleri bulunmaktadır. Bu e-posta protokollerinin SMTP'ye geçit yolu (gateway) vardır. SMTP, Aktarım Temsilcisi (Mail Transfer Agent, MTA) ve Kullanıcı Temsilcisi (Mail User Agent, MUA) yazılımları arasındaki iletişimi sağlar. TCP'nin üst katmanında çalışır.

Sadece e-posta yollamak için kullanılan bu protokolde, basitçe istemci bilgisayar SMTP sunucusuna bağlanarak gerekli kimlik bilgilerini gönderir, sunucunun onay vermesi halinde gerekli e-postayı sunucuya iletir ve bağlantıyı sonlandırır.

E-posta almak için POP3 ya da IMAP protokolü kullanılır.

Ücretsiz hizmet veren büyük e-posta hizmet sağlayıcıları da SMTP ve diğer e-posta gönderim ve kontrol protokollerini desteklemeye başlamışlardır.

Outlook, Eudora, Gmail, Mozilla Thunderbird, Evolution gibi e-posta istemcileri, e-postalarınızı gönderilmek üzere sunucunuza iletirken SMTP hizmetinden faydalanır.

25, 465 ve 587 numaralı portlar SMTP sunucuları için ayrılmıştır. Türkiye'deki internet servis sağlayıcıları 25. portu kapattığı için 465 veya 587. port üzerinden bu hizmet sunulmaktadır.^[1][2]

587. Port SMTP için önerilen port olup, e-posta istemcileri ile sunucuları arasında güvenli iletişim sağlamak amacıyla kullanılır. Genellikle TLS (Transport Layer Security) ile birlikte çalışarak, veri iletimi sırasında şifreleme ve güvenlik sağlar. Bu nedenle, e-posta göndermek için en uygun ve modern seçenek olarak kabul ve tercih edilir.^[3]

Birebir elektronik mesajın çeşitli şekilleri 1960'larda kullanılmıştır. İnsanlar belirli ana bilgisayarlar için birbirleriyle gelişmiş başka sistemleri kullanarak iletişim kurdular. Daha az bilgisayar, özellikle ABD hükûmetindeki ARPANET’te, birbirlerine e-posta gönderebilmek için bağlandı. Standartlar farklı sistemlerin kullanıcılarının birbirlerine e-posta göndermelerine izin verecek şekilde geliştirildi. SMTP, 1970'ler boyunca bu standartlara göre büyüdü. SMTP'nin 1971'de açıklanan iki uygulamanın kökünü takip ettiği söylenebilir: Posta kutusu protokolünün uygulanması tartışmalı olmuştur ama RFC 196 ve diğer RFC’lerde ve SNDMSG programında tartışılmıştır. RFC 2.235 göre, BBN Ray Tomlinson ARPANET üzerinden posta iletileri göndermek için Tenex bilgisayarlar icat etti. 1973’ten beri diğer uygulamaları FTP E-posta ve E-posta protokolünün her ikisini de içerir. ARPANET 1980 yıllarında modern internete dönüştürülene kadar, geliştiriciler 1970'li yıllar boyunca çalışmalarına devam ettiler. Sonra Jon Postel 1920 yılında FTP'de posta bağımlılığını kaldırmak için e-posta transfer protokolünü öngördü. SMTP Kasım 1981'de Postel tarafından RFC 788 olarak yayınlandı.

SMTP standartlarında USENET gibi benzer birçok iletişim ağı geliştirildi.

SMTP geniş ölçüde 1980'li yılların başlarında kullanılmaya başlandı. O zaman makineler arasında e-posta transferlerini işlemek için hangisinin bağlanması daha iyi uygunlukta olduğu "Unix-to-Unix Copy" Programı (UUCP) postasıyla tamamlayıcı oldu. SMTP diğer taraftan, gönderme ve alma makineleri ağa bağlı olduğu her zaman en iyi şekilde çalışır. Her ikisi de bir saklama ve iletme mekanizması kullanımı ve push teknolojisi örnekleridir. USENET haber grubu sayesinde UUCP sunucular arasında hala dağıtılmasına rağmen, mesaj gönderme başlıkları olarak kullanılan UUCP sanal olarak "patlama yolları" ile birlikte kayboldu.

İlk SMTP tarihi ve kaynağı hakkında bilgi RFC 123 den önce yeniden göndermeyle alakalı makale teknik altyapı içerir. Sendmail, RFC 788 den hemen sonra 4.1 cBSD ile birlikte yayınlanan SMTP’yi uygulamak için e-posta transfer maddelerinin ilklerinden birisi oldu. BSD Unix zaman içinde internet üzerindeki en popüler işletim sistemi olduğu gibi, Sendmail en yaygın MTA (Mail Transport Agent) oldu. Bazı diğer popüler SMTP sunucu programları Posfix, Gmail, Novell GroupWise, Exim, Novell NetMail, Microsoft Exchange Server, Sun Java System Messaging sunucuları içerir.

Tek kişilik elektronik mesajlaşma biçimleri 1960'larda kullanılmaya başlandı. Kullanıcılar, belirli büyük bilgisayarlar için geliştirilmiş sistemleri kullanarak iletişim kuruyordu. Özellikle ABD Hükümeti'nin ARPANET'inde daha fazla bilgisayar birbirine bağlandıkça, farklı işletim sistemleri arasında mesaj alışverişi yapmak için standartlar geliştirildi. SMTP, 1970'lerde geliştirilen bu standartların bir sonucuydu. ARPANET'teki posta kökleri 1971'e kadar uzanır: Uygulanmayan ancak RFC 196 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'da tartışılan Posta Kutusu Protokolü ve aynı yıl BBN'den Ray Tomlinson'ın iki bilgisayar arasında mesaj göndermek için uyarladığı SNDMSG programı. Bir Posta Protokolü için daha fazla öneri, Haziran 1973'te RFC 524'te yapılmıştır, ancak uygulanmamıştır. ARPANET'te "ağ postası" için Dosya Aktarım Protokolü (FTP) kullanımı, Mart 1973'te RFC 469'da önerilmiştir. RFC 561, RFC 680, RFC 724 ve son olarak Kasım 1977'de RFC 733 ile FTP posta sunucuları kullanarak "elektronik posta" için standart bir çerçeve geliştirildi.

1980 yılında Jon Postel ve Suzanne Sluizer, e-posta için FTP kullanımının yerine geçecek olan Posta Aktarım Protokolü'nü öneren RFC 772 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'yi yayınladılar. Mayıs 1981'deki RFC 780 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi., FTP'ye yapılan tüm atıfları kaldırdı ve TCP ve UDP için 57 numaralı port tahsis edildi (bu tahsis IANA tarafından o zamandan beri kaldırılmıştır). Kasım 1981'de Postel, "Basit Posta Aktarım Protokolü" olan RFC 788 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'i yayınladı.

SMTP standardı Usenet ile aynı zamanda geliştirildi ve bazı benzerlikleri olan birçok kişiye iletişim ağıydı.

SMTP, erken 1980'lerde yaygın olarak kullanılmaya başladı. O zamanlar, aralıklı olarak bağlı olan makineler arasında e-posta transferlerini işlemek için daha uygun olan Unix to Unix Kopya Programı (UUCP) ile tamamlanmıştı. Öte yandan, SMTP gönderen ve alıcı makinelerin her zaman ağa bağlı olduğunda en iyi şekilde çalışır. Her ikisi de depolama ve ileri mekanizması kullanan ve itme teknolojisi örnekleridir. Usenet'in haber grupları hala sunucular arasında UUCP ile yayıldıysa da, mesaj yönlendirme başlıkları olarak kullandığı "bang paths" ile birlikte UUCP bir posta taşıma yöntemi olarak neredeyse yok oldu.

1983'te 4.1cBSD ile yayınlanan Sendmail, SMTP'yi uygulayan ilk posta aktarım ajanlarından biriydi. Zaman içinde, BSD Unix İnternet'teki en popüler işletim sistemi haline geldiğinde, Sendmail en yaygın MTA (posta aktarım ajanı) haline geldi.

Orijinal SMTP protokolü, yalnızca doğrulanmamış, şifrelenmemiş 7-bit ASCII metin iletişimlerini desteklerken, basit bir ara kişi saldırısına, sahte kimlik oluşturma ve istenmeyen posta gönderimine karşı hassastı ve herhangi bir ikili verinin aktarım öncesi okunabilir metne kodlanmasını gerektiriyordu. Uygun bir kimlik doğrulama mekanizması yokluğundan dolayı, tasarım gereği her SMTP sunucusu açık bir posta röle olarak kabul ediliyordu. Internet Mail Consortium (IMC), 1998 yılında mail sunucularının %55'inin açık röle olduğunu bildirdi, ancak 2002'de bu oran %1'in altına düştü. Spam endişeleri nedeniyle, çoğu e-posta sağlayıcısı açık röleleri engellerken, orijinal SMTP, genel kullanım için Internet'te neredeyse kullanılamaz hale geldi.

Kasım 1995'te RFC 1869 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi., tüm mevcut ve gelecekteki uzantıların eksik özellikleri eklemeyi amaçladığı genel bir yapıyı belirleyen Genişletilmiş Basit Posta Aktarım Protokolünü (ESMTP) tanımladı. ESMTP, ESMTP istemcilerinin ve sunucularının tanımlanabileceği tutarlı ve yönetilebilir yöntemler belirler ve sunucular desteklenen uzantıları gösterir.

Mesaj gönderimi (RFC 2476 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.) ve SMTP-AUTH (RFC 2554 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.), e-posta teslimatındaki yeni eğilimleri açıklayan 1998 ve 1999 yıllarında tanıtıldı. Öncelikle SMTP sunucuları, bir kuruluşun dışından gelen postayı alıp kuruluş için iletilerini iletmek üzere kuruluş içindeydi. Ancak zamanla, SMTP sunucuları (posta transfer ajanları), uygulamada, bazıları kuruluşun dışından posta ileten Posta kullanıcı ajanları için mesaj gönderim ajanları haline geldiler. (Örneğin, bir şirket yöneticisi, kurumsal SMTP sunucusunu kullanarak seyahatteyken e-posta göndermek istiyor.) Bu sorun, Dünya Çapında Ağ'ın hızlı genişlemesi ve popülerliği sonucu, kötüye kullanımı önlemek için özel kurallar ve yöntemler içeren SMTP'ye dahil edilmesi gerekiyordu, örneğin istenmeyen e-posta (spam) iletmenin önlenmesi için kullanıcıların doğrulanması. Mesaj gönderimi (RFC 2476) üzerindeki çalışmalar, popüler posta sunucularının sık sık postayı düzeltmek için yeniden yazması nedeniyle başlatıldı, örneğin, tanımlanmamış bir adrese bir etki alanı adı eklemek. Bu davranış, ilk gönderim olan mesaj düzeltme için faydalıdır, ancak başka bir yerden kaynaklanan ve iletilen mesajlarda tehlikeli ve zararlıdır. Mesajı gönderim ve iletim olarak temiz bir şekilde ayırmak, gönderimleri yeniden yazmanın ve iletimleri yeniden yazmayı yasaklamanın bir yolu olarak görüldü. Spam daha yaygın hale geldikçe, bir kuruluştan gönderilen postalar için yetkilendirme sağlamak ve izlenebilirlik sağlamak için bir yol olarak da görülmüştür. İleti ve gönderim arasındaki bu ayrım, modern e-posta güvenliği uygulamalarının temelini oluşturdu.

Bu protokol başlangıçta sadece ASCII metin tabanlı olduğu için, ikili dosyalar veya birçok yabancı dildeki karakterlerle iyi başa çıkamadı. Multipurpose Internet Mail Extensions (MIME) gibi standartlar, ikili dosyaların SMTP aracılığıyla aktarılması için kodlama yöntemleri geliştirildi. Sendmail'den sonra geliştirilen posta aktarım ajanları (MTA) genellikle 8 bit temiz olarak uygulandı, böylece SMTP aracılığıyla herhangi bir 8 bit ASCII benzeri karakter kodlamasında herhangi bir metin verisi göndermek için "sadece sekiz gönder" stratejisi kullanılabilirdi. Mojibake, farklı karakter kümesi eşleştirmeleri nedeniyle hala bir sorundu, ancak e-posta adresleri yalnızca ASCII'yi desteklediği için bu sorun sadece gövde metniyle ilgilendi. Bugün 8-bit temiz MTA'lar genellikle 8BITMIME uzantısını desteklerler, bu da bazı ikili dosyaların düz metin gibi neredeyse kolayca iletilmesine izin verir (satır uzunluğu ve izin verilen oktet değerlerine yönelik sınırlamalar hala geçerlidir, bu nedenle çoğu metin olmayan veri ve bazı metin biçimleri için MIME kodlaması gereklidir). 2012'de SMTPUTF8 uzantısı oluşturuldu, UTF-8 metni desteklemek için, Kiril veya Çince gibi Latin olmayan yazıtlar içeren uluslararası içerik ve adreslere izin vererek. Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin ve Keith Moore gibi birçok kişi, temel SMTP özelliklerine katkıda bulunmuştur.

Mavi oklar SMTP varyasyonlarının uygulanmasını gösterir E-posta, bir posta istemcisi (posta kullanıcı arayüzü, MUA) tarafından TCP bağlantı noktası 587'de SMTP kullanarak bir posta sunucusuna (posta gönderim ajanı, MSA) gönderilir. Çoğu posta kutusu sağlayıcısı hala geleneksel bağlantı noktası 25 üzerinden gönderim yapmaya izin vermektedir. MSA, postayı posta transfer ajanına (posta transfer ajanı, MTA) teslim eder. Çoğu durumda, bu iki ajan aynı makinede farklı seçeneklerle başlatılan aynı yazılım örnekleridir. Yerel işlem, tek bir makine üzerinde veya birden fazla makine arasında bölünebilir. Bir makinedeki posta ajanı işlemleri dosyaları paylaşabilir, ancak işlem birden fazla makine üzerinde yapılıyorsa, makineler birbirleriyle SMTP kullanarak mesajları aktarır, her makine bir sonraki makineyi akıllı ana bilgisayar olarak kullanacak şekilde yapılandırılmıştır. Her işlem kendi MTA'sında (kendi SMTP sunucusunda) gerçekleştirilir.

Sınır MTA, alıcının alanının (e-posta adresinin sağ tarafındaki bölüm) MX (posta değiştirici) kaydını DNS üzerinden arar. MX kaydı hedef MTA'nın adını içerir. Gönderen MTA, hedef ana makineye ve diğer faktörlere bağlı olarak bir alıcı sunucusu seçer ve posta değişimini tamamlamak için ona bağlanır.

Mesaj transferi iki MTA arasında tek bir bağlantıda veya ara sistemler arasında bir dizi atlayışta gerçekleşebilir. Bir alıcı SMTP sunucusu, nihai hedef olabilir, bir ara "röle" (yani mesajı saklar ve iletir) veya bir "geçit" (yani mesajı SMTP'den farklı bir protokol kullanarak iletir) olabilir. RFC 5321 30 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. bölüm 2.1'e göre, her atlayış bir mesaj için sorumlulukların resmi bir devri olup, alıcı sunucu mesajı teslim etmelidir veya bunu yapamamanın başarısızlığını doğru bir şekilde bildirmelidir.

Son aşama, gelen iletiyi kabul eden son sunucudur ve yerel dağıtım için bir posta teslim ajanına (MDA) aktarılır. MDA, ilgili posta kutusu formatında mesajları kaydeder. Gönderme işlemi gibi, bu alım işlemi de bir veya birden fazla bilgisayar kullanılarak yapılabilir, ancak yukarıdaki diyagramda MDA, posta değiştirici kutusuna yakın bir kutu olarak tasvir edilmiştir. MDA, mesajları doğrudan depolamaya teslim edebilir veya bu amaçla SMTP veya Local Mail Transfer Protocol (LMTP) gibi başka bir protokol üzerinden ağda iletebilir.

Yerel posta sunucusuna teslim edildikten sonra, posta yetkilendirilmiş posta istemcileri (MUAs) tarafından toplu olarak alınmak üzere depolanır. Posta, Internet Mesaj Erişim Protokolü (IMAP) veya geleneksel mbox posta dosyası formatını kullanan Posta Ofisi Protokolü (POP) gibi protokoller kullanılarak, Microsoft Exchange / Outlook veya Lotus Notes / Domino gibi özel sistemler veya web tabanlı posta istemcileri tarafından alınabilir. Ancak alım protokolü genellikle resmi bir standart değildir.

SMTP, mesaj içeriğini değil mesaj taşımacılığını tanımlar. Bu nedenle, posta zarfını ve zarf gönderen gibi parametrelerini tanımlar, ancak başlık (iz bilgisi hariç) veya mesajın gövdesini tanımlamaz. STD 10 ve RFC 5321 30 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi., SMTP'yi (zarfı) tanımlarken, STD 11 ve RFC 5322 5 Ağustos 2021 tarihinde Wayback Machine sitesinde arşivlendi., mesajı (başlık ve gövde) tanımlar ve resmen İnternet Mesaj Formatı olarak adlandırılır.

SMTP (Simple Mail Transfer Protocol) bir bağlantı odaklı, metin tabanlı bir protokoldür. Bir posta göndericisi, güvenilir bir sıralı veri akışı kanalı üzerinden genellikle Transmission Control Protocol (TCP) bağlantısı kullanarak gerekli verileri sağlayarak komut dizileri vererek bir posta alıcısıyla iletişim kurar. Bir SMTP oturumu, bir SMTP istemcisinden (başlatıcı ajan, gönderen veya verici) kaynaklanan komutlardan ve SMTP sunucusundan (dinleyen ajan veya alıcı) karşılık gelen yanıtlardan oluşur, böylece oturum açılır ve oturum parametreleri değiştirilir. Bir oturumda sıfır veya daha fazla SMTP işlemi olabilir. Bir SMTP işlemi, üç komut/yankı dizisinden oluşur:

1. Geri dönüş adresini (return-path, reverse-path, bounce adresi, mfrom veya zarf gönderen olarak da bilinir) belirlemek için MAIL komutu.
2. Mesajın bir alıcısını belirlemek için RCPT komutu. Bu komut, her bir alıcının biri için tekrarlanabilir. Bu adresler ayrıca zarfın bir parçasıdır.
3. İleti metninin başlangıcını bildirmek için DATA. İletinin zarfından farklı olarak, içeriği mesaj başlığı ve bir boş satır tarafından ayrılmış bir mesaj gövdesinden oluşur. DATA aslında bir dizi komuttur ve sunucu iki kez yanıt verir: birincisi, metnin alınmaya hazır olduğunu doğrulamak için DATA komutu kendisi için, ikincisi ise verinin sonu işaretlendiğinde, tüm mesajı kabul etmek veya reddetmek için.

DATA'nın ara yanıtı dışında, her sunucu yanıtı olumlu (2xx yanıt kodları) veya olumsuz olabilir. Olumsuz yanıtlar kalıcı (5xx kodları) veya geçici (4xx kodları) olabilir. Bir reddetme kalıcı bir hatadır ve istemci, ondan aldığı sunucuya bir geri dönüş mesajı göndermelidir. Bir düşürme, teslimat yerine olumlu bir yanıtın ardından mesajın reddedilmesini takip eder.

Başlatan ana bilgisayar (SMTP istemcisi) ya bir son kullanıcının e-posta istemcisi olarak işlev gören bir posta kullanıcı ajanı (MUA) ya da postayı aktarmak için bir SMTP sunucusu olarak hareket eden bir SMTP sunucusu olan bir röle sunucusunun posta transfer ajanı (MTA) olabilir. Tamamen yetenekli SMTP sunucuları, geçici hatalara neden olan mesaj iletimlerinin yeniden deneme kuyruklarını tutarlar.

Bir MUA, yapılandırmasından çıkan posta SMTP sunucusunu bilir. Bir geçiş sunucusu genellikle her alıcının etki alanı adı için MX (Mail eXchange) DNS kaynak kaydını arayarak hangi sunucuya bağlanılacağını belirler. Eğer MX kaydı bulunamazsa, uyumlu bir geçiş sunucusu (hepsi değil) bunun yerine A kaydını arar. Geçiş sunucuları ayrıca akıllı ana bilgisayar kullanacak şekilde yapılandırılabilir. Bir geçiş sunucusu, SMTP için "iyi bilinen bağlantı noktası" olan 25 numaralı bağlantı noktası veya MSA'ya bağlanmak için 587 numaralı bağlantı noktasında sunucuya bir TCP bağlantısı başlatır. MTA ve MSA arasındaki temel fark, MSA'ya bağlanmanın SMTP Kimlik Doğrulaması gerektirmesidir.

SMTP, sadece bir teslimat protokolüdür. Normal kullanımda, posta geldiği anda hedef posta sunucusuna (veya sonraki adım posta sunucusuna) "itilir". Posta, adreslendiği bireysel kullanıcılara değil, hedef sunucuya göre yönlendirilir. Diğer protokoller, örneğin Posta Ofisi Protokolü (POP) ve İnternet Mesaj Erişim Protokolü (IMAP), özel olarak bireysel kullanıcıların mesajları almasına ve posta kutularını yönetmesine olanak tanımak için tasarlanmıştır. Aralıklı olarak bağlanan bir posta sunucusunun isteğe bağlı olarak uzak bir sunucudan mesajları almasına izin vermek için, SMTP'nin bir özelliği, uzaktaki bir sunucuda posta kuyruğu işleme başlatmak için (aşağıda Uzak Mesaj Kuyruğu Başlatma) vardır. POP ve IMAP, aralıklı olarak bağlanan makineler tarafından posta iletme için uygun olmayan protokollerdir; posta iletme işleminin doğru çalışması için kritik bilgilerin (posta zarfı) kaldırıldığı son teslimattan sonra çalışacak şekilde tasarlanmışlardır.

"Remote Message Queue Starting", Türkçeye "Uzaktan Mesaj Kuyruğu Başlatma" olarak çevrilebilir. Bu özellik, bir uzak ana bilgisayarın, ilgili bir komut göndererek sunucudaki posta kuyruğunun işlenmesini başlatmasına ve kendisine yönlendirilen iletileri almasına olanak tanır. Orijinal TURN komutu güvenli olmadığı için RFC 1985 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. ile ETRN komutuyla genişletilmiştir. ETRN komutu, Alan Adı Sistemi bilgilerine dayalı bir kimlik doğrulama yöntemi kullanarak daha güvenli bir şekilde çalışır.

Bir e-posta istemcisi, yapılandırmasının bir parçası olarak (genellikle bir DNS adı olarak verilir), başlangıç SMTP sunucusunun IP adresini bilmelidir. Bu sunucu, kullanıcının adına giden mesajları iletecektir.

Sunucu yöneticileri, hangi istemcilerin sunucuyu kullanabileceği konusunda bir kontrol uygulamak zorundadır. Bu, örneğin spam gibi kötüye kullanımla başa çıkmalarını sağlar. İki çözüm yaygın olarak kullanılmaktadır:

• Geçmişte birçok sistem, istemcinin konumuna göre kullanım kısıtlamaları uyguladı ve yalnızca sunucu yöneticilerinin kontrol ettiği IP adreslerine sahip istemcilerin kullanımına izin verdi. Herhangi başka bir istemci IP adresinden kullanım engellendi.
• Modern SMTP sunucuları genellikle erişimi konumla sınırlamak yerine istemcilerin kimlik bilgileriyle kimlik doğrulamasını gerektiren alternatif bir sistem sunar.

Bu sistem altında, bir ISP'nin SMTP sunucusu, ISP'nin ağı dışında olan kullanıcılara erişime izin vermez. Daha doğrusu, sunucu yalnızca ISP tarafından sağlanan bir IP adresine sahip kullanıcılara erişime izin verebilir, bu da aynı ISP'yi kullanarak internete bağlanmalarını gerektirir. Bir mobil kullanıcı genellikle normal ISP'sinin ağından farklı bir ağda olabilir ve yapılandırılmış SMTP sunucusu seçimi artık erişilebilir olmadığı için e-posta gönderme işlemi başarısız olabilir.

Bu sistemde birkaç varyasyon vardır. Örneğin, bir kuruluşun SMTP sunucusu, organizasyon içinde sadece aynı ağdaki kullanıcılara hizmet sağlayabilir ve bu, kullanıcıların İnternet'in geniş kapsamındaki kullanıcıların erişimini engelleyen bir güvenlik duvarı kullanarak zorunlu kılınabilir. Veya sunucu, istemcinin IP adresi üzerinde aralık kontrolü yapabilir. Bu yöntemler genellikle sadece organizasyon içinde dışa doğru e-posta için bir SMTP sunucusu sağlayan şirketler ve üniversiteler gibi kurumlar tarafından kullanılırdı. Ancak, çoğu kurum artık aşağıda açıklandığı gibi istemci kimlik doğrulama yöntemlerini kullanıyor.

Bir kullanıcının mobil olduğu ve internete bağlanmak için farklı İnternet Servis Sağlayıcıları kullanabileceği durumlarda, bu tür kullanım kısıtlamaları yorucu olabilir ve yapılandırılmış çıkış e-postası SMTP sunucusu adresini değiştirmek pratik değildir. Değişmeyen bir e-posta istemci yapılandırma bilgisi kullanmak istemek oldukça arzu edilir.

Modern SMTP sunucuları genellikle, önceden açıklanan gibi konum bazlı erişim kısıtlaması yerine, istemcilerin kimlik bilgileriyle kimlik doğrulamasını gerektirir. Bu daha esnek sistem mobil kullanıcılara dostça bir yaklaşımdır ve onlara yapılandırılmış çıkış SMTP sunucusu seçiminde sabit bir seçenek sağlar. SMTP kimlik doğrulaması, genellikle SMTP AUTH olarak kısaltılır ve bir kimlik doğrulama mekanizması kullanarak giriş yapmak için SMTP'nin bir uzantısıdır.

Posta sunucuları arasındaki iletişim genellikle SMTP için ayrılmış standart TCP portu 25 kullanılarak yapılır.

Ancak posta istemcileri genellikle bunu kullanmaz, bunun yerine özel "gönderim" portları kullanılır. Posta hizmetleri genellikle müşterilerden gelen e-posta gönderimini aşağıdaki bağlantı noktalarından birinde kabul eder:

587 (Gönderim), RFC 6409 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'da (daha önce RFC 2476 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'da) belirtildiği gibi 465 Bu port, RFC 2487 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'den sonra kaldırılmıştır, ancak RFC 8314' 6 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. ün çıkmasına kadar sorunlu kalmıştır. Port 2525 ve diğerleri bazı bireysel sağlayıcılar tarafından kullanılabilir, ancak resmi olarak desteklenmemiştir.

Birçok İnternet servis sağlayıcısı artık müşterilerinden giden tüm 25 numaralı bağlantı noktası trafiğini engellemektedir. Bunun başlıca nedeni spam önleme tedbiri olmakla birlikte, açık bırakmanın yüksek maliyeti nedeniyle belki de yalnızca açık olan az sayıdaki müşterilerinden daha fazla ücret talep ederek tedavi etmektedir.

SMTP aracılığıyla aynı posta alanına (example.com) bağlı iki posta kutusuna (alice ve theboss) mesaj gönderme örneği, aşağıdaki oturum değişimiyle yeniden üretilmiştir. (Bu örnekte, konuşma parçaları sunucu ve istemci için sırasıyla S: ve C: ile ön eklenmiştir; bu etiketler exchange'in(değişimin) bir parçası değildir.)

Mesaj gönderen (SMTP istemcisi), mesaj alıcısına (SMTP sunucusu) güvenilir bir iletişim kanalı oluşturduktan sonra, oturumu genellikle FQDN'sini (tam nitelikli etki alanı adını) içeren bir karşılama ile açar, bu örnekte smtp.example.com. İstemci, FQDN'si (veya mevcut değilse bir adres anlamsalı) ile kendini tanımlayan bir komutla yanıt vererek diyalogunu başlatır.

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: RCPT TO:<theboss@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.org>
C: To: "Alice Example" <alice@example.com>
C: Cc: theboss@example.com
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}

İstemci, mesajın kaynak e-posta adresini bildirmek için MAIL FROM komutunu kullanarak alıcıyı bilgilendirir. Bu ayrıca mesajın teslim edilememesi durumunda geri dönüş veya bounce adresidir. Bu örnekte e-posta mesajı aynı SMTP sunucusunda bulunan iki posta kutusuna gönderilir: To: ve Cc: başlık alanlarında listelenen her bir alıcı için bir adet. Karşılık gelen SMTP komutu RCPT TO'dur. Her bir komutun başarılı bir şekilde alınması ve işleme konulması sunucu tarafından bir sonuç kodu ve yanıt mesajı ile onaylanır (örneğin, 250 Ok).

Mail mesajının gövdesinin aktarımı, bir DATA komutuyla başlatılır ve ardından kelimesi kelimesine aktarılır ve sonuçlandırıcı bir veri dizisiyle sonlandırılır. Bu dizi, bir yeni satır (<CR><LF>), tek bir tam nokta (.) ve başka bir yeni satır (<CR><LF>) içerir. Bir mesaj gövdesi, metin olarak bir periyod içeren bir satır içerebileceğinden, istemci, her bir satır periyodla başladığında iki periyod gönderir; buna karşılık, sunucu, her bir satırın başındaki iki periyod dizisini tek bir periyoda dönüştürür. Bu kaçırma yöntemi nokta-doldurma olarak adlandırılır.

Sunucunun mesajın teslimiyle ilgili olumlu yanıtı, örnekteki gibi, sunucunun mesajın tesliminden sorumlu olduğu anlamına gelir. Bu sırada bir iletişim hatası olması durumunda mesaj iki kez gönderilebilir, örneğin bir güç kesintisi nedeniyle: Gönderen, 250 Ok yanıtını alana kadar mesajın teslim edilmediğini varsaymalıdır. Öte yandan, alıcı mesajı kabul etmeye karar verdiğinde, mesajın kendisine teslim edildiğini varsaymalıdır. Bu nedenle, bu süre boyunca, her iki aracın da teslim etmeye çalışacakları aktif kopyaları vardır. İletinin gövdesinde yaptığı filtreleme miktarıyla doğru orantılı olarak, bir iletişim hatası bu adımda tam olarak oluşma olasılığı, genellikle istenmeyen e-postaların engellenmesi için yapılacak filtreleme işlemiyle ilgilidir. Sınırlayıcı zaman aşımı 10 dakika olarak belirlenmiştir.

QUIT komutu oturumu sonlandırır. Eğer e-postanın başka alıcıları farklı bir yerde bulunuyorsa, müşteri mevcut hedefler için kuyruğa alındıktan sonra QUIT yapacak ve sonraki alıcılar için uygun bir SMTP sunucusuna bağlanacaktır. Müşterinin HELO ve MAIL FROM komutlarında gönderdiği bilgiler, alıcı sunucu tarafından ek header alanları olarak mesaja eklenir. Sırasıyla, Received ve Return-Path header alanları eklenir.

Bazı istemciler, mesaj kabul edildikten sonra bağlantıyı kapatarak uygulanır (250 Ok: queued as 12345), bu nedenle son iki satır aslında atlanabilir. Bu, sunucunun 221 Bye yanıtını göndermeye çalışırken bir hata oluşmasına neden olur.

Aşağıdaki örnekte görüldüğü gibi, istemciler orijinal HELO yerine EHLO selamı kullanarak sunucunun desteklediği seçenekleri öğrenirler. Sunucu EHLO selamını desteklemiyorsa, istemciler HELO'ya geri dönerler.

Modern istemciler, ESMTP uzantı anahtar kelimesi SIZE'ı kullanarak sunucudan kabul edilebilecek maksimum mesaj boyutunu sorgulayabilirler. Daha eski istemciler ve sunucular, dakika başına ödenen ağ bağlantılarına bağlanarak ağ kaynaklarını tüketen ve reddedilecek aşırı boyutlu mesajları aktarmaya çalışabilirler.

Kullanıcılar, ESMTP sunucularının kabul ettiği maksimum boyutu önceden manuel olarak belirleyebilirler. İstemci, HELO komutunu EHLO komutuyla değiştirir.

S: 220 smtp2.example.com ESMTP Postfix
C: EHLO bob.example.org
S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201]
S: 250-SIZE 14680064
S: 250-PIPELINING
S: 250 HELP

Bu şekilde, smtp2.example.com'un, 14.680.064 oktet (8-bit bayt) büyüklüğünde sabit bir maksimum mesaj boyutunu kabul edebileceği belirtilir.

En basit durumda, bir ESMTP sunucusu, EHLO aldıktan hemen sonra maksimum boyutunu belirtir. Ancak RFC 1870 6 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'e göre, EHLO yanıtındaki SIZE uzantısının sayısal parametresi isteğe bağlıdır. İstemciler, bir MAIL FROM komutu verirken, aktardıkları mesajın boyutu için sayısal bir tahmin dahil edebilirler, böylece sunucu aşırı büyük mesajların alınmasını reddedebilir.

Orijinal SMTP yalnızca tek bir ASCII metin gövdesini desteklediğinden, herhangi bir ikili veri, mesaj gövdesine aktarım öncesinde metin olarak kodlanmalı ve ardından alıcı tarafından çözülmelidir. Genellikle uuencode ve BinHex gibi ikili-veriye-metin kodlamaları kullanılırdı.

Bu sorunu çözmek için 8BITMIME komutu geliştirilmiştir. 1994 yılında RFC 1652 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. olarak standartlaştırılmıştır. Bu, MIME içerik bölümleri olarak kodlanarak, genellikle Base64 ile kodlanan yedi bitlik ASCII karakter kümesi dışındaki octetler içeren e-posta mesajlarının şeffaf bir şekilde değiş tokuşunu kolaylaştırır.

Ana madde: On-Demand Mail Relay

On-Demand Mail Relay (ODMR), yani İsteğe Bağlı Posta Aktarımı, RFC 2645 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'te standartlaştırılmış bir SMTP uzantısıdır ve aralıklı olarak bağlantı sağlayan bir SMTP sunucusunun, bağlandığında sıraya alınmış e-postaları almasına olanak tanır.

Uluslararası karakter setlerini ve ASCII karakter setinde olmayan diakritik işaretleri kullanan kullanıcılar için ASCII karakterleriyle oluşan e-posta adreslerinin kullanımı zor olduğundan, orijinal SMTP'ye UTF-8'ın adres adlarında kullanımını sağlayan uzantılar eklendi. RFC 5336 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi., deneysel UTF8SMTP komutunu tanıttı ve daha sonra SMTPUTF8 komutunu tanıtan RFC 6531 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. tarafından yerini aldı. Bu uzantılar, diakritik işaretler ve Yunanca ve Çince gibi diğer dil karakterleri gibi çok baytlı ve ASCII olmayan karakterlerin e-posta adreslerinde kullanımına olanak sağlar.

Mevcut destek sınırlı olsa da, özellikle Latin (ASCII) karakterlerinin yabancı bir karakter seti olduğu büyük bir kullanıcı tabanına sahip olan Çin gibi ülkelerde RFC 6531 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. ve ilgili RFC'lerin yaygın olarak benimsenmesi için yoğun ilgi vardır.

ESMTP, İnternet postasını taşımak için kullanılan bir protokoldür. Hem bir sunucu arasında taşıma protokolü olarak hem de (kısıtlı davranışlarla zorunlu) bir posta gönderme protokolü olarak kullanılır.

ESMTP istemcileri için ana tanımlama özelliği, orijinal RFC 821 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. standardı olan HELO yerine genişletilmiş bir "HELLO" komutu olan EHLO ile iletişim kurmaktır. Bir sunucu, yapılandırmasına bağlı olarak başarılı (kod 250), başarısız (kod 550) veya hata (kod 500, 501, 502, 504 veya 421) yanıtı verir. ESMTP sunucusu, desteklenen uzantıları göstermek için alan adı ve anahtar kelime listesi ile bir çoklu satır yanıtında kod 250 OK döndürür. RFC 821 uyumlu bir sunucu, hata kodu 500 döndürür, böylece ESMTP istemcileri HELO veya QUIT deneyebilirler.

Her hizmet uzantısı, IANA (Internet Assigned Numbers Authority) tarafından kaydedilen sonraki RFC'lerde onaylanmış bir formatta tanımlanır. İlk tanımlar RFC 821 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. isteğe bağlı hizmetleridir: SEND, SOML (Send or Mail), SAML (Send and Mail), EXPN, HELP ve TURN. Ek SMTP fiillerinin biçimi ve MAIL ve RCPT'teki yeni parametreler için tanımlanmıştır.

Bugün kullanılan nispeten yaygın bazı anahtar kelimeler (hepsi komutlara karşılık gelmez) şunlardır:

• 8BITMIME – 8 bit veri iletimi, RFC 6152 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.
• ATRN – İsteğe Bağlı Posta Geçişi için Kimliği Doğrulanmış TURN, RFC 2645 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.
• AUTH – Doğrulanmış SMTP, RFC 4954^[]
• CHUNKING – Parçalama, RFC 3030 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.
• DSN – Teslimat durumu bildirimi,, RFC 3461 6 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.
• ETRN – Uzak ileti sırası başlatma komutu TURN'un genişletilmiş sürümü, RFC 1985 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.
• HELP –Yararlı bilgiler sağlayın,, RFC 821 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.
• PIPELINING – Komut ardışık düzen oluşturma, RFC 2920 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.
• SIZE – Mesaj boyutu bildirimi, RFC 1870 6 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.
• STARTTLS – Aktarım Katmanı Güvenliği, RFC 3207 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. (2002)
• SMTPUTF8 – Posta kutusu adlarında ve başlık alanlarında UTF-8 kodlamasına izin ver, RFC 6531 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.
• UTF8SMTP – Posta kutusu adlarında ve başlık alanlarında UTF-8 kodlamasına izin ver, RFC 5336 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. (deprecated)

ESMTP formatı RFC 2821 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'de (RFC 821 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'in yerine geçen) yeniden belirtildi ve en son tanımı 2008'de RFC 5321 30 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'de güncellendi. Sunucularda EHLO komutuna destek zorunlu hale geldi ve HELO bir zorunlu yedek olarak belirlendi.

Kayıtlı olmayan standart dışı hizmet uzantıları karşılıklı anlaşmayla kullanılabilir. Bu hizmetler, "X" ile başlayan bir EHLO mesajı anahtar kelimesiyle ve benzer şekilde işaretlenmiş herhangi bir ek parametre veya fiil ile belirtilir.

SMTP komutları büyük-küçük harf duyarsızdır. Burada vurgu yapmak için büyük harfle sunulmuşlardır. Belirli bir büyük harfleme yöntemi gerektiren bir SMTP sunucusu, standartların ihlalidir.

En azından aşağıdaki sunucular 8BITMIME uzantısını tanıtmaktadır:

• Apache James (since 2.3.0a1)
• Citadel (since 7.30)
• Courier Mail Server
• Gmail
• IceWarp
• IIS SMTP Service
• Kerio Connect
• Lotus Domino
• Microsoft Exchange Server (as of Exchange Server 2000)
• Novell GroupWise
• OpenSMTPD
• Oracle Communications Messaging Server
• Postfix
• Sendmail (since 6.57)

Aşağıdaki sunucular, 8BITMIME'i duyurmak için yapılandırılabilir, ancak 8 bitlik verileri 7 bitlik olmayan bir relaya bağlanırken dönüştürmezler:

• Exim ve qmail, RFC tarafından gerektirilen şekilde, 8 bitlik verileri 7 bitlik verilere dönüştürmeden, 8 bitlik veri iletimi yapmaya çalışırken 7 bitlik veri alıcılarına iletim yapmazlar. Bu, pratikte her şeyin 8 bit temiz olması nedeniyle sorun yaratmaz.
• Microsoft Exchange Server 2003, varsayılan olarak 8BITMIME'i duyurur, ancak 8BITMIME desteği olmayan bir alıcıya iletim yapıldığında bir atışla sonuçlanır. Bu, RFC 6152 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. bölüm 3 tarafından izin verilir.

SMTP-AUTH uzantısı bir erişim kontrol mekanizması sağlar. Gönderme işlemi sırasında istemcinin posta sunucusuna gerçekten giriş yaptığı bir kimlik doğrulama adımından oluşur. SMTP-AUTH'ı destekleyen sunucular genellikle istemcilerin bu uzantıyı kullanmasını gerektirecek şekilde yapılandırılabilir, böylece gönderenin gerçek kimliği bilinir. SMTP-AUTH uzantısı RFC 4954 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi.'te tanımlanmıştır.

SMTP-AUTH, yasal kullanıcılara posta iletmesine izin verirken spam göndericileri gibi izinsiz kullanıcılara iletme hizmeti sağlamayı engellemek için kullanılabilir. Bu, SMTP zarf göndereninin veya RFC 2822 31 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. "From:" başlığının otantikliğini kesin olarak garanti etmez. Örneğin, sahtekarlık, bir göndericinin bir başkası gibi davranması, SMTP-AUTH ile mümkündür, AUTH kullanıcısı için yetkilendirilmiş adreslere sınırlandırılmış olmadığı sürece.

SMTP-AUTH uzantısı ayrıca bir posta sunucusunun, posta iletirken gönderenin doğrulandığını başka bir sunucuya bildirmesine olanak tanır. Genel olarak, bu, alıcı sunucunun gönderen sunucuya güvenmesini gerektirir, bu nedenle SMTP-AUTH'ın bu yönü İnternet'te nadiren kullanılır.

Desteklenen sunucular şunları içerir:

• Postfix (version 3.0 and later)
• Momentum (versions 4.1 and 3.6.5, and later)
• Sendmail (experimental support in 8.17.1)
• Exim (experimental as of the 4.86 release, quite mature in 4.96)
• CommuniGate Pro as of version 6.2.2
• Courier-MTA as of version 1.0
• Halon as of version 4.0
• Microsoft Exchange Server as of protocol revision 14.0
• Haraka and other servers.
• Oracle Communications Messaging Server as of release 8.0.2.

Posta teslimi, hem düz metin hem de şifreli bağlantılar üzerinden gerçekleşebilir. Ancak iletişim kuran taraflar, diğer tarafın güvenli kanal kullanma yeteneğinden önceden haberdar olmayabilir.

STARTTLS uzantısı, destekleyen SMTP sunucularının, TLS şifreli iletişimi desteklediğini bildirerek bağlanan istemcilere, bağlantılarını yükseltme fırsatı sunan STARTTLS komutunu göndermesine olanak tanır. Uzantıyı destekleyen sunucular, bağlantıyı yükseltmek isteyen istemcilerin bu seçeneği kullanmaya karar vermesine bağlı olduğu için, yalnız başına herhangi bir güvenlik avantajı elde etmezler, bu nedenle fırsatçı TLS terimi kullanılır.

STARTTLS, yalnızca pasif gözlem saldırılarına karşı etkilidir, çünkü STARTTLS müzakeresi açık metinde gerçekleşir ve bir aktif saldırgan, STARTTLS komutlarını kolayca kaldırabilir. Bu tür bir man-in-the-middle saldırısı bazen STRIPTLS olarak adlandırılır, çünkü bir uçtan gönderilen şifreleme müzakeresi bilgileri diğerine asla ulaşmaz. Bu senaryoda, her iki taraf da geçersiz veya beklenmeyen yanıtları, diğerinin STARTTLS'yi doğru bir şekilde desteklemediği şeklinde bir işaret olarak alır ve geleneksel açık metinli e-posta transferine varsayılan olarak geçerler. STARTTLS ayrıca başka RFC'lerde IMAP ve POP3 için tanımlanmış olsa da, bu protokoller, SMTP mesaj transfer ajanları arasındaki iletişim için kullanılırken, IMAP ve POP3, son istemciler ve mesaj transfer ajanları içindir.

2014 yılında Elektronik Özgürlükler Derneği, "HTTPS Everywhere" listesi gibi, iletişim öncesi başka birinin güvenli iletişim desteğini keşfetmesine olanak tanıyan "STARTTLS Everywhere" projesini başlattı. Proje 29 Nisan 2021'de başvuruları kabul etmeyi durdurdu ve EFF, bilgileri keşfetmek için DANE ve MTA-STS'ye geçilmesini önerdi.

RFC 8314 6 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi., açık metnin artık modası geçtiğini ve posta gönderimi ve erişimi için her zaman TLS kullanılmasını, açık TLS bağlantı noktalarının eklenmesini önererek resmi olarak ilan etti.

2018 yılında yayınlanan daha yeni bir RFC 8461 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. olan "SMTP MTA Strict Transport Security (MTA-STS)", aktif saldırgan sorununu ele almayı amaçlayarak posta sunucularının belirli dosyalarda ve özel DNS TXT kayıtlarında güvenli kanalları kullanma yeteneklerini bildiren bir protokol tanımlamaktadır. Güvenen taraf, böyle bir kaydın varlığını düzenli olarak kontrol eder ve kayıtta belirtilen süre boyunca önbellekte tutar ve kayıt süresi dolana kadar güvensiz kanallar üzerinden iletişim kurmaz. MTA-STS kayıtları, kullanıcının istemci ve posta sunucusu arasındaki iletişimi SMTP / MSA, IMAP, POP3 veya HTTPS ile birleştirerek koruyan Taşıma Katmanı Güvenliği ile birlikte bir kurumsal veya teknik politikayla birlikte üçüncü taraflara böyle bir politikayı genişletmek için bir araçtır.

Nisan 2019'da Google Mail, MTA-STS'yi destekleyeceğini duyurdu.

Güvenli mesaj teslim etmek için tasarlanan protokoller, yanlış yapılandırmalar veya kasıtlı aktif müdahale nedeniyle teslim edilemeyen mesajlara veya şifrelenmemiş veya kimlik doğrulamasız kanallar üzerinden teslim edilmesine neden olabilir. RFC 8460 29 Mart 2023 tarihinde Wayback Machine sitesinde arşivlendi. "SMTP TLS Raporlama", alıcı alanlarla potansiyel saldırıları tespit etmek ve istenmeyen yapılandırmaları teşhis etmek için istatistikler ve belirli bilgiler paylaşmak için bir raporlama mekanizması ve formatı tanımlar.

Nisan 2019'da Google Mail, SMTP TLS Raporlama'yı destekleyeceğini duyurdu.

Ana maddeler: List of mail server software ve Comparison of mail servers

SMTP'nin orijinal tasarımı, gönderenleri kimlik doğrulamak veya sunucuların adına gönderme izni olup olmadığını kontrol etmek için herhangi bir araç sağlamamıştır, bu nedenle e-posta sahteciliği mümkün olmuştur ve e-posta spam ve dolandırıcılığında yaygın olarak kullanılmaktadır.

SMTP'yi geniş kapsamlı olarak değiştirme veya tamamen değiştirme önerileri ara sıra yapılır. Bu örneklerden biri Internet Mail 2000'dir, ancak ne bu ne de diğerleri, klasik SMTP'nin büyük kurulu tabanının ağ etkisi karşısında çok ilerleme kaydetmemiştir.

Bunun yerine, e-posta sunucuları artık RFC 5322 5 Ağustos 2021 tarihinde Wayback Machine sitesinde arşivlendi. gibi standartların daha sıkı uygulanması, DomainKeys Identified Mail, Gönderen Politika Çerçevesi ve DMARC, DNSBL'ler ve gri liste gibi teknikleri kullanarak şüpheli e-postaları reddetmek veya karantinaya almak için bir dizi teknik kullanmaktadır.

Ana maddeler: List of mail server software(Posta sunucusu yazılımları listesi) ve Comparison of mail servers (Posta sunucularının karşılaştırılması.)

• Hughes, L (1998). Internet E-mail: Protocols, Standards and Implementation. Artech House Publishers. ISBN 978-0-89006-939-4.^[4]
• Hunt, C (2003). sendmail Cookbook. O'Reilly Media. ISBN 978-0-596-00471-2.^[5]
• Johnson, K (2000). Internet Email Protocols: A Developer's Guide. Addison-Wesley Professional. ISBN 978-0-201-43288-6.^[6]
• Loshin, P (1999). Essential Email Standards: RFCs and Protocols Made Practical. John Wiley & Sons. ISBN 978-0-471-34597-8.^[7]
• Rhoton, J (1999). Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. Elsevier. ISBN 978-1-55558-212-8.^[8]
• Wood, D (1999). Programming Internet Mail. O'Reilly. ISBN 978-1-56592-479-6.^[9]

• RFC2821 SMTP 19 Şubat 2006 tarihinde Wayback Machine sitesinde arşivlendi.