Perché i client di posta elettronica non sono in grado di vedere la busta?

Alternatively, if I am incorrect about this: then in what way?

Questa parte della domanda era parzialmente errata:

[Email] servers, when receiving mail over SMTP, are not required to record the SMTP envelope values in a way that makes them available for retrieval by email clients. [E.g. adding] envelope information to the headers of emails before delivering them to the user ... does not seem to be required by any standards documents...

La busta SMTP ha due valori (sto usando "value" sinonimo di "campo" qui):

1. il campo MAIL FROM, noto anche come argomento "reverse-path" per il comando SMTP MAIL;
2. il campo RCPT-TO.

RFC 5321 §4.4 mandati copia del valore MAIL FROM in un intestazione email:

When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. This use of return-path is required; mail systems MUST support it. The return-path line preserves the information in the <reverse-path> from the MAIL command. Here, final delivery means the message has left the SMTP environment. Normally, this would mean it had been delivered to the destination user or an associated mail drop, but in some cases it may be further processed and transmitted by another mail system.

RFC 5321 §4.4 consente di copiare il valore RCPT-TO in un'intestazione email:

When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content...

... e una delle informazioni che può essere legittimamente inclusa nell'intestazione "Received" è il "percorso" pertinente (indirizzo email, essenzialmente) dal valore RCPT-TO della busta . *

E, naturalmente, le intestazioni delle email sono disponibili per il recupero da parte dei client di posta elettronica.

* (Altri percorsi, se presenti nel campo RCPT-TO, non dovrebbero essere inclusi, per RFC 5321 §7.2: "Specialmente quando è presente più di un comando RCPT, e per evitare di sconfiggere alcuni dei lo scopo dei meccanismi [BCC o mailing list], i client ei server SMTP NON DEVE copiare l'intero set di argomenti del comando RCPT nella sezione dell'intestazione, come parte dei campi dell'intestazione di traccia o come campi di intestazione dell'estensione informativa o privata. ")

Alternatively, if I am incorrect about this: then in what way?

Stai confrontando le mele con le arance.

L'intestazione dell'e-mail è più simile alla busta della posta fisica - ancora meglio, l'intestazione dell'email rappresenta le informazioni di routing non accessibili al destinatario nella posta fisica. Quindi non è corretto dire che l'accesso del client di posta elettronica alle "informazioni sulla busta" è ostacolato. Infatti, in base alla progettazione, gli aspetti importanti delle "informazioni sulla busta" vengono iniettati nell'intestazione, assicurando che le intestazioni delle e-mail contengano informazioni di routing di gran lunga superiori a quelle che potrebbero ottenere i destinatari della posta fisica.

Alcune definizioni (assumendo la posta degli Stati Uniti per semplicità):

Busta e-mail : i valori trasmessi utilizzando i comandi HELO / EHLO, MAIL FROM e RCPT SMTP. Ognuno di questi può legittimamente cambiare da un salto a quello successivo.

Intestazione email : il testo trasmesso dopo il comando SMTP DATA, fino alla prima riga vuota, dopo di che inizia il corpo dell'email. Questo probabilmente include un Da: (che può o non può essere d'accordo con la Busta MAIL DA) e un A: (che può o meno essere d'accordo con l'intestazione Envelope RCPT TO). Questa intestazione email cresce man mano che ciascun server di posta intermedio invia le informazioni ricevute, come richiesto da RFC 5321 §3.7.2. Inoltre i server di posta dei destinatari possono registrare l'Envelope RCPT TO iniettando un'intestazione come Apparently-To, Delivered-To, X-Envelope-To, X-Original-To, ecc. (Ma vedere nota in calce qui sotto.

Busta fisica : l'indirizzo Da (facoltativo, l'angolo in alto a sinistra), l'indirizzo (centrale), il timbro di origine (in alto a destra, sopra il timbro). Potrebbero esserci ulteriori codifiche delle informazioni sul destinatario come il codice a barre IM e le codice a barre arancione , ma sono entrambe rappresentazioni effettivamente più o meno lossy dell'indirizzo A.

Si noti che RFC 5321 §3.6.3 suggerisce che i server di inoltro SMTP non debbano mai modificare nulla nell'intestazione e nel corpo tranne che per anteporre la riga Ricevuta richiesta. In pratica, vengono prepensionate altre intestazioni, in particolare con relè intermedi anti-SPAM / malware.

Ecco come l'intestazione dell'email incorpora le informazioni necessarie sulla busta

L'intestazione SMTP Received viene anteposta da ciascun server SMTP e descrive le informazioni Envelope su se stesso e sul server precedente. Considera questa voce:

Received: from mail2.example.com (mail2.example.com [192.168.3.4])
    by lix-xx.members.linode.com (Postfix) with ESMTPS id 838CD4AE0
    for <[email protected]>; Fri,  4 May 2012 12:45:26 -0400 (EDT)

Questo include il nome host EHLO / HELO (il primo mail2.example.com), l'IP reale (192.168.3.4) di quel sistema e il nome DNS che si risolve tramite PTR (il secondo mail2.example.com). Questa informazione è utile per individuare e-mail fraudolente.

Potrebbero essere registrate ulteriori informazioni sulla busta, come mostrato in questo esempio:

Received: from NAM01-SN1-obe.outbound.protection.outlook.com
    (mail-oln040092002074.outbound.protection.outlook.com [40.92.2.74])
    by smtp21.example.org (Postfix) with ESMTP id AF320401EE
    for <[email protected]>;
    Wed,  5 Dec 2018 15:28:59 +0000 (UTC)

Qui la busta RCPT TO è stata codificata usando la clausola FOR della linea Received. (Si noti che per RFC 5321 §4.4 è consentita una sola voce, anche quando ci sono più comandi RCPT TO.)

Cosa non è conservato

Gli indirizzi MAIL FROM e RCPT TO non vengono registrati, o possono essere registrati in modo incompleto, nell'intestazione. Questo potrebbe essere parte della tua preoccupazione di rilevamento "manomissione". È un effetto collaterale del fatto che SMTP è stato progettato per il trasporto di messaggi incapsulati che possono avere le proprie informazioni di indirizzamento e routing complete prima e dopo la fase SMTP della connessione. È anche qualcosa senza analogo fisico.

Questa considerazione di progettazione potrebbe anche riflettere sul fatto che SMTP non è stato progettato per essere considerato affidabile, semplicemente per funzionare. Non appena sono sorte considerazioni sulla fiducia, sono stati trasferiti su altri livelli della connessione (PGP, SPF, DKIM, tutti questi si verificano "al di fuori" del protocollo SMTP).

Non dimentichiamo

Qualsiasi parte dell'intestazione o del corpo può essere manomessa da un relay malevolo. Maggiore è il numero di tentativi di registrazione dei relè che registrano le informazioni sulla sicurezza, maggiore è la possibilità di affidarsi a informazioni errate. Ecco perché ogni linea ricevuta si riflette sul relay precedente e non su quello che lo sta anticipando.

In altre parole, c'è un valore limitato nel provare a caricare più fiducia nei relay.

Come registrare Envelope RCPT TO nell'intestazione, RFC 5321 §7.2 afferma:

There is no inherent relationship between either "reverse" (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the header section. Receiving systems SHOULD NOT attempt to deduce such elationships and use them to alter the header section of the message for delivery. The popular "Apparently-to" header field is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used.

Il mercato ha ampiamente ignorato questa raccomandazione.