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

[Matt Wilson <msw@xxxxxxxxxx>]

On Mon, Aug 06, 2012 at 07:31:32AM -0700, Ian Jackson wrote:
> Matt Wilson writes ("Re: [Xen-devel] lists.xen.org Mailman configuration and 
> DKIM"):
> > On Fri, Aug 03, 2012 at 07:44:30AM -0700, Ian Jackson wrote:
> > > 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.
> > 
> > Ultimately I think that Mailman should verify DKIM signatures, provide
> > a new signature for the modified message (or have the outbound MTA do
> > the signing), and retain the origional DKIM signature as a trace. I
> > believe that this is in line with the recomendations for intermediary
> > email handlers like Mailman in RFC 5863 [4]. Of course, I don't know
> > if Gmail will rework their implementation to ignore the invalid
> > signature. At least one Mailman user reported success simply adding a
> > new signature and not stripping any header [5].
> 
> The solution to the broken DKIM implementations, or broken spec, must
> not be allowed to become "install more DKIM".  That is making the
> problem worse, not better.

That's possibly true, but I'm not well versed enough in the DKIM and
related specs to say if "install more DKIM" makes things worse or
better.

> > Personally, I think that stripping DKIM headers as a short term
> > workaround is less objectionable.
> 
> So bottom line is you think that Gmail is violating a SHOULD NOT.
> And you are suggesting that the right fix for this is for us to also
> violate a SHOULD NOT.  That can't be right.

Andrew Cooper helpfully pointed out that the actual problem is a DMARC
policy advertised by amazon.com that requests all messages pass DKIM
checks:

$ dig +short TXT _dmarc.amazon.com.
"v=DMARC1\; p=quarantine\; pct=100\; 
rua=mailto:dmarc-reports@xxxxxxxxxxxxxxxxxx\; 
ruf=mailto:dmarc-reports@xxxxxxxxxxxxxxxxxx";

Gmail will treat a message with no DKIM signature from amazon.com the
same as a broken DKIM signature from amazon.com, so stripping the
headers won't actually help here.

> > If a test of removing DKIM headers to see if it helps with delivery to
> > Gmail is off the table, then perhaps configuring Mailman in a way that
> > doesn't break DKIM signatures would be an option? Amazon's signed
> > headers include date, from, to, cc, subject, message-id and
> > mime-version. If the subject manipulation of adding [Xen-devel] was
> > removed, the signature would likely still be valid.
> 
> I don't think that would be popular and I don't think this is a good
> reason to do it.
> 
> Personally I think these subject line prefixes are annoying and if it
> were my list it wouldn't have had them to start with.  But if you want
> us to turn that off I think you need to get consensus for that.

The DMARC FAQ, http://dmarc.org/faq.html, has only this advice to
mailing list operators:

  I operate a mailing list, what should I do?

    DMARC introduces the concept of aligned identifiers. It means the
    domain in the from header must match the d= in the DKIM signature
    and the domain in the mail from envelope.  You have a few
    solutions:
     * operate as a strict forwarder, where the message is not changed
       and the validity of the DKIM signature is preserved
     * introduce an "Original Authentication Results" header to
       indicate you have performed the authentication and you are
       validating it
     * take ownership of the email, by removing the DKIM signature and
       putting your own as well as changing the from header in the
       email to contain an email address within your mailing list domain.

None of these options are terribly compelling to me. I think that
Mailman could run as a strict forwarder if the subject tags and
message footers were disabled, but you're right that we'd need to get
consensus to make that change. The "Original Authentication Results"
option sounds like yet another header that will have non-standard
handling depending the implementer.

Since modifying the Xen.org mailman configurations would only address
the problem on one list server, I'll investigate alternative solutions
on the Amazon side of things. It seems that Google has a googlers.com
domain for this type of thing [1].

Thanks again,

Matt
[1] 
http://mail.python.org/pipermail/mailman-developers/2011-December/021640.html



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