[Top] [All Lists]

Re: [ietf-smtp] Two recent Internet-Drafts about using TLS with email protocols

2013-10-24 03:10:45
On 23/10/2013 18:48, Keith Moore wrote:

The document seems to be fairly well written and worked out in a decent amount of detail. It proposes Opportunistic TLS rather than an SMTP extension or message header that would require secure delivery for the entire path. For mail relaying I think Opportunistic TLS is a more realizable goal. But even if people want to propose an SMTP extension to mandate use of TLS for the remainder of the path to the recipient, I think it would need to use the certificate verification mechanisms described in this draft.

I had a thought about a low impact idea which may help wrt TLS security, but this draft doesn't include it and I haven't seen it anywhere else (apologies if it is there and I've missed it)

It may be a waste of time, but I'll throw it into the mix anyway ;-)

At the moment I have no idea how 'secure' a message was on its journey to me. Would it be sensible/a good idea for MTAs/MSAs/MDAs to add the 'TLS' state into the Received trace line somehow - eg instead of

Received: from (localhost [IPv6:::1]) by
 (Postfix) with ESMTP id 737EC11E8372; Wed, 23 Oct 2013 10:48:15 -0700


Received: from (localhost [IPv6:::1]) by
 (Postfix) with ESMTP (TLS:no) id 737EC11E8372; Wed, 23 Oct 2013 10:48:15 -0700

(or some such)

Then, at the receiving end, you would have an idea that the message was sent in a plain session at some point in its transfer (you could have something like 'TLS:no', 'TLS:yes', and the absense of such a marker would indicate that that MTA doesn't tell you).

It wouldn't make a message more secure, but it'd be trivial to code, I can't see it breaking anything, and it would at least let you know if there had been a time when the message had been at risk of snooping in transit.


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>