I have changed literally nothing on my MUA so this is new behavior. The list, otoh, has been changing stuff since the switchover a while ago. This seems to have changed in list the last week or so? Mike On 5/23/25 7:12 AM, Josh Luthman wrote:

Thunderbird client probably.

I'm on Gmail and your message reads... from: Michael Thomas via NANOG <nanog@lists.nanog.org>

That's a strange from as the envelope shows... Reply-To: North American Network Operators Group <nanog@lists.nanog.org> List-Id: North American Network Operators Group <nanog.lists.nanog.org <http://nanog.lists.nanog.org>>

On Fri, May 23, 2025 at 10:10 AM Michael Thomas via NANOG <nanog@lists.nanog.org> wrote:

I'm using Thunderbird to read mail and lately the only thing I've seen in the mail.from address is

|North American Network Operators Group |

and not the author's address which makes it really hard to tell who is talking to whom.

I is just me, or has there been a list config change that is causing this?

Mike _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3N4JW7AV...

On 23/05/2025 17:16, Josh Luthman via NANOG wrote: I have the same experience and am on 128.10.2esr Regards, Hank

The last two Thunderbird releases were 5/20 and 5/13. Are you on 138.0 ?

On Fri, May 23, 2025 at 10:14 AM Michael Thomas <mike@mtcc.com> wrote:

...

I have changed literally nothing on my MUA so this is new behavior. The list, otoh, has been changing stuff since the switchover a while ago. This seems to have changed in list the last week or so?

Mike On 5/23/25 7:12 AM, Josh Luthman wrote:

Thunderbird client probably.

I'm on Gmail and your message reads... from: Michael Thomas via NANOG <nanog@lists.nanog.org>

That's a strange from as the envelope shows... Reply-To: North American Network Operators Group <nanog@lists.nanog.org> List-Id: North American Network Operators Group <nanog.lists.nanog.org>

On Fri, May 23, 2025 at 10:10 AM Michael Thomas via NANOG < nanog@lists.nanog.org> wrote:

...

I'm using Thunderbird to read mail and lately the only thing I've seen in the mail.from address is

|North American Network Operators Group |

and not the author's address which makes it really hard to tell who is talking to whom.

I is just me, or has there been a list config change that is causing this?

Mike _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3N4JW7AV...

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/52ZXCFAT...

Somewhat similar to Josh, I’m using Protonmail and your email comes in as: Michael Thomas via NANOG <[nanog@lists.nanog.org](mailto:On Fri, May 23, 2025 at 9:15 AM, Michael Thomas via NANOG <<a href=)> No issues or difference from the previous years of me using it. Cory On Fri, May 23, 2025 at 9:15 AM, Michael Thomas via NANOG <[nanog@lists.nanog.org](mailto:On Fri, May 23, 2025 at 9:15 AM, Michael Thomas via NANOG <<a href=)> wrote:

I have changed literally nothing on my MUA so this is new behavior. The list, otoh, has been changing stuff since the switchover a while ago. This seems to have changed in list the last week or so?

Mike

On 5/23/25 7:12 AM, Josh Luthman wrote:

...

Thunderbird client probably.

I'm on Gmail and your message reads... from: Michael Thomas via NANOG <nanog@lists.nanog.org>

That's a strange from as the envelope shows... Reply-To: North American Network Operators Group <nanog@lists.nanog.org> List-Id: North American Network Operators Group <nanog.lists.nanog.org <http://nanog.lists.nanog.org>>

On Fri, May 23, 2025 at 10:10 AM Michael Thomas via NANOG <nanog@lists.nanog.org> wrote:

I'm using Thunderbird to read mail and lately the only thing I've seen in the mail.from address is

|North American Network Operators Group |

and not the author's address which makes it really hard to tell who is talking to whom.

I is just me, or has there been a list config change that is causing this?

Mike _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3N4JW7AV...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MVJHKBQW...

Thank you! I solved this by right-clicking "NANOG" in the To/From line of a received email, selecting "edit details", "edit contact", clearing out all name fields and clicking "Save". On 23/05/25 17:05, Hank Nussbacher via NANOG wrote:

On 23/05/2025 17:32, Mark Tinka via NANOG wrote:

...

On 5/23/25 16:09, Michael Thomas via NANOG wrote:

...

I'm using Thunderbird to read mail and lately the only thing I've seen in the mail.from address is

|North American Network Operators Group |

and not the author's address which makes it really hard to tell who is talking to whom.

I is just me, or has there been a list config change that is causing this?

It's a Thunderbird thing.

https://thunderbird.topicbox.com/groups/planning/Tec65c7b3d9001140-M8645baa1...

-Hank

...

I don't have the energy to get into fixing it, but some day, I will... just not tomorrow :-).

Mark. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EWV25PI2...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3AX2BTOP...

On 5/23/25 1:49 PM, William Herrin wrote:

On Fri, May 23, 2025 at 7:09 AM Michael Thomas via NANOG <nanog@lists.nanog.org> wrote:

...

I'm using Thunderbird to read mail and lately the only thing I've seen in the mail.from address is

|North American Network Operators Group |

and not the author's address which makes it really hard to tell who is talking to whom.

I is just me, or has there been a list config change that is causing this? It's not just you. The "From:" header is being changed to:

From: Your Name via NANOG <nanog@lists.nanog.org>

I understand this has to do with DKIM crappiness where if any trace of the original email address remains in the From: header, the message may be rejected.

Not DKIM, DMARC to be more precise. I'm certain that close all of the domains people are sending from if they have a DMARC record, it's p=none which shouldn't trigger the 822.From rewrite, but that's what seems to be happening. Mike

It appears that Bryan Fields via NANOG <nanog@lists.nanog.org> said:

On 5/23/25 16:56, Michael Thomas via NANOG wrote:

...

Not DKIM, DMARC to be more precise. I'm certain that close all of the domains people are sending from if they have a DMARC record, it's p=none which shouldn't trigger the 822.From rewrite, but that's what seems to be happening.

lists.nanog.org is configured to rewrite the from regardless of DMARC setting.

Yup. Not a great choice.

Even if you have p=none, it still shows as a broken signature on the email and will be rejected by google/MS/etc. They are large enough to violate the standards and we all have to submit, unless you pay for delivery to their customers.

Sorry, but this is nonsense. Please, sir, step away from the kool-aid. They aren't perfect but that kind of conspiracy theory helps nobody. I run mailing lists that have lots of subscribers at large providers, They only rewrite sender addresses when DMARC policies require it, and they get mail delivered just fine. R's, John

On 5/24/25 3:47 PM, Bryan Fields via NANOG wrote:

ARC/RFC8617 was considered, but right now other than google, it appears to be not widely used.  If this was widely supported, it appears to be a good solution.

No, ARC doesn't help anything beyond what DKIM  can already do for mailing list traversal. It's basically a failed experimental RFC. Mike

It appears that Bryan Fields via NANOG <nanog@lists.nanog.org> said:

ARC/RFC8617 was considered, but right now other than google, it appears to be not widely used. If this was widely supported, it appears to be a good solution.

ARC turned out to be a failure since it depends on knowing that the system sending you mail with ARC seals is trustworthy, and that doesn't scale. The IETF is currently working on a follow-on to DKIM tentatively named DKIM2 that is intended among other things to do what ARC was supposed to do in a more scalable and verifiable way. I hope by the end of the year we can have trial code for mailing list software to see how it works. The large mail systems are all involved in this and are as eager as anyone for it to succeed. R's, John

The IETF is currently working on a follow-on to DKIM tentatively named DKIM2 that is intended among other things to do what ARC was supposed to do in a more scalable and verifiable way.

so i took your message, removed classic '^(To|From|Subject|Date):' and the actual text you wrote, leaving only the cruft that decades of ietf email standards work produces to add some sort of credibility to it and got $ wc foo 55 299 5224 foo and the purpose of much of it is to validate the servers on the *path* the message followed; when i really do not give much of a damn about the servers or the path. what i actually care about is: - authenticity: that you sent the message, for some value of "you," maybe your email addy[0], - integrity: it was not altered (and, in this case it was, both headers and text, thanks to dmarc, mailmate, etc.), and - confidentiality: for some, not this, email privacy is needed from my pov there is a serious disconnect here < shaking of fist at clouds > randy, a dinosaur who still uses pgp for email with passwords etc. --- [0] - i am sure the ietf could spin up a working group or three to go down this identity rabbit hole

...

what i actually care about is: - authenticity: that you sent the message, for some value of "you," maybe your email addy[0], - integrity: it was not altered (and, in this case it was, both headers and text, thanks to dmarc, mailmate, etc.), and - confidentiality: for some, not this, email privacy is needed

from my pov there is a serious disconnect here

On my small system I feel pretty much the way you do, but large systems have different issues. Someone will get a plausible sender to send them a message with spammy contents, then they will resend that message unaltered to a zillion recipients at large mail systems which is hard to detect quickly since the DKIM, DMARC et al. are all OK. Being able to see there is an extra hop or two in the path that doesn't look like a mailing list is useful for them.

and 30+ years of email content and protocol hacking driven by that view has worked sooooo well randy

...

...

On my small system I feel pretty much the way you do, but large systems have different issues. Someone will get a plausible sender to send them a message with spammy contents, then they will resend that message unaltered to a zillion recipients at large mail systems which is hard to detect quickly since the DKIM, DMARC et al. are all OK. Being able to see there is an extra hop or two in the path that doesn't look like a mailing list is useful for them.

and 30+ years of email content and protocol hacking driven by that view has worked sooooo well

I go to a lot of meetings with people who run large mail systems, but I don't think I've ever seen you at one.

If you have some key insight we've all missed, and that will work at scale for mail systems with billions of users, let me know and I'll pass it along.

just wow! and whose credibility does this ad homina call into question? but back to technology. of the myriad of protection techniques in use by providers large and small, statistically which reject/protect-against how much? actual measures. ip-range filtering, smtp protocol errors & violations, et alia vs dkim, dmarc, even spf. randy

On 5/26/25 5:52 PM, John R. Levine via NANOG wrote:

On Mon, 26 May 2025, Randy Bush wrote:

...

but back to technology.  of the myriad of protection techniques in use by providers large and small, statistically which reject/protect-against how much?  actual measures.  ip-range filtering, smtp protocol errors & violations, et alia vs dkim, dmarc, even spf.

No two mail systems are the same, and large mail systems don't publish their stats because they don't want to give more hints to the crooks. Small mail systems vary so much that even if you tried to collect and combine stats, it's unlikely it would tell you anything more than that mail systems vary a lot and we already know that.

Large providers not being forthcoming cuts both ways though. The bad guys may not get hints, but neither do the good guys. That would be fine if they wanted to invent non-public standards amongst themselves, but it's not OK when they want it blessed by IETF with what amounts to "trust us, we know what we're doing." That's doubly true when it's pretty obvious that they don't know what they are doing, cf ARC. They can't have it both ways. Mike

On Fri, May 23, 2025 at 01:49:07PM -0700, William Herrin via NANOG wrote:

It's not just you. The "From:" header is being changed to:

From: Your Name via NANOG <nanog@lists.nanog.org>

I understand this has to do with DKIM crappiness where if any trace of the original email address remains in the From: header, the message may be rejected.

