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

[Nico Williams <[e-mail]>]

On Thu, May 07, 2026 at 11:52:24AM +0200, Eliot Lear wrote:
> Martin:
> 
> On 07.05.2026 10:20, Martin J. Dürst wrote:
> > [...]
> 
> There are two primary objections to the AS as I see it:
> 
> 1. We need to be careful not to encourage clear text communications.

That's the reasonable way of putting it, but the ones stating (1) aren't
being reasonable or putting in reasonable terms.  They want to do more
than to encourage encrypted communications: they want no attempt at
acknowledging the continued need for cleartext in SMTP (I don't think
I'm stretching their positions, but they might reasonably believe so and
correct me).

> 2. We should not tell coders what is configuration and what is code.

Some have said this, but the IETF does this specify bits of required
local policy, sometimes more explicitly than others (often we write
"subject to local policy" and leave all the details out, but even in
those cases we envision and even require local policy).  I posted some
examples.

> We can make clear that the first is a matter of local policy, and we can
> make clear that whether this is code or configuration is not subjecting to
> MUSTs.  That's why I offered the following alternative:

The I-D already does that.  You're proposing more required configuration
knobs, and I'm ok with that.

> > What email to drop *MUST* be considered a local policy decision in
> > accordance with a wide range of administrative needs.   Accepting email
> > that does not use STARTTLS is no exception to this rule.  Local policy
> > choices [may/*MAY*] be implemented in code, but are often implemented as
> > configuration for versatility's/generality's sake.  At the time of this
> > writing, a substantial installed base does not use STARTTLS, and
> > therefore those not permitting email without STARTTLS should expect to
> > drop at least some mail.
> 
> This text would go along with servers MUST support STARTTLS, and clients
> MUST use STARTTLS, when available.

Clients need a configuration knob to not send email in the clear, and
servers need a configuration knob to reject email in the clear.  We need
not say anything more about their default settings than the text in the
I-D has now about servers accepting email in the clear.

Nico
--