The masochistic side of me spent some time going through this entire thread over the long weekend to fish out the pieces that can be folded into the lists draft. This is a summary of that sifting, which I'm using to generate the -01 draft.
Please, folks, change the Subject: field for the ADSP-specific part of this discussion. The part of the thread that has to do with what we can tell list participants and software developers now must be based on RFC4871 and RFC5617, and not on what we think either of those things should have been in the first place. The rest is a totally different conversation, unless we think we need to fix those before any list practices get discussed, which I don't believe to be the case. Also, please constrain follow-ups to this posting (with this Subject:) to the lists draft, and in particular, +1s, proposed changes to wording, or sections that should be added, rearranged or removed. The more specific you are, the more useful the contribution; stuff like "you should say more/less about ADSP" isn't really meaningful. In several places, where there have been suggestions to remove some text from the draft because it conveys a bad idea, I intend to leave it in accompanied by text explaining that it's a bad idea and why. I believe it's better to close off such a path from a new participant than it is to leave it unexplored. An interesting point came up late in the thread, and that is a challenge to our well-established mantra that the MUA is the slowest thing to change. With Gmail and Yahoo being active-yet-silent participants in all this, and I think we can presume the likes of AOL is included, and even open source solutions like Horde might not be far behind, is that all still true? If not, then perhaps the lists document might suggest some MUA improvements to assist with all of this effort. Or maybe a separate effort can be started that recommends common MUA changes to make them more DKIM-aware and put some of all this work to better use. Finally, a question: So that an MLM can proudly exclaim "We are RFCxxxx compliant!" and have it be meaningful, should this document seek the status of a BCP, or is Informational sufficient? Now then: > -----Original Message---- > From: [email protected] [mailto:[email protected]] > On Behalf Of John Levine > Sent: Friday, April 23, 2010 9:41 AM > To: [email protected] > Cc: [email protected] > Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM signatures > > [...] > There's no new semantics, deep or othterwise. Yahoo is treating the > signature as an assertion of responsibility -- it has my signature, > the recipient complained about it, they have reason to think I'm not > evil, so they sent me the complaint. All that is fine, but the > problem is that for list mail, I'm not the one who can do anything > about it. I kind of don't buy this as a DKIM-specific problem. Even before DKIM, a provider might decide to send a copy of the complaint report to you since you're in the From: even though there's a Sender: or the IP address matched an FBL registration or something. It might be useless, sure. But it's not a fault specifically of DKIM; it's a questionable FBL choice. > If a list adds its own signature and leaves the contributor's, now > it's up to heuristics by the recipient to guess what to do. For list > mail, the correct guess is to treat the list as responsible. Wouldn't > it be a better idea to avoid the guessing? Again, pre-DKIM, that could still happen. But in the DKIM world, the FBL could take this apparent heuristic one step further and identify the list's signature by matching it to other domains like the one in List-Post: or such, and thus not bother the author since, as you say, she/he can't do anything about it. > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Steve Atkins > Sent: Friday, April 23, 2010 10:07 AM > To: IETF-DKIM WG > Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM signatures > > [...] > > Wouldn't > > it be a better idea to avoid the guessing? > > Yes, by notifying all the responsible parties who have set up a > DKIM based FBL and who have valid DKIM signatures on the > message. +1 (and there were at least two other +1s) > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Ian Eiloart > Sent: Wednesday, April 28, 2010 2:19 AM > To: McDowell, Brett; [email protected] > Cc: [email protected] > Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should > strip DKIM signatures > > [...] > > Mailman doesn't check DKIM signatures, or add them. Quite properly, in > my > opinion, this is regarded as the business of the local MTA, not the MLM > software. I find this a particularly important point to framing of the problem. And this is in part exactly what RFC5451 was for. Unfortunately to provide a lists BCP in general, we have to consider that some MLMs will be forced to do that work as their MTAs are not DKIM-aware, so we need to be general about this (i.e. say that verification should be done, but not specify which agent in the local chain does it). > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of MH Michael Hammer (5304) > Sent: Wednesday, April 28, 2010 8:03 AM > To: [email protected] > Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should > strip DKIM signatures > > [...] > > 2) One possible recommendation to list managers is that if a message to > the list is DKIM signed AND has an ADSP discardable policy AND the > signature cannot be maintained intact then the list should bounce the > message. We seem to have rough consensus on this point, and it's in the draft. > 3) Is there a way for us (perhaps in a future version) to provide for > some sort of "encapsulation" that will allow the original > signature/message to be maintained even as the list does certain (as > yet > unspecified) actions which might currently break the signature? Just > blue skying here. Technically yes: The MLM could MIME-ify the original message as a message/rfc822 part in a larger message that contains anything else it cares to add -- headers, footers, new header fields, whatever -- and that encapsulated message could include its original author signature, which presumably would continue to validate if evaluated over that encapsulated message. That would probably solve a lot of problems, although it's ironic that we'd be encouraging an even more substantial change to the message to get around the problem of messages being changed. But as I recall, we have text in various places saying DKIM signatures inside MIME parts shouldn't be evaluated anyway. Maybe that should be revisited given the possible value of it in this context. > 4) I recognize the chorus which says "mail lists have always done > things > a certain way and who are you to tell us how or what we have to do". > Having given that recognition, in creating an authentication model it > seems self defeating not to provide mechanisms for the authentication > to > survive things like maillists (for those maillists/software providers > willing to adopt whatever we come up with). Those lists which have > always done thigns a certain way and wish to continue could do so - no > harm no foul. That would be ideal, but we've created an authentication mechanism that relies on MLMs not doing things they've been doing for a long time. Maybe a mechanism like what you're describing could be concocted, but DKIM isn't it. The best shot at this would be an alternate canonicalization, which has been proposed, that is more likely to survive the myriad modifications that are described in the lists draft (and others we may not have mentioned), but specifying, let alone implementing, such a thing would be a small nightmare. I suspect if we want to design an authentication mechanism that is specifically transparent to lists, we need to start over. > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Ian Eiloart > Sent: Tuesday, May 04, 2010 1:48 AM > To: DKIM List > Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion > > [...] > > I agree it's hypothetically possible, but have you ever seen an actual > > need for this in practice, a list where the recipients filter out > > messages that a more competently managed list would have rejected? > > I've seen spam posted to mailing lists. Recently, I've seen lists > targetted > in more intelligent ways by spammers. For example, by using sender > addresses in the domain of the list (quite a useful way of attacking > academic lists, which tend to have lots of local users, but some non- > local). Though I've not witnessed this myself, I think it stands to become a more common attack vector if it is found to be even marginally successful, because it's free to try. > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Alessandro Vesely > Sent: Tuesday, May 18, 2010 5:55 AM > To: John Levine > Cc: [email protected] > Subject: Re: [ietf-dkim] Lists "BCP" draft available > > [...] > > > Yes, of course. The signature means that this message really truly > > came from the mailing list, as opposed to being a random piece of > spam > > that happened to resemble list mail. > > +1. However, may I ask how does the verifier know which signature is > the one that belongs to the list? I can think of > > * look at the MAIL FROM domain, à la SPF (breaks forwarding), > * have the list's domain in a white list (requires maintenance), > * use some of the "List-*" fields (which one?) > > Apparently, section 5.4 doesn't cover this point. Quite right. And at the risk of doing something drastic like tying "d=" to something else in the message, I suggest the latter. (Dave suggested something like that, and it was +1'd at least once anyway.) And with that, draft-kucherawy-dkim-lists-01 has been posted for your perusal and feedback. This thread was enormous so it's possible I missed something. If so, please do point it out. -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
