DMARCbis is around the corner: what's changing(dmarcwise.io) |
DMARCbis is around the corner: what's changing(dmarcwise.io) |
There are two changes I would like to see but that don't seem to be addressed.
1. Option to require DKIM, instead of the current SPF *or* DKIM. I can hold my key close and have less trusted forwarders (which is sometimes necessary for receivers who are very picky about source IP) without allowing them to send mail that I didn't pass to them. For example with AWS SES I can hold the key and let them deliver my mail. But with the current situation they can also corrupt or make up new mail and it is trusted because it passes SPF. If I could say that the message *must* have a DKIM signature then they can't do that.
2. Solving mailing lists. Right now I use p=reject so my participation on many mailing lists (including IETF ones) is basically prevented. Google Groups does sender rewriting when solves this in an ugly way, but it isn't common and it would be nice to have a standardized solution.
Why bother adding a successor to pct? It works fine, so what if people always use pct=0 or pct=100, that is fine. No need to add a new spelling and confuse everyone.
> what’s the “denominator” and how do you estimate it?
Roll a d100 and if it is <= pct then apply the policy to the message. I don't get what is confusing about this.
There's hope that the mailing list problem will be solved by DKIM2 [1], since ARC has the problem of trusting the intermediaries.
On `pct`, you're right in theory, but it seems that implementers didn't get the message. From the mailing list [2]:
> That's how we intended it when we wrote that, and that's how early implementations did it. But maybe this is the lesson: People have inferred lots of different things from that rather straightforward definition, so maybe it's more ambiguous than we realized all those years ago.
And the draft says [3]:
> Operational experience showed that the pct tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.
I agree that replacing it with another tag is such a confusing and unnecessary change, though.
[1] https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...
[2] https://mailarchive.ietf.org/arch/msg/dmarc/Sk6JnDlXH_MkM4xm...
[3] https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarc...
Yeah, that is sort of what I assumed :(
> other values varied widely from one implementation to another.
IMHO the best solution to this is:
1. Clarify the specification so that future implementations are more likely to be correct.
2. Add a note that only pct=100 and pct=0 are recommended as the other values are inconsistently implemented. I would even rather go as far as calling all other values deprecated than add two new values that mean the exact same thing but will force implementations to support both and open this chicken and egg of you can't really switch to the new one because not everyone will support it. Just say that the pct flag has two possible values 100 and 0.
It seems like changes for changes sake and solves practically nothing DMARC actually needs fixed.
> Since most organisations are going to use p=reject anyway, a provision for receiving mail servers was added, so that an email isn’t rejected and instead only quarantined if there are signs that the message was forwarded or is coming from a mailing list.
Are you fucking kidding me?
The draft says:
>It is therefore critical that Mail Receivers *MUST NOT* reject incoming messages solely on the basis of a "p=reject" policy by the sending domain. Mail Receivers must use the DMARC policy as part of their disposition decision, along with other knowledge and analysis. "Other knowledge and analysis" here might refer to observed sending patterns for properly-authenticated mail using the sending domain, content filtering, etc. In the absence of other knowledge and analysis, Mail Receivers *MUST* treat such failing mail as if the policy were "p=quarantine" rather than "p=reject".
So basically `p=reject` doesn't actually mean reject anymore and receivers should instead treat it as quarantine by default.
The document then goes on by saying "nobody will listen to us anyway", which is an interesting thing to read in what will be a Proposed Standard:
>In practice, despite this advice, few Mail Receivers apply any mitigation techniques when receiving indirect mail flows, few organizations consider the effect of DMARC policies on their users' indirect mail, and it is unlikely that any advice in this document will change that.
And they are right because their recommendations about handling a reject policy are idiotic.
Orgs want a real reject policy, full stop. If we wanted our email to be quarantined... We would fucking set it a quarantine.
This is seriously one of the stupidest things I've read, in a spec, in a long time. It's right up there with whatever dumbass decided BIMI VMCs must not be used for reputation.
VMCs require a verification of personhood, trademark, and a non trivial momentary investment. But why use this reputation being served up on a silver platter to email providers when we can instead keep using our blackbox of IP reputation that already hasn't been working well for a decade.