On Tuesday 13 October 2009 20:54:40 Charles Lindsey wrote:
On Tue, 13 Oct 2009 02:24:56 +0100, hector
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com>
wrote:
The deployment guide section 6.5 writes:
Any forwarder that modifies messages in ways that will break
preexisting DKIM signatures SHOULD always sign its forwarded
messages.
But it should in addition say that it SHOULD also add an
Authentication-Results header for the signature it is about to break AND
include that A-R header within what it then signs. That will provide much
more information to the ultimate recipient.
This is good.
Before any forwarder attempts to modifies messages and add
a new signature to the message, it SHOULD look at the
ADSP record for the 5322.From domain. If the domain has
an ADSP record with "dkim=all" or "dkim=discardable", the
forwards SHOULD NOT forward the message.
No, I think that would lose too much genuinely wanted mail.
I'm not convinced there would be much genuinely wanted email in this case.
I believe there are sufficient mailing lists out there that break DKIM
signatures sufficient for the DKIM WG to consider them fully the DKIM
standardization suite.
My quick assertion is:
"The input to these mailing lists is, in every sane case that I can think of,
direct from the author."
THE INSANE CHAIN of MAIL LISTS
The insane case I can recall is (with names anonymised):
A group of server administrators of a software mirror site maintained a
mailman list with all their email addresses as a subscribers. They got
convinced to mirror a linux distribution on their mirror. This linux distro
had another email list for communicating amongst mirror admins. Our group of
server admins subscribed their mailing list address to the mailing list for
mirror admins. The impact of this was a mirror admin would email to the mirror
admin list. This would distribute an email to our group of server admins via
their list. Our server admin list would reject the email back to the mirror
list saying "please confirm email" and this email was sent to every mirror
admin. The end result was our group of server admins was force-ably
unsubscribed from the mirror list and told to subscribe sensibly (sanely).
What has this got to do with DKIM? well it highlights that chaining email
lists that require subscribers or email confirmation won't work because they
don't share common subscribers. These are the kind of email lists that break
DKIM signatures. The current in-operability of chained email lists make this
already a rare (and insane) configuration.
The world of spam was made the "require subscribers or email confirmation" a
common type of DKIM signature breaking email list.
Had the server admin list been a simple alias expander then there would of
been no problem. As Dave has already said further down this thread, alias
expanders aren't a problem with DKIM and the same applies here.
PLEA:
if ANYONE has a reason why a email forwarder that breaks DKIM signatures would
receive a broken DKIM signature in a fairly common case please share this now!
ALTERNATE:
If there are cases here, or perhaps if we just want to be more liberal, then
perhaps email forwarders need to see if there is any Third Party
authorizations from the Author Domain delegating authority to a third party to
sign on their behalf (don't look at Doug's draft yet - an updated one will be
coming out soon).
SUPPORT +1
Short of a quantification from the words above if needed, I'm totally in
support of Hector's proposal to reduce the conflict in the deployment guide,
and encourage forwarders that break signatures to consider the Author Domain's
wishes up front (in not forwarding broken signatures when
ADSP=ALL/DISCARDABLE), as they are unlikely to receive a valid message with a
broken signature.
Daniel
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html