[edit] having done a bit more research, I think the problem lies with the BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809
[edit] having done a bit more research, I think the problem lies with the BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809
Some List on behalf of John Sender <list@example.com>
... instead of ...
John Sender <john@other-example.com>
And now the list software can generate its own (valid) DKIM signature.
EDIT: Nevermind, listen to dbqpdb[0] instead. ARC sounds like a better way to go.
However the issue is fixed by the new ARC protocol though, which is supported by most major email providers & in most mailing list software as of like this year. Theoretically, just a matter of time until they update their software & the issue is resolved.
* https://en.wikipedia.org/wiki/Authenticated_Received_Chain
SPF: passed or failed
DKIM: passed or failed
DMARC: passed or failed
There are basically 0 violations, until I mail the Debian BTS or a mailing list, whereupon there are dozens. So it could be a problem at my end, Debian's end, or maybe downstream of Debian (e.g., if mail for foo@debian.org is forwarded on to someone else who has a misconfigured email setup...)
Regardless, my DMARC record has p=none so these reports are informational only. On the other hand, it's basically the reason I've never gotten around to changing it to p=reject...
A lot of owners reconfigured said software to rewrite the From header since Yahoo changed their DMARC policy to a hard fail and broke quite a lot of mailing lists in doing so, as the resulting backscatter caused the software to unsubscribe people from the mailing list when delivery failed if someone sent a message from their Yahoo account.