On 02/13/2016 05:54 PM, John Levine wrote:
Further comments are of course appreciated.
I still don't get it. If a sender wants to talk only to MTAs that
support STARTTLS, it can just do so, and on today's Internet that
covers the vast majority of mail.
In the draft, I use "sender" to refer to the originator of a mail
message, the person or entity that writes it. Perhaps that wasn't clear.
Very often the sender will submit that message to an MTA they have a
relationship with, which will then send it onward. The sender rarely
controls that MTA, and currently there is no way for the sender to
signal the MTA that they want to ensure that TLS is used when the
message is sent onward. This draft addresses that issue.
Even if STARTTLS is supported by both sides, it is possible for an
intermediary to interfere with it, by simply garbling the command. There
are commercial products that do this, as described at
http://www.cisco.com/c/en/us/about/security-center/intelligence/asa-esmtp-starttls.html
. This is also addressed by REQUIRETLS.
As soon as you try to get clever, you quickly run into perverse
effects. Here's an example:
You send a message to a mailing list with the SMTP required flag.
Does that mean that the list should preserve the flag so its outbound
MTA applies the rule to the message when it's sent out the recipients?
If not, seems pretty ineffective.
My first inclination is that it's up to the mailing list manager what to
do in this case since it's generating a new message to the mailing list
subscribers. I don't think that makes REQUIRETLS ineffective at all; I
would think twice before sending sensitive information to a mailing list
anyway.
-Jim
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp