Re: [dmarc-ietf] Mandatory Sender Authentication

[Hector Santos <[e-mail]>]

On 6/3/2019 10:29 AM, Douglas E. Foster wrote:

> So Sender Authentication needs to become mandatory:
>
>   * Senders MUST implement SPF or DKIM,  and SHOULD implement both.
>     Although the MX list becomes a default SPF list for those who do
>     not publiish a policy.
>   * MTAs MUST ensure that DKIM signatures remain verifiable.  If they
>     are unwilling or uinable to do so, they should reject the message
>     with a PermError.
>   * Forwarders MUST either forward with breaking DKIM signatures,
>     rewrite messages under their own identity, refuse the message, or
>     discard the message as spam.
>   * IETF MUST provide a way for intermediate systems (both spam
>     filters and list fowarders) to insert content under their own
>     signature, without breaking original signatures.    This will have
>     implications for MUAs..
>
> Sure it will be hard, but has this not been what you have been trying
> to achieve for 15 years?  SPF and DKIM provided the enabling
> technology, but they were deployed as sender options.

Hi Douglas,

It's ideal, but not the SMTP realities.

- In certain areas, some things are already "mandatory" depending on 
the business, for example, a Bank may be required by their auditor to 
use SPF Hard Fail -ALL policy in the same way a bank must be PCI 
compliant via the web which basically means SSL, session management 
and other security-related requirements.

- You can't enforce anything beyond legacy RFC821/5321 transactions 
under Port 25 SMTP operations.  You can only raise the email bar with 
NON-PORT 25 operations like when using the Message Submission protocol 
(RFC6409) which is port 587.  For example, the Extended SMTP (ESMTP) 
AUTH protocol is not required under Port 25. It is optional to 
implement and optional to use by the client.  Under Port 587,  ESMTP 
AUTH is a requirement among other things the receiver can enforce 
which are not required under port 25 operations.

- We can not have a mandate for DKIM POLICY because there is no 
official IETF standard here and even if there was, it would not be 
enforcible under Port 25.  That's not the same as a domain having a 
restrictive policy, it fails and the receiver honors and rejects the 
mail.  The Receiver can not enforce the sender to have a DKIM or any 
sort of policy above and beyond legacy SMTP port 25 operations.  It 
can not reject a message on the basis the sender does not have SPF or 
DKIM or DMARC.

- Keep in mind, SPF Hard Failures are generally good enough and can be 
mutually exclusive of a restrictive DKIM Policy.  For example, I just 
did some emailing with a bank which uses SPF -ALL (Hard Fail) but has 
no DKIM signature nor DMARC policy. For exclusive high value domains, 
an SPF -ALL is often good enough.  Even if it had a DKIM/DMARC 
p=reject policy, how will that change a -ALL failure?  Why would a 
bank override a SPF -ALL failure with with DMARC (or ARC) and raise 
the fussiness of the transaction?  I am sure there is possible a 
scenario where a SPF -ALL defined IP is doing something different with 
the PAYLOAD and could fail a DKIM signature.  But the reason you may 
see a domain with SPF -ALL and not DKIM is because it is good enough.

- Without port 25 operations, we would no longer be able to receive 
unsolicited messages from anyone, good or bad which is the blessing 
and the curse of standard SMTP port 25 operations.

The general rule of thumb for SMTP has been that for unsolicited mail 
from "unknown" addresses, authenticated and/or authorization is not 
required when targeting a local recipient or locally hosted domain. 
But for relaying mail (receiving a message to be routed, relayed to a 
remote target), some level of authentication is required and in the 
history of SMTP, that has been:

  - Having some form of an "Allow IP Relay" database/table.

Your network provider saves the connection IP in a table allowing for 
relay.

But as the roaming user problem began where the client's IP can 
change, an early method called POP B4 SMTP was common.

  - POP b4 SMTP worked on the basis a MUA will generally pop first 
before sending
    email and this allowed a small temporary "Allow IP" window for the 
SMTP client
    to send mail.  So the POP3 client connected to a host, the IP was 
saved while any
    new mail was picked up.  If the MUA had mail to send out, the 
client IP would
    be known by the SMTP receiver and allow the client to relay mail.

This was a god-send for tech support before ESMTP AUTH came along and 
becamewide spread:

  - ESMTP AUTH allows a way to login with ID and Password from 
anywhere. No IP required.

Since ESMTP AUTH is an extension for PORT 25, it is not requirement.

-- 
HLS