Ciclo di vita dell'e-mail dopo l'invio


13

Stavo testando la configurazione STARTTLS del mio server di posta quando mi sono imbattuto in questa pagina: https://starttls.info/about . Il seguente estratto mi confonde:

Quando invii un'email tramite il tuo server di posta in uscita, quell'e-mail eseguirà potenzialmente più salti tra diversi server di posta prima di raggiungere la sua destinazione. Tutti questi server intermedi dovranno avere un forte supporto STARTTLS, affinché il tuo messaggio non venga esposto in una o più fasi del suo viaggio.

Compresi che il processo di invio di un'e-mail era il seguente:

  1. Il server di posta esegue una ricerca DNS per ottenere l'MX del nome di dominio del destinatario.
  2. Il server di posta avvia una connessione all'IP ottenuto sulla porta 25 (SMTP).
  3. Se entrambi i server supportano la crittografia opportunistica, viene stabilita una connessione sicura.
  4. L'e-mail viene recapitata al destinatario (EHLO, MAIL FROM :, RCPT TO :, DATA,.)

Ora, dove in tutto ciò c'è un'opportunità per l'e-mail di rimbalzare su più server?


1
Prendi un'e-mail ricevuta, guarda le intestazioni. Ogni riga "Ricevuto:" mostra un sistema attraversato dalla posta. Potrebbero esserci diversi sistemi sullo stesso host (ad esempio un filtro antispam o uno scanner di virus), per lo più riconoscibili dall'indirizzo "localhost". Ma il resto saranno tutti gli host che hanno gestito quell'email. Almeno nella misura in cui sono conformi a RFC e lasciano una di quelle intestazioni "Ricevute:".
Dubu,

Risposte:


19

La posta viene regolarmente rimbalzata tra i server. Ad esempio, se invio un'email a un amico, potrebbe:

  • Vai dal mio computer al mio server di posta (si spera crittografato)
  • Il mio server di posta lo invia al suo smarthost, poiché è configurato per non inviare direttamente la posta
  • Lo smarthost lo invia al record MX del dominio di destinazione, che risulta essere un filtro antispam ospitato
  • Il filtro antispam tenta di inviarlo al vero server di posta della destinazione, ma è irraggiungibile, quindi utilizza l'MX secondario, un sistema ospitato che archivia la sua e-mail nel caso in cui il vero server di posta sia inattivo.
  • Viene eseguito il backup del server di posta reale, l'MX secondario invia l'e-mail al server di posta di destinazione.
  • I miei amici scaricano la sua e-mail dal suo server di posta.

Questa è una configurazione abbastanza comune e fa rimbalzare l'e-mail circa 6 volte. Alla fine arriva dove sta andando, ma a meno che tutti quei server non utilizzino STARTTLS o altra crittografia, ad alcuni punti non sarà crittografato. Anche con la crittografia di trasporto, l'amministratore di uno di questi server potrebbe ancora leggere l'e-mail. Viene archiviato non crittografato sui loro dischi rigidi mentre attende di essere inviato allo stadio successivo.

Potrebbero essercene facilmente di più se il mio amico avesse impostato la sua e-mail per l'inoltro da qualche altra parte, il che è comune se anche il tuo provider di web hosting fa la tua e-mail e la inoltri al tuo account Gmail.

Se sei preoccupato per le persone che leggono la tua e-mail, la cosa migliore da fare è crittografare il messaggio usando qualcosa come GPG, non fare affidamento sulla crittografia del trasporto. Naturalmente, ciò richiede che anche la persona che riceve l'e-mail si preoccupi abbastanza di impostare GPG e scambiare le chiavi.


La ringrazio per la risposta! Accettato per chiarezza (scusate TomTom, ma anche il vostro è stato fantastico!). Bel tocco sottolineando che le e-mail vengono archiviate in chiaro sui server intermedi: non vedo STARTTLS come qualcosa di diverso da una difesa contro l'ascolto passivo.
Executifs

@Executifs senza offesa. Detto questo: "statl come qualsiasi altra cosa": una difesa contro il passaparola passivo è fondamentale. Entrambe le parti controllano praticamente tutti i server intermedi (relè di invio, relè di ricezione) ma non hanno alcun controllo sul cavo. Al giorno d'oggi, in cui Obama e altri funzionari leggono le e-mail di tutto il mondo per notizie sulla colazione (daramatization) che crittografano la strada tra i server è super critico.
TomTom,

@TomTom Mi dispiace, sembra che il mio commento non sia stato chiaro. Volevo dire che per me STARTTLS è principalmente una difesa contro enormi capacità di intercettazione e non trasmette gli occhi indiscreti dell'amministratore (per i quali GPG sarebbe una soluzione). Quindi sono completamente d'accordo con te su questo.
Executifs

7

Prova questo: il server che invii non è quello che termina. è il MIO server gateway per le e-mail in arrivo che sta facendo delle belle cose anti-spam e le inoltra al vero server.

Va ancora meglio. Il server di invio e-mail che usi non è quello che la tua azienda utilizza su Internet. NON esegue una ricerca DNS ma inoltra tutte le e-mail a un server gateway che POI le invia al destinatario finale. Questa non è una configurazione rara nelle organizzazioni più grandi.

Mantengo un sistema come quello in cui più reti condividono un server gateway comune per le e-mail in entrata e in uscita. Le e-mail in arrivo vengono inoltrate a uno di più server, a seconda del client.

Sul sito in arrivo potrebbe anche essere che il vero server di posta elettronica sia inattivo. MX può modificare le voci di backup e, in alcuni casi, queste semplicemente buffereranno l'e-mail e la inoltreranno di nuovo una volta che il server reale sarà nuovamente disponibile.


Tutte queste cose, oltre agli alias.
Nick

3

Come hai delineato è praticamente come funziona su tutta la linea.

Esistono ancora server di posta intermedi, ma generalmente sono i server pubblici a cui si connette il server di origine. Tale server può inoltrare il messaggio a un server interno in base a un numero qualsiasi di regole, come nome utente, ora, caricamento, contenuto (spam), ecc.

Spero che queste organizzazioni o fornitori di terze parti supportino le stesse funzionalità in tutto. La posta non deve passare attraverso un server di posta sconosciuto alla fonte o alla destinazione, poiché tutti gli intermediari devono essere di proprietà o gestiti da una parte fidata.


L'ultima frase non è nemmeno vicina al vero; prova dig mx insolvency.gsi.gov.ukuno dei tanti esempi di routing della posta attraverso server di proprietà né di origine né di destinazione. Oppure invia la posta a uno dei domini della legione che hanno la posta gestita da Gmail.
MadHatter,

2
Hai ragione. L'ho espresso male e intendevo dire che la posta non doveva essere instradata attraverso un server di posta di terze parti sconosciuto mentre era in transito verso la destinazione finale. Che eventuali server di posta intermedi, se non di proprietà dell'origine o della destinazione, siano almeno conosciuti e gestiti da una parte fidata. Ho modificato la risposta, grazie per il chiarimento.
David Houde,

Quello che hai ora è molto più vicino al modo in cui credo che tutto funzioni, quindi ho rimosso il mio voto negativo.
MadHatter

Per aggiungere al commento di @ MadHatter, qualcuno che utilizza un tale servizio di posta esterno può anche dimenticare di implementare diverse altre funzionalità di sicurezza (come SPF).
Hagen von Eitzen,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.