3. Le procedure SMTP: panoramica (The SMTP Procedures: An Overview)
Questa sezione fornisce una panoramica delle operazioni SMTP, inclusi avvio della sessione, transazioni di posta, verifica degli indirizzi, relay, gateway e terminazione della sessione.
3.1. Avvio della sessione (Session Initiation)
Una sessione SMTP (SMTP session) viene avviata quando l'SMTP mittente (client) stabilisce un canale di trasmissione bidirezionale con l'SMTP ricevente (server). Il canale è completamente asincrono e non ci sono restrizioni sul flusso di dati. Dopo aver completato la connessione TCP, il server normalmente invia una risposta "220 Service ready" (servizio pronto). Il client normalmente inizia le operazioni dopo aver ricevuto questo saluto.
3.2. Avvio del client (Client Initiation)
Dopo che il servizio di trasporto ha fornito il canale di avvio e il server ha inviato il saluto 220 servizio pronto, il client normalmente invia il comando EHLO (EHLO command) per identificarsi e richiedere al server di informarlo sulle estensioni di servizio disponibili. Se il server non supporta le estensioni, risponderà a EHLO con un errore 500, e il client DOVREBBE (SHOULD) ripiegare sul comando HELO (HELO command).
Esempio di comando EHLO:
S: 220 smtp.example.com ESMTP Postfix
C: EHLO client.example.com
S: 250-smtp.example.com
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 HELP
3.3. Transazioni di posta (Mail Transactions)
Una transazione di posta (mail transaction) consiste in una serie di comandi dal client al server per trasferire un messaggio. Una transazione di posta include:
- Comando MAIL - Identifica il mittente del messaggio
- Uno o più comandi RCPT - Identifica il/i destinatario/i del messaggio
- Comando DATA - Invia il contenuto del messaggio
Esempio di transazione completa:
C: MAIL FROM:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: [email protected]
C: To: [email protected]
C: Subject: Test message
C:
C: This is a test message.
C: .
S: 250 Ok: queued as 12345
Il comando MAIL avvia la transazione di posta. Il completamento riuscito di questo comando fa sì che il ricevente cancelli tutti i buffer e le tabelle di stato e si prepari a ricevere comandi RCPT.
Il comando RCPT identifica un singolo destinatario di questa posta. Più comandi RCPT possono essere emessi per un particolare messaggio. Ogni comando RCPT riuscito aggiunge un destinatario al buffer.
Il comando DATA fa sì che le righe successive siano trattate come testo del messaggio piuttosto che come comandi. Il messaggio è terminato da una riga contenente solo un punto (.).
3.4. Inoltro per correzione o aggiornamento indirizzo (Forwarding for Address Correction or Updating)
Alcuni server potrebbero voler inoltrare la posta a un indirizzo corretto o aggiornato piuttosto che all'indirizzo del destinatario originale. SMTP fornisce i codici di risposta 251 e 551 (response codes) per questo scopo. Questi codici permettono al server di informare il client che l'indirizzo dell'utente è cambiato, ma che il server tenterà di inoltrare il messaggio (251) o non può inoltrarlo (551).
3.5. Comandi per il debug degli indirizzi (Commands for Debugging Addresses)
3.5.1. Panoramica (Overview)
SMTP fornisce due comandi per verificare nomi utente e mailing list:
- VRFY - Verifica un nome utente o mailbox
- EXPN - Espande una mailing list
Questi comandi sono principalmente per scopi di debug e molti server li disabilitano o li limitano per motivi di sicurezza e privacy.
3.5.2. Risposta normale VRFY (VRFY Normal Response)
Una risposta riuscita al comando VRFY è normalmente il codice 250 seguito da testo contenente il nome completo dell'utente e l'indirizzo della mailbox.
Esempio:
C: VRFY Jones
S: 250 Fred Jones <[email protected]>
3.5.3. Significato della risposta di successo VRFY o EXPN (Meaning of VRFY or EXPN Success Response)
Una risposta riuscita ai comandi VRFY ed EXPN non garantisce che l'indirizzo possa ricevere posta o che la posta sarà consegnata. Indica semplicemente che l'indirizzo è noto al server ed è sintatticamente valido.
3.5.4. Semantica e applicazioni di EXPN (Semantics and Applications of EXPN)
Il comando EXPN viene utilizzato per espandere una mailing list o un alias. Restituisce tutti gli indirizzi nella lista.
Esempio:
C: EXPN staff
S: 250-Alice <[email protected]>
S: 250-Bob <[email protected]>
S: 250 Charlie <[email protected]>
3.6. Relay e routing della posta (Relaying and Mail Routing)
3.6.1. Route di origine e relay (Source Routes and Relaying)
Il routing di origine (source routing) (specificare esplicitamente un percorso attraverso host intermedi) è deprecato nell'SMTP moderno. Il routing della posta DOVREBBE (SHOULD) basarsi sui record MX DNS.
3.6.2. Record di scambio posta e relay (Mail eXchange Records and Relaying)
Il sistema di record MX (Mail eXchanger) DNS viene utilizzato per identificare i server di posta responsabili dell'accettazione della posta per un dominio. Quando si consegna posta:
- Cercare i record MX per il dominio di destinazione
- Ordinare per priorità (numero inferiore = priorità superiore)
- Tentare la consegna ai server in ordine di priorità
- Se tutti i record MX falliscono, tentare la consegna diretta ai record A/AAAA
Esempio di record MX DNS:
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
example.com. IN MX 30 mail3.example.com.
3.6.3. Server di sottomissione messaggi come relay (Message Submission Servers as Relays)
I Message Submission Agent (MSA, Agenti di Sottomissione Messaggi) funzionano come relay speciali che:
- Accettano posta dai Mail User Agent (MUA, Agenti Utente Posta)
- Applicano politiche di sottomissione
- Aggiungono header necessari
- Autenticano i mittenti
- Inoltrano agli MTA appropriati
3.7. Gateway della posta (Mail Gatewaying)
Un gateway di posta (mail gateway) collega l'infrastruttura SMTP ad altri sistemi di posta (es. X.400, UUCP). I gateway traducono tra protocolli e formati.
3.7.1. Campi header nel gatewaying (Header Fields in Gatewaying)
I gateway DEVONO (MUST) preservare i campi header obbligatori e POSSONO (MAY) aggiungere campi specifici del gateway. La traduzione DEVE (MUST) mantenere l'equivalenza semantica quando possibile.
3.7.2. Righe Received nel gatewaying (Received Lines in Gatewaying)
I gateway DEVONO (MUST) aggiungere campi header Received per tracciare il percorso del messaggio:
- Identificazione del gateway
- Timestamp
- Informazioni sul protocollo
3.7.3. Indirizzi nel gatewaying (Addresses in Gatewaying)
La traduzione degli indirizzi è complessa e specifica del gateway. I gateway DOVREBBERO (SHOULD):
- Preservare le informazioni originali sull'indirizzo
- Fornire mappatura bidirezionale degli indirizzi
- Documentare le regole di traduzione
3.7.4. Altri campi header nel gatewaying (Other Header Fields in Gatewaying)
I gateway DEVONO (MUST) gestire correttamente vari campi header:
- From, To, Cc, Bcc (campi indirizzo)
- Subject, Keywords (campi di testo)
- Date (conversione timestamp)
- Message-ID (conservazione identificatore univoco)
3.7.5. Buste nel gatewaying (Envelopes in Gatewaying)
Le buste SMTP (MAIL FROM e RCPT TO) possono differire dagli indirizzi header. I gateway DEVONO (MUST) gestire correttamente entrambi.
3.8. Terminazione di sessioni e connessioni (Terminating Sessions and Connections)
Una sessione SMTP viene terminata con il comando QUIT:
C: QUIT
S: 221 smtp.example.com closing connection
Dopo aver inviato la risposta 221, il server chiude la connessione TCP. Il client DOVREBBE (SHOULD) attendere la risposta 221 prima di chiudere, ma DEVE (MUST) essere preparato che il server chiuda per primo.
Terminazione anormale: In caso di errore grave, una delle parti può chiudere immediatamente la connessione. Il server PUÒ (MAY) utilizzare il codice di risposta 421 per indicare che il servizio non è disponibile prima di chiudere.
3.9. Mailing list e alias (Mailing Lists and Aliases)
3.9.1. Alias (Alias)
Un alias (alias) è un nome di mailbox che, quando risolto, si riferisce a uno o più altri nomi di mailbox. L'espansione degli alias è trasparente per il mittente.
Esempio: [email protected] potrebbe essere un alias per [email protected]
3.9.2. Liste (Lists)
Una mailing list (mailing list) è simile a un alias ma tipicamente ha:
- Gestione tramite software di lista
- Permette iscrizione/disiscrizione
- Può modificare messaggi (aggiungere header, footer)
- Mantiene un database di iscritti
Quando la posta viene inviata a una lista, viene espansa e consegnata a tutti gli iscritti. Il software di lista tipicamente:
- Aggiunge header specifici della lista (List-ID, List-Unsubscribe)
- Può richiedere moderazione
- Gestisce i rimbalzi
- Mantiene archivi