fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

11K
active users

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 tarpits such as iocaine.madhouse-project.org/, has anyone built a fake report generator before? Quick search finds github.com/celesteking/dmarcfa, 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.

iocaine.madhouse-project.orgiocaine - the deadliest poison known to AI

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.

@link2xt Reminds me that I should just throw away the report thing because 100% of the time it's the *other* provider that has a complete garbage setup.

@link2xt
@mwl can probably relate with the #RYOMS he's writing

A rebuttal to the "STOP USING DMARC" meme by @link2xt making the rounds in IT mastodon. DMARC absolutely has a real-world uses.

  • Identifying message sources sending as your domains, so you can see what services your organization is using to send email, which isn't always obvious, particularly in large organizations
  • Identifying which email sending services aren't configured to be authenticated, which more important now that Google and Yahoo are going to require authentication, including a published DMARC policy record when using bulk email senders
  • Once you have all legitimate sources properly authenticated, setting a DMARC policy to 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 requests
  • I have never seen the pct option at less than 100 (the default) because anything else makes policy enforcement inconsistent
  • If the entire US federal government can implement an enforced DMARC policy, you can too

For information about DMARC, it's benefits, and how to properly use it, check out Demystifying DMARC

seanthegeek.net · How to comply with Google and Yahoo's requirements for bulk email sendersStarting February 2024 Google and Yahoo will start enforcing additional requirements for emails to reach the inbox. Here's how to comply.
#DMARC#DKIM#SPF

@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.

seanthegeek.net · Proofpoint is requiring their customers to pay for Email Fraud Defense to get aggregate DMARC data from their gatewaysIn order to get aggregate DMARC data on mail flowing through their own gateways, Proofpoint customers must purchase Proofpoint Email Fraud Defense

@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

I never read even a single one of DMARC reports I got. Ever.

@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.

Oh, I did not know rua is an optional field. Then I guess I will update my setup from:
v=DMARC1;p=reject;rua=mailto:postmaster\@example.com
to:
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: wiki.list.org/DEV/DKIM

I fully support checking DKIM, this is what we do at github.com/deltachat/chatmail/

wiki.list.orgDEV/DKIM - Mailman Wiki

@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 github.com/deltachat/chatmail email setup running on nine.testrun.org/

For email authentication we have SPF, DKIM and DMARC records and pass all 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.

chatmail service deployment scripts and docs . Contribute to deltachat/chatmail development by creating an account on GitHub.
GitHubGitHub - deltachat/chatmail: chatmail service deployment scripts and docschatmail service deployment scripts and docs . Contribute to deltachat/chatmail development by creating an account on GitHub.

@link2xt @delta If you want that, just set up SPF 'v=spf1 ~all' and a DMARC `p=reject` policy. This way, an aligned DKIM signature is mandatory for DMARC to pass.

@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 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.