Re: [dmarc-ietf] SPF/DKIM/DMARC statistics observed at UMN (past 30 days)
Hector, Answers inline below. On Fri, Jun 16, 2023 at 11:30 AM Hector Santos wrote: > Steve, > > Thanks for the inbound MX verification stats. > > Can I ask, does the umn.edu mx network of compliant SPF/DMARC servers > honor the Reject and Quarantine? > Yes. We only did this after a year or two of analysis on what would be rejected. Meaning, are transactions with DMARC Rejects done at the SMTP DATA state > with 55z SMTP responses? or the transactions are accepted (250 reply code) > but then discarded (DMARC reject) or DMARC quarantined to a user's > junk/spam box? With either method, the end user does not see the DMARC > failed message in their In-box? > Rejections are done at the SMTP DATA state with 55z SMTP responses. Accepting and later sending NDN would of course make us a source of joe-jobs. End users therefore do not see these rejections. > > If so, considering only the DMARC results reject and quarantine in your > table, I summed up 0.29% are rejected/quarantined. Would that be correct? > I did not include email that was rejected at the SMTP layer for other reasons prior to the opendmarc milter running. > > On the other hand, in my implementation, SPF failure preempts DMARC by > default - mail is rejected (55z). If we considered only the SPF column > with fail in your table, you would have 1.82% rejectable mail. > We do not consider SPF separately, only as part of DMARC evaluation. > > At the end of the day, it's about the payoff with the empirical field > data. I believe in the idea of a PCN or BCN - Personal or Business > Community Network. We all have one. Our PCN or BCN are not all the same. > Not all the ESPs are the same. > > Obviously, scale is a one of the main factors, it changes your PCN/BCN but > there is a commonality regardless of scale among all in the community small > to large. I see your low DMARC reject/quarantine rate and high DMARC > passage rate as good markers of a well-run system. It may reflect not > getting a lot of junk mail and it would be interesting to know, with your > volume, what percentage is actually DMARC passed spam. > Content filtering, including anti-virus, occurs after acceptance, so not all accepted email is delivered and some that is delivered could still result in being marked spam. > > My combined PCN/BCN incoming mail stats are collected daily since 2003 at > https://winserver.com/spamstats > > The SPF failure rate was slow to grow over the years. As of this June 2023 > month, I am seeing a high 12.9% SPF rejection, but its has been normally > ~5%. This high may just represent some level of attack this month. > Nevertheless, of the accepted mail, we have a relatively high spam mail > rate. > > Thanks > > -- > Hector Santos,https://santronics.comhttps://winserver.com > > > > On 6/16/2023 10:24 AM, Steve Siirila wrote: > > Below is a table of SPF/DKIM/DMARC statuses over the past 30 days on our > inbound MX servers (umn.edu and several *.umn.edu domains). Note that we > employ a DMARC policy of p=reject; also note that we have split our dmarc > 'fail' status into three categories: > > *fail* indicates a DMARC failure where the sender domain had a policy of > p=none > *quarantine* indicates a DMARC failure where the sender domain had a > policy of p=quarantine > *reject* indicates a DMARC failure where the sender domain had a policy > of p=reject > > *dkim* > > *spf* > > *dmarc* > > *count* > > *pct* > > *description* > > pass > > pass > > pass > > 52954883 > > 73.62% > > Accepted > > pass > > pass > > none > > 11792134 > > 16.40% > > Accepted; no “From:” domain > > fail > > pass > > pass > > 2529364 > > 3.52% > > Accepted: Passed based solely on SPF alignment > > pass > > pass > > fail > > 1155823 > > 1.61% > > Accepted, but alignment failed for both SPF and DKIM > > fail > > pass > > none > > 1131260 > > 1.57% > > Accepted; no “From:” domain > > pass > > fail > > pass > > 991879 > > 1.38% > > Accepted: Passed based solely on DKIM alignment > > pass > > none > > pass > > 200502 > > 0.28% > > Accepted: Passed based solely on DKIM alignment > > fail > > pass > > fail > > 191296 > > 0.27% > > Accepted: Failed, no DMARC policy > > pass > > none > > none > > 190378 > > 0.26% > > Accepted; no “From:” domain > > fail > > none > > fail > > 134941 > > 0.19% > > Accepted: Failed, no DMARC policy > > fail > > none > > none > > 134144 > > 0.19% > > Accepted; no “From:” domain > > pass > > fail > > none > > 102386 > > 0.14% > > Accepted; no “From:” domain > > fail > > fail > > none > > 88609 > > 0.12% > > Accepted; no “From:” domain > > fail > > none > > reject > > 65894 > > 0.09% > > Rejected (missing or bad DKIM) > > fail > > fail > > fail > > 58133 > > 0.08% > > Accepted: Failed, no DMARC policy > > fail > > fail > > reject > > 49305 > > 0.07% > > Rejected (missing or bad DKIM) > > pass > > pass > > quarantine > > 36596 > > 0.05% > > Marked as spam (lack of alignment) > > pass > > none > > fail > > 16517 > > 0.02% > > Accepted: Failed, no DM
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
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
[dmarc-ietf] SPF/DKIM/DMARC statistics observed at UMN (past 30 days)
Below is a table of SPF/DKIM/DMARC statuses over the past 30 days on our inbound MX servers (umn.edu and several *.umn.edu domains). Note that we employ a DMARC policy of p=reject; also note that we have split our dmarc 'fail' status into three categories: *fail* indicates a DMARC failure where the sender domain had a policy of p=none *quarantine* indicates a DMARC failure where the sender domain had a policy of p=quarantine *reject* indicates a DMARC failure where the sender domain had a policy of p=reject *dkim* *spf* *dmarc* *count* *pct* *description* pass pass pass 52954883 73.62% Accepted pass pass none 11792134 16.40% Accepted; no “From:” domain fail pass pass 2529364 3.52% Accepted: Passed based solely on SPF alignment pass pass fail 1155823 1.61% Accepted, but alignment failed for both SPF and DKIM fail pass none 1131260 1.57% Accepted; no “From:” domain pass fail pass 991879 1.38% Accepted: Passed based solely on DKIM alignment pass none pass 200502 0.28% Accepted: Passed based solely on DKIM alignment fail pass fail 191296 0.27% Accepted: Failed, no DMARC policy pass none none 190378 0.26% Accepted; no “From:” domain fail none fail 134941 0.19% Accepted: Failed, no DMARC policy fail none none 134144 0.19% Accepted; no “From:” domain pass fail none 102386 0.14% Accepted; no “From:” domain fail fail none 88609 0.12% Accepted; no “From:” domain fail none reject 65894 0.09% Rejected (missing or bad DKIM) fail fail fail 58133 0.08% Accepted: Failed, no DMARC policy fail fail reject 49305 0.07% Rejected (missing or bad DKIM) pass pass quarantine 36596 0.05% Marked as spam (lack of alignment) pass none fail 16517 0.02% Accepted: Failed, no DMARC policy pass fail fail 15971 0.02% Accepted: Failed, no DMARC policy pass pass reject 15923 0.02% Rejected (lack of alignment) fail pass quarantine 14532 0.02% Marked as spam (lack of alignment) fail pass reject 13484 0.02% Rejected (lack of alignment) pass tempfail pass 10640 0.01% Accepted: Passed based solely on DKIM alignment fail tempfail none 10543 0.01% Accepted; no “From:” domain fail fail quarantine 9149 0.01% Marked as spam fail none quarantine 5437 0.01% Marked as spam pass tempfail none 1226 0.00% Accepted; no “From:” domain pass fail reject 1179 0.00% Rejected (lack of alignment or DKIM signature match) pass fail quarantine 926 0.00% Marked as spam (lack of alignment) pass none reject 630 0.00% Rejected (lack of alignment or DKIM signature match) fail tempfail reject 547 0.00% Rejected (lack of alignment) fail tempfail fail 537 0.00% Accepted: Failed, no DMARC policy pass none quarantine 265 0.00% Marked as spam (lack of alignment) pass tempfail fail 106 0.00% Accepted: Failed, no DMARC policy pass tempfail reject 10 0.00% Rejected (lack of alignment or DKIM signature match) fail tempfail quarantine 9 0.00% Marked as spam pass tempfail quarantine 1 0.00% Marked as spam (lack of alignment) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
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. Is it not in our best interest to encourage and motivate in particular the less sophisticated senders to use the higher confidence mechanisms? On 16.06.23 13:02, Douglas Foster wrote: RFC 7489 takes 8 different authentication mechanisms and lumps them into a single PASS result: DKIM or SPF, each with up to four types of alignment: same domain, parent->child, child->parent, and sibling->sibling These eight mechanisms all provide some level of confidence that the message is not impersonated, but they do not provide an equal level of confidence. Unsophisticated senders have little incentive to use the higher confidence mechanisms because any PASS result is still PASS. The solution is not to pretend that SPF is worthless, because that is an overstatement. The solution is to talk about the differences in confidence provided by the different authentication methods, and note that evaluators have reason to distrust some of them. That distrust could cause a weakly authenticated message to be distrusted by some evaluators. Similarly, needs multiple types of FAIL. Since the data indicates that missing (or invalid) public keys are a significant portion of all failures, it needs a separate failure code from "normal" failures which suggest in-transit changes. The DKIM group needs to define the result code but this group would need to integrate it into our aggregate reports. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
On Fri 16/Jun/2023 13:02:46 +0200 Douglas Foster wrote: The solution is to talk about the differences in confidence provided by the different authentication methods, and note that evaluators have reason to distrust some of them. That distrust could cause a weakly authenticated message to be distrusted by some evaluators. SPF reliability is not something that an evaluator can automatically learn, at least not straightforwardly. Overbloated SPF settings can make impersonation possible, thereby betraying DMARC intent. Concerned domains should be advised to not include such stuff in their SPF record. If someone set +all in their SPF record, then anyone is authorized to send mail on their behalf. It is not an evaluator's job to syndicate their policy. The problem arises if —as someone voiced— there are cases where a domain is somehow forced to publish a bloated SPF record, yet doesn't want to be freely impersonated and seeks DMARC protection. Do such cases exist? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
RFC 7489 takes 8 different authentication mechanisms and lumps them into a single PASS result: DKIM or SPF, each with up to four types of alignment: same domain, parent->child, child->parent, and sibling->sibling These eight mechanisms all provide some level of confidence that the message is not impersonated, but they do not provide an equal level of confidence. Unsophisticated senders have little incentive to use the higher confidence mechanisms because any PASS result is still PASS. The solution is not to pretend that SPF is worthless, because that is an overstatement. The solution is to talk about the differences in confidence provided by the different authentication methods, and note that evaluators have reason to distrust some of them. That distrust could cause a weakly authenticated message to be distrusted by some evaluators. Similarly, needs multiple types of FAIL. Since the data indicates that missing (or invalid) public keys are a significant portion of all failures, it needs a separate failure code from "normal" failures which suggest in-transit changes. The DKIM group needs to define the result code but this group would need to integrate it into our aggregate reports. On Fri, Jun 16, 2023 at 5:52 AM Sebastiaan de Vos wrote: > > > Many thanks. That figure seems to be more or less in agreement with > > what others here have obtained on smaller samples. However small, it > > may confer to SPF the role of a stabilizer in DMARC mail flows. > > How could SPF be a stabilizer when it's proven to be a highly unreliable > mechanism? I'd rather consider that a de-stabiliser. From what I > understand, SPF is part of the problem, not part of the solution. > > Sebastiaan > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
Many thanks. That figure seems to be more or less in agreement with what others here have obtained on smaller samples. However small, it may confer to SPF the role of a stabilizer in DMARC mail flows. How could SPF be a stabilizer when it's proven to be a highly unreliable mechanism? I'd rather consider that a de-stabiliser. From what I understand, SPF is part of the problem, not part of the solution. Sebastiaan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
On Thu 15/Jun/2023 23:25:44 +0200 Tero Kivinen wrote: I rerun the statistics and yes, there is 0.84% cases where dkim failed, but spf returned either pass, softfail or neutral. Many thanks. That figure seems to be more or less in agreement with what others here have obtained on smaller samples. However small, it may confer to SPF the role of a stabilizer in DMARC mail flows. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
