--On 14 October 2009 09:39:42 -0700 Steve Atkins <st...@wordtothewise.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
