On Sat 25/Jan/2025 19:18:00 +0100 Bob Proulx wrote:
> Gregory Nowak wrote:
>> golinux wrote:
>>> Nothing has changed. You have just noticed it perhaps because the number of
>>> such occurrences has increased. However, maybe someone on this list will
>>> know the answer because it is a common practice that I see on many email
>>> lists.
>>
>> The short answer is DMARC. This was fully explained on this list way
>> back when the change was first implemented. That message should still
>> be in the list archives, try some time around 2016 I think.
>
> A strict DMARC setting breaks mailing lists. This is by design of
> DMARC which was intended to banks and financial institutions to allow
> user sites to avoid phishing attacks. But this has been abused to be
> used elsewhere and that causes trouble with mailing lists. Any user
> mail sites which set a strict DMARC is abusing the design of it and
> doing a disservice to their users.


Correct. The upcoming standardization of DMARC (now in last call) fully acknowledges this point in a section named Interoperability Considerations:
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis#name-interoperability-considerat


> A high security bank site never sends mail through mailing lists.
> They want to ensure that their 2-factor email security tokens and
> other communications are allowed directly from them to you with
> nothing in the middle. Setting a strict DMARC allows mail user agents
> to reject, discard, or file into SpamScam folders any mail forging
> that high security site's email address.
>
> Users on the other hand send email through mailing lists and send mail
> to people who have set up forwarding and other very common things. In
> that case a strict DMARC breaks mailing lists.


Some heavily abused domains, considering that list traffic is a minor part of their email usage and that mailing lists can apply From: munging as a workaround, apply strict policies nevertheless. I think it's a rather hopeless, desperate attempt, because display names don't have to match the actual From: domain. In practice, I receive scams like this:

From: PayPal <spammer@???>

That way, Paypal's reject policy never plays. An advantage is still visible, though, because without DMARC the actual address would have been spoofed as well. One might suppose that heuristics to tell inconsistencies between display phrase and address can be developed in the future. Certainly, the habit to munge From: doesn't help, as it confirms that display phrase and address may disagree.

A common perception is that if the mailing list problem were solved, every domain could set p=reject, and that would improve our chances of fighting spam quite a bit. How can we get there?

To begin with, mailing lists whose subscribers are not mailing lists themselves, could comply with DMARC strict policies. Even though counterfeit From:s are quite uncommon on mailing lists (and the only ones I ever saw were completely transparent posts aimed at highlight this weakness) closing that flaw would already be an improvement.

Subscribers can set the Author: header field (RFC 9057). It resists munging and some clients (Thunderbird, for one) display it.

For a future possibility, there is an ARC protocol that provides for marking authentication status on entry. Then, if a mailbox provider could be involved in its users' confirmed opt-ins when they subscribe to a mailing list, it could trust the ARC seals of that mailing list. This way, the mailing list could keep From: unchanged in messages forwarded to users of this provider. Forwarding agreements.

For another one, there is a DKIM2 project about a signing technique that accounts for changes, envelopes and bounces. Time will tell.


Best
Ale
--