Hi,
Am 16.06.2023 um 13:28 schrieb Sebastiaan de Vos:
The need for separate DKIM failure codes to be able to separate
between in-transit changes and public key errors is more than just
valid and I don't consider SPF worthless in general, but I just find
it disturbing how the obviously misplaced confidence in SPF currently
weakens the whole DMARC standard.
Exactly.
There are rare bugs in DKIM software (signer or verifier) that only were
fixed recently. These bugs have been there for years, but nobody noticed
them because of the "SPF safety net" in DMARC. SPF is hiding bugs in
DKIM software.
The SPF safety net has holes/problems, like:
- "I include 7 different big ESPs into my SPF record", which results in
millions of IPs
- or "I put my whole cloud IP range into my SPF record to be sure that
my future IPs that I might get are already in it",
- or when switching the mail provider, only add the new IP at the new
provider, but don't remove the old IP of the old provider. Then some
lucky guy will get/reuse that old IP sooner or later...
- or "+all"
- or: If you have an ESP which puts multiple customers on one outbound
IP ("shared infrastructure"), then all customers who are on the same IP
can send mails with all the other domains on that IP. The same with mail
relays on "standard web hosters": Lots of them don't check the
Envelope-From or From-Header, they just relay all mails to the Internet.
Every customer can send mails with the domains of all other customers,
and you get an SPF=pass.
- "my mails fail DKIM, but I have the safety net SPF, so everything is
fine, I don't need to fix DKIM". They forget that all those mails will
fail SPF/DMARC if they are being forwarded (indirect mailflow).
You can argue that SPF helps as a safety-net to DKIM (but only on
"direct mailflows"), but you also have lots of problems in DMARC because
of SPF.
You don't need a half-broken safety net to DKIM if you concentrate on
fixing the DKIM bugs, like bugs in DKIM software (signer+verifier) or
fixing bugs in DKIM deployments like missing/wrong DKIM DNS records, or
not DKIM-signing your bounce mails (default behaviour of Postfix,
locally generated bounce-mails are not processed by milters).
If everyone on this mailing list can generate a list of DKIM signatures
which are failing often, but should not fail, and contact those top 20
or top 50 domains, then I guess 95% of the total mail volume with DKIM
problems will be fixed, and you can get rid of the SPF safety net that
you don't need anymore in DMARC (you might still use SPF later in the
analysis as a "scoring/reputation/detection mechanism" or so, we are
just talking about removing it from DMARC to reduce problems while
calculating the DMARC result and detect sender forgery).
I don't know how BIMI will proceed, currently it relies on the DMARC
result. But because of recent problems with Gmail and UPS, it looks like
it's a good idea to only trust the DMARC result if it was based on the
DKIM result. I found this statement from Google:
"This issue stems from a third-party security vulnerability allowing bad
actors to appear more trustworthy than they are. To keep users safe, we
are requiring senders to use the more robust DomainKeys Identified Mail
(DKIM) authentication standard to qualify for Brand Indicators for
Message Identification (blue checkmark) status."
https://www.theregister.com/2023/06/09/google_bimi_email_authentication/
...requiring senders to use the more robust DKIM authentication standard...
Which means: the SPF result is being ignored when evaluating BIMI, "DKIM
only" is the way to go for sender authentication.
/M
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
