I've taken the liberty to remove the ad-hominem which you used. I'm not
happy with your approach to this discussion, but I'll try to stick with the
technical points.
There is active work within the DMARC WG, with first drafts being published
only *two months ago* [1]. My suggestion for everybody who doesn't have
time to follow this process is to sit back, relax, and watch the IETF come
up with a solution, and *then* start implementing their suggestions. Asking
one's user base to reach every list service administrator out there with a
"fix your DKIM/DMARC" is not going to work. Deploying DMARC at this point
in time, when substantial changes are still being worked on, doesn't look
like a good idea, either. This is all that I'm saying.
The mailing list hosts don't have to deploy DKIM. All they have to do
is not break signatures on mails bearing a DKIM signature.
Which, as I noted in my email is something that only requires a few
toggles within the Mailman administration interface.
(And, using the withlist tool can be changed on all lists on an entire
server with relative ease). This is what Debian has chosen to do.
You're saying that it's easy to configure a ML to stop breaking DMARC
signatures. I disagree. Here's my reasoning:
1) Full compliance with DMARC requires a substantial reduction of features
which distinguish mailing lists from dumb forwarders. This includes:
- the Reply-To munging,
- adding a [prefix] to subject headers,
- automatic signatures,
- in case of overly strict DKIM setup, the various List-* headers which are
actually mandated by RFCs to be automatically added.
2) Some domains might specify DMARC policies which prevent *any*
distribution of their e-mails over mailing lists. The only solution for
this problem is rewriting the RFC5322.From header to something like:
From: "Foo Bar via a KDE ML" <kde...@lists.kde.org>
This in turns leads to e-mails where one cannot reply to the original
author anymore, etc etc etc.
In case someone is still following this thread, let me quote [2] John R.
Levine, one of the Internet graybeards:
Mailing list apps can't "implement DMARC" other than by getting rid of every
feature that makes lists more functional than simple forwarders. Given that we haven't
done so for any of the previous FUSSPs that didn't contemplate mailing lists, because
those features are useful to our users, it seems unlikely we'll do so now.
If receivers want to implement DMARC policy, they need to make their false
alarm whitelist first. This appears to be a substantial, perhaps
insurmountable, hurdle.
"FUSSP" is a "Final Ultimate Solution to the Spam Problem".
That entire thread is worth reading, btw.
Cheers,
Jan
[1] https://tools.ietf.org/html/draft-andersen-arc-00
[2] http://www.ietf.org/mail-archive/web/ietf/current/msg87157.html
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
