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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
