Spoofed email from LWN [LWN.net]

We were made aware today of an email sent to a reader that was spoofed to appear to be from LWN. The message claimed, among other things, that we were providing personal information about the reader to another site user. As is explained in our privacy policy we do not, and would not, provide such information.

If any other readers have received an odd message from LWN, it is an attempt at a hoax; if in doubt, please check the DKIM header of the email. Any email that does come from LWN will have a proper DKIM signature in its headers.

If you receive such a message, please feel free to send it to us, with its headers intact. But to reiterate, we are not providing any user information upon request, nor banning any accounts. We hope this will not be a recurring problem.

to post comments

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 2, 2026 21:28 UTC (Thu) by TwizzyDizzy (guest, #164887) [Link] (12 responses)

I guess your DMARC policy of "p=none" could be a little stricter. Depending on whether you have a tight grip over who and what is sending for lwn.net, of course.

Cheers
Thomas

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 3:43 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (7 responses)

It's always nerve-wracking to change that knob, especially since (AFAIK) there's no decent non-LLM tool to process the random feedback emails you get into coherent alarms.

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 7:08 UTC (Fri) by vasvir (subscriber, #92389) [Link] (1 responses)

Yes that's true. Nerve wrecking as in would I ever know if something is wrong? - and - what I am supposed to do with these?

BTW, I am using:

https://github.com/techsneeze/dmarcts-report-parser
https://github.com/techsneeze/dmarcts-report-viewer

You need both.

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 11:46 UTC (Fri) by TwizzyDizzy (guest, #164887) [Link]

Well, you don't necessarily need to publish reporting addresses. The reporting is only one aspect of DMARC. As long as you are sure you do not send SPF-or-DKIM-invalid mail yourself and if you are not interested in knowing if others do either, you could just publish a policy of "p=quarantine" or "p=reject" as guidance for other postmasters.

Cheers
Thomas

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 8:59 UTC (Fri) by rwky (subscriber, #119998) [Link]

I've had a good experience with parsedmarc https://github.com/domainaware/parsedmarc

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 10:45 UTC (Fri) by cortana (subscriber, #24596) [Link]

I have been using https://github.com/cry-inc/dmarc-report-viewer which makes an IMAP connection and parses and displays any emails that appear in the inbox. It doesn't send out alerts or anything like that, but it's a nice low-footprint tool to browse historical reports with.

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 12:12 UTC (Fri) by dskoll (subscriber, #1630) [Link] (2 responses)

I've never really understood the utility of DMARC reports. So someone is spoofing email from you. Great. What are you supposed to do about it? Unless you're a massive company with the clout and resources to actually go after spoofers, all you can do is warn people. There's no practical way to shut down the spoofing.

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 12:23 UTC (Fri) by daroc (editor, #160859) [Link] (1 responses)

The use for us is to detect problems where a legitimate email fails validation for some reason. That shouldn't happen with a proper configuration, but we're only human and configuration mistakes do happen.

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 12:25 UTC (Fri) by dskoll (subscriber, #1630) [Link]

OK, that's fair. I hadn't considered that case. Thanks.

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 12:03 UTC (Fri) by daroc (editor, #160859) [Link] (3 responses)

Yes, we do have a tight grip over who sends for lwn.net. All legitimate emails should come from our mail server, ms.lwn.net, with the exception of some internal monitoring emails that come from the rest of our infrastructure.

But we didn't want to learn that we'd accidentally broken something, so when Jon initially set up DMARC, it was with p=none. He intended to get around to checking our DMARC reports and then upgrading it, but then got sidetracked by actually writing articles. It never caused a problem until now.

Now that it has caused a problem, it's on our list to fix — including, hopefully, writing up an article about the tools that exist to scan and manage DMARC reports.

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 3, 2026 14:26 UTC (Fri) by TwizzyDizzy (guest, #164887) [Link]

Oh that would indeed be a nice outcome of this, as I agree with previous commenters that the tooling question regarding the evaluation of reports is, in fact, an issue one can spend a considerable amount of time on.

Cheers and thanks for teasing that :)
Thomas

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 4, 2026 1:51 UTC (Sat) by LWN-net23 (subscriber, #164757) [Link]

I am looking forward to the article about the tools that exist to scan and manage DMARC reports

SPF seems solid, but the DMARC policy could be stricter

Posted Jul 6, 2026 10:50 UTC (Mon) by Funcan (guest, #44209) [Link]

Is it bad of me that I'm sometimes pleased when LWN messes something up, because their incident reviews usually come in the form off a good tutorial?

PGP sign your email

Posted Jul 3, 2026 7:09 UTC (Fri) by ballombe (subscriber, #9523) [Link] (5 responses)

Just publish a public PGP key on LWN.net and sign all email with it.
Not signed -> not from LWN.
This is simpler and more robust than any SPF scheme.

PGP sign your email

Posted Jul 3, 2026 7:46 UTC (Fri) by anselm (subscriber, #2796) [Link]

Except that this won't help you with email providers who will penalise you for not publishing SPF records for your domains.

PGP sign your email

Posted Jul 3, 2026 9:18 UTC (Fri) by taladar (subscriber, #68407) [Link] (3 responses)

That is more or less exactly what DKIM does only with a much better supported and better specified system than PGP.

PGP sign your email

Posted Jul 4, 2026 21:55 UTC (Sat) by ballombe (subscriber, #9523) [Link] (2 responses)

DKIM identifies the mail server that was used to send the email, not the person who actually sent the email, which is the only thing that matters.

PGP sign your email

Posted Jul 4, 2026 22:54 UTC (Sat) by dskoll (subscriber, #1630) [Link]

DKIM does a bit more than that. It asserts that the domain of the From: header (to the best of the knowledge of the server doing the signing) is not spoofed. It also makes it obvious if the email body and some of the headers have been tampered with once the email has left the signing server. So you can generally trust the domain, if not the actual sender, and in the case of preventing spoofing from LWN.net, that's good enough.

If you need to know the person sending the email, then it has to be signed by somebody's personal secret key and verified by that person's personal public key.

PGP sign your email

Posted Jul 4, 2026 23:22 UTC (Sat) by anselm (subscriber, #2796) [Link]

DKIM does include a way to communicate the identity of the sender of a message on top of the sending domain (the i= tag in the DKIM-Signature header). How hard you want to lean on it in any particular case may be debatable, and it's not as if MUAs or spam filters generally look at it at all, but it's there in principle.