Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Benjamin,
A couple of comments on some of your DISCUSS points:

> On 21 Feb 2019, at 04:55, Benjamin Kaduk <[e-mail]> wrote:
> 
> I'm also concerned about the apparent new burden placed on senders to
> actively decide whether every outgoing message requires end-to-end TLS
> protection or is safe to forward without TLS, especially in light of the
> apparent goal (see next paragraph) of quickly achieving (near-)universal
> deployment.

While I have sympathy toward the feeling that some users would be unable to decide, there are certain classes of email messages that would require either "yes" or "no" option. For example, banking statements sent in email might always require "yes".

>  There doesn't seem to be much in this document to justify
> the stance that the default "don't care" option should be removed.

The default option is always present (as it is the default SMTP behaviour) when the client chooses not to use the extension. So "don't care" option is always possible.
> 
> The "must chain forward to final delivery" property for the REQUIRETLS
> option seems to present some incremental deployment difficulties, in that
> it will be nigh-impossible to successfully deliver such a message until
> there is fairly significant deployment coverage.  E.g., if any major email
> hosting provider does not implement, then it will forever remain a niche
> technology.  What indication to we have that this technology can succeed as
> specified?

There are several SMTP extensions on Standards Track that have similar properties. IETF generally didn't require "prove that it gets deployed" for them. There are already some implementations (as per the write-up).

>  If we anticipate it becoming a part of the de facto core,
> mandatory, SMTP feature set, should we not indicate that by an Updates:
> relationship?

We haven't done this in the past even for widely deployed SMTP extensions. This is not a reason not to do this in the future, but I think starting with this extension would cause more confusion.

Best Regards,
Alexey