For mailman and DKIM problems (remote reject)
Example:
2014-04-06 08:09:43 1WWkxK-0007jZ-T5 H=mail.ietf.org [4.31.198.44]:45557
rejected DKIM : DKIM: encountered the following problem validating gmail.com:
signature_incorrect
Fix:
In:
mm_cfg.py
Add:
REMOVE_DKIM_HEADERS = Yes
Alex Matias Ojeda Mercado
NOG CHILE
alex(_at_)nog(_dot_)cl
+56971922362
-----Mensaje original-----
De: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] En nombre de
ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com
Enviado el: martes, 08 de abril de 2014 12:53
Para: John R Levine
CC: IETF general list; Robin H. Johnson; zwicky(_at_)yahoo-inc(_dot_)com
Asunto: Re: DMARC: perspectives from a listadmin of large open-source lists
The problem described WILL vanish when all mailing list apps
implement DMARC, but until then, it's really broken.
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.
Actually, mailing lists *can* implement DMARC, just not that way: Do a DMARC
check on all incoming messages, and if the domain policy is one that is
incompatible with the list's own policies - whatever they are - either change
the list's policies to conform to that message or reject it outright,
preferably with a nasty "find another a better mail provider" sort of message.
If the IETF wants to take a leadership position in regards to this issue,
perhaps someone could set this up.
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.
At the same time, delaying mass usage of the reject policy would
limit damage.
Reject policy is fine for domains that don't have individual human
users, or for companies with firm staff policies that all mail goes
through the company mail server, and employees don't join mailing
lists and the like using company addresses, or the company provides a
separate less strictly managed domain for its staff mail. Strict
policies will never be appropriate for public webmail systems where
the users will use their mail addresses any way one can use a mail
address. Yahoo appears to understand most of this, viz. the different domain
for Elizabeth's company mail.
Which is why support for such policies is even in the specification. The
problem is there's no way to stop inappropriate use of such politicies in
advance of it happening. The best you can do is apply the clue-by-four later.
Ned