SMTP posta aktarım harekatı üç aşamada gerçekleşir. Harekat, göndericiyi tanıtan bir
MAIL komutu ile başlar. (Genelde,
MAIL komutu sadece hiçbir posta aktarımı olmayacağı zaman da gönderilebilir; bkz,
Komutların Sırası.) Bunu alıcıların bilgilerini veren bir veya daha fazla
RCPT komutu izler. Ardından da posta verisinin aktarımını başlatıp sonunda "posta sonu" veri belirteci ile aktarımı sonlandırmakla ayrıca aktarım onayını da sağlayan
DATA komutu gelir.
Süreçteki ilk adım MAIL komutudur.
MAIL FROM:<dönüş-yolu> [ BOŞKRK <posta-parametreleri> ] <CRLF>
Bu komut SMTP alıcısına yeni bir posta aktarım harekâtının başladığını, alıcılar ve posta verisi dahil olmak üzere tüm durum tablolarını ve tamponları sıfırlamasını söyler. <
dönüş-yolu> kısmı ilk, belki de tek argümandır ve hataları raporlamakta kullanılacak kaynak posta kutusunu ( "<" ve ">" arasında) içerir (hataları raporlama ile ilgili olarak
SMTP Yanıtları bölümüne bakınız). Eğer kabul edilirse, SMTP sunucusu bir 250 OK yanıtı gönderir.
Eğer posta kutusu belirtimi bazı sebeplerle kabul edilebilir değilse, sunucu hatanın kalıcı mı yoksa geçici mi olduğunu belirten bir yanıt vermelidir *ZORUNLU* (kalıcı ise kalıcı olduğunu belirtmelidir ki, istemci aynı adresi tekrar denerse hatanın tekrarlanacağını bilsin; geçici ise geçici oluğunu belirtmelidir ki, istemci bir süre sonra tekrar denediğinde postanın kabul edilebileceğini bilsin). Bu gereksinimin böylesine apaçık oluşuna rağmen, dönüş yolunun kabul edilebilirliğinin bir veya daha fazla sevk yolu (
RCPT komutlarında bulunur) incelenebilir olana kadar saptanabilir olmayacağı bazı durumlar vardır. Bu durumlarda,
sunucu makul olanı yapıp dönüş yolunu (bir 250 yanıtı ile) kabul edebilir ve sevk yollarını alıp inceledikten sonra sorunu raporlayabilir *SEÇİMLİK*. Normalde, başarısızlık 550 ve 553 yanıtları üretir.
Tarihsel olarak,
<dönüş-yolu> tek bir posta kutusundan fazlasını içerebilir, ancak, çağdaş sistemler kaynak yönlendirmesini kullanmasalar iyi olur *ÖNERİ* (bkz,
Kaynak Rotalar).
İsteğe bağlı <
posta-parametreleri> uzlaşılacak SMTP hizmet eklentileri ile ilgilidir (bkz,
Eklenti Modeli).
Sürecin ikinci adımını RCPT komutu oluşturur.
RCPT TO:<sevk-yolu> [ BOŞKRK <alım-parametreleri> ] <CRLF>
Bu komutun ilk, belki de tek argümanı bir alıcıyı betimleyen sevk yolunu içerir (normalde, bir posta kutusu ve alan'dan oluşur ve daima "<" ile ">" arasında belirtilir). Eğer kabul edilirse, SMTP sunucusu bir 250 OK yanıtı gönderir ve sevk yolunu bir yere kaydeder. Eğer alıcının teslimat yapılabilir bir adres olmadığı biliniyorsa, SMTP sunucusu bir 550 koduyla genellikle posta kutusu için "no such user - " (böyle bir kullanıcı yok - ...) gibisinden bir dizge içeren bir yanıt yollar (başka durumlar ve yanıt kodları mümkündür). Harekâtın bu aşaması defalarca yinelenebilir.
<
sevk-yolu> tek bir posta kutusundan fazlasını içerebilir. Tarihsel olarak,
<sevk-yolu> konakların ve hedef posta kutularının oluşturduğu bir kaynak yönlendirme listesi olabilir, yine de, çağdaş SMTP istemcileri kaynak rotaları dikkate almasalar daha iyi olur *ÖNERİ* (bkz,
Kaynak Rotalar).
Sunucuların bir kaynak rota listesi karşılamaya hazır olmalarının gerekmesine *ZORUNLU* karşın,
bu rotaları yoksaymaları daha iyidir *ÖNERİ*,
hatta ifade ettikleri rölelemeyi desteklemeyi reddedebilirler *SEÇİMLİK*. Benzer şekilde,
sunucular başka konakları ve sistemleri hedefleyen postaları kabul etmeyi reddedebilirler *SEÇİMLİK*. Bu kısıtlamalar bir sunucuyu, SMTP işlevselliğini tamamen desteklemeyen istemciler için bir röle olarak kullanışsız yapar. Sonuç olarak,
yetenekleri kısıtlı istemciler, Genel Ağ'daki herhangi bir SMTP sunucusunu kendi posta işleme (röleleme) siteleri gibi kullanabileceklerini varsaymamalıdırlar *ZORUNLU*.
Eğer bir RCPT komutu evveliyatında bir MAIL komutu olmaksızın alınmışsa, sunucunun 503 koduyla bir "Bad sequence of commands" (Komut sıralaması hatalı) yanıtı vermesi gerekir *ZORUNLU*. İsteğe bağlı <
alım-parametreleri> uzlaşılacak SMTP hizmet eklentileri ile ilgilidir (bkz,
Eklenti Modeli).
Sürecin üçüncü adımını DATA komutu oluşturur (veya bir hizmet eklentisinde belirtilmiş bir eşdeğeri).
Kabul edilirse, SMTP sunucu 354 koduyla bir aracı yanıt gönderir ve tüm başarılı satırların üstesinden gelebileceğini fakat ileti metninde olası bir posta verisi sonu belirtecinin buna dahil olmadığını varsayar. Metin sonu başarılı şekilde alındığında ve kaydedildiğinde SMTP alıcısı 250 OK yanıtını gönderir.
Posta verisi aktarım kanalı üzerinden gönderildiğinden, posta verisi sonu belirtilmelidir ki, komut ve yanıt alışverişi kaldığı yerden devam edebilsin. SMTP, posta verisinin sonunu sadece tek bir nokta (".") içeren bir satır göndererek belirtir. Bunun kullanıcı metniyle etkileşime girmesini engellemek için şeffaf bir yordam kullanılır (bkz,
Şeffaflık).
Posta verisi sonu belirteci ayrıca posta aktarımının onaylanması anlamına gelir ve SMTP sunucusuna kayıtlı alıcıları ve posta verisini artık işleme sokmasını söyler. Kabul edilirse, SMTP sunucu bir 250 OK yanıtı gönderir. DATA komutu protokol alışverişinde sadece iki noktada başarısız olabilir:
Ne MAIL ne de RCPT komutu varsa veya böyle tüm komutlar reddedilmişse, sunucu DATA komutuna yanıt olarak 503 koduyla bir "command out of sequence" (komut sıra dışı) veya 554 koduyla bir "no valid recipients" (alıcılar geçersiz) yanıtı gönderebilir *SEÇİMLİK*. Bu yanıtlardan biri (veya 5yz kodlu başka bir yanıt) alındığında, istemcinin ileti verisini göndermemesi gerekir *ZORUNLU*; daha genel olarak, ileti verisi bir 354 yanıtı alınmadıkça gönderilmemelidir *ZORUNLU*.
Eğer fiil baştan kabul edilmiş ve 354 yanıtı verilmişse, DATA komutu sadece, posta aktarımı tamamlanmamışsa (örn, alıcılar yoktur) veya özkaynaklar kullanımdışıysa (sunucunun beklenmedik şekilde kullanımdışı kalmasını da dahil ederek) ya da iletinin kural ihlali veya başka bir sebeple reddedildiği sunucu tarafından saptanmışsa başarısız sayılır.
Bununla birlikte, bazı sunucular uygulamada, ileti metni alınana kadar alıcı varlık doğrulaması yapmaya çalışmazlar.
Bu sunucular bir veya daha fazla alıcı için bir başarısızlığı bir "ardçıl başarısızlık" olarak ele almaları ve Sorun Saptama ve Giderme bölümünde açıklandığı gibi bir posta iletisi göndermeleri daha iyi olur *ÖNERİ*. "550 mailbox not found" (posta kutusu yok) veya eşdeğeri bir yanıt kodunun veri kabul edildikten sonra kullanımı, istemci açısından hangi alıcının başarısız olduğunun saptanmasını zor hatta imkansız hale getirir.
RFC 822 biçimi [
7,
32] kullanıldığında, posta verisi bilgi neviinden
Date, Subject, To, Cc, From gibi başlık öğeleri içerir. Sunucu SMTP sistemleri,
RFC 822 veya MIME [12] ileti başlığı veya ileti gövdesindeki farkedilir kusurlara dayalı iletileri reddetmeseler iyi olur *ÖNERİ*. Özellikle,
Resent-fields sayısının uyuşmadığı veya Resent-to'nun Resent-from ve/veya Resent-date olmaksızın göründüğü iletileri reddetmemeleri gerekir *ZORUNLU*.
Posta aktarım harekâtı komutları yukarıdaki sırasıyla kullanılmalıdır *ZORUNLU*.