Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Michael Kliewe <[e-mail]>]

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