In other news, _dmarc.gmail.com TXT record reads "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com", _dmarc.fastmail.com is "v=DMARC1; p=none; sp=none; rua=mailto:rua@fastmaildmarc.com", _dmarc.outlook.com is "v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:rua@dmarc.microsoft; ruf=mailto:ruf@dmarc.microsoft; fo=1"
Speaking of the trending #aipoisoning tarpits such as https://iocaine.madhouse-project.org/, has anyone built a fake #DMARC report generator before? Quick search finds https://github.com/celesteking/dmarcfaker, but it does not look like something ready for use. I see some DMARC services already advertise that they filter DMARC reports according to a custom allowlist, so fake DMARC reports must be a thing.
I WANT TO SPEAK TO DMARC MANAGER !!11! QUICK!!!1!
@cek The Karen manager can't be reached right now, your request is still in spool and awaiting DMARC authentication.
A rebuttal to the "STOP USING DMARC" meme by @link2xt making the rounds in IT mastodon. DMARC absolutely has a real-world uses.
p=quarantine
or p=reject
prevents malicious spoofing and prevents the organization from going out and using whatever service the organization wants without making proper DNS change requestspct
option at less than 100
(the default) because anything else makes policy enforcement inconsistentFor information about DMARC, it's benefits, and how to properly use it, check out Demystifying DMARC
@seanthegeek You have to know your message sources to manage DKIM keys and rotate them anyway. You cannot rely on mail recipients to send DMARC reports, so it is not a replacement for enumerating and documenting the services sending emails.
Publishing "p=reject" DMARC is useful to make some recipients (e.g. rspamd) check at least SPF or DKIM, but only because better ADSP standard to enforce DKIM is not supported.
@link2xt A lot of SaaS services manage their own DKIM keys and give you a CNAME record to add to your domain's DNS so they can rotate the keys themselves. Sometimes, you don't even get to pick the selector. The DMARC reports have helped me match a service (via the reverse hostname of the sending IP address) to a DKIM selector. True, not all recipients send DMARC reports like they should glares at Proofpoint, but enough do to still be helpful. I'm absolutely maintaining internal documentation on DKIM selectors now.
No standard is perfect. DMARC policies are widely respected by most email providers, and almost all of the major ones do the right thing and send the reports back. I'll take that over no supported protection against spoofing.
@link2xt @seanthegeek
The point is with DKIM alone you can't prevent spoofing, because the d= parameter in the DKIM-Signature: header allows you to pass any domain name. Only when you set up DMARC will it check the d= parameter is the same with From:.
To me it's more like a design failure tho. Why does the DKIM standard allow you to pass the d= parameter in the first place? Standard communities are always like trying to fix something but result in complex systems with more problems
@vv221 You can also unsubscribe from them. My preferred setup currently is "v=DMARC1;p=reject;adkim=s;aspf=s", the strictest policy possible with no reports. Yet it is still not as strict as I want, because I want DKIM enforced and don't care about SPF. Relying on SPF for authentication is like using Telnet with IP address based authentication instead of SSH, this should have been deprecated long ago.
rua
is an optional field. Then I guess I will update my setup from:v=DMARC1;p=reject;rua=mailto:postmaster\@example.comto:
v=DMARC1;p=reject
@link2xt current state of the art: measures intended to combat spoofing not very effective, yet collateral damages are excruciatingly high
@link2xt makes you wonder how much energy will be wasted by enabling DMARC policy with 0% rejection (aka, no change at all) but now you get hundreds of email every day for the rest of all times
@link2xt this is some niche but accurate content
@link2xt Don't forget the harm DMARC has done to mailing lists.
@wingedpig Mailing lists are fine if they relay the message as is and don't break DKIM or rewrite the From header to clearly indicate they have changed the email. Allowing incoming mail with spoofed From: is not a solution.
The problem is not DMARC enforcing DKIM checking, but Mailman breaking DKIM signatures: https://wiki.list.org/DEV/DKIM
I fully support checking DKIM, this is what we do at https://github.com/deltachat/chatmail/blob/6a30db7ce0ec40e24f813958e1e3eb4d88379ae3/cmdeploy/src/cmdeploy/opendkim/final.lua
@link2xt While it's true that understanding the nuances of email authentication like SPF, DKIM, and DMARC can be complex, these protocols serve crucial roles in securing email communications. They are highly effective when implemented properly. Securing and ensuring the deliverability of your emails requires a certain level of effort and understanding. If you find it challenging, opting for a third-party email service that manages DNS records might be a viable alternative.
Implementing DMARC isn't just about receiving reports; it's also about checking alignment to prevent email spoofing and spear-phishing attacks, thereby enhancing your email security. Choosing not to enable DMARC reports is an option, but it's important to understand that DMARC, along with SPF and DKIM, is fundamentally about protecting your email infrastructure. The notion that "they" have misled us is a misunderstanding of the purpose and function of these email security measures. It's essential to approach these topics with a willingness to learn and understand their significance in the broader context of internet security.
@freddieleeman
At @delta we are currently building https://github.com/deltachat/chatmail email setup running on https://nine.testrun.org/
For email authentication we have SPF, DKIM and DMARC records and pass all https://www.learndmarc.com/ checks, but instead of any DMARC implementation run only OpenDKIM and reject any incoming mail that does not have strictly aligned to HELO, MAIL FROM and From: field DKIM record without even requesting SPF or DMARC from the sender. That is more secure than any DMARC setup.
@freddieleeman This would result in similar policy for outgoing mail if every receiver implements DMARC correctly. But we want to enforce strict DKIM policy on every other server sending incoming mail to us even if they publish p=none record or no SPF/DKIM/DMARC at all.
I consider changing current "v=spf1 a:nine.testrun.org -all" to "'v=spf1 ~all" or "'v=spf1 -all", but this might break delivery to servers that only implement SPF.
@link2xt Sorry, your reply is very confusing, so I hope this response makes sense. Setting a DMARC policy is for receiving servers, not incoming email. If you run your own mail server, you can bounce every email without a valid aligned DKIM signature, but that would undoubtedly cause deliverability issues. Most large email providers have properly adopted DMARC, so if you want servers to reject emails from your domain, without DKIM, set up SPF and DKIM like I mentioned previously.
@freddieleeman
> If you run your own mail server, you can bounce every email without a valid aligned DKIM signature
This is what we do. This already resulted in two servers reportedly fixing their DKIM setup after getting a DKIM error and revealed a bug in incoming filter breaking DKIM signature in some cases. We are fine with not receiving mails without proper DKIM signatures.
@freddieleeman
> Most large email providers have properly adopted DMARC, so if you want servers to reject emails from your domain, without DKIM, set up SPF and DKIM like I mentioned previously.
This is almost what we do. We publish proper SPF, DKIM and DMARC records with the strictest policies possible except that we have not removed "a:nine.testrun.org" from SPF yet because of the concern that it might break delivery to servers that only support SPF.
@freddieleeman Opened an issue to track this with more explanation: https://github.com/deltachat/chatmail/issues/211
@freddieleeman To clarify, STOP DOING DMARC is mostly a joke, but I am also serious about not running DMARC software on the server which implements all sorts of policies and generates DMARC reports as it adds a lot of complexity. We can do this because we don't care about federating with non-secure servers not supporting DKIM and hopefully it results in faster adoption of DKIM among servers which want to federate with us.
@freddieleeman This is not a conventional setup as we have essentially defederated all email servers not implementing DKIM, but is much easier to reason about than learning about all the possible non-strict alignments, interactions between SPF and DKIM fails/softfails etc.