Thank you, Bryan. — Greg Newman

On Mar 1, 2025, at 1:26 AM, Bryan Fields <Bryan@bryanfields.net> wrote:

The lists have been migrated to mailman 3 and are on lists.nanog.org now. The new archive interface is online and is searchable, along with the ability to reply from the archive interface. You will need to make an account associated with the email address you use to receive mail on lists.nanog.org if you want to use these features.

Thank you, -- Bryan Fields

727-409-1194 - Voice http://bryanfields.net _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SC3GCS2N...

On Sun, Mar 2, 2025 at 10:55 AM Niels Bakker <niels=nanog@bakker.net> wrote:

| Subject: [NANOG]Re:

Congrats on completing the move to Mailman 3 but is this Subject line mangling truly necessary?

It has been standard for mailing lists for a quarter of a century now. Isn't it time NANOG caught up with mailing list best practices? Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

I’d love a whitespace after the “[NANOG]”

* William Herrin:

On Sun, Mar 2, 2025 at 10:55 AM Niels Bakker <niels=nanog@bakker.net> wrote:

...

| Subject: [NANOG]Re:

Congrats on completing the move to Mailman 3 but is this Subject line mangling truly necessary?

It has been standard for mailing lists for a quarter of a century now. Isn't it time NANOG caught up with mailing list best practices?

Many mailing lists have moved away from Subject:/body rewriting because it breaks DKIM signatures and may prevent successful message delivery to recipients whose servers enforce the sender's DMARC policy. The alternative is to rewrite the From: line, at least for senders with restrictive DMARC policies, but this breaks other things. <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html>

* Bryan@bryanfields.net (Bryan Fields) [Mon 03 Mar 2025, 00:47 CET]:

The footer is a bit redundant, as mailman3 has the direct link in the "Archived-At:" header now. I'd propose removing the footer and subject prefix, and investigate implementing ARC now that we can support it on mailman3. Keep in mind there's over 12k people on this list, so performance is a bit of concern.

What do others think of this?

Agreed on both counts. Look at this monstrosity: Subject: [NANOG] Re: [NANOG]Re: Hardware for MPLS/SR network -- Niels.

On 3/3/25 12:30 PM, Matt Corallo via NANOG wrote:

On 3/2/25 6:46 PM, Bryan Fields wrote:

...

There are two other options:

1. Rewrite the from for all messages 2. Implement ARC https://arc-spec.org/

Option one is a bit like a shotgun approach, but it works across all providers, and is well understood.  A number of other lists in our industry do it with little issue; the -nsp lists and outages to name a few.  A receiver can view the headers and see if it's signed/valid along the way.

Option two is outside the scope of migration, but arguably could be the best as it directly solves the issue.  Google does implement it.

The footer is a bit redundant, as mailman3 has the direct link in the "Archived-At:" header now.  I'd propose removing the footer and subject prefix, and investigate implementing ARC now that we can support it on mailman3. Keep in mind there's over 12k people on this list, so performance is a bit of concern.

What do others think of this?

Personally, I always liked that DKIM stayed valid through NANOG. It meant that mail sent to NANOG was evaluated mostly by the actual sender, and not by the list itself, which seems much better than lists laundering senders from the PoV of spam filters.

In theory, at least. Unfortunately all of that logic is proprietary especially by the big mailbox providers so it's really hard to say what's happening under the hood. It would be nice to know how it's being used in real life, but I'm not aware of any papers that describe it (feel free if anybody knows some). Mike

On Sun, Mar 02, 2025 at 11:17:35PM +0100, Florian Weimer wrote:

Many mailing lists have moved away from Subject:/body rewriting because it breaks DKIM signatures and may prevent successful message delivery to recipients whose servers enforce the sender's DMARC policy. The alternative is to rewrite the From: line, at least for senders with restrictive DMARC policies, but this breaks other things.

And this is one of the great ironies of the entire DKIM/DMARC push: it breaks things that were working just fine for decades while (a) providing no anti-spam value [1] and (b) making the email forgery problem *much* worse [2]. ---rsk [1] I've been monitoring deployment over all email traffic to several dozen domains scattered across a number of servers scattered across a number of networks. And amusingly (or not), significantly more spam is correctly signed than non-spam. This should surprise nobody; it's been a repeated pattern with multiple technologies that were claimed to deal with spam effectively and have instead either had no real impact or made the problem worse. [2] The convergence of multiple bad choices is in play here. First, the proliferation of new TLDs that have been rapidly overrun by abusers of all descriptions. Second, dubious choices in email user interfaces that obfuscate sender addresses. Third, equally dubious choices in email UIs that mark messages that pass validation as "signed" or "secure" or "certified" or whatnot. Fourth, the increasing inability of users to understand email address RHS, e.g., to distinguish example.com from example.tld or example.com.tld or exammple.com or exammple.tld. Fifth, many example.com'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. Sixth, they also include URLs and encourage their users to use those URLs. Seventh, as everyone here is painfully aware, there are all kinds of hosting/cloud operations that will happily take example.tld's money even though they know full well they're not the real example.com and know equally full well what they're really doing. The result of all this is that users are being trained to fall for forgeries, and there is ample supporting infrastructure to make those forgeries effective. Yeah, abusers will have a hard time successfully forging messages from example.com and getting them delivered: *but they don't have to* because example.tld (for ~1000 values of "tld") is available. And of course example.tld can recreate the language and appearance of messages from the real example.com at will, and can mimic the web site, which means that users will be presented messages that look like, feel like, smell like they're from example.com, are dutifully marked as "authentic" or whatever in their email client...and are all fakes that lead them to a fake web site.