[FFmpeg-devel] [RFC] mailing list From mangling and bounces and DMARC

[FFmpeg-devel] [RFC] mailing list From mangling and bounces and DMARC

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 1934 bytes --]

Hi everyone

As we all certainly know, this ML since a few months rewrites
all "From:" headers to "X Y via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>"
We changed this because neither me nor timo nor rather unhelpfull AI
could fix the bounce & dmarc issue

33 @outlook and 19 @hotmail subscribers got deleted on october 8th
because their accounts where disabled from earlier bounces and they
did not re-enable their accounts.

Other mailing lists from other projects seem to survive without
universal rewriting.

Should we try to switch this list back to only rewrite the
addresses that need it ?

mailman3 has a list where we can manually add domains which need it

hotmail.com and outlook.com both have a DMARC policy of none
so they would not automatically fall under DMARC mitigations
and it seems noone added them to the mailman3 list
nor was outlook in the postfix list we had from mailman2 days

Both me and timo want to try reducing the from rewriting again.
We seem to disagree a bit on if we try with the mailman3 manual
DMARC list empty first or starting with outlook and all entries from
the sender_canonical rewrite list.

Are there any people reading this, who have some information / experiencees
they can share about mailman3 DMARC settings ?
(so we can benefit of your experience and can skip some trial and error :)

What do people think ?
any other thing we are missing ?

PS: we now have a DMARC setup, ARC signing and mailman3

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] mailing list From mangling and bounces and DMARC

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 2488 bytes --]

Hi all

On Thu, Oct 16, 2025 at 06:25:00PM +0200, Michael Niedermayer via ffmpeg-devel wrote:
> Hi everyone
> 
> As we all certainly know, this ML since a few months rewrites
> all "From:" headers to "X Y via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>"
> We changed this because neither me nor timo nor rather unhelpfull AI
> could fix the bounce & dmarc issue
> 
> 33 @outlook and 19 @hotmail subscribers got deleted on october 8th
> because their accounts where disabled from earlier bounces and they
> did not re-enable their accounts.
> 
> Other mailing lists from other projects seem to survive without
> universal rewriting.
> 
> Should we try to switch this list back to only rewrite the
> addresses that need it ?
> 
> mailman3 has a list where we can manually add domains which need it
> 
> hotmail.com and outlook.com both have a DMARC policy of none
> so they would not automatically fall under DMARC mitigations
> and it seems noone added them to the mailman3 list
> nor was outlook in the postfix list we had from mailman2 days
> 
> Both me and timo want to try reducing the from rewriting again.
> We seem to disagree a bit on if we try with the mailman3 manual
> DMARC list empty first or starting with outlook and all entries from
> the sender_canonical rewrite list.
> 
> Are there any people reading this, who have some information / experiencees
> they can share about mailman3 DMARC settings ?
> (so we can benefit of your experience and can skip some trial and error :)
> 
> What do people think ?
> any other thing we are missing ?
> 
> PS: we now have a DMARC setup, ARC signing and mailman3

verp_probes are now enabled, thus people should receive a mail from mailman
now before having their account disabled/removed after several bounces.

And only if that last mail bounces would their account be disabled/removed

This is a mitigation to reduce the annoyance of bounces, not a final solution
Ive also enabled that bounced messages will be sent to the list owners so
I can see what exactly bounces and why. Iam not sure why this was disabled

From rewriting / DMARC mitigation is still unchanged.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] mailing list From mangling and bounces and DMARC

[Nicolas George via ffmpeg-devel]

Michael Niedermayer via ffmpeg-devel (HE12025-10-16):
> As we all certainly know, this ML since a few months rewrites
> all "From:" headers to "X Y via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>"
> We changed this because neither me nor timo nor rather unhelpfull AI
> could fix the bounce & dmarc issue

Hi. I do not know about mailman's configuration, but in the recent
months I have been trying to find a solution to the problem of
forwarding mail to former users, and I can share what I understand of
the issues at hand.

(Spoiler: there is no solution, monopolists have effectively broken
unconditional forwarding addresses. People being able to use their
resources without showing it in their address, people being able to
leave by just changing the target of the forwarding address, that was
not what the monopolists had ordered.)

Emails have to pieces of information that indicate who sent them. There
is the “From:” field in the header of the mail data, called without
originality the “header from”: it is presented to the user and used to
send replies (unless there is a reply-to header). And there is the
sender passed through the MAIL FROM command of the SMTP protocol, called
“envelope from”: it is used to report errors through the infamous
“mailer daemon” mails.

When forwarding an email, a system can alter anything in its data. It
can also pass the envelop from as is to the next hop or replace it by an
address of its own (any other option being absurd). Usually, one will
keep the envelop from when forwarding to a single person, so that an
error on the destination is reported to the author of the mail, and one
will replace it when forwarding to multiple persons. Mailing-lists do
that: Sympa uses $listname-owner, Mailman seems to use
$listname-bounces.

All this used to be open-bar: any server could send with any envelope or
header from. That was a feast for spammers. Over the years, various
anti-spam measures were added, and are being enacted by large operators,
which makes it necessary to comply with their constraints if we want our
email to reach the customers of these operators.


SPF uses the DNS to publish a list of IP addresses allowed to send mail
for a certain domain. It controls the envelop from. It can encode a
more-or-less strict policy, up to the instruction to reject mails coming
from an IP not listed.

Mailing-lists take ownership of the envelope from, they are not affected
by SPF provided their own server is properly configured. For individual
redirections, there is a scheme, Sender Rewriting Scheme (SRS), where
the envelop from is replaced with one from the local system using a
reversible transform of the address, and messages arriving back are
forwarded back by reversing the transform.


DKIM uses cryptography to authenticate the body and part of the header
of the mail by putting a big signature in the header. The signature
indicates which domain is signing the mail, and the DNS is used to
distribute the public key. The standard does not specify what must be
checked, therefore DKIM does nothing to help with spam: the spammer just
signs the email from their domain.

Any service that alters a mail while forwarding it, like a mailing-list
adding “[ffmpeg-devel]” in the subject line, will break the signature.
What they are expected to do is to add a signature of their own, from
their own domain, and possibly a signature telling that it checked the
original DKIM signature and it passed.


DMARC is not a new mechanism by itself but a way to publish a policy to
tie SPF, DKIM and the contents together. There are cosmetic options, but
the core of it is that the domain of the envelop from, the domain of the
header from and the domain of the DKIM signature must match, i.e. be
equal or subdomains of each other.


Note that the large operators are increasingly putting pressure on
everybody to force adoption of these standards. One of their methods is
the blackmail “if you do not set your DMARC policy strict enough, we
will start considering mail from your domain as spam”. This things is
here for good, unfortunately.


What I deduce from all this is that we cannot hope to keep
“From: developer@their-domain.org” in the mails sent from our
mailing-lists: it will only work if their-domain.org has SPF and DMARC
policies lax enough, and these will vanish. The new scheme where the
header from is replaced with the address of the mailing-list seems
unavoidable.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] mailing list From mangling and bounces and DMARC

[Pavel Roslyy via ffmpeg-devel]

On Tue, Nov 4, 2025 at 11:12 AM Nicolas George via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
> Any service that alters a mail while forwarding it, like a mailing-list
> adding “[ffmpeg-devel]” in the subject line, will break the signature.
> What they are expected to do is to add a signature of their own, from
> their own domain, and possibly a signature telling that it checked the
> original DKIM signature and it passed.

The headers that are signed for DKIM can be configured.  It is not
recommended, but if needed you can remove Subject from the list of
signed headers.  I don't know how you have it set up, but with OpenDKIM
adding a line like "OmitHeaders *,+subject" to the configuration file
should do it.  If there are any other headers that mailman(?) modifies,
they also need to be added in order to pass DKIM.


> What I deduce from all this is that we cannot hope to keep
> “From: developer@their-domain.org” in the mails sent from our
> mailing-lists: it will only work if their-domain.org has SPF and DMARC
> policies lax enough, and these will vanish. The new scheme where the
> header from is replaced with the address of the mailing-list seems
> unavoidable.

I had a similar situation at $dayjob where we wanted the From to have
the user's email but the mail to be sent from our server.  The solution
I found was to include a Sender header after the From, in this case
it should probably be "Sender: ffmpeg-devel@ffmpeg.org".  This should
cause the SPF lookup to happen to ffmpeg.org instead of
their-domain.org.  Note that if the From is already ffmpeg-devel@ffmpeg.org then
you should not add a Sender header, according to RFC 5322.

Regards,
Pavel Roslyy
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org