Open philipwhiuk opened 8 years ago
I think it's useful to have a note about lack of TLS. But it's too much to label a message which has headers that purport to show TLS usage as "secure". First, that confuses users about security properties and e2e vs transport security. Second, those headers are unauthenticated.
I agree with the notion of having a way to annotate messages that appear to have not used TLS.
Agreed completely - this shouldn't involve specifically using the word "secure" especially not without context. The headers assert you trust the mail relays which is the level SMTP/TLS operates, rather than every transit router on the path.
The main purpose of "Received" headers is to help debugging. The format of this header is part of the RFC but I'd be very surprised if the majority of MTAs only generated well-formatted headers, making parsing a nightmare. Also, according to the RFC, gateways are required to add a "Received" header, but I doubt everyone is doing that. I don't think "Received" headers are a reliable source of information. Even if they were, my belief is this information is not useful to 99.9% of users. Even for experts there's not much information to derive there. Just because the meta data of your emails wasn't leaked in transit, doesn't mean it wasn't leaked by any of the gateways.
Maybe not completely reliable, but i think it would be nice to have. Thunderbird has https://addons.mozilla.org/en-US/thunderbird/addon/paranoia/ and GoogleMail also recently added similiar indicators: https://gmail.googleblog.com/2016/02/making-email-safer-for-you-posted-by.html
Expected behaviour
An email which was delivered between two servers (i.e. not between a server and itself over a loopback address) should be marked as insecure if it was not done in an encrypted fashion.
An email which was delivered securely in each step should be mark as secure.
Note: This does still apply to PGP/MIME and S/MIME email which otherwise leak information like the subject, to and from address and other headers.
Steps to test
Method to implement
Processing of MIME "Received" headers.