4. Le specifiche SMTP (The SMTP Specifications)
Questa sezione contiene specifiche dettagliate per comandi SMTP, risposte, sequenze, informazioni di traccia e problemi di implementazione.
4.1. Comandi SMTP (SMTP Commands)
I comandi SMTP sono parole ASCII insensibili alle maiuscole di quattro caratteri (alcuni estesi a otto caratteri), opzionalmente seguiti da parametri. Le specifiche complete per tutti i comandi SMTP (EHLO, HELO, MAIL FROM, RCPT TO, DATA, RSET, VRFY, EXPN, HELP, NOOP, QUIT) con sintassi, semantica ed esempi sono descritte in dettaglio in RFC 5321 Sezione 4.1.1.
4.2. Risposte SMTP (SMTP Replies)
4.2.1. Gravità e teoria dei codici di risposta (Reply Code Severities and Theory)
I codici di risposta sono numeri a tre cifre:
- 2yz: Completamento positivo
- 3yz: Intermedio positivo
- 4yz: Completamento negativo transitorio (riprovabile)
- 5yz: Completamento negativo permanente (non riprovare)
4.2.2. Codici di risposta per gruppi funzionali (Reply Codes by Function Groups)
Codici importanti: 220 (servizio pronto), 250 (Ok), 354 (inizio dati), 421 (servizio non disponibile), 450/550 (mailbox non disponibile), 500 (errore di sintassi), 554 (transazione fallita).
4.3. Sequenziamento di comandi e risposte (Sequencing of Commands and Replies)
SMTP è lock-step: il client invia un comando, attende la risposta, poi invia il comando successivo. Eccezione: l'estensione PIPELINING permette l'elaborazione batch.
4.4. Informazioni di traccia (Trace Information)
Ogni server SMTP aggiunge un campo header Received quando accetta un messaggio:
Received: from sender.example.com (host.example.com [192.0.2.1])
by receiver.example.com (Postfix) with ESMTP id 12345
for <[email protected]>; Mon, 24 Dec 2024 10:00:00 +0000 (UTC)
4.5. Problemi di implementazione aggiuntivi (Additional Implementation Issues)
4.5.1. Implementazione minima (Minimum Implementation)
Un SMTP completamente funzionale DEVE (MUST) supportare: comandi EHLO, MAIL, RCPT, DATA, RSET, NOOP, QUIT, tutti i codici di risposta standard, logica di accodamento e retry, gestione errori appropriata.
4.5.2. Trasparenza (Transparency)
I server DEVONO (MUST) gestire il dot-stuffing: le righe che iniziano con . devono essere sfuggite come .. durante la trasmissione DATA.
4.5.3. Dimensioni e timeout (Sizes and Timeouts)
Requisiti minimi: Local-part 64 ottetti, Domain 255 ottetti, Path 256 ottetti, Riga comando 512 ottetti, Riga risposta 512 ottetti, Riga testo 1000 ottetti, Buffer destinatari 100 destinatari.
Timeout: Messaggio 220 iniziale 5 minuti, Comando MAIL 5 minuti, Comando RCPT 5 minuti, Avvio DATA 2 minuti, Blocco DATA 3 minuti, Terminazione DATA 10 minuti.
4.5.4. Strategie di retry (Retry Strategies)
Per fallimenti transitori (codici 4yz): Riprovare almeno ogni 30 minuti, continuare i tentativi per almeno 4-5 giorni, inviare avvisi al mittente a intervalli, generare rimbalzo dopo fallimento finale.
4.5.5. Messaggi con percorso inverso nullo (Messages with a Null Reverse-Path)
I messaggi di rimbalzo usano MAIL FROM:<> (percorso inverso nullo) per evitare loop di posta. I server DEVONO (MUST) accettare il percorso inverso nullo ma NON DEVONO (MUST NOT) generare rimbalzi per essi.