On Tue 29/Dec/2020 18:22:18 +0100 ned+dmarc wrote:
On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote:
DMARC validation failures can be caused either due to legitimate mail
(i.e., mail originated by or on behalf of the publisher of the DMARC
policy, a.k.a., the domain owner) failing authentication checks due to a
shortcoming in the authentication practices of the domain owner or some
other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
not originated by or on behalf of the domain owner, so mail intended to
fraudulently impersonate the domain), specifically the kind of mail that
DMARC is purported to be designed to stop.
That kind of analysis seems to be missing from the draft. After some years of
experience, we should be able to provide some, I'd hope. If not, we'd better
bluntly drop the draft.
I think a list of possible failure causes would be nice to have, because
a lot of people seem to think that DMARC is a completely reliable mechanism.
I'm not entirely convinced this document is the place for it, but OTOH
I'm not convinced it isn't.
A list of failure causes w/o further considerations may well live in an
appendix of the main document. If failure causes are specifically categorized
for failure reports, this document becomes a good candidate.
It also strikes me as more of an exercise in enumeration of possibilities than
an actual analysis.
Let's see. We have:
o Illegitimate mail
o Message changed in transit, invalidating DKIM signature
o Unintended DKIM breakage
o Intentional DKIM breakage (e.g. MLM)
o DKIM signatures not evaluated or not reported
o Missing DKIM signature
o Incorrect DKIM signing
o Incorrect SPF setup
o "Mute" forwarding (SPF failure)
o VERP disalignment
o Unintentional domain misalignment
o Improper assertion of DMARC policy
We regularly get problem reports whose root cause turns out to be one of
these things.
The point is working out why one cannot understand the failure reason from
aggregate reports. In what cases we do need a failure report in order to
understand what's wrong? Maybe we need better aggregate reports?
I found one problematic report today, reported by Yahoo! (Oath) on behalf of
aol:
<record>
<row>
<source_ip>4.31.198.44</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>tana.it</header_from>
</identifiers>
<auth_results>
<spf>
<domain>ietf.org</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
4.31.198.44 is mail.ietf.org. DKIM and SPF are not aligned, hence the failure.
I'm surprised there are no DKIM signatures. Now I'm going to add "DKIM
signatures not evaluated or not reported" to the list above, as it turns out
that Yahoo! seem to report valid signatures only. Anyway, would I have got a
better understanding had I received a ruf as well?
One thing a failure reports brings is the Received: (or ARC) chain. If I
wandered how come the IETF sends messages with my header_from, a ruf might
help. Is that a real case? Forwarding for email address portability (either
"mute" or SRS) is probably not even worth being reported, since there's nothing
a mail admin can do about that —updating the address could be done by the
author, had the server returned a 251/551.
Today's other reports are even more straightforward. But then I run such a
tiny server that I don't get an interesting assortment of cases.
Another question is *if* I were running a large server and *if* that
problematic record had a <count>1 zillion</count>, how many of the
corresponding failure reports would I read, assuming I received any?
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