I believe it's DMARC, but: also crappiness. Some instances of Mailman are configured to only do this when it's necessary (based on the records published by the domain); some are configured to do it all the time; some are configured to never to do it. I'm going to guess that this list may be in the first category, but that's only a guess and I very much defer to the list-owners. As long as we're discussing this, let me note that there's an unfortunate consequence of this DMARC...accomodation that sometimes arises when email clients that auto-add contact addresses are in play. Let me use the message I'm replying to as an example. It includes this header:

From: William Herrin via NANOG <nanog@lists.nanog.org>

An email client that wants to helpfully populate the user's contact list is likely going to extract: nanog@lists.nanog.org and assign the text string: William Herrin via NANOG to it. This is not good. And it becomes even more fun if the user (later) composes a message addressed to nanog@lists.nanog.org, because the email client may auto-populate it thus: To: William Herrin via NANOG <nanog@lists.nanog.org> even though it's a new message in a new discussion thread. OR if the user (later) tries to compose a message to William Herrin, because they may start to type "William Her", the client will autocomplete it, and if they're not paying attention to what the address really is, they'll send it here instead of where they're trying to send it. Unfortunately, this is not speculation. (Well, this example is.) I've seen it -- twice -- on other mailing lists. But all this DMARC and DKIM complexity and bag-on-the-side-of-a-bag ad hackery must be worth it, because surely they have solved the spam problem (narrator: NO!) and forgery problem (narrator: NO, AYFKM?!). ---rsk

On 5/25/25 2:20 AM, Tom Ivar Helbekkmo via NANOG wrote:

SPF was the first. It lets you publish, through DNS, a list of the addresses of the mail servers that you have authorized to send email from your domain. When some mail server tries to deliver email purporting to be from your domain, you're asking the recipient mail server to check that list, and accept the email if the delivering mail server is on it, but refuse if it is not.

SPF wasn't really the first. Both DKIM and SPF arose pretty much at the same time.

DKIM was next. It lets you publish, again through DNS, the public key of a public/private pair. You then use the private key to create a cryptographic fingerprint of the message, using the body and a few selected headers (To:, Cc:, From:, and Subject: normally included). When a mail server out there receives the email, it can use your public key to verify the fingerprint. A match implies that the email has not been modified since it left the signing server. If the domain in the "From:" header matches the domain where the public key is stored, the recipient knows that the email was DKIM signed by a mail server trusted by the sending domain (since it must have the private key). It can, therefore, assume that the email really is from the "From:" address, and has not been modified along the way.

DMARC, finally, ties these things together. It lets you publish, once again using DNS, a few policy options for the handling of SPF and DKIM, for what you want done with the email, and for reporting back to you what was done, and why. DMARC requires either SPF or DKIM to pass, and you can choose whether you want the recipient system to quarantine or simply refuse email that fails to pass at least one of them.

It's never been especially clear to me why these two piece of policy needed to be unified -- it's certainly caused a huge amount of grief and a near-infinite amount of standards churn trying to do so as evidenced by it taking 10+ years to get to a still non-PS rfc, afaik. SPF had its own policy mechanism, DKIM its own too (ADSP nee SSP). Why DMARC is "better" is still pretty much a mystery, and my suspicion is it's mainly politics.

A modern mailing list is not a simple forwarder. It sends out copies of the received email item (which, then, will have passed the DMARC requirements of the sending domain, if specified, or it wouldn't reach the mailing list software in the first place),

There is no requirement that a mailing list honor or even care about DMARC. That's true of all of this: it's purely informational to the receiver to use as they will (or not). Expecting mailing lists to do anything in particular is a mistake.

So mailing list software today typically checks the originating domain's DMARC configuration. If that has a policy other than "none" (which says to deliver email even if it fails both SPF and DKIM), it will send the email "From:" the list, and not the originator. The email then nicely passes the mailing list's own SPF, of course. Additionally, the mail server sending it out from the list software will normally DKIM sign the outgoing email, so it ends up properly authenticating as coming from the mailing list software. It would be nice if this were more uniformly true, but alas I don't think you can really count on it. Even IETF mailing lists don't resign (somebody has claimed this is a bug, but it's been a bug for a very long time, from what I can tell).

This means that members of the list can choose to trust the mailing list owner to have configured everything so that they've properly verified the originating sender, and are not passing on something that is a forgery. If their own mail server is properly configured to check SPF/DKIM/DMARC, they can trust that the email is really arriving from the (trusted) mailing list.

More likely is that the receiving domain (ie, the mailbox provider) is the ones doing that. Obviously individual mailboxes don't scale very well.

This stuff isn't perfect, of course. As is obvious from what I wrote toward the end of the last paragraph, transitive trust is a problem that it would be nice to have a good solution for. ARC is an attempt at this, but has failed to gain traction. Let's hope that DKIM2 (which John Levine mentioned in another post in this thread), by attacking the problem from another angle, does better!

I don't expect that the soi-dissant DKIM2 will do much to help, and it seems to be a lot of wheel reinvention for its own sake. The closest thing for mailing list traversal is the so-called "modification algebra" but it's not really much different than what is already available with DKIM (ie, z= and l=), and it unfortunately requires active participation of the mailing list software which is going to be dodgy for probably a long, long time (this is unlike z= and l= which are under the control of the originating domain). Nobody but me, it seemed, cared about using that capability with DKIM so anything new imo is too little too late. If people started using the current DKIM capabilities as standardized in STD 76 I might have a different opinion, but to my knowledge either nobody or very few are. There isn't a silver bullet here and anything that claims so is peddling snake oil, IMO. Mike

On 5/25/25 8:42 AM, Tom Ivar Helbekkmo wrote:

Michael Thomas via NANOG <nanog@lists.nanog.org> writes:

...

It's never been especially clear to me why [SPF and DKIM] needed to be unified -- [...] SPF had its own policy mechanism, DKIM its own too (ADSP nee SSP). Why DMARC is "better" is still pretty much a mystery, and my suspicion is it's mainly politics. The way I see it, you can't have both without something that lets each do its evaluation, and then uses those results as input to a final decision. If you just put both of them in there, as independent agents, you'll get e.g. SPF rejecting a forwarded email, and never letting DKIM verify that it is, in fact, genuine.

My position is that what could actually be helpful is a BCP which describes the entire ecosystem and what MTA's and potentially other things in the mail delivery path ought to either be doing, or cognizant of. I have long thought that the concept of a "well behaved mailing list" might be useful to assist with an admittedly imperfect situation. But it might be nice to give advice for receivers (and that would be *extremely* helpful if big mailbox providers were more forthcoming... alas). Beyond that, I really don't see what DMARC has brought to the table beyond 10 years of argument and... irrelevance in many ways. Mike

On 5/25/25 11:57 AM, John Levine via NANOG wrote:

It appears that Michael Thomas via NANOG <nanog@lists.nanog.org> said:

...

There is no requirement that a mailing list honor or even care about DMARC. That's true of all of this: it's purely informational to the receiver to use as they will (or not). Expecting mailing lists to do anything in particular is a mistake.

...

So mailing list software today typically checks the originating domain's DMARC configuration. If that has a policy other than "none" (which says to deliver email even if it fails both SPF and DKIM), it will send the email "From:" the list, and not the originator. The email then nicely passes the mailing list's own SPF, of course. Additionally, the mail server sending it out from the list software will normally DKIM sign the outgoing email, so it ends up properly authenticating as coming from the mailing list software. It would be nice if this were more uniformly true, but alas I don't think you can really count on it. Even IETF mailing lists don't resign (somebody has claimed this is a bug, but it's been a bug for a very long time, from what I can tell). Really, it was a bug. A bunch of stuff broke when we moved to the new mail server earlier this year, and it's fixed now. (I checked.) The DMARC rewrite stuff that I added broke at the same time, haven't checked whether it's back yet.

AFAIKT, it's still a bug. But the larger point is that bug or no, there seems to be no urgency to fix it which doesn't bode well for other mailing list software to be upgraded in the wild any time soon. The incentives senders and mailing list operators is not very well aligned. Mike

Bjørn Mork <bjorn@mork.no> writes:

Tom Ivar Helbekkmo via NANOG <nanog@lists.nanog.org> writes:

...

SPF broke forwarding, both for individual recipients, and through email distribution lists, because the forwarding server wasn't on the list.

This is not entirely precise. It broke traditional alias forwarding, where the forwarding server would reuse the original envelope sender. But SPF does not break forwarding as long as the forwarding server use its own proxy envelope sender. Mailing lists have traditionally "always" done this, even before SPF. Remember the "owner-" aliases?

Yes, of course. I didn't want to get into all the details, like the difference between envelope and header senders, in what was an attempt at clarifying the basic functionality and purpose of these mechanisms.

The big problem with DMARC is that it ties SPF to the From header field, so changing the envelope sender will not work anymore. This forces the forwarder to mess with the From field to align it with a SPF valid envelope. Which again will break any existing DKIM signature. Which of course can be worked around by adding another DKIM signature.

Well, no. If the forwarder specifies a proxy envelope sender, and doesn't change the "From:" header, SPF will not be aligned, but the original DKIM signature will be valid, so DMARC verification will pass. It's certainly far from perfect, but DMARC does allow some scenarios to work that wouldn't with just SPF and DKIM, ignorant of each other. -tih -- The creation of the state of Israel was a regrettable mistake. It is time to undo this mistake, and finally re-establish a free Palestine.

On 5/25/25 10:16 AM, Bjørn Mork via NANOG wrote:

...

If the domain in the "From:" header matches the domain where the public key is stored, the recipient knows that the email was DKIM signed by a mail server trusted by the sending domain (since it must have the private key). It can, therefore, assume that the email really is from the "From:" address, and has not been modified along the way. Yes, so this also works through a forwarding mail server, provided it only changes the envelope. Older mailing list software broke because it messed around with the message content, but that was completely unnecessary. And good to get rid of. Injecting some additional mailing list headers is still fine, and will not break DKIM.

It should be noted that NANOG's mailing list before the change over didn't cause DKIM-breaking signature behavior, but now it does (like most mailing lists).

The big problem with DMARC is that it ties SPF to the From header field, so changing the envelope sender will not work anymore. This forces the forwarder to mess with the From field to align it with a SPF valid envelope. Which again will break any existing DKIM signature. Which of course can be worked around by adding another DKIM signature.

DMARC is broken by design. SPF and DKIM worked fine alone.

Has anybody even enumerated why "alignment" is even a supposedly good idea? Or why unification of SPF and DKIM policy was needed at a protocol level? I mentioned that a BCP might be useful, but that doesn't require protocol level standardization. I was sort of ambivalent about "alignment" when I first heard about it, but maybe that's really the heart of why it went off the rails where both SPF's policy and DKIM's ADSP were actually sufficient before. Mike

Sir, this is a Wendy's. On Wed, Jul 2, 2025 at 3:47 PM Rich Kulawiec via NANOG < nanog@lists.nanog.org> wrote:

On Sun, May 25, 2025 at 11:20:16AM +0200, Tom Ivar Helbekkmo via NANOG wrote:

...

First: SPF/DKIM/DMARC are not about spam, so that part is irrelevant.

Perhaps you don't remember this, but when SPF was announced, its home page read:

"Spam as a technical problem is solved by SPF."

Shortly thereafter, spammers became far and away the largest early adopters of SPF.

Of course, that claim was eventually disappeared down the memory hole.

Now onto the long, and I do mean REALLY LONG part of this. Sorry, it's a complex issue and it takes time to explain all the pieces.

Here's a one-sentence summary:

All these alleged anti-email-forgery technologies have accomplished is to make the email forgery problem MUCH worse than before they existed.

Introduction ------------

I've never considered email forgery to be a significant problem -- not when compared to the other problems we face.

But let's put my opinion aside for a moment, and let's presume that email forgery really is a significant problem -- one so serious that it's worth adding an enormous amount of fragile complexity to an ecosystem already under serious stress from spam and other attacks/abuse. Let's assume that it's worth breaking email forwarding (working fine for decades) and mailing lists (working fine for decades, and clearly the best mass collaboration/communication mechanism we have) and adding enormous cost, effort, and complexity to every email system.

There's a problem with that: email forgery can't be solved.

Even if if these byzantine hacks were perfectly designed (they're not) and globally deployed (not happening) and correctly deployed everywhere (nope) and always worked perfectly (also no) and weren't attacked (they are) and so on, even if everything worked *exactly* as intended...the overall impact of all this effort and expense and brittle complexity is to make the email forgery problem MUCH worse.

I've explained this before (briefly) but let me add a lot more detail this time around.

Part A: contributory factors ----------------------------

A1. We've had a problem with fake/junk domains for decades. It was bad enough when there were only 7 gTLDs, but now there are now ~1000 new gTLDs that nobody needed or wanted except (a) registrars, who of course want to make the cash registers ring and (b) abusers/attackers, who buy domains in bulk, burn through them, and then buy more. This symbiotic relationship works beautifully for both parties involved but not for anyone else. And of course registrars are performing no due diligence whatsoever (why should they?) so it's trivial for abusers/attackers to register example.xyz or example.lol or example-com.xyz or example-site.red or whatever, where "example" is a name explicitly designed to suggest that they're some other Internet operation -- e.g., Amazon, Paypal, Google, Joe's Donuts, etc.

I've been studying large samples of domain data for multiple decades, and there are enormous numbers of these fake/junk domains. Many are abandoned once they've served their purpose, but new ones are being registered constantly. And every time a new TLD is put into production, there's a land rush as abusers/attackers swarm it in an attempt to be the first to register the optimal fake domains.

I see no signs that this problem will be solved, because the people responsible for creating it don't want it to be solved. If these registrars performed any kind of due diligence, it would (a) cost them money and (b) reduce their sales. There's no reason in the world for them to do that.

Bottom line: it's cheap, simple, and easy to register an arbitrary number of domains whose names correspond to any operation that abusers/attackers wish to target.

You want a real-world example? Okay. Here's an example:

Infrastructure Laundering: Blending in with the Cloud

https://krebsonsecurity.com/2025/01/infrastructure-laundering-blending-in-wi...

U.S. Sanctions Cloud Provider "Funnull" as Top Source of "Pig Butchering" Scams

https://krebsonsecurity.com/2025/05/u-s-sanctions-cloud-provider-funnull-as-...

Complete List of Domains Attributed to Funnull

https://www.ic3.gov/CSA/2025/Complete_List_of_Domains_Attributed_to_Funnull....

There are 332,696 lines in that list. Well over a quarter million fake/junk domains used by just one scamming operation. And as large as this is, it's the tip of the tip of the tip of the iceberg.

Let me also ask a very pointed question: if someone shows up at your hosting or cloud operation, and they want to deploy, let's say, 52,782 domains: do you think that maybe, just *maybe*, you ought to ask a few questions about what the heck they're up to?

If you're Microsoft or Amazon (see Krebs articles above): nope. Which brings me to:

A2. There are all kinds of hosting/cloud operations out there which will happily take example.xyz's money because they perform the same level of due diligence as registrars in (1): none. These operations know full well that example.xyz is not Example Inc, and they know full well what they're doing, but because example.xyz pays the bills and they're repeat/bulk customers, the hosts/clouds just take the money and look the other way.

This isn't a small problem. It's massive. And it includes a lot of hosting/cloud operations that should know better. And probably *do* know better, but: due diligence costs money and takes effort, it's cheaper and easier to just blow it off and only take action belatedly -- long after the damage is done -- if there's any bad press.

Bottom line: even the most obvious scam/fraud operations have no problem finding hosting.

A3. The combination of (A1) and (A2) mean that you can go out today and register 1000, 10000, 100000 fake domains impersonating the Example, Inc's of the world and you can find hosting for them, and you can do it all at a bulk rate discount. Your only real difficulty will be competing with the other people doing the same thing. And unless you do something that generates a sufficient amount of sufficiently bad press, it's very unlikely that a registrar or host will take any action to shut down anything you're during, and even if they do that, they'll only shut down the small part directly involved -- everything else you have in place will be just fine. And then, on top of all this, they'll slow-walk whatever they do in order to keep the income coming as long as they possibly can.

A4. User interfaces in email clients -- whether standalone pieces of software, or webmail interfaces that run in a web browser -- are increasingly being modified to obfuscate sender addresses. In other words, rather than displaying:

From: Joe Smith <joe@example.com>

they display:

From: Joe Smith

and some kind of user action is required to actually see the address.

The aggregate effect of this, across all UIs across all clients across all users, is to train users to ignore actual email addresses in favor of the text strings that purport to be someone.

(Did YOU check the actual email address in this message to see if it's really from me?)

A5. One consequence of (A4) is that users are increasingly unable and/or unwilling to understand email addresses. They can't distinguish @example.com from @example.xyz or @example-com.lol or @exammple.com or @exammple.somethingsomething.fun.

(Yes, yes, there are *some* users that can do this. A few clueful ones. As in: "A person is smart. People are..." C'mon, you know the rest of this.)

This loss of comprehension/function resulting from (A4) and (A5) works beautifully for the operators of domains in (A1) and (A2): they don't even have to try hard. Even sloppy half-ass typosquatted domains (and subdomains) work just fine.

[ Let me interject that while I was drafting this I read about the plans by Mozilla to completely screw up the address bar in Firefox -- because of course leaving the simplest, most fundamental, and most important thing in the browser alone was never a choice for these incompetent clowns. If I understand what they're going to do correctly, and I really hope I don't, they're going to make life MUCH easier for forgers/scammers/et.al. who are deploying fake domains. ]

A6. User interfaces in email clients are being modified to provide signaling to users that a given message has been "authenticated" or "verified" or "signed" or "certified" or some similar designation. This is of course the result of a successful check of whichever anti-forgery mechanism(s) the receiving email server chose to utilize.

And just as users being trained to accept (A4), they're being trained to accept this. They believe what's in front of them on the screen.

But of course this means *nothing*: a message from joe@example.xyz will be dutifully marked (provided the keepers of example.xyz set things up correctly and everything's working) as authentic even though example.xyz is a fake domain that has nothing to do with the real Example Inc. and Joe is a fake person.

In other words, obviously fake messages from obviously fake domains are treated the same as authentic messages from authentic domains.

("But couldn't...". No. It's not a tractable problem, because it would require enumerating the authentic domain(s) of every operation on the Internet, i.e. determining that example.com is the "real Example Inc. -- for millions of example.com's, example.edu's, example.net's, etc. And not only would this be incredibly expensive, it would break badly as companies and domains change ownership or go out of business, it would greatly favor large operations over small ones, it would quickly be corrupted by the people with the biggest wallets, it would... So don't even go there.)

This is analogous to the wry saying about https:// -- yeah, it means you have a (putatively) secure connection, but you could have a secure connection to the worst people in the world.

A7. Many Example Inc's of the world don't send plaintext email messages; they mark them up with HTML and graphics and so on, which means that they're teaching their users that any message which looks like it's from them is really from them.

They're training their users to fall for forgeries/phishes.

And years (decades now) of this training have paid off: it's much, MUCH easier to trick users now than it was 20 years ago.

A8. Similarly, many Example Inc's of the world include URLs in their messages. They've spent years (decades now) training users to utilize those URLs, and of course users have dutifully learned to do this, and once again:

They're training their users to fall for forgeries/phishes.

And years (decades now) of *this* training have also paid off: again, it's much easier to trick users now than it was 20 years ago.

A9. The combination of (A7) and (A8) means that there's no help coming from the Example Inc's of the world. They'll continue to train their users to be victims while exhorting them to not be victims. The relevance to my point here? These email worst practices distract users from the small pieces of critical information that *might* give them a slim chance of spotting a forgery. They don't cause the problem, but they certainly exacerbate it.

A10. The aggregate impact of (A1)-(A9) is: users see a message that looks as they expect it to -- it has the pretty graphics and typography of Example Inc. It claims to be from Example Inc. It's marked as "verified" in their email UI. It has a domain that looks kinda like Example Inc's (if they even bother to check, which almost none of them will).

What do you *think* they're going to do? I can tell you what they won't do: they won't take the time to actually study the email address and see that it's @example-com-completely-fake.xyz, or to study the embedded URLs, and even if they do, a substantial fraction of them Will Not Get It.

If you think I'm wrong about this, then I must ask: have you actually spent any time with a significant number of users?

Part B: large email operations ------------------------------

It's not always necessary to go through the trouble and expense of registering domains, arranging for hosting, etc.

It's easy to set up an arbitrary number of accounts that claim to be arbitrary people/companies and spam/phish/whatever from them at will, because there are some very large mail operations that make this easy.

And because those same operations have implemented all this anti-forgery tech, those messages will dutifully pass every check that can be done on them.

And before someone trots out the "...but they're so large and it's SOOOO hard..." nonsense as an excuse for the malfeasance of these very large email operations: no. If you can't run an enormous operation properly, you shouldn't *build* an enormous operation. It's irresponsible. It's unprofessional. It's unethical.

Especially when it would be trivial for these operations to throw 1,000 people and a billion dollars at the problem tomorrow. (We *know* they have those resources, because they're already wasting them on bogus "AI" development.)

Let me note, in fairness, that there are also some other rather large operations that -- as far as I can tell by measuring across hundreds of domains over several decades -- do a very good job. The problem is that they're the exception.

Recap of part A and part B: ---------------------------

The combination of (A) and (B) means that we have an environment where it's cheap, easy, and simple to register an arbitrary number of domains masquerading as Example Inc. It's also cheap, easy, and simple to find hosting for them. And then -- thanks to very poor choices in user interfaces combined with lack of user knowledge/effort, it's cheap, easy, and simple to convince lots of people that completely fake messages from completely fake domains are authentic. And there's even a pretty good chance that forgeries which don't even use a fake domain will work: there are certainly unlimited opportunities to try -- also cheap, easy, and simple.

The sad reality is that while it's true that thanks to this anti-forgery tech, abusers will have a hard time successfully forging messages from the real example.com and getting them delivered: they don't have to.

Part C: bots ------------

And then it gets even worse, because of a problem that still exists but doesn't garner the headlines that it did years ago.

The problem is bots. Remember this?

Vint Cerf: one quarter of all computers part of a botnet http://arstechnica.com/news.ars/post/20070125-8707.html

That was 18 years ago. And in the ensuing time, *nothing* has happened to seriously address that problem. (Yes, yes, I'm aware of all the headline-grabbing when someone somewhere dismantles a botnet, but those are momentary disruptions at best.)

On the other hand, lots of things have happened to make the bot problem worse, including (1) more computers (2) more users (3) vastly more sophisticated bot-creating malware (4) bot-creating malware targeting non-Windows systems (5) major improvements in botnet C&C (6) the IOT -- remember, the "S" in "IOT" stands for security. And (7) thanks to Microsoft's "Recall", things will get worse yet again.

Oh, and let's (8) toss in AI, because the people frantically developing those systems want to spend lots of time and money hyping them but can't be bothered to put in any guardrails or do any real testing or even concern themselves for a moment about how this tech will be misused by some of the worst people on the planet. I'll bet even money that there's already a botnet being run by a commercial AI. It's an obvious move, don't you think?

Note that:

C1. Anyone in control of a bot can utilize any email credentials stored on or transiting that bot at will. If Joe has an address @example.org and one at @aol.com, then the new owner of Joe's system can send outbound messages via those at will.

C2. They can also rummage through all email stored on that system or in the accounts from (1), which means that -- if they want -- they can easily make some first-order guesses at who's likely to believe that a message which claims to be from Joe AND that their email system's UI says is from Joe, really is from Joe.

C3. This is already bad if Joe is just some guy and Joe's system is just some random laptop somewhere. But what if it's not? What if Joe works at Example Inc. and this is his desktop system and it's loaded with customer correspondence and it's connected to his work email account, also loaded with customer correspondence? *Now* the new owner of Joe's system is in an ideal situation to phish or scam all of those people, because such a message really will come from Joe's email address via Joe's work email server, it'll pass all the anti-forgery checks anyone cares to run, and it'll dutifully be marked as "authentic" in most/all those email UIs used by its recipients.

So even if the content is a little sketchy -- maybe enough to raise an eyebrow or two among recipients -- they'll look at their screen, see that the message is marked as real, see that the fancy graphics and typography look real, AND THEY'LL BELIEVE IT. Of course they will, they've been trained to, see A7 and A8 and above

C4. And what about the tiny fraction of people who will catch on that think that's something amiss? What, EXACTLY, do you propose that they do about it? Example Inc has probably done its very best to turn itself into an impenetrable corporation where it's nearly impossible to reach anyone in a position to understand a problem like this and take prompt action to fix it. Do they have working postmaster@, security@, abuse@ addresses -- something that every novice sysadmin on this planet should know about? Probably not. Do they have a published security contact? Probably not. Do they have any mechanism whereby someone who calls in can reach anyone useful? Probably not. So even if one of those rare, clueful, diligent people spots this and tries to report it, they're probably going to give up in frustration long before they achieve anything.

C5. And even if -- by some miracle of science -- someone in (C4) manages to reach a contact inside Example Inc who understands the problem...the most likely outcome is that Example Inc will ignore it and pretend it doesn't exist. The next most likely outcome is that they'll quietly fix it but say nothing. Why should they inform or warn anyone? That's bad for business. And since there are no significant penalties for anyone involved, their best bet is to disappear the problem and claim it never happened. (If caught? Deny everything. If REALLY caught? Blame a miscommunication and throw a third-level manager under the bus.)

Sadly, (C4) and (C5) are not hypothetical. They're why I don't even bother any more. Why should I invest my time and unpaid labor when these operations can't even be bothered to do the simplest, easiest, most obvious things like supporting RFC 2142 addresses and reading what shows up there, acting on it promptly, and publicly acknowledging what's happened?

How many email accounts are affected by bot proliferation? A first-order estimate may be found by multiplying (a) an estimate of the worldwide population of bots by (b) an estimate of the average number of email accounts used/present on those bots. I think the floor for (a) is 750M and 1.5B is much more likely. (Go back to Cerf's estimate from 18 years ago and extrapolate.) As to (b) I think it's probably between 1 and 2 -- let's go with 1.5, probably low but that may also account for duplicate email accounts across bots.

This gives us a quite conservative back-of-the-envelope guesstimate somewhere north of 1B.

One billion compromised email accounts.

And you want to tell me it's possible to do something truly meaningful about email forgery? Okay. Fine. *Fix this problem first*, then we'll talk.

I'll wait. Let me know when you're done.

Note that not only do you have to (1) remediate all those accounts, you'll also need to (2) remediate all the bot'd systems and then (3) keep them that way -- which means discovering the root cause(s) of their compromise and fixing it. (3) will be very difficult if the root cause is something like "the user clicks on every shiny thing they see". But if you're going to claim it's possible to do something truly meaningful about email forgery, then you must do all those steps first.

Part D: email account compromises ---------------------------------

And (C) isn't even all the compromised email accounts, because we also have to think about all the cases where only an email account (not an entire system) has been compromised. I don't know how many there are (nobody does), but I strongly suspect it's also an enormous (hundreds of millions or more) number. One way to approach an estimate of this is to observe the marketplaces where they're being sold, and in those places, there are lots people selling them in bulk: how many hundred thousand would you like?

(Do recall that a few years ago, EVERY Yahoo email account was compromised. That was a neat 3 billion accounts right there.

Every single Yahoo account was hacked - 3 billion in all

https://money.cnn.com/2017/10/03/technology/business/yahoo-breach-3-billion-...

And as anyone who's paying attention to the daily parade of security breaches and dataloss incidents is painfully aware: this isn't an isolated case. It's the norm.)

This problem is exacerbated by the complete lack of support at some very large email operations: even when someone who's the real owner of one of these compromised email accounts detects it and make a good-faith effort to fix the problem...yeah, good luck with that. Their chances of recovering their own email account are pretty much zero thanks to awful procedures and non-existent customer service. Thus there's a high probabilty that any compromised email account is going to stay compromised until it no longer exists.

Again, if you want to tell me that something serious is going to happen WRT email forgery: *you have to fix this too*. Let me know when that's done as well.

Part E: email server compromises --------------------------------

And *then*, on top of (C) and (D), we have to consider the cases where email servers themselves have been compromised, and there's a steady parade of those. Hardly a day goes without another announcement of a massive security breach that involves most/all of some operation's infrastructure,

Those announcements are only the tip of the iceberg, since pretty much everyone does their best to conceal such things until either the press reports on them and/or they're legally required to report them... and even *then* they'll sometimes persist in denial and minimization.

I'm looking right at you, Oracle.

Anyway, compromise of an email server means that it's not only possible to undetectably forge email from every account on it, it's also possible to create new ones and do the same with those. And of course the new owners of these servers have access to everything stored on or transiting them, which provides all kinds of resources that are useful in figuring out who to target, how best to target them, etc.

And yet once again, if you want to tell me that something serious is going to happen WRT email forgery: *you have to fix this too*. First.

Yeah, I'll wait for this too. Sure I will.

Summary of (C) (D) (E): ------------------------

So whether (C) email accounts have been compromised via bot'd systems or (D) just the email accounts themselves have been taken over or (E) entire email servers have been comprommised, outbound messages from all of those will pass any anti-forgery check anybody feels like running. This problem is already well past "enormous" and will continue to get worse, as various ill-conceived bandaids (e.g. "let's get rid of passwords and use passkeys", a breathtakingly stupid and cruel idea) are haphazardly slapped on the problem because nobody wants to spend the massive resources it would take to solve it properly -- one system, one account, one server at a time. Nobody wants to do the hard boring work that might actually succeed in the real world *without* creating more problems than it claims to solve.

Until then, we're living in a world where "one billion compromised email accounts" is very likely a serious underestimate. And there will be more tomorrow -- doubly so because attackers know everything I just said. They recognize that the ill-advised rollout of anti-forgery tech that doesn't actually solve the forgery problem has created a great opportunity for them...and they're all over it.

Conclusions? Well, maybe. ;) -----------------------------

As I've said before, if you want to solve email forgery for a real-world value of "solve" at the scale of the Internet, then you have to solve the underlying security problems first.

ALL OF THEM.

And nobody's interested in doing that, because "doing nothing" and "pretending those problems don't exist" is not only far easier, it's far more profitable. Plus it's much more fun to invent technology and promote it and deploy it and declare "Mission Accomplished" and take credit for solving the problem than it is to do the hard work of actually solving the problem.

So what's really transpired here, as a consequence of this headlong rush to "solve" email forgery, is that all these elaborate mechanisms have been deployed on top of an ecosystem that's broken all the way down.

They're gold leaf on a rotting garbage pile.

They don't work because they can't work. They've make-believe -- and unfortunately *users are being trained to believe in them*, which is going to lead to very bad real-world outcomes.

Note well: none of this commentary has anything to do with the actual mechanics of SPF or DMARC or DKIM or anything else, which is why I haven't discussed their specifics. The specifics *do not matter*. If someone comes up with another one of these tomorrow and writes an RFC and releases code and tells us all about it: that's not going to work either -- for the same reasons.

Yes, in some ideal best-case world, maybe, MAYBE, this elaborate anti-forgery tech might have a fighting chance. (Although: if we were living in that ideal best-case world, we probably wouldn't need it. Do recall that we did just fine for many years without any of this, modulo the occasional prankster or idiot.)

But this is not the ideal best-case world. This is a world with massive problems that nobody wants to solve -- and as long as this writeup is, I've only listed some of them. (Yeah, it's worse. It's always worse.)

---rsk

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/J4QLVGCK...

On 7/3/25 5:33 PM, Alex Buie via NANOG wrote:

"the more you try to outsource critical thinking to a machine that cannot critically think, the more and more you will get duped by scammers"

SPF/DKIM/DMARC are all automated ways to try and outsource truthiness checks to machines. they make people feel comfortable with their result. so much so they stop actually using their brains to protect themselves.

So by all means, let's get rid of TLS as well. ::eyeroll:: Mike

On Thu, Jul 3, 2025 at 7:28 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:

...

Sir, this is a Wendy's.

On Wed, Jul 2, 2025 at 3:47 PM Rich Kulawiec via NANOG < nanog@lists.nanog.org> wrote:

...

On Sun, May 25, 2025 at 11:20:16AM +0200, Tom Ivar Helbekkmo via NANOG wrote:

...

First: SPF/DKIM/DMARC are not about spam, so that part is irrelevant. Perhaps you don't remember this, but when SPF was announced, its home page read:

"Spam as a technical problem is solved by SPF."

Shortly thereafter, spammers became far and away the largest early adopters of SPF.

Of course, that claim was eventually disappeared down the memory hole.

Now onto the long, and I do mean REALLY LONG part of this. Sorry, it's a complex issue and it takes time to explain all the pieces.

Here's a one-sentence summary:

All these alleged anti-email-forgery technologies have accomplished is to make the email forgery problem MUCH worse than before they existed.

Introduction ------------

I've never considered email forgery to be a significant problem -- not when compared to the other problems we face.

But let's put my opinion aside for a moment, and let's presume that email forgery really is a significant problem -- one so serious that it's worth adding an enormous amount of fragile complexity to an ecosystem already under serious stress from spam and other attacks/abuse. Let's assume that it's worth breaking email forwarding (working fine for decades) and mailing lists (working fine for decades, and clearly the best mass collaboration/communication mechanism we have) and adding enormous cost, effort, and complexity to every email system.

There's a problem with that: email forgery can't be solved.

Even if if these byzantine hacks were perfectly designed (they're not) and globally deployed (not happening) and correctly deployed everywhere (nope) and always worked perfectly (also no) and weren't attacked (they are) and so on, even if everything worked *exactly* as intended...the overall impact of all this effort and expense and brittle complexity is to make the email forgery problem MUCH worse.

I've explained this before (briefly) but let me add a lot more detail this time around.

Part A: contributory factors ----------------------------

A1. We've had a problem with fake/junk domains for decades. It was bad enough when there were only 7 gTLDs, but now there are now ~1000 new gTLDs that nobody needed or wanted except (a) registrars, who of course want to make the cash registers ring and (b) abusers/attackers, who buy domains in bulk, burn through them, and then buy more. This symbiotic relationship works beautifully for both parties involved but not for anyone else. And of course registrars are performing no due diligence whatsoever (why should they?) so it's trivial for abusers/attackers to register example.xyz or example.lol or example-com.xyz or example-site.red or whatever, where "example" is a name explicitly designed to suggest that they're some other Internet operation -- e.g., Amazon, Paypal, Google, Joe's Donuts, etc.

I've been studying large samples of domain data for multiple decades, and there are enormous numbers of these fake/junk domains. Many are abandoned once they've served their purpose, but new ones are being registered constantly. And every time a new TLD is put into production, there's a land rush as abusers/attackers swarm it in an attempt to be the first to register the optimal fake domains.

I see no signs that this problem will be solved, because the people responsible for creating it don't want it to be solved. If these registrars performed any kind of due diligence, it would (a) cost them money and (b) reduce their sales. There's no reason in the world for them to do that.

Bottom line: it's cheap, simple, and easy to register an arbitrary number of domains whose names correspond to any operation that abusers/attackers wish to target.

You want a real-world example? Okay. Here's an example:

Infrastructure Laundering: Blending in with the Cloud

https://krebsonsecurity.com/2025/01/infrastructure-laundering-blending-in-wi...

...

U.S. Sanctions Cloud Provider "Funnull" as Top Source of "Pig Butchering" Scams

https://krebsonsecurity.com/2025/05/u-s-sanctions-cloud-provider-funnull-as-...

...

Complete List of Domains Attributed to Funnull

https://www.ic3.gov/CSA/2025/Complete_List_of_Domains_Attributed_to_Funnull....

...

There are 332,696 lines in that list. Well over a quarter million fake/junk domains used by just one scamming operation. And as large as this is, it's the tip of the tip of the tip of the iceberg.

Let me also ask a very pointed question: if someone shows up at your hosting or cloud operation, and they want to deploy, let's say, 52,782 domains: do you think that maybe, just *maybe*, you ought to ask a few questions about what the heck they're up to?

If you're Microsoft or Amazon (see Krebs articles above): nope. Which brings me to:

A2. There are all kinds of hosting/cloud operations out there which will happily take example.xyz's money because they perform the same level of due diligence as registrars in (1): none. These operations know full well that example.xyz is not Example Inc, and they know full well what they're doing, but because example.xyz pays the bills and they're repeat/bulk customers, the hosts/clouds just take the money and look the other way.

This isn't a small problem. It's massive. And it includes a lot of hosting/cloud operations that should know better. And probably *do* know better, but: due diligence costs money and takes effort, it's cheaper and easier to just blow it off and only take action belatedly -- long after the damage is done -- if there's any bad press.

Bottom line: even the most obvious scam/fraud operations have no problem finding hosting.

A3. The combination of (A1) and (A2) mean that you can go out today and register 1000, 10000, 100000 fake domains impersonating the Example, Inc's of the world and you can find hosting for them, and you can do it all at a bulk rate discount. Your only real difficulty will be competing with the other people doing the same thing. And unless you do something that generates a sufficient amount of sufficiently bad press, it's very unlikely that a registrar or host will take any action to shut down anything you're during, and even if they do that, they'll only shut down the small part directly involved -- everything else you have in place will be just fine. And then, on top of all this, they'll slow-walk whatever they do in order to keep the income coming as long as they possibly can.

A4. User interfaces in email clients -- whether standalone pieces of software, or webmail interfaces that run in a web browser -- are increasingly being modified to obfuscate sender addresses. In other words, rather than displaying:

From: Joe Smith <joe@example.com>

they display:

From: Joe Smith

and some kind of user action is required to actually see the address.

The aggregate effect of this, across all UIs across all clients across all users, is to train users to ignore actual email addresses in favor of the text strings that purport to be someone.

(Did YOU check the actual email address in this message to see if it's really from me?)

A5. One consequence of (A4) is that users are increasingly unable and/or unwilling to understand email addresses. They can't distinguish @example.com from @example.xyz or @example-com.lol or @exammple.com or @exammple.somethingsomething.fun.

(Yes, yes, there are *some* users that can do this. A few clueful ones. As in: "A person is smart. People are..." C'mon, you know the rest of this.)

This loss of comprehension/function resulting from (A4) and (A5) works beautifully for the operators of domains in (A1) and (A2): they don't even have to try hard. Even sloppy half-ass typosquatted domains (and subdomains) work just fine.

[ Let me interject that while I was drafting this I read about the plans by Mozilla to completely screw up the address bar in Firefox -- because of course leaving the simplest, most fundamental, and most important thing in the browser alone was never a choice for these incompetent clowns. If I understand what they're going to do correctly, and I really hope I don't, they're going to make life MUCH easier for forgers/scammers/et.al. who are deploying fake domains. ]

A6. User interfaces in email clients are being modified to provide signaling to users that a given message has been "authenticated" or "verified" or "signed" or "certified" or some similar designation. This is of course the result of a successful check of whichever anti-forgery mechanism(s) the receiving email server chose to utilize.

And just as users being trained to accept (A4), they're being trained to accept this. They believe what's in front of them on the screen.

But of course this means *nothing*: a message from joe@example.xyz will be dutifully marked (provided the keepers of example.xyz set things up correctly and everything's working) as authentic even though example.xyz is a fake domain that has nothing to do with the real Example Inc. and Joe is a fake person.

In other words, obviously fake messages from obviously fake domains are treated the same as authentic messages from authentic domains.

("But couldn't...". No. It's not a tractable problem, because it would require enumerating the authentic domain(s) of every operation on the Internet, i.e. determining that example.com is the "real Example Inc. -- for millions of example.com's, example.edu's, example.net's, etc. And not only would this be incredibly expensive, it would break badly as companies and domains change ownership or go out of business, it would greatly favor large operations over small ones, it would quickly be corrupted by the people with the biggest wallets, it would... So don't even go there.) This is analogous to the wry saying about https:// -- yeah, it means you have a (putatively) secure connection, but you could have a secure connection to the worst people in the world.

A7. Many Example Inc's of the world don't send plaintext email messages; they mark them up with HTML and graphics and so on, which means that they're teaching their users that any message which looks like it's from them is really from them.

They're training their users to fall for forgeries/phishes.

And years (decades now) of this training have paid off: it's much, MUCH easier to trick users now than it was 20 years ago.

A8. Similarly, many Example Inc's of the world include URLs in their messages. They've spent years (decades now) training users to utilize those URLs, and of course users have dutifully learned to do this, and once again:

They're training their users to fall for forgeries/phishes.

And years (decades now) of *this* training have also paid off: again, it's much easier to trick users now than it was 20 years ago.

A9. The combination of (A7) and (A8) means that there's no help coming from the Example Inc's of the world. They'll continue to train their users to be victims while exhorting them to not be victims. The relevance to my point here? These email worst practices distract users from the small pieces of critical information that *might* give them a slim chance of spotting a forgery. They don't cause the problem, but they certainly exacerbate it.

A10. The aggregate impact of (A1)-(A9) is: users see a message that looks as they expect it to -- it has the pretty graphics and typography of Example Inc. It claims to be from Example Inc. It's marked as "verified" in their email UI. It has a domain that looks kinda like Example Inc's (if they even bother to check, which almost none of them will).

What do you *think* they're going to do? I can tell you what they won't do: they won't take the time to actually study the email address and see that it's @example-com-completely-fake.xyz, or to study the embedded URLs, and even if they do, a substantial fraction of them Will Not Get It.

If you think I'm wrong about this, then I must ask: have you actually spent any time with a significant number of users?

Part B: large email operations ------------------------------

It's not always necessary to go through the trouble and expense of registering domains, arranging for hosting, etc.

It's easy to set up an arbitrary number of accounts that claim to be arbitrary people/companies and spam/phish/whatever from them at will, because there are some very large mail operations that make this easy.

And because those same operations have implemented all this anti-forgery tech, those messages will dutifully pass every check that can be done on them.

And before someone trots out the "...but they're so large and it's SOOOO hard..." nonsense as an excuse for the malfeasance of these very large email operations: no. If you can't run an enormous operation properly, you shouldn't *build* an enormous operation. It's irresponsible. It's unprofessional. It's unethical.

Especially when it would be trivial for these operations to throw 1,000 people and a billion dollars at the problem tomorrow. (We *know* they have those resources, because they're already wasting them on bogus "AI" development.)

Let me note, in fairness, that there are also some other rather large operations that -- as far as I can tell by measuring across hundreds of domains over several decades -- do a very good job. The problem is that they're the exception.

Recap of part A and part B: ---------------------------

The combination of (A) and (B) means that we have an environment where it's cheap, easy, and simple to register an arbitrary number of domains masquerading as Example Inc. It's also cheap, easy, and simple to find hosting for them. And then -- thanks to very poor choices in user interfaces combined with lack of user knowledge/effort, it's cheap, easy, and simple to convince lots of people that completely fake messages from completely fake domains are authentic. And there's even a pretty good chance that forgeries which don't even use a fake domain will work: there are certainly unlimited opportunities to try -- also cheap, easy, and simple.

The sad reality is that while it's true that thanks to this anti-forgery tech, abusers will have a hard time successfully forging messages from the real example.com and getting them delivered: they don't have to.

Part C: bots ------------

And then it gets even worse, because of a problem that still exists but doesn't garner the headlines that it did years ago.

The problem is bots. Remember this?

Vint Cerf: one quarter of all computers part of a botnet http://arstechnica.com/news.ars/post/20070125-8707.html

That was 18 years ago. And in the ensuing time, *nothing* has happened to seriously address that problem. (Yes, yes, I'm aware of all the headline-grabbing when someone somewhere dismantles a botnet, but those are momentary disruptions at best.)

On the other hand, lots of things have happened to make the bot problem worse, including (1) more computers (2) more users (3) vastly more sophisticated bot-creating malware (4) bot-creating malware targeting non-Windows systems (5) major improvements in botnet C&C (6) the IOT -- remember, the "S" in "IOT" stands for security. And (7) thanks to Microsoft's "Recall", things will get worse yet again.

Oh, and let's (8) toss in AI, because the people frantically developing those systems want to spend lots of time and money hyping them but can't be bothered to put in any guardrails or do any real testing or even concern themselves for a moment about how this tech will be misused by some of the worst people on the planet. I'll bet even money that there's already a botnet being run by a commercial AI. It's an obvious move, don't you think?

Note that:

C1. Anyone in control of a bot can utilize any email credentials stored on or transiting that bot at will. If Joe has an address @example.org and one at @aol.com, then the new owner of Joe's system can send outbound messages via those at will.

C2. They can also rummage through all email stored on that system or in the accounts from (1), which means that -- if they want -- they can easily make some first-order guesses at who's likely to believe that a message which claims to be from Joe AND that their email system's UI says is from Joe, really is from Joe.

C3. This is already bad if Joe is just some guy and Joe's system is just some random laptop somewhere. But what if it's not? What if Joe works at Example Inc. and this is his desktop system and it's loaded with customer correspondence and it's connected to his work email account, also loaded with customer correspondence? *Now* the new owner of Joe's system is in an ideal situation to phish or scam all of those people, because such a message really will come from Joe's email address via Joe's work email server, it'll pass all the anti-forgery checks anyone cares to run, and it'll dutifully be marked as "authentic" in most/all those email UIs used by its recipients.

So even if the content is a little sketchy -- maybe enough to raise an eyebrow or two among recipients -- they'll look at their screen, see that the message is marked as real, see that the fancy graphics and typography look real, AND THEY'LL BELIEVE IT. Of course they will, they've been trained to, see A7 and A8 and above

C4. And what about the tiny fraction of people who will catch on that think that's something amiss? What, EXACTLY, do you propose that they do about it? Example Inc has probably done its very best to turn itself into an impenetrable corporation where it's nearly impossible to reach anyone in a position to understand a problem like this and take prompt action to fix it. Do they have working postmaster@, security@, abuse@ addresses -- something that every novice sysadmin on this planet should know about? Probably not. Do they have a published security contact? Probably not. Do they have any mechanism whereby someone who calls in can reach anyone useful? Probably not. So even if one of those rare, clueful, diligent people spots this and tries to report it, they're probably going to give up in frustration long before they achieve anything.

C5. And even if -- by some miracle of science -- someone in (C4) manages to reach a contact inside Example Inc who understands the problem...the most likely outcome is that Example Inc will ignore it and pretend it doesn't exist. The next most likely outcome is that they'll quietly fix it but say nothing. Why should they inform or warn anyone? That's bad for business. And since there are no significant penalties for anyone involved, their best bet is to disappear the problem and claim it never happened. (If caught? Deny everything. If REALLY caught? Blame a miscommunication and throw a third-level manager under the bus.)

Sadly, (C4) and (C5) are not hypothetical. They're why I don't even bother any more. Why should I invest my time and unpaid labor when these operations can't even be bothered to do the simplest, easiest, most obvious things like supporting RFC 2142 addresses and reading what shows up there, acting on it promptly, and publicly acknowledging what's happened?

How many email accounts are affected by bot proliferation? A first-order estimate may be found by multiplying (a) an estimate of the worldwide population of bots by (b) an estimate of the average number of email accounts used/present on those bots. I think the floor for (a) is 750M and 1.5B is much more likely. (Go back to Cerf's estimate from 18 years ago and extrapolate.) As to (b) I think it's probably between 1 and 2 -- let's go with 1.5, probably low but that may also account for duplicate email accounts across bots.

This gives us a quite conservative back-of-the-envelope guesstimate somewhere north of 1B.

One billion compromised email accounts.

And you want to tell me it's possible to do something truly meaningful about email forgery? Okay. Fine. *Fix this problem first*, then we'll talk.

I'll wait. Let me know when you're done.

Note that not only do you have to (1) remediate all those accounts, you'll also need to (2) remediate all the bot'd systems and then (3) keep them that way -- which means discovering the root cause(s) of their compromise and fixing it. (3) will be very difficult if the root cause is something like "the user clicks on every shiny thing they see". But if you're going to claim it's possible to do something truly meaningful about email forgery, then you must do all those steps first.

Part D: email account compromises ---------------------------------

And (C) isn't even all the compromised email accounts, because we also have to think about all the cases where only an email account (not an entire system) has been compromised. I don't know how many there are (nobody does), but I strongly suspect it's also an enormous (hundreds of millions or more) number. One way to approach an estimate of this is to observe the marketplaces where they're being sold, and in those places, there are lots people selling them in bulk: how many hundred thousand would you like?

(Do recall that a few years ago, EVERY Yahoo email account was compromised. That was a neat 3 billion accounts right there.

Every single Yahoo account was hacked - 3 billion in all

https://money.cnn.com/2017/10/03/technology/business/yahoo-breach-3-billion-...

...

And as anyone who's paying attention to the daily parade of security breaches and dataloss incidents is painfully aware: this isn't an isolated case. It's the norm.)

This problem is exacerbated by the complete lack of support at some very large email operations: even when someone who's the real owner of one of these compromised email accounts detects it and make a good-faith effort to fix the problem...yeah, good luck with that. Their chances of recovering their own email account are pretty much zero thanks to awful procedures and non-existent customer service. Thus there's a high probabilty that any compromised email account is going to stay compromised until it no longer exists.

Again, if you want to tell me that something serious is going to happen WRT email forgery: *you have to fix this too*. Let me know when that's done as well.

Part E: email server compromises --------------------------------

And *then*, on top of (C) and (D), we have to consider the cases where email servers themselves have been compromised, and there's a steady parade of those. Hardly a day goes without another announcement of a massive security breach that involves most/all of some operation's infrastructure,

Those announcements are only the tip of the iceberg, since pretty much everyone does their best to conceal such things until either the press reports on them and/or they're legally required to report them... and even *then* they'll sometimes persist in denial and minimization.

I'm looking right at you, Oracle.

Anyway, compromise of an email server means that it's not only possible to undetectably forge email from every account on it, it's also possible to create new ones and do the same with those. And of course the new owners of these servers have access to everything stored on or transiting them, which provides all kinds of resources that are useful in figuring out who to target, how best to target them, etc.

And yet once again, if you want to tell me that something serious is going to happen WRT email forgery: *you have to fix this too*. First.

Yeah, I'll wait for this too. Sure I will.

Summary of (C) (D) (E): ------------------------

So whether (C) email accounts have been compromised via bot'd systems or (D) just the email accounts themselves have been taken over or (E) entire email servers have been comprommised, outbound messages from all of those will pass any anti-forgery check anybody feels like running. This problem is already well past "enormous" and will continue to get worse, as various ill-conceived bandaids (e.g. "let's get rid of passwords and use passkeys", a breathtakingly stupid and cruel idea) are haphazardly slapped on the problem because nobody wants to spend the massive resources it would take to solve it properly -- one system, one account, one server at a time. Nobody wants to do the hard boring work that might actually succeed in the real world *without* creating more problems than it claims to solve.

Until then, we're living in a world where "one billion compromised email accounts" is very likely a serious underestimate. And there will be more tomorrow -- doubly so because attackers know everything I just said. They recognize that the ill-advised rollout of anti-forgery tech that doesn't actually solve the forgery problem has created a great opportunity for them...and they're all over it.

Conclusions? Well, maybe. ;) -----------------------------

As I've said before, if you want to solve email forgery for a real-world value of "solve" at the scale of the Internet, then you have to solve the underlying security problems first.

ALL OF THEM.

And nobody's interested in doing that, because "doing nothing" and "pretending those problems don't exist" is not only far easier, it's far more profitable. Plus it's much more fun to invent technology and promote it and deploy it and declare "Mission Accomplished" and take credit for solving the problem than it is to do the hard work of actually solving the problem.

So what's really transpired here, as a consequence of this headlong rush to "solve" email forgery, is that all these elaborate mechanisms have been deployed on top of an ecosystem that's broken all the way down.

They're gold leaf on a rotting garbage pile.

They don't work because they can't work. They've make-believe -- and unfortunately *users are being trained to believe in them*, which is going to lead to very bad real-world outcomes.

Note well: none of this commentary has anything to do with the actual mechanics of SPF or DMARC or DKIM or anything else, which is why I haven't discussed their specifics. The specifics *do not matter*. If someone comes up with another one of these tomorrow and writes an RFC and releases code and tells us all about it: that's not going to work either -- for the same reasons.

Yes, in some ideal best-case world, maybe, MAYBE, this elaborate anti-forgery tech might have a fighting chance. (Although: if we were living in that ideal best-case world, we probably wouldn't need it. Do recall that we did just fine for many years without any of this, modulo the occasional prankster or idiot.)

But this is not the ideal best-case world. This is a world with massive problems that nobody wants to solve -- and as long as this writeup is, I've only listed some of them. (Yeah, it's worse. It's always worse.)

---rsk

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/J4QLVGCK... _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E4QDYX4Z...

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BHV2FPLR...

On 7/3/25 6:02 PM, Alex Buie via NANOG wrote:

On Thu, Jul 3, 2025 at 7:43 PM Michael Thomas via NANOG < nanog@lists.nanog.org> wrote:

...

On 7/3/25 5:33 PM, Alex Buie via NANOG wrote:

...

"the more you try to outsource critical thinking to a machine that cannot critically think, the more and more you will get duped by scammers"

SPF/DKIM/DMARC are all automated ways to try and outsource truthiness checks to machines. they make people feel comfortable with their result. so much so they stop actually using their brains to protect themselves. So by all means, let's get rid of TLS as well. ::eyeroll::

Mike

I'm not saying to get rid of any of these things. I'm just saying expecting them to replace user training in critical thinking is foolish, and overall, the point Rich made makes sense. If you tell people "as long as you check these things you can trust it" they are way more likely to believe something unbelievable if it has all those "you can trust me" flags.

Good thing nobody thought that it's a substitute. Making incremental improvements don't have to be viewed as, uh, cure-alls. That would be, uh, foolish. Mike

On 7/3/25 6:16 PM, Alex Buie wrote:

On Thu, Jul 3, 2025 at 8:12 PM Michael Thomas via NANOG <nanog@lists.nanog.org> wrote:

. >> So by all means, let's get rid of TLS as well. ::eyeroll:: >> >> Mike >> >> > I'm not saying to get rid of any of these things. I'm just saying expecting > them to replace user training in critical thinking is foolish, and overall, > the point Rich made makes sense. If you tell people "as long as you check > these things you can trust it" they are way more likely to believe > something unbelievable if it has all those "you can trust me" flags.

Good thing nobody thought that it's a substitute. Making incremental improvements don't have to be viewed as, uh, cure-alls. That would be, uh, foolish.

Mike

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4FPNUYKZ...

I agree with you they are not a substitute and that is foolish. There are many who come to say they have the one and final true solution to spam and email auth though. My argument is anything purporting to do so is attempting to critically think for the user.

While the incremental improvement to auth is good, one could argue the user experience implementing is not, as I think Rich is saying, and I agree. We are training people to only check for and believe the machine signal which can sometimes be “truthfully false” as in the case of email credential compromise and trademark impersonation.

The idea is to train people that something might be wrong. Not that something is right. He's wrong if he thinks that is what the intent was. That would be bad read of history. Mike

On 7/5/25 11:08 AM, Amir Herzberg wrote:

Friends, I think we all agree we have a big problem here; and while Rich focused on email, I'm sure he and all of us know it's actually universal - SMS, social-networks, everywhere. Yes, part of the problem is due to the ease of registering misleading domain, along with other parts...

But I beg to differ on one point. It seems that Rich, Alex and others think that the better solution is to educate users to understand domain names and be careful. Well, sorry, I don't believe in that. Some of my research was (and is) about usable security; it's really a critical component that does not receive as much attention as it should. But, basically, I think I can confidently say that attempting to teach users so that they notice the phishing domains is futile. But I do agree that the UI _is_ an important part of the problem. I simply think is should also be a big part of the solution.

Indeed. Part of the problem with email is that there isn't anything universal like the lock icon on browsers. Yes, we all know that the lock icon isn't a cure all, but it does serve the purpose of letting users know that their web pages, etc, are not being shipped in clear text with no domain authentication. Email doesn't even have that. Thunderbird, which is what I use, has precisely *nothing* to say about DKIM/SPF/DMARC. It doesn't even exist to it.  Some MUA's do things in their UI's, but from what I can tell it's nothing approaching some standard(s). IETF doesn't do UI stuff, and apparently the industry groups don't care or are politically wrapped around the axle, or whatever the cause of the dysfunction, but the net-net is that going from MUA to MUA to MUA, you get different experiences with the email authentication results. There is a Usenix paper <https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf> that dove into this, and it showed that UI improvements modestly help. If the indicatiors were more uniform and widely implemented, it would probably be even better. If there were an industry-wide effort to standardize this and especially uniform messaging about its meaning, it would probably approach the utility of the lock icon -- maybe even better than the lock icon since its messaging was sort of muddled with words like "safe" and "secure" thrown around without enough context, especially since it came around when nobody actually knew what any of it meant except a few security geeks.

We have developed a prototype of a UI-based defense against phishing, for both websites and emails, that actually can benefit from the deployment of DKIM/SPF/DMARC. The idea is simple; let me explain for email. We train the user to click on a button when they open an email which is - or they think it is - from a trusted sender. So, when they do, we can check (and here DKIM/SPF etc. are helpful !) if this is correct - and block the phishing attack if it isn't.

Do you have any visibility into, say, MAAWG and why they don't take this up as a standards effort? When we were developing DKIM, even though a UI component was out of scope for IETF it didn't mean there was anything like consensus that it was also a bad idea. It's just not what IETF does. 20 years on, it's pretty depressing that it has either fallen through the cracks and nobody took it up, or it flamed out due to dysfunction, leaving it to be a mish-mash in MUA's, where nothing at all like Thunderbird is in the range of things that end users have to contend with. Mike

It appears that Michael Thomas via NANOG <nanog@lists.nanog.org> said:

Email doesn't even have that. Thunderbird, which is what I use, has precisely *nothing* to say about DKIM/SPF/DMARC.

Well, yeah. As you surely know as well as anyone, if a message is authenticated that tells you nothing about whether it's mail you want or mail that's malicious. For that you need a reputation system that knows something about the domain that's authenticated. That seems a lot easier to do at delivery time and put the bad ones in the Junk folder, or don't deliver them at all.

Do you have any visibility into, say, MAAWG and why they don't take this up as a standards effort?

Honestly, they'd just laugh. It's not a new idea, and there is a great deal of experience that says asking users to make security decisions in the UI mostly adds confusion. On the other hand, if you use Thunderbird, I don't think it'd be very hard to write a plugin that looks at the Authentication-Results: header and adds locks or skulls and crossbones to the message display. Try it, tell us how you like it. You can start with this one: https://addons.thunderbird.net/en-US/thunderbird/addon/dkim-verifier/ R's, John

It appears that Michael Thomas via NANOG <nanog@lists.nanog.org> said:

The research paper I pointed to disagrees. It's not a panacea, but it's helpful.

I took a look at the paper and was underwhelmed. They were shocked to find that most of the Alexa top 1000 don't have DKIM or DMARC records, and well, duh, that's intended to be a list of the top 1000 web domains most of which don't do mail at all. For the ones that did do DKIM and DMARC, the mail systems did a reasonable job of keeping the forged mail out.

...

You can start with this one:

https://addons.thunderbird.net/en-US/thunderbird/addon/dkim-verifier/

Authentication-Results is not intended by itself to be a UI element, so that's not what I'm talking about. Any effort would require collaboration with security human factors experts for starters.

A-R tells you whether the DKIM, SPF, and DMARC validations passed. What else would you expect to show? And why do it in the UI rather than at delivery time? R's, John

On Sat, Jul 5, 2025 at 10:06 PM John Levine via NANOG <nanog@lists.nanog.org> wrote:

I took a look at the paper and was underwhelmed. They were shocked to find that most of the Alexa top 1000 don't have DKIM or DMARC records, and well, duh, ...

I think Mike mostly referred us to the experiment in section 6 (Mike, correct me if I'm wrong), rather than the claim John mentioned (which I think is citation of previous work and not result of this one). That said, the experiment was of the effectiveness of a warning for a failure of the (SPF/DKIM/...) validation, i.e., would users ignore it and access the email anyway. As Rich explained nicely, this is rarely the method used by attackers; they usually use their own domains, so they pass this validation. The vast majority of users fail to notice the email was sent from the wrong domain (see lots of discussion in earlier messages, mainly by Rich). So, I'm not sure it's a great example showing that UI can be used for effective defense. Ah, and John also asked

... A-R tells you whether the DKIM, SPF, and DMARC validations passed. What else would you expect to show? And why do it in the UI rather than at delivery time?

Obviously the reason is that the providers don't want to risk blocking the email due to false positive. They prefer to shift the responsibility to the user... (I wonder if John asked seriously or if it was sarcasm, as I know John is very well aware of the fact providers hate the risk of false positives...) Best, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography and Cybersecurity' textbook: https://sites.google.com/site/amirherzberg/crypto-cyber-book

R's, John _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CTWHM5RK...

On 7/5/25 3:44 PM, Barry Shein via NANOG wrote:

At the 2003 MIT Spam Conference there were two keynotes, myself and someone else who is highly esteemed in the e-mail world.

They spoke about these various emerging (in 2003) authentication methods and I asked a question like any participant which echoed what's being said below: Aren't the bad guys just going to learn how to make their email authenticated? So all I know, with great certainty, is this email is from Phishing R Us, Inc?

The answer was, well of course, but this will all work because we will also develop reputation systems.

That was 2003, nearly a quarter century ago.

Unfortunately too many of the problems on the internet were solved on paper (i.e., RFCs and their ilk) 20, 30, 40...years ago.

But nothing came of them because writing down a clever engineering hack is a lot easier than herding a billion cats but the organizational structures lean heavily in favor of the "let's write up another clever engineering hack!" crowd.

If you're talking about reputation systems, maybe you should talk to the folks clamoring to solve the DKIM so-called "replay" problem who claim that spam "replays" causes problems with their reputation from big mailbox providers. Part of the problem with all of this is that everything that happens on the receiver side is opaque to the world at large and providers aren't saying what's going on under the hood with any specificity for... reasons. I can understand their reasons, but unless you've worked at one and by some miracle can talk about it, nobody on the outside knows what they are really doing. Mike

On 7/5/25 4:00 PM, Tim Howe via NANOG wrote:

One of the biggest problems I face is that spamming is largely accepted as perfectly normal for some groups.

Convince marketing people that they shouldn't be able to just email everyone they can identify about anything they want and it just doesn't compute.

I get more spam directly from Salesforce's network than anywhere else because it's a service their customers expect them to supply.

Have fun fighting that.

Is that still really a thing? I mean of course I know that opt-out marketing mail is common as dirt, but it seems pretty common to have a simple unsubscribe button at the end of the email. I mean, it's annoying, but they see to work from what I can tell. Mike

On 7/5/25 4:39 PM, Tim Howe via NANOG wrote:

On Sat, 5 Jul 2025 16:08:40 -0700 Michael Thomas via NANOG <nanog@lists.nanog.org> wrote:

...

On 7/5/25 4:00 PM, Tim Howe via NANOG wrote:

...

One of the biggest problems I face is that spamming is largely accepted as perfectly normal for some groups.

Convince marketing people that they shouldn't be able to just email everyone they can identify about anything they want and it just doesn't compute.

I get more spam directly from Salesforce's network than anywhere else because it's a service their customers expect them to supply.

Have fun fighting that.

Is that still really a thing? I mean of course I know that opt-out marketing mail is common as dirt, but it seems pretty common to have a simple unsubscribe button at the end of the email. I mean, it's annoying, but they see to work from what I can tell. Yeah, maybe. How many new iterations of the same email, same list, same company with a slightly different domain or slightly different name do you feel you should be unsubscribing from on a daily basis?

5? 6? 10? Daily?!??!

"Just unsubscribe!" Sure.

Heh, I haven't had too many of those, and the ones I do get a one way trip to my junk filter. Mike

So you want people to click a random url in an unsolicited email message? List-unsubscribe: RFC8085 provides a mechanism to mitigate that issue as there is no expected interaction. MUAs know how to display an unsubscribe button these days. -- Mark Andrews

On 6 Jul 2025, at 09:09, Michael Thomas via NANOG <nanog@lists.nanog.org> wrote:



...

On 7/5/25 4:00 PM, Tim Howe via NANOG wrote: One of the biggest problems I face is that spamming is largely accepted as perfectly normal for some groups.

Convince marketing people that they shouldn't be able to just email everyone they can identify about anything they want and it just doesn't compute.

I get more spam directly from Salesforce's network than anywhere else because it's a service their customers expect them to supply.

Have fun fighting that.

Is that still really a thing? I mean of course I know that opt-out marketing mail is common as dirt, but it seems pretty common to have a simple unsubscribe button at the end of the email. I mean, it's annoying, but they see to work from what I can tell.

Mike

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Q3R2SWY3...

-- Mark Andrews

On 6 Jul 2025, at 09:01, Tim Howe via NANOG <nanog@lists.nanog.org> wrote:

One of the biggest problems I face is that spamming is largely accepted as perfectly normal for some groups.

Convince marketing people that they shouldn't be able to just email everyone they can identify about anything they want and it just doesn't compute.

I get more spam directly from Salesforce's network than anywhere else because it's a service their customers expect them to supply.

Have fun fighting that.

--TimH

...

On Sat, 5 Jul 2025 18:44:05 -0400 Barry Shein via NANOG <nanog@lists.nanog.org> wrote:

At the 2003 MIT Spam Conference there were two keynotes, myself and someone else who is highly esteemed in the e-mail world.

They spoke about these various emerging (in 2003) authentication methods and I asked a question like any participant which echoed what's being said below: Aren't the bad guys just going to learn how to make their email authenticated? So all I know, with great certainty, is this email is from Phishing R Us, Inc?

The answer was, well of course, but this will all work because we will also develop reputation systems.

That was 2003, nearly a quarter century ago.

Unfortunately too many of the problems on the internet were solved on paper (i.e., RFCs and their ilk) 20, 30, 40...years ago.

But nothing came of them because writing down a clever engineering hack is a lot easier than herding a billion cats but the organizational structures lean heavily in favor of the "let's write up another clever engineering hack!" crowd.

Put another way: Why is there no economics behind solving any of this?

In other areas like, e.g., creditworthiness vast infrastructures have been built and maintained and seem to work well enough to keep the lenders afloat (actually, to keep them among the wealthiest in all of world history.)

But this stuff remains mostly a volunteer effort except where someone can maybe spin up a consultancy or customized service but it's always tiny in the scheme of things.

Follow the money? Apparently there is no money to follow!

...

On July 5, 2025 at 16:11 nanog@lists.nanog.org (John Levine via NANOG) wrote: It appears that Michael Thomas via NANOG <nanog@lists.nanog.org> said:

...

Email doesn't even have that. Thunderbird, which is what I use, has precisely *nothing* to say about DKIM/SPF/DMARC.

Well, yeah. As you surely know as well as anyone, if a message is authenticated that tells you nothing about whether it's mail you want or mail that's malicious. For that you need a reputation system that knows something about the domain that's authenticated. That seems a lot easier to do at delivery time and put the bad ones in the Junk folder, or don't deliver them at all.

...

Do you have any visibility into, say, MAAWG and why they don't take this up as a standards effort?

Honestly, they'd just laugh. It's not a new idea, and there is a great deal of experience that says asking users to make security decisions in the UI mostly adds confusion.

On the other hand, if you use Thunderbird, I don't think it'd be very hard to write a plugin that looks at the Authentication-Results: header and adds locks or skulls and crossbones to the message display. Try it, tell us how you like it.

You can start with this one:

https://addons.thunderbird.net/en-US/thunderbird/addon/dkim-verifier/

R's, John _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZKODZNYV...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JZFJX3FA...

On July 5, 2025 at 20:59 johnl@iecc.com (John R. Levine) wrote:

https://taugh.com/epostage.pdf

It's a fine paper but it has one problem which is it sets up a strawman: It proposes a particular architecture for e-postage (ok, granted, more than one, but similar) and proceeds to knock it down. 1. Professional spammers send O(1B) msgs per day per each. I assume they need to send roughly that many to be economically viable. So if one could limit them significantly one hopes their endeavors become economically unviable and they disappear from the face of the earth. The big point is that we're in a statistical space, not an engineering space where a solution has to be mathematically perfect or nearly perfect to be acceptable. Like marketing in general, which is basically what most spam is (I'd call phishing a perverse form of marketing), it relies on statistical modeling. Sending a billion spam messages might yield .01% success rate which is roughly true of any mass marketing. Unfortunately we've made it essentially free. Internet behemoths (Google, Facebook, et al) make literally trillions per year selling marketing, but we give it away free. That's a problem. 2. Unfortunately the thundering "spam" hoofsteps we hear also include an increasing amount of "ham". Why not? It's free! Some of it one can block, some one can partially opt out of, but some you can't, practically. Block your utility company from sending you several promos per day and you also won't see your bills or actually important notices about outages etc, for example. What's their motivation to help you manage that? Not much. I know I seem to get sometimes dozens of such ham msgs per day, complete a survey! call before you dig! we're having a sale! new product! etc etc etc. That tide is rising as their marcom people are figuring out the fantastic leverage they have. 3. We only need to increase the costs to the sort of people who send O(1B) messages per day to introduce some sanity into the system. So, to explain my strawman comment, it's like a pruning problem in a chess program: You don't have to compute every single move, that would be computationally prohibitive as you detail. Only compute the moves likely to be productive. For example give everyone the ability to send, for argument's sake, 100,000 msgs/day free. Maybe 1M/day. Spammers can't live with that sort of limit. Neither of course can many "legitimate" bulk senders so there has to be some way to buy more. I know, but how? Without trying to architect the whole thing in this mail message that does open some more realistic possibilities by pruning the problem space significantly. And even if there's leakage, so what? That might offend some people's sense of fair play but if the net result is it puts the big spammers out of business we won, no? A big utility company or bank, for example, might be able to budget $100K/month for their overages, but I doubt the typical spammer can even come close to that. Many are probably what we used to call chicken-boners* on Usenet which meant losers sitting up to their knees in KFC chicken bones in a double-wide somewhere happy if they can get a coupla hundred bucks for a spam campaign. And the income generated could go towards enforcement. I realize there's this net culture that wants to see an algorithmic, preferably involving cryptography, solution to every problem but with money other means of enforcement become possible. And where jurisdictions won't cooperate, oh well, no more chicken bones for them! etc. It's a big conversation and this is way too long already but I think it calls for a sea change in thinking. That is, think in terms of the actual problem and what would put the actual miscreants out of commission rather than some utopian ideal. * https://www.netlingo.com/word/chicken-boner.php -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On July 6, 2025 at 10:18 nanog@lists.nanog.org (John R. Levine via NANOG) wrote:

On Sat, 5 Jul 2025, bzs@theworld.com wrote:

...

It's a fine paper but it has one problem which is it sets up a strawman: It proposes a particular architecture for e-postage (ok, granted, more than one, but similar) and proceeds to knock it down.

1. Professional spammers send O(1B) msgs per day per each.

In the aggregate, sure, but there are plenty of spammers who send a lot less than that.

No doubt it's a "long tail" but this source estimates about 160B email spam msgs per day (2023): https://www.emailtooltester.com/en/blog/spam-statistics/ The reason we all get the same spam messages to the point that one can satirize one and get laughs from a crowd seems to indicate something closer to the O(1B)/each, that is, not that many sources. "Long tail" reasoning would say that of that 160B/day probably less than 100 spam operations account for 100B or more which gets one pretty close to O(1B)/day. Admittedly totally back of the envelope but I doubt they're spread evenly among sources.

The B2B spam I get from throwaway accounts at large mail providers is probably only 1000 or less at a time since that's all you can send that way. I do not think there is one master criminal with a million throwaway Gmail accounts.

You've moved from spam to ham, no?

...

3. We only need to increase the costs to the sort of people who send O(1B) messages per day to introduce some sanity into the system.

Beyond the fact that the underlying assumption is wrong, that's extremely unlikely to work unless you envision a world where you have to show ID and get a license to send mail. It is certainly true that a large flow of mail from an unfamilar place is suspicious, so spammers have lots of ways of making their stuff look like lots of little flows. It even has a name, snowshoe spamming.

I think you just set up another strawman and knocked it down. Do you have to show ID to drop a stamped envelope in a postal box? No, only to operate a postage meter and even in that case they aren't a high security operation. You just can get in a lot of trouble for defrauding them, even for using one w/o paying your bill. So most businesses operate their postal meters honestly because the downside of not doing so isn't worthwhile. But anyone can buy a book of stamps, even a few thousand, and use them w/o any ID.

At this point I get a whole lot of mail from Salesforce and Sendgrid. I would love to block them but unfortunately they also send a lot of mail my users want, so I have to do hacks that try to recognize the customer and let through the less bad ones. It is painfully clear that they have made business decisions not to spend enough money on abuse management to clean this up. The mail gets through, why should they?

Again this is what is generally called "ham" unless you want to apply it to anything you're not personally interested in. I tend towards that definition since they're not paying for it. But not the main event here and I believe I already made that point: That the tide of "ham" is rising because why not, it's just about free in a world where any other form of advertising or marcom costs big bucks. One of the approaches post-9/11 to undoing the worst terrorist networks was to disrupt their economics. Some if it was almost comical, they were taking in millions per month on grocery coupon fraud by bullying grocery store owners to submit fraudulent coupon reimbursements. Did it wipe out terrorism? No, not really, but it probably hurt and was more creative than adding new cryptography requirements to coupons. So all I'm saying is we have to start thinking more about disrupting spammers' economics and less about designing sharper razor wire fences. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

Who is having this spam problem are the people and companies expending resources keeping that spam out of your inbox. What's the current estimate? Around 90% of all email volume is spam. You can say "well I don't see it so I don't care" but that's a little like who needs the police I've never been mugged. This is an operations and infrastructure list. On July 6, 2025 at 15:08 nanog@lists.nanog.org (Michael Thomas via NANOG) wrote:

On 7/6/25 2:05 PM, Barry Shein via NANOG wrote:

...

So all I'm saying is we have to start thinking more about disrupting spammers' economics and less about designing sharper razor wire fences.

Really? Why? I rarely get spam (UCE) these days through my Google linked accounts, and haven't for years. I assume most of the major mailbox providers need to keep up with Google, so their customers probably aren't getting a lot of spam either. For the mailbox providers, it's just a cost of doing business, and reducing Google's cost of doing business isn't very high up on my list of concerns.

I suspect that the same is true of enterprise mailboxes as well since if the anti-spam vendors couldn't keep up, it would give more incentive to outsource their mail to somebody who could. And again, reducing their cost of doing business isn't very high up on my list of concerns.

So who exactly is having this spam problem these days? I suppose if you're running sendmail and spamassassin it might be bad (I personally gave up on that) but that's in the long tail of people being ornery rugged email individualists. Again, not something very high up on my list of concerns.

Is there some other large set of mailboxes that I'm missing here? Ideally mailboxes that I would care about their economics?

That is distinctly different than phishing and its social engineering aspect. Doubly so with spear-phishing which by its nature, the content is likely to look like legitimate email. Phishing can be catastrophic and will always be a concern. This is where the meta information of authn, etc, become more important in the fight to combat it, but that's different than UCE.

Mike

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EAHHNWMC...

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On 7/2/25 12:46 PM, Rich Kulawiec via NANOG wrote:

On Sun, May 25, 2025 at 11:20:16AM +0200, Tom Ivar Helbekkmo via NANOG wrote:

...

First: SPF/DKIM/DMARC are not about spam, so that part is irrelevant. Perhaps you don't remember this, but when SPF was announced, its home page read:

"Spam as a technical problem is solved by SPF."

Sorry, I don't know about the SPF folks, but nobody that I know of thought that for DKIM, so this just looks like cherry-picking to make a point. That is to say, a strawman.

I've never considered email forgery to be a significant problem -- not when compared to the other problems we face. Huh. Reports of spear-phishing and how easy it was to do scared the hell out of us at Cisco.

But let's put my opinion aside for a moment, and let's presume that email forgery really is a significant problem -- one so serious that it's worth adding an enormous amount of fragile complexity to an ecosystem already under serious stress from spam and other attacks/abuse. Let's assume that it's worth breaking email forwarding (working fine for decades) and mailing lists (working fine for decades, and clearly the best mass collaboration/communication mechanism we have) and adding enormous cost, effort, and complexity to every email system.

DKIM doesn't break forwarding. And it is a *vast* overstatement about "enormous cost". Indeed, compared to all of the other things that happen in the mail pipeline, signing and verifying signatures is completely in the noise, and the complexity is minimal. Mailing lists are a different matter, but the amount of traffic generated by them is a rounding error on the total traffic. Old school geeks care about them, but the rest of the world has moved on.

There's a problem with that: email forgery can't be solved.

If the implication here is that DKIM/SPF claim to "solve" email forgery, that is another strawman. They are tools that can help with various tasks in the email infrastructure, but they alone don't purport to solve the whole problem, since it obviously has human factors considerations which a standards body like IETF doesn't do. Pointing at one mistaken marketing blurb (most likely) from 20 years ago that was taken down as evidence to the contrary is really weak.

Even if if these byzantine hacks [...]

Which "byzantine hacks" might those be? Sorry, I can't go on because I don't even know which windmill you seem to tilting at. I assume it has something to do with SPF/DKIM/DMARC, given the title, but I can't tell for sure. Given the strong smell of straw in the lead up, wading through the rest doesn't seem promising. Mike

On 25/05/2025 11:49, Eliot Lear via NANOG wrote:

I wrote:

On 24.05.2025 12:57, Eliot Lear via NANOG wrote:

...

This is a known TB bug.  It's fixed in the dev releases but not yet out to the general public.

A bit of a clarification:

The fix should be in the monthly releases now.  You can go to https://www.thunderbird.net/en-US/thunderbird/all/ and download it.  That's the "release update channel".  It is NOT fixed in the extended support release (ESR) (128).  A special thank you to Magnus Melin who did the work.

Eliot

 Upgraded to 138.0.2 and issue still exists. Regards, Hank

On 5/25/25 3:46 AM, Hank Nussbacher via NANOG wrote:

Correction.  Go to Settings -> General -> Reading & Display -> find  the

option: "Show only display name for people in my address book" and uncheck this box and TB will then show the actual sender.

Thanks Elliot for pointing out the normal release update.

Yes, that works. What a pain... Mike,  even though this entire bit of rewriting the 822.From address is an unfortunate step in the wrong direction wrt security