--On 14 October 2009 09:39:42 -0700 Steve Atkins
<steve(_at_)wordtothewise(_dot_)com>
wrote:
The whole point of "discardable" is that the final recipient should not
see it in that case. It's for things like transactional mail, bank
statements, that sort of thing - which should never go to mailing lists
anyway as
the sender believes it should be sent directly to the final recipient,
or not at all.
(If you disagree with my characterization of the sort of email that
might use discardable that's fine, but lets be specific about the
operational
details, like what classes of email we're talking about. Discussing it
solely in the abstract protects the discussion from common sense.)
That seems sensible to me. So lists should not forward email that they're
about to render 'discardable' by breaking the signature. Instead, they
should reject (5xx) or bounce (DSN) the message. Presumably, a bank wants
to know if it has a bad email address for a customer. Of course, if you
aren't going to break the signature, or are rewriting the From: address,
then it's OK to forward the email. Oh, and if the list sees incoming mail
already has a broken signature, or none at all, then it should be discarded
by the list software (or its MTA).
If a list does nevertheless forward an email, after rendering it
'discardable', of course RFC 5617 says that it should be discarded by the
MDA. It also occurs to me that 'discardable' means that you can deploy
per-recipient policies after seeing the message body - by passing the
message to some recipients, but not others. That's not usually possible.
The treatment of email with authors in a domain with 'dkim=discardable'
policy seems absolutely straightforward. What's more complicated is the
treatment of email with authors in a domain with 'dkim=all' policy. There's
no guidance about handling such mail.
List operators need to be advised that breaking signatures in such domains
may result in the message becoming undeliverable, even though the inbound
message carried a valid signature. There are several actions that a list
could take, to mitigate consequential problems:
1. Not apply VERP bounce policies to messages that are consequently
rejected. This risks eroding the value of VERP if 'dkim=all' becomes widely
deployed among domains used by the list's members. Eventually, VERP could
become unusable if it didn't adapt. Oh, but the lists would become unusable
first, if people are rejecting messages from dkim=all domains. Is there any
sense in such domains applying lightweight signatures that are less likely
to be broken by lists? Can such a thing be done without making the
signatures reuable? Is it possible to sign the From: header, + the subject
*after* a list prefix, and the body *before* a list footer? Or would these
just be newly exploitable holes?
2. Make sure they sign their messages, so that recipients have some
confidence that this isn't a spammer spoofing a trusted list. And, as has
been suggested, make clear that they've assessed the signature before
breaking it. OF course, this is spoofable, OF course it relies on a trust
relationship between the recipient and the list. But, the recipient
(ideally) knows which lists s/he's subscribed to, and with DKIM can tell
whether to trust the list. Some MDA or MUA assistance would be really
useful here.
You know, I'm not sure I'm averse to a world in which a spammer can only
deliver mail by adding list-id headers for lists that I'm not subscribed
to! One where most domains publish 'dkim=all', and all my legitimate mail
has carries a dkim signature, and broken signatures only come mailing lists
that I've either subscribed to or not.
3. Some fancy munging of the From: header (like VERP, perhaps), in such a
way that replies could be routed to the sender? Ugh!
A more interesting case to consider is acm.org style forwarders,
where the forwarder is, in many ways, the final destination, and where
the address at the forwarder is "owned" by the final recipient, and
where they will likely ask for transactional mail of the sort that
senders might consider discardable be sent.
Cheers,
Steve
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html