Exactly, Actually DMARC just let's you know what SPF records would already do
on their own, but silently. By implementing DMARC records, you know who's
trying to send mail "on your behalf" and I noticed that in the DMARC reports,
this mailing list's server was one of them. In my case, SPF records limit who
can send mail with a "from" mydomain.com And DMARC system let's me know who's
sending such emails "without my consent" (= who's ignoring my spf records). I
hope I'm making sense without getting too technical, but I guess there are many
tech minded people in this list anyway. Le 2022-05-03 16:42, Joshua O'Keefe
<[email protected]> a écrit : > > > > > > On May 3, 2022, at 7:09 AM,
Cedric Amand <[email protected]> wrote: > > I did not investigate this much ;
but I would look at the DMARC and « from » problems > DMARC is definitely one
-- potentially the main -- issue here. If someone with a strict DMARC record
submits a message to the list for broadcast, many list recipients will
quarantine or reject the message unless the From: header is munged. > > > >
Mailman has some potential mitigation strategies against this[1], none of which
are great, but DMARC fundamentally broke the way email works by pinning its
mechanism on the From: header.[2] > > > > [1]
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html
> > > > [2] RFC7489 §5 says, essentially: requiring trust in From: was the
only way to make DMARC go. It doesn't actually justify doing so beyond saying
(in §6.7) acceptance is a local decision. The RFC takes no responsibility for
establishing a de facto status quo that is broken. >
