[Emailcore] Re: [Last-Call] Your (Roman's) DISCUSS on draft-ietf-emailcore-as and status of the document

[John C Klensin <[e-mail]>]

--On Wednesday, September 23, 2026 22:02 -0700 Christian Huitema
<[e-mail]> wrote:

> On 9/23/2026 9:47 PM, Viktor Dukhovni wrote:
> 
>> So it appears that sometimes refusing cleartext could have been
>> beneficial, and other times it could have resulted in losing wanted
>> email (loss of interoperability).  The A/S specifies what it takes
>> to be interoperable, and notes that local policy may nevertheless
>> choose to require encrypted transmission.
> 
> There are two sides to that argument. As you said, being generous
> in what you accept means that the buggy implementation is still
> capable to send mail. But it also means that this buggy
> implementation will never get fixed, because why fix something that
> works?

Christian,

Indeed, two sides, but complicated in this case by the fact that
there are multiple reasons for continuing to allow cleartext.  It
seems that focusing on one of them in a particular case gets those
who prefer that position/side accused of shifting ground and
searching for excuses while the reality is that all of those figure
in and it is just a shift in emphasis.  I'll spare people my trying
to go through the whole list.

For your particular explanation, others have explained this
differently, but Internet email as we know it has been around the
Internet for a very long time, noting in particular that RFC 821
predates wide acceptance of TCP and IPv4.  We've come up with newer
versions that add or extend features, but we've avoided getting
ourselves into a situation where we say "practice X was normal and
required in the past but, as of this date, anything using it is
retroactively declared buggy".  At least for email, we usually talk
about perserving interoperability rather than declarations of
buggy-ness, but the IETF (not just the email community) has generally
avoided such retroactive declarations for multiple reasons.  One
interesting one is that "after this date, you are forbidden to use
that older, working feature anymore" requires a flag day and the
protocol police.  The last time we did that we something important on
the Internet was when we shut NCP off and, in that case, the protocol
police were alive, well, and active -- there were clear and
enforceable provisions that any system running NCP after that Flag
Day would simply be disconnected.   The modern, nearly equivalent,
example is that the IETF has never tried to force the use of IPv6 by
declaring any network, and any application, that still supports IPv4
as obsolete and buggy.   If we did, we've be ignored, treated as a
joke, or both.  For IPv4, we haven't even gone as far as the AS goes
wrt TLS, where we say that the new plan MUST be supported, the
question is whether, in your terminology, it is time to declare any
system that supports cleartext and buggy and/or forbidden.

  john