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),

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

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

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

On 23.05.2025 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?

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/36WR43N5...

On 25/05/2025 13:40, Hank Nussbacher via NANOG wrote:

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.

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

Regards,

Hank

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