Re: [Xen-devel] lists.xen.org Mailman configuration and DKIM

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Matt Wilson writes ("[Xen-devel] lists.xen.org Mailman configuration and DKIM"):
> Several folks have let me know that my messages sent via lists.xen.org
> are marked as spam / spoofed, especially when using Gmail to receive
> Xen mail. I believe this is because outbound Amazon email contains a
> DKIM signature. When Mailman modifies my message and re-sends it, the
> DKIM signature is invalidated [1].
> 
> To work around this, Mailman 2.1.10 and later contain a configuration
> variable called "REMOVE_DKIM_HEADERS" [2]. Perhaps if this were turned
> on we'd work around the problem.
...
> [1] http://wiki.list.org/display/DEV/DKIM
> [2] https://bugs.launchpad.net/mailman/+bug/557493

Having checked RFC4871 I think it is clear that according to the
standards
  - Mailman SHOULD NOT [1] strip DKIM-Signature
  - No-one should treat a message with an invalid DKIM signature
    differently from a message with no DKIM signature at all [2]

[1] 4871 says in s3.5 that DKIM-Signature SHOULD be treated the same
way as a trace header (ie a Received), so removing it would be a
violation of that SHOULD not necessarily a violation of the MUST NOT
mess with Received headers.

[2] RFC4871 6.1:
   A verifier SHOULD NOT treat a message that has one or more bad
   signatures and no good signatures differently from a message with
   no signature at all; such treatment is a matter of local policy and
   is beyond the scope of this document.

I think it would be better if you would do one of:
  (a)  Get Gmail fixed to comply with RFC4871 6.1;
  (b)  Get your correspondents to use a non-broken email host;
  (c)  Get the DKIM the spec changed or clarified;
  (d)  Stop putting these abused things in your email headers.

That would be better than asking lists.xen.org to start violating the
specified protocol.  Now of course a SHOULD is not an absolute
requirement.  Perhaps mailing lists are a special case somehow; but if
so I would expect this to be addressed in the relevant standards
documents.  I don't see any particular reason to think that
lists.xen.org is somehow unusual.

Do you agree ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel