What's happening to Sender: headers?

From: Andrew Reilly <areilly_at_bigpond.net.au>
Date: Sun, 14 Apr 2024 22:33:05 UTC
Hi all,

I can’t think of anywhere else to ask, but this knowledgeable group is as likely as any to know what’s going on, I think.

For years and years I’ve been able to filter all of my FreeBSD mailing list messages into a separate FreeBSD inbox with a pair of simple dovecot-sieve rules:

   if address :matches "Sender" "*owner@freebsd.org"    { fileinto "in.freebsd"; }
elsif address :matches "Sender" "owner*@freebsd.org"    { fileinto "in.freebsd"; }

(… and similarly for most of my other mailing lists).  The Sender header is (used to be) a reliable reflection of the envelope FROM address, which reliably tied things to the email server sending the list messages.

On about the 11th or 12th of April, a significant chunk of FreeBSD mailing list messages, including especially the git commit messages, started showing up in my normal INBOX, evading the filter rules.

Over the weekend I got around to investigating, and discovered that the errant messages don’t _have_ a Sender: header.  There’s a Return-Path: header that captures the envelope-from, but I haven’t figured out how to make sieve check that yet: it doesn’t seem to like it.  Sieve documentation is spectacularly inconclusive, but I suspect that the envelope extension might do what I want, but that’s not really my question.

Does anyone know why the Sender: header, which used to be so reliable that I had thought it an intrinsic part of the SMTP/MTA ecosystem, has gone away, or is at least not ubiquitous?

I’m running dovecot and pigeonhole and postfix from ports, on stable/14 and feeding messages in using fetchmail rather than direct SMTP: I’ve found that exposing an SMTP endpoint requires more anti-spam fu than I've been prepared to muster so far.  Using fetchmail is clunky but it keeps me behind my ISP’s spam filter.

Cheers,

Andrew