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

[Michael Richardson <[e-mail]>]

Viktor Dukhovni <[e-mail]> wrote:
    >> 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:
    >>
    >> > 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.

    > This entirely misses the point of the A/S, which makes it clear that
    > **support** for cleartext is required from implementations of MTAs that
    > are intended to match the A/S profile.  If a user of that MTA then
    > configures it to reject non-STARTTLS mail, that's the user's choice.

What I want/need and I suspect others do as well, is some facilities in MTA software:
1. ability to demand (or allow bypass) of STARTTLS on a per-IP address basis.
   The bypass specifically allows an operator to accept email from legacy
   devices.   Like the full-size multifunction scanner I had in my previous
   office that would email the scanned documents as PDFs.

   (That device would still be around, but COVID related rightsizing means
   it's in a closet somewhere.  It was physically large.)
   Yes, we told the device to punt to the local-LAN smarthost, and that
   smarthost did STARTTLS with the external email provider.  Not everyone can
   set that up.  Given NAT44, IP address based filtering like this would
   likely be impossible.   But that scanner did do IPv6...

2. ability to demand that some mailboxes only get STARTTLS, and if the sender
   didn't do that, then the mailbox probably does not exist.  Or..more variations.

3. potentially the same things again with per client-certificate
   sub-policies.  client-certificate based policies potentially get around
   the NAT44 filtering problem, but obviously, require STARTTLS.

While all of these things are **local policies**, I think that everyone would
benefit from signals from the MTA(s) to the MUAs as to what happened.
Configuring client-certificate policies is made easier if the way by which
one describes the client (a fingerprint/AKI is common) is somewhat standard.

{Much of what I describe above is already possible in some systems, but the
ways in which it can be combined, explained, is very uneven.  So it's harder
for customer/operators to communicate this well to suppliers}

Reading through Received: lines is doable for an expert human, but
fundamentally one can only trust the headers added by the last hop MTA.
Human clue/suspicion is needed here to decide how if some information has been faked.
This is where I'd like the standards process to go.

    > None of this changes the protocol (5321bis), or imposes requirements on
    > implementations outside the A/S profile.

I wish we had a series of headers that were clearly hop-by-hop headers, and
that *all* receiving MTAs had always been removing.   It's probably far far
too late to create such a thing, but I'd love to be proven wrong.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

**       My working hours and your working hours may be different.         **
** Please do not feel obligated to reply outside your normal working hours **