I relay di posta devono sempre indicare l'uso della crittografia nel campo dell'intestazione "Received:"?

Question

I relay di posta devono sempre indicare l'uso della crittografia nel campo dell'intestazione "Received:"?

#1 da (5 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Quando un messaggio di posta elettronica viene inviato con la crittografia di trasporto, puoi dirlo dal campo "Ricevuto:" che il relay di posta ricevente aggiunge all'intestazione del messaggio.

> Received: from [...].google.com ([...]) by
> [...].mail.protection.outlook.com ([...]) with Microsoft
> SMTP Server (TLS) id [...] via Frontend Transport; [...] +0000

Mi chiedo se questo è sempre il caso (ad es. perché è richiesto da una sorta di standard).

Ecco un estratto dall'intestazione di un messaggio ricevuto di recente da un servizio di assistenza clienti.

> Received: from freshdesk.com (ec2-[...].compute-1.amazonaws.com [...])
>         by ismtpd[...]iad1.sendgrid.net (SG) with ESMTP id [...]
>         for <[...]>; [...] +0000 (UTC)

Ed ecco un altro, forse più preoccupante, dallo spedizioniere di posta elettronica di ACM.

> Received: from in-007.lax.mailroute.net
>        by acmsmtp01.acm.org (ACM Email Forwarding Service) with ESMTP id [...]
>        for <[...]>; [...] -0500

Posso essere certo in questi casi che i messaggi sono stati trasmessi in chiaro?

email encryption starttls

posta ȷ̇c 10.12.2015 - 10:09

fonte

3 risposte

1

Sì

rfc5321 sezione 3.7.2 dice:

The gateway SHOULD indicate the environment and protocol in the "via" clauses of Received header field(s) that it supplies

quindi, un server di posta non può fornire la clausola "with" (questo è ancora più chiaro nell'ANTLR della sezione 4.4, vedi Opt-info), nel qual caso non hai dati

... ma se specifica che il trasporto era ESMTP, allora sì, affermerei che è stato trasmesso in chiaro. In caso contrario, avrebbero dovuto utilizzare il tipo di protocollo ESMTPS ( vedere il registro IANA ). Non conosco alcun MTA che supporti ESMPTS ma lo registra come ESMTP nell'intestazione ricevuta.

OTOH potresti trovare un trasporto registrato, ma con una parola chiave per la quale devi indovinare se è stato trasportato in sicurezza o meno. Il tuo primo estratto è un buon esempio. Yahoo utilizza anche un trasporto personalizzato internamente.

risposta data 24.02.2016 - 00:50

fonte

0

Non puoi essere certo di nulla dalle intestazioni "Received". Possono essere modificati o interamente falsificati facilmente.

risposta data 10.12.2015 - 10:21

fonte

Leggi altre domande sui tag email encryption starttls

C'è qualche svantaggio nel dichiarare sempre alcuni caratteri errati di default durante la generazione di exploit? Perchè la paura dell'hardware viene portata in Cina, quando la maggior parte viene dalla Cina?

score 5 · Accepted Answer

I’m wondering if this is always the case (e.g., because it is required by some sort of standard).

Non proprio. Il più recente RFC per SMTP RFC 5321 descrive il formato dell'intestazione ricevuta ma questo non include tali informazioni, probabilmente anche perché STARTTLS per SMTP è uno standard extra. Questo standard è descritto in RFC 3207 e non fornisce informazioni su cosa aggiungere all'intestazione Received.

Generalmente le informazioni sono memorizzate all'interno di parti di commenti dell'intestazione Received (che possono essere inserite quasi ovunque) e sembrano non aderire a un singolo formato specifico. Quindi dipende principalmente dal server di posta se e come questo è incluso nell'intestazione Received e diversi server di posta lo gestiscono in modo diverso.

A parte questo, non è una prova che il messaggio sia stato realmente trasmesso con TLS anche se trovi questa intestazione. Questa intestazione è appena inserita dal server che può inserire qualsiasi cosa al suo interno. Potrebbe anche essere modificato o rimosso da altri server di posta più avanti nel percorso. Nessuna se le informazioni possono essere attendibili pienamente, perché non sono protette da cancellazione, spoofing o modifica in alcun modo.