Passa al contenuto principale

1. Introduzione (Introduction)

L'obiettivo del Simple Mail Transfer Protocol (SMTP, Protocollo Semplice di Trasferimento Posta) è trasferire la posta in modo affidabile ed efficiente.

SMTP è indipendente dal particolare sottosistema di trasporto e richiede solo un canale di flusso dati ordinato e affidabile. Sebbene questo documento si concentri specificamente sull'uso di SMTP su TCP, altri trasporti sono possibili. Le appendici di questo documento forniscono informazioni importanti su TCP e altri dettagli di implementazione.

1.1. Trasporto della posta elettronica (Transport of Electronic Mail)​

La posta elettronica viene trasferita da un server all'altro fino a raggiungere il sistema di destinazione. Più precisamente, la posta viene trasferita da un agente di trasferimento messaggi (Message Transfer Agent, MTA) a un altro utilizzando SMTP. L'MTA di destinazione è responsabile della consegna della posta alla mailbox dell'utente o del suo inoltro a un altro sistema.

Gli utenti non interagiscono direttamente con SMTP. Invece:

  • Gli user agent (UA, agenti utente) o mail submission agent (MSA, agenti di sottomissione posta) sottomettono la posta agli MTA
  • Gli mail access agent (MAA, agenti di accesso posta) permettono agli utenti di recuperare la posta dalle mailbox utilizzando protocolli come POP3 o IMAP

1.2. Storia e contesto di questo documento (History and Context for This Document)​

SMTP fu specificato per la prima volta in RFC 821 nell'agosto 1982. Da allora, è stato oggetto di numerosi aggiornamenti e chiarimenti:

  • RFC 821 (1982): Specifica SMTP originale
  • RFC 1123 (1989): Requisiti per gli host Internet - chiarì e aggiornò SMTP
  • RFC 1869 (1995): Introdusse il meccanismo di estensione del servizio SMTP (ESMTP)
  • RFC 2821 (2001): Consolidò e chiarì le specifiche precedenti
  • RFC 5321 (2008): Questo documento - specifica attuale

Questo documento rende obsoleto RFC 2821 e aggiorna RFC 1123. Incorpora l'esperienza e le migliori pratiche degli ultimi due decenni di deployment SMTP su Internet.

Modifiche chiave rispetto a RFC 2821​

  1. Chiarimenti: Linguaggio più preciso sul comportamento dei comandi
  2. Migliori pratiche: Raccomandazioni aggiornate basate sull'esperienza operativa
  3. Considerazioni sulla sicurezza: Guida alla sicurezza ampliata
  4. Interoperabilità: Guida migliorata per gestire i sistemi legacy

1.3. Convenzioni del documento (Document Conventions)​

Le parole chiave "MUST" (DEVE), "MUST NOT" (NON DEVE), "REQUIRED" (RICHIESTO), "SHALL" (DEVE), "SHALL NOT" (NON DEVE), "SHOULD" (DOVREBBE), "SHOULD NOT" (NON DOVREBBE), "RECOMMENDED" (RACCOMANDATO), "MAY" (PUÒ) e "OPTIONAL" (OPZIONALE) in questo documento devono essere interpretate come descritto in RFC 2119.

Significato delle parole chiave RFC 2119​

  • MUST / REQUIRED / SHALL: Requisito assoluto della specifica
  • MUST NOT / SHALL NOT: Divieto assoluto
  • SHOULD / RECOMMENDED: Possono esistere motivi validi per ignorare, ma le implicazioni devono essere comprese
  • SHOULD NOT / NOT RECOMMENDED: Possono esistere motivi validi quando il comportamento è accettabile, ma le implicazioni devono essere comprese
  • MAY / OPTIONAL: L'elemento è veramente opzionale

Notazioni​

In questo documento:

  • Gli esempi di protocollo usano "C:" per le righe del client e "S:" per le righe del server
  • La sintassi è specificata usando Augmented Backus-Naur Form (ABNF, Forma Aumentata di Backus-Naur) come definita in RFC 5234
  • I termini definiti in questo documento sono evidenziati al loro primo utilizzo

Esempio di sessione SMTP​

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
C: MAIL FROM:<[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
C: 
C: This is a test message.
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
Ultimo aggiornamento il