[Last-Call] Re: [Emailcore] Re: Re: Re: Re: draft-ietf-emailcore-as-28 ietf last call Secdir review

[Rob Sayre <[e-mail]>]

Hi,

Pardon the top quote. I found this process a little frustrating, because
this MUST in 6.5 was added at the last minute as the result of a conference
call with no minutes and no rationale or even an attendee list.

I was fine with it as a SHOULD (for all of the reasons discussed here).
What would break if it was a SHOULD, given that you can configure STARTTLS
not to fall back to cleartext?

thanks,
Rob



On Thu, Apr 30, 2026 at 10:07 AM John C Klensin <[e-mail]> wrote:

>
>
> --On Thursday, April 30, 2026 17:59 +0200 Eliot Lear <[e-mail]>
> wrote:
>
> > I think it might be good to add some text to fire a shot across the
> > bow as it were; that in line with our policy of encrypting
> > everything, future versions of email standards may no longer
> > support plaintext.
>
> Eliot,
>
> As Victor has pointed out in detail, such a requirement would require
> an incompatible redesign of SMTP.  That could be done by developing a
> new protocol to supercede SMTP (as Rob has more or less suggested) or
> by doing something similar to what we did in 1993 (RFC 1425 and
> friends), in this case providing an alternative to "EHLO" with, e.g.,
> an "SHLO" verb that specified some version of TLS and implied "if you
> don't want to provide confidentiality, I don't want to talk with
> you".  Even that would raise complex questions, starting with whether
> we'd encourage servers to just close the connection if they didn't
> understand the verb (that is what would typically happen today if a
> session-opening command other than HELO or EHLO were sent) or whether
> they would be expected to reply in a different way and then wait (and
> for how long).  Whatever decision were made about that, there is no
> practical way to know at the time of message submission what every
> relay would do, leading to more complexity.
>
> To be a bit more explicit than Victor was, if one tried to impose
> such a requirement without some redesign, the result would be the
> cleartext exposure of some envelope information (even more of that
> information with pipelining).  Because of those complications, a
> statement like the one you suggest would basically be a platitude:
> not much more likely to be true (or false) than "future versions of
> email standards may support transport over avian carriers"
> (modifications for SMTP for that transport would probably be less
> complicated) even though naive readers much be more likely to assume
> it is meaningful.
>
> One think I'm sure of that consideration of those design options was
> out of scope for EMAILCORE.  I'm nearly as sure that sort of
> speculation about the future is out of scope too.
>
> I don't know whether those issues reinforce the suggestion that such
> a shot would be more likely to be to the foot than across the bow,
> but it is certainly possible.
>
>    best,
>     john
>
> --
> last-call mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>