Basit Posta Aktarım Protokolü

SMTP (Türkçe: Basit Posta Aktarım Protokolü), e-posta göndermek için sunucu ile istemci arasındaki iletişimi belirleyen protokoldür. Farklı işletim sistemleri için geliştirilmiş çeşitli e-posta protokolleri mevcuttur. Bu protokollerin SMTP , , ve son olarak Kasım 1977'de ile FTP posta sunucuları kullanarak "elektronik posta" için standart bir çerçeve geliştirildi.

İlkel SMTP
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 'yi yayınladılar. Mayıs 1981'deki RFC 780 , 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 '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 ) ü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.

Mail İşleme Modeli
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 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 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
ATRN – İsteğe Bağlı Posta Geçişi için Kimliği Doğrulanmış TURN, RFC 2645
AUTH – Doğrulanmış SMTP, RFC 4954
CHUNKING – Parçalama, RFC 3030
DSN – Teslimat durumu bildirimi, RFC 3461
ETRN – Uzak ileti sırası başlatma komutu TURN'un genişletilmiş sürümü, RFC 1985
HELP –Yararlı bilgiler sağlayın, RFC 821
PIPELINING – Komut ardışık düzen oluşturma, RFC 2920
SIZE – Mesaj boyutu bildirimi, RFC 1870
STARTTLS – Aktarım Katmanı Güvenliği, RFC 3207 (2002)
SMTPUTF8 – Posta kutusu adlarında ve başlık alanlarında UTF-8 kodlamasına izin ver, RFC 6531
UTF8SMTP – Posta kutusu adlarında ve başlık alanlarında UTF-8 kodlamasına izin ver, RFC 5336 (deprecated)

ESMTP formatı RFC 2821 'de (RFC 821 'in yerine geçen) yeniden belirtildi ve en son tanımı 2008'de RFC 5321 '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.

8BITMIME
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 bölüm 3 tarafından izin verilir.

SMTP-AUTH
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 '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 "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.

SMTPUTF8
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.

Güvenlik Uzantıları
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 veya "Fırsatçı TLS"
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 , 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.

SMTP MTA Sıkı Taşıma Güvenliği
2018 yılında yayınlanan daha yeni bir RFC 8461 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.

SMTP TLS Raporlaması
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 "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.

Adres Sahteciliği Ve Spam (Spoofing And Spamming)
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 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.

Uygulamalar
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ı.)

Kaynakça
Hughes, L (1998). Internet E-mail: Protocols, Standards and Implementation. Artech House Publishers. ISBN 978-0-89006-939-4.
Hunt, C (2003). sendmail Cookbook. O'Reilly Media. .
Johnson, K (2000). Internet Email Protocols: A Developer's Guide. Addison-Wesley Professional. .
Loshin, P (1999). Essential Email Standards: RFCs and Protocols Made Practical. John Wiley & Sons. .
Rhoton, J (1999). Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. Elsevier. .
Wood, D (1999). Programming Internet Mail. O'Reilly. .

TTNet IRC Lord
RFC2821 SMTP

Kaynakça