Post by Jeremy Stanley Post by Thomas Goirand
Absoultely not. Adding some DMARC records in our DNS doesn't break any
server not checking DMARC records.
Migrating _client_ configurations/workflows to all submit via
Debian-controlled relays on the other hand would be necessary, to
avoid servers who check DMARC records rejecting messages from people
using their debian.org addresses in other ways (for example, yours
seems to have been sent through an MTA in GPLHost for relaying to
the lists.d.o MX).
Right, the whole point of DMARC is to say that messages from a given
domain only originate from a small and well-defined set of servers, or
from servers with access to specific private key material.
Right now, people can use their debian.org address and send mail from
anywhere. For example, this message is being sent from my personal
servers and, were it not addressed to a Debian mailing list, would not go
anywhere near Debian infrastructure.
If we're not going to require that anyone sending mail from a debian.org
address do so through project infrastructure (which is a large change),
there's basically no point in doing anything with DMARC. It would only
increase the chances that mail not sent through Debian infrastructure
would be rejected by over-aggressive implementations that treat unknown as
Whether we want to continue to support that use case is certainly
something we can ask, and balance against the benefits of setting up
proper DMARC, SPF, DKIM, and so forth. The advantage would be that
project mail might be more reliably deliverable, and we would allow
receiving systems to discard more forged spam. The disadvantage is that
setting up infrastructure, documentation, and client configuration to send
all mail from debian.org addresses through project infrastructure would be
a lot of work, particularly since I'm sure that, in the grand Debian
tradition, there are at least as many ways we all send mail as there are
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>