msw at amazon
Aug 7, 2012, 2:56 PM
Post #7 of 7
On Mon, Aug 06, 2012 at 07:31:32AM -0700, Ian Jackson wrote:
Re: lists.xen.org Mailman configuration and DKIM
[In reply to]
> 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 . 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 .
> 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
> > 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
$ dig +short TXT _dmarc.amazon.com.
"v=DMARC1\; p=quarantine\; pct=100\; rua=mailto:dmarc-reports [at] bounces\; ruf=mailto:dmarc-reports [at] bounces"
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
* 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
* 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 .
Xen-devel mailing list
Xen-devel [at] lists