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

[S Moonesamy <[e-mail]>]

Hi Richard,
At 02:39 PM 25-09-2026, Richard Barnes wrote:
>On Fri, Sep 25, 2026 at 11:23 AM Dave Cridland <[e-mail]> wrote:
>But let me rephrase, so it's clear.
>
>Are you ok with reducing interoperability such that email becomes 
>less reliable than it is now, and such that no feedback is available 
>to the recipient?
>
>
>First of all, email is plenty unreliable as it is, for reasons 
>entirely unrelated to encryption.
>
>But that's not the question on the table, the decision is between:
>
>1. [Current text] Requiring all email server developers to write 
>code to accept unencrypted mail, even if none of their users wants it
>2. [Deleting the MUST] Allowing email server developers to skip the 
>non-secure code if they only want to serve users who accept the tradeoffs
>
>(1) is not a good look for the IETF, and honestly our track record 
>of making developers do things their users don't want is not fantastic anyway.

Viktor Dukhovni sent a message on September 26 at 13:25.  The message 
included an explanation on the "non-secure code" used in mail 
software.  I can't tell whether there are other people writing mail 
software on this mailing list.  It would be good, in my opinion, to 
ask them for their opinion on (1).

I agree with you that mail delivery has been quite unreliable over 
the years.  There is an industry which advertizes information which 
can be used to prevent mail from being delivered.  There is another 
industry which sells services on how to get mail delivered.  One of 
those two industries cater for SMTP receivers.  The other one sells 
its services to SMTP senders.  What I have been seeing over the years 
is a lot of header inflation.  I assume that header inflation has not 
helped if mail has become more unreliable since then.

The IESG uses email to solicit comments [1].  Will the persons 
responding to the solicitation be required to ensure that the service 
operator delivering their comments enforces STARTTLS for mail 
delivery given that the SMTP extension is described as ubiquitous?

One of the points in your message was that the IETF would not be able 
to convince other people to do things which their users do not 
wish.  Did the IETF discuss with people operating SMTP receivers to 
understand what they want?  Does the IETF remain in a state of 
privileged seclusion to ignore the realities of running a SMTP 
receiver?  How does the IETF know that the proposed Applicability 
Statement matches reality?

What if encryption makes mail delivery more unreliable?  Will the 
IETF use vague generalizations to evade the question?

Regards,
S. Moonesamy

1. 
https://mailarchive.ietf.org/arch/msg/ietf-announce/K6V_8PFYvdLbn1b9Iy 
bkD-A1tAg/