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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Eliot,

I might be wrong, but possibly if you are able to soften your proposed text slightly, then you may find text this is acceptable to others.  E.g.,


   Given the above, SMTP-senders MUST use confidentiality if it is
   available and accepted by the receiver.  For interoperability,
   SMTP-receivers are generally configured to accept mail with or
   without confidentiality.  What a sender or receiver chooses to do
   in any particular circumstance is a local policy issue.  See
   'Security Considerations' for further discussion of this.

Such text still states the standard deployment that all mail operators use.  Of course, it also implicitly requires that any such MTA software deployed in such scenarios must be able to support that (which from my read, I don't think folks are particularly objecting to).  But it also doesn't explicitly mandate that a MTA must be configurable in an insecure way to be complaint with the RFC (which some folks are strongly opposed to).

Kind regards,
Rob


From: Eliot Lear <[e-mail]>
Date: Saturday, 26 September 2026 at 08:56
To: Martin Thomson <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [Last-Call] Re: [Emailcore] Your (Roman's) DISCUSS on draft-ietf-emailcore-as and status of the document

Hey Martin,

On 26.09.2026 09:35, Martin Thomson wrote:

On Sat, Sep 26, 2026, at 17:28, Eliot Lear wrote:


The decision to accept or reject messages not sent with STARTTLS MUST be left as a configuration choice for the operator.


Oh, that's subtle.  It carries a hidden requirement on implementations to implement support for accepting non-TLS mail.  Not good enough, sorry.

I presume that was sarcasm; it's not intended to be subtle at all; but the medium might be failing us in the moment.

On this notion of "mandates" and "requirements", as a voluntary standards organization, we can't mandate directions to the restroom.  But implementations can impose both.  Let's just admit the tension here and either respect that the people who live this code either as an implementor or an operator in the emailcore group made a tough call or otherwise leave it with the IESG to decide how to address this tension both technically and procedurally.

Unless someone has a comment to add that hasn't already been made a dozen times?

Eliot