Hi, Paul,
On 10/24/2013 10:04 AM, Paul Smith wrote:
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 ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com
(Postfix) with ESMTP id 737EC11E8372; Wed, 23 Oct 2013 10:48:15 -0700
(PDT)
have
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com
(Postfix) with ESMTP (TLS:no) id 737EC11E8372; Wed, 23 Oct 2013 10:48:15 -0700
(PDT)
(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.
seems RFC3848 (http://tools.ietf.org/html/rfc3848) is what you're
looking for? Please note, that the mere presence of a Received line with
a "with" clause of 'ESMTPS' or 'ESMTPSA' in itself is no proof that the
message actually has been sent via an encrypted channel.
/rolf
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp