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

["Alexey Melnikov" <[e-mail]>]

Hi Benjamin,

On Thu, Feb 21, 2019, at 12:02 PM, Benjamin Kaduk wrote:
> On Thu, Feb 21, 2019 at 10:24:17AM +0000, Alexey Melnikov wrote:
> > Hi Benjamin,
> > A couple of comments on some of your DISCUSS points:
> > 
> > > On 21 Feb 2019, at 04:55, Benjamin Kaduk <[e-mail]> wrote:

 (snip)

> > > 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).
> 
> It's just surprising to see a "your message won't get sent if the whole
> path doesn't support this extension" behavior; this seems to require a
> critical mass of deployment before any major usage is possible.
> I don't object per se to specifying things like this, but it does make one
> wonder whether we should spend so much effort on things that may be of
> little use in practice.

There is a bit of Catch-22 here: we need this in an RFC to see if we want widespread use.

> > >  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.
> 
> Perhaps this could be discussed on the call (which, sadly, I don't expect
> ot be on).  I recognize that it would be weird to start a precedent here,
> and of course if the intention is not that this extension become de facto
> part of core SMTP then my concern disappears.

I can add this topic to the informal telechat next week.

Best Regards,
Alexey