Re: [ietf-dkim] DKIM and mailing lists
On 12 May 2011, at 17:44, Hector Santos wrote: For the record, the old MLM was read as well Levine's poison pill MLM. With no intent nor suggest the writer is stupid, writers do say stupid things and that paragraph was stupid then and it remains to be stupid as in a stupid manner; he had stupidly defined a one way ticket for DKIM. I'm sorry, but in English, it's almost impossible to say that an idea is stupid without implying that the person who had the idea is stupid. I understand that the Spanish language may be different in this respect, in that it's much easier in Spanish to say that something bad has happened without assigning direct responsibility to some person involved. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
Perhaps its a cultural thing. You should hear the number of the times my Jewish wife had said; oh silly! stop being stupid! or New York, Miami Cuban or Ricans cousins saying stupppid (its a special prolonged funny emphasis), or Cuban exiles elders calling me a Stupid Communist just because I want the Cuban embargo to end, Elian going back to this dad) or an Italian uncle saying was a studid (Dominoes) move! but I really hate it when he calls me a Paper Hat! Oh, really gets to me! Whatever, I remain convinced that particular paragraph is terrible, wrong, improper, even incompatible.But I can also see where that can imply, infer, suggest, insinuate or make people silently erroneously ponder the writer is a terrible, wrong and improper person writing incompatible material. All of which, all this, is chippy and infers signs of disrespects. Mucho Gracias, Ciao, Bonjour, Cheerio!, Catch you later, see ya on the rebound, Bye Bye! Ian Eiloart wrote: On 12 May 2011, at 17:44, Hector Santos wrote: For the record, the old MLM was read as well Levine's poison pill MLM. With no intent nor suggest the writer is stupid, writers do say stupid things and that paragraph was stupid then and it remains to be stupid as in a stupid manner; he had stupidly defined a one way ticket for DKIM. I'm sorry, but in English, it's almost impossible to say that an idea is stupid without implying that the person who had the idea is stupid. I understand that the Spanish language may be different in this respect, in that it's much easier in Spanish to say that something bad has happened without assigning direct responsibility to some person involved. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
I think You miss to state the important point that MLMs usually preserve the RFC5322.From when sending the email to the subscribers except in digest mode where it replaces it by the list-owner(?) email. This is why ADSP fails, otherwise if the RFC5322.From was replaced we would have no issues with ADSP. On 5/12/11 5:36 , John R. Levine jo...@iecc.com wrote: I realize it's a little late, but here's what I think the MLM document should have said: http://www.taugh.com/draft-levine-mlm-minus-00.html I shamelessly stole Murray's intro sections, but you should blame me for the whole thing, borrowed or otherwise. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
I don't disagree with you, but it is important to state why ADSP fails, because mailing lists keep RFC5322.From and as the IETF could put it, if it is widely used then it has to be considered as a standard. ADSP can hardly change standards, nor any other email policy. On 5/12/11 17:47 , John R. Levine jo...@iecc.com wrote: I think You miss to state the important point that MLMs usually preserve the RFC5322.From when sending the email to the subscribers except in digest mode where it replaces it by the list-owner(?) email. This is why ADSP fails, otherwise if the RFC5322.From was replaced we would have no issues with ADSP. As I tried to say tactfully in the draft, mailing lists have worked just fine for 40 years, so if DKIM or ADSP don't work with mailing lists, it's not because the lists are broken. ADSP seems to be carrying on the SPF tradition of claiming that it's everyone else's fault that it doesn't work. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
On 12 May 2011, at 06:47, John R. Levine wrote: I think You miss to state the important point that MLMs usually preserve the RFC5322.From when sending the email to the subscribers except in digest mode where it replaces it by the list-owner(?) email. This is why ADSP fails, otherwise if the RFC5322.From was replaced we would have no issues with ADSP. As I tried to say tactfully in the draft, mailing lists have worked just fine for 40 years, so if DKIM or ADSP don't work with mailing lists, it's not because the lists are broken. I think I agree with this. I get very little spam from mailing lists, and very little spam purporting to be from mailing lists that I subscribe to. ADSP seems to be carrying on the SPF tradition of claiming that it's everyone else's fault that it doesn't work. On the other hand, I still get a lot of spam. To me, that's prima facie evidence that email needs fixing. I use, and like, the additional information that SPF publishers give me. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
On 5/11/2011 1:35 PM, John Levine wrote: It's unnecessary and unwelcome to call what other people write stupid. FYI, that section is taken verbatim from the MLM draft that Barry sent off yesterday. I guess now we know who read it and who didn't. He was just following instructions: On 5/11/2011 10:36 AM, John R. Levine wrote: ... but you should blame me for the whole thing, borrowed or otherwise. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
John Levine wrote: FYI, that section is taken verbatim from the MLM draft that Barry sent off yesterday. I guess now we know who read it and who didn't. Dave CROCKER followed up: He was just following instructions: On 5/11/2011 10:36 AM, John R. Levine wrote: ... but you should blame me for the whole thing, borrowed or otherwise. d/ For the record, the old MLM was read as well Levine's poison pill MLM. With no intent nor suggest the writer is stupid, writers do say stupid things and that paragraph was stupid then and it remains to be stupid as in a stupid manner; he had stupidly defined a one way ticket for DKIM. I have noted the issue before but I guess it didn't get any attention until it was called stupid - very funny. That said, FWIW, I do apologize it was given that attribute and I am sorry it was read with an ill-intent in mind. Everyone here are pretty smart and experience people. It would be stupid to think otherwise. We simply have different views, and unfortunate strong views residing at point ends of the spectrum. In strong opinion, even I would accept the single output modeling, you can't have a background description that says X is the only way, then have deviations of that X in the document and in other documents. I tried to suggest how make it both functionally and technically correct with the general statement that: X (DKIM) under Y (MLM) conditions can only work one way (RESIGN) by assigning Y trust when Z (Author Domain) has no policy against it. We are talking a special stream (MLM) that historically and inherently breaks the integrity of mail (in an industry acceptable manner). DKIM does not naturally fit into the MLM technology and thus the feasible Pottery Theorem solution is correct - resign. But I object to the idea it is an unrestricted resigning model only and I firmly believe it will harm the general wide best interest of the IETF mail community and DKIM itself if we allowed this to be the one way ticket. Is that any more clear? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
I have noted the issue before but I guess it didn't get any attention until it was called stupid - very funny. It got attention; it didn't get consensus. Sometimes, people don't respond because they don't agree. Sometimes what one needs are people agreeing, and it isn't necessary for people to post with their disagreement. In any case, this issue is finished for now. The MLM document is in IETF last call. Discussion will go to the IETF discussion list. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
Ian Eiloart wrote: On 12 May 2011, at 06:47, John R. Levine wrote: As I tried to say tactfully in the draft, mailing lists have worked just fine for 40 years, so if DKIM or ADSP don't work with mailing lists, it's not because the lists are broken. I think I agree with this. I get very little spam from mailing lists, and very little spam purporting to be from mailing lists that I subscribe to. And I see a lot of spam in some of the list I have subscriptions to. Most of it is trapped though and discarded. ADSP seems to be carrying on the SPF tradition of claiming that it's everyone else's fault that it doesn't work. On the other hand, I still get a lot of spam. To me, that's prima facie evidence that email needs fixing. I use, and like, the additional information that SPF publishers give me. Well, Levine never liked SPF since MARID, yet the world thought otherwise (especially in the high-value domain world) and have deployed SPF en masse. I think his arguments have been inconsistent (see ending comment below). The problem is that DKIM was exclusive redesigned to work for a natural integrity breaking MLM and unrestricted resigner market and you can only technically do this by ignoring all claims of originating integrity and originality and authenticity behind it. John is saying for the most part: For 40 years, we (MLM) has been ignoring the originating integrity and originality of mail, ergo, any new mail claims of mail security and authenticity can be naturally ignored too. Speaking as a MLM vendor, there is something functionally wrong with logic. Its ok to say we being it one way for a long time, but its not ok to say I want to add something new and break inherent rules that come with the new. Finally, DKIM event without ADSP also has the same arguments stated against SPF. DKIM + TRUST is what the key WG cogs want using a single output. This also comes with a same similar concept of the SPF policies: DKIM + Expected signer : PASS (-ALL) DKIM + Unknown signer : Unknown (?ALL) or SoftFail (~ALL) For example: Suppose I have in my local receiver DKIM trust tables (a POLICY concept or ACL idea) to trust mail from signer MyBank.com: TRUST s=mybank.com Thus all mail signed by mybank.com would be a locally certified PASS concept. But what the faults? First, Levine claims that whats good for me, is good for all users on my system. So any mail signed by mybank.com should be trusted at a SYSTEM LEVEL! Thats a problem right there, but not unreasonable to have this scenario base on a Local Receiver Policy. Realistically, I will probably only expect mail from MyBank.com to be for me or for certain users who are allowed to make the unique vendor/user claim. So perhaps my local version of the trust table might be: TRUST s=mybank.com to:hsan...@isdg.net or for the AUID advocates (defined as it is technically defined): TRUST s=mybank.com i=hsan...@isdg.net.mybank.com This would be based on the BANK DKIM Policy of telling me to set that up which could come with a BANK DKIM POLICY based on Originating Author Domain: TRUST s=mybank.com odid=users.mybank.com So if a message comes in purported signed mybank.com but doesn't with any of the user or author domain policies, you have what now? FAIL SOFTFAIL UNKNOWN DKIM is the the same boat as any other policy based technology yielding indeterminate results. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM and mailing lists
I realize it's a little late, but here's what I think the MLM document should have said: http://www.taugh.com/draft-levine-mlm-minus-00.html I shamelessly stole Murray's intro sections, but you should blame me for the whole thing, borrowed or otherwise. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
John R. Levine wrote: I realize it's a little late, but here's what I think the MLM document should have said: http://www.taugh.com/draft-levine-mlm-minus-00.html I shamelessly stole Murray's intro sections, but you should blame me for the whole thing, borrowed or otherwise. John, you never cease to surprise me! Change that stupid section 2. background last paragraph to one tells the truth and it is 100% compatibility with everyone needs, consistent with all documents and you got my endorsement in this simplified, straight to the point, more realistic MLM informative I-D. How about this paragraph replacing text (edit at will): DKIM provides a mechanism which allows for the separation of the authorized relationship of the identity of the message signer from any other agent or user identity, including the originating author domain. This is vital issue in MLM environments which is known to take control of submissions with altered distributions. This requires MLM to have some independent and autonomy in deciding how to resign list distribution in order to restore DKIM integrity and pass signer trust to the MLM list domain. That original background last paragraph text just isn't the truth and it doesn't fit with the other discussions regarding Author Domains and references to ADSP - can't have it both ways. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
Change that stupid section 2. background last paragraph to one tells the truth and it is 100% compatibility with everyone needs, It's unnecessary and unwelcome to call what other people write stupid. It's also the case that while you think it doesn't tell the truth, it seems to me that everything in that paragraph is an accurate assessment of what's in the DKIM base spec, and agrees with rough consensus of the working group. Barry, as ... as Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
It's unnecessary and unwelcome to call what other people write stupid. FYI, that section is taken verbatim from the MLM draft that Barry sent off yesterday. I guess now we know who read it and who didn't. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
Barry Leiba wrote: Change that stupid section 2. background last paragraph to one tells the truth and it is 100% compatibility with everyone needs, It's unnecessary and unwelcome to call what other people write stupid. I can see where calling it stupid is unwelcome. It's also the case that while you think it doesn't tell the truth, it seems to me that everything in that paragraph is an accurate assessment of what's in the DKIM base spec, and agrees with rough consensus of the working group. I don't agree, it is technically incorrect with false conclusions that is unmatched anyway else and if that wasn't true than you won't need any discussions regarding Author Domains for this document for that matter. After all, that was the original purpose of this MLM I-D effort when many people had express concerns with the MLM/DKIM conflicts and lack of respect for ADSP and me showing real examples for the interoperability problem - it was only then that gave life to this document. Rough consensus in the group really doesn't match the many concerns over the years with this issue and its unfortunate they aren't around anymore to express their input. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 11, 2011 2:34 PM To: Barry Leiba Cc: DKIM List Subject: Re: [ietf-dkim] DKIM and mailing lists After all, that was the original purpose of this MLM I-D effort when many people had express concerns with the MLM/DKIM conflicts and lack of respect for ADSP and me showing real examples for the interoperability problem - it was only then that gave life to this document. That is not in fact the purpose of the MLM I-D effort. Its focus, instead, was to discuss how DKIM signatures have survivability issues when transiting MLMs, and how ADSP can impact MLM operation, and how MLMs might be encouraged to play nicer in a DKIM world. And it does all of those things. The discussions about identities in a message were actually largely removed because they can't be substantiated. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
On 5/11/2011 2:41 PM, Murray S. Kucherawy wrote: After all, that was the original purpose of this MLM I-D effort when many people had express concerns with the MLM/DKIM conflicts and lack of respect for ADSP and me showing real examples for the interoperability problem - it was only then that gave life to this document. That is not in fact the purpose of the MLM I-D effort. Since this has all been discussed multiple times before, I suggest it /not/ be discussed further, yet again. The outcome won't be any better this time than it has been in the past and there's no new material. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 11, 2011 2:34 PM To: Barry Leiba Cc: DKIM List Subject: Re: [ietf-dkim] DKIM and mailing lists After all, that was the original purpose of this MLM I-D effort when many people had express concerns with the MLM/DKIM conflicts and lack of respect for ADSP and me showing real examples for the interoperability problem - it was only then that gave life to this document. That is not in fact the purpose of the MLM I-D effort. Its focus, instead, was to discuss how DKIM signatures have survivability issues when transiting MLMs, and how ADSP can impact MLM operation, and how MLMs might be encouraged to play nicer in a DKIM world. Isn't that just generality stated? Geez! And it does all of those things. Then the background statement as it written is wrong. The discussions about identities in a message were actually largely removed because they can't be substantiated. Based on what you BELIEVE can't be substantiated on a ROUGH consensus basis only which does not remove the substantiated claims, years of proof of concept and the fact the APIs support it since day one, implementations such as support it, including major corporations like Microsoft support it! So it is patently false that it can't be substantiated. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
Shutting people up and scaring them out the WG hasn't worked for you very well nor removed the concerns. hm, on second thought, I guess it has worked for you to rubber stamp documents even when broken. This has been a long WG concern and problem to have out of scope considerations injected in DKIM that conflicts with everything else that was written. And for the record, I can't blame me - others have long stated the concerns of a single output focus has damaged DKIM - a single out that has no universally wide receiver payoff and non-existence (Trust Assessor) requirement. Where are these batteries required? Dave CROCKER wrote: On 5/11/2011 2:41 PM, Murray S. Kucherawy wrote: After all, that was the original purpose of this MLM I-D effort when many people had express concerns with the MLM/DKIM conflicts and lack of respect for ADSP and me showing real examples for the interoperability problem - it was only then that gave life to this document. That is not in fact the purpose of the MLM I-D effort. Since this has all been discussed multiple times before, I suggest it /not/ be discussed further, yet again. The outcome won't be any better this time than it has been in the past and there's no new material. d/ -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and mailing lists
I think You miss to state the important point that MLMs usually preserve the RFC5322.From when sending the email to the subscribers except in digest mode where it replaces it by the list-owner(?) email. This is why ADSP fails, otherwise if the RFC5322.From was replaced we would have no issues with ADSP. As I tried to say tactfully in the draft, mailing lists have worked just fine for 40 years, so if DKIM or ADSP don't work with mailing lists, it's not because the lists are broken. ADSP seems to be carrying on the SPF tradition of claiming that it's everyone else's fault that it doesn't work. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] dkim and mailing lists
Should DKIM transit a mailing list? if a message arrives at a list manager the author/sender theoretically should be a pre-qualified by whatever means used to be a member of that list. Any recipient that has subscribed to that list has a reasonable expectation that any message addressed to the list would be interesting. With that in mind all signatures should be discarded, resigned by the dkim aware mailing list then forwarded on as if it is a new mail message. Now whether a dkim aware mailing list should follow adsp practices is worth discussing. thanks, Bill Oxley On Aug 10, 2010, at 10:06 AM, Dave CROCKER wrote: On 8/9/2010 11:53 PM, Murray S. Kucherawy wrote: Since Dave suggests a fissioning of this document into two or more, I'll hold off applying his until after that's done and some discussion about it has been had. I'm a fan of getting the mix and balance of documents right. Extra documents are a hassle, but a single document that mixes agendas is too. I was a bit surprised to make the suggestion that this doc get split. 1. Are there different topics? If so, what are they and which should be pursued? The working groups needs to comment on this. I think I saw 3 different topics, and that there has already been a bit of discussion about this. The topics are: a. Handling DKIM messages transiting a Mailing List Manager b. Trust-based enhancements for Mailing List Managers based on DKIM c. Best practices for Mailing List Managers The first is/was the official goal of the current work. The latter two have emerged. Neither is formally within scope of the working group, although b. is a natural addition. Note, however, that it is formal protocol specification work and we need to worry about adoption first -- who needs to adopt it and why do we think they will? c. is not reasonably in scope; I do not see any way to justify it within this working group, in spite of there having been some good discussion. 2. If a split is appropriate, how should the existing content be divided? I vote for letting Murray handle this. (You're welcome, Murray.) So, the first question is intended to get some working group consensus, before Murray puts in the effort of dividing things up. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] dkim and mailing lists
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Tuesday, August 10, 2010 7:16 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: [ietf-dkim] dkim and mailing lists Should DKIM transit a mailing list? if a message arrives at a list manager the author/sender theoretically should be a pre-qualified by whatever means used to be a member of that list. Any recipient that has subscribed to that list has a reasonable expectation that any message addressed to the list would be interesting. With that in mind all signatures should be discarded, resigned by the dkim aware mailing list then forwarded on as if it is a new mail message. Now whether a dkim aware mailing list should follow adsp practices is worth discussing. Bill, Have you read the draft? A lot of this is already discussed in there. If you have specific feedback about the text that's in there already, that would be really helpful. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
Let me try to summarise this thread so we don't have to do it all again (or at least not too often:-) Please correct where I've missed things, or gotten stuff wrong. Where a particular message seems to contain a bunch of potentially useful text, I've included a link to the archive. Note that I don't mean that I think every word of the linked message is perfect, more that a document author might find it useful to go back to those messages. Stephen. The thread was kicked off by this post: [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001753.html] Discussion ensued: - Mailing list servers can be thin (where they don't disturb existing DKIM signatures) or thick (where they do disturb a pre-existing signature). There might even be intermediate cases but both approaches are reasonable and its not our job to argue for one over the other. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001762.html] - There is merit in mailing lists DKIM signing messages - verifiers might be willing to whitelist some such mailing lists. This applies regardless of whether or not the message sent to the list was originally DKIM signed or not. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001818.html] - If the message sent to the list was originally signed, there can be merit in preserving the signature so that the original signature on the message received from the mailing list could still be verified. - There are arguments that supporting both original and mail-list signatures would be useful, but there are also difficulties with this in particular adding the mail-list signature will often break the original signature. (If the mail-list signature only covers the content and certain headers like List-Id then this might work better). - Some particular headers may cause difficulty when a mailing list is re-signing an originally signed message (e.g. Reply-To, Subject). [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001821.html] - The l= approach to modifications performed by mail lists might, or might not, be worthwhile. [Couldn't find that post when I went looking;-(] - There may be merit in a mailing list considering the SSP of the original message's domain before deciding how to process the message. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001774.html] - SSP was suggested as being a useful check to make during subscription processing. (Although there was no feedback on the suggestion, or else I missed it.) [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001816.html] - There may be implementation issues that warrant consideration since mail-list code may be separate from the inbound and/or outbound mail handling code = processing of DKIM could be happening in different code bases. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001774.html] - We have a few different (though not necessarily conflicting) proposals for MUST/SHOULD/MAY language that can be considered later on. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001781.html] [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001800.html] [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001810.html] - There are reasons to not add 1 From to the message. [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001825.html] My conclusions:- - There are conflicting possibilities allowed by the above, but each of the possibilities may be sensible. In other words, there is not a unique correct design that meets all of the above (and other real world) requirements. So the WG probably need to flesh out a few practical use-cases and try satisfy those. - Are there any documented surveys on the things that mail lists actually do? If so, I'd be interested in that for my own education. But we might also be able to use such a document to decide which use cases to try support. I don't think we need to get the ultimate survey document, but if there's something we can all agree lists some good-to-support cases that'd be enough. Of course, since no-one's posted a link that I spotted so far, that probably doesn't exist. ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
On Jan 23, 2006, at 7:35 AM, Stephen Farrell wrote: Please correct where I've missed things, or gotten stuff wrong. Where a particular message seems to contain a bunch of potentially The mailing-list summary missed what should be serious concerns related to replay abuse, whether it is a list-server, free email- address provider, newsletter, or large domain. Even aggressive rate restrictions, outbound filtering, and banishing offending email-addresses will not offer an effective solution for an abusive replay problem. When a common key is used, key revocation is not practical. Per-user keys or per-user policies will impact the related overhead, as both approaches will tend to overwhelm caching. A bad actor is capable of sending replays from tens of thousands of sources simultaneously. The use of a user policy as a means of control also unfairly impacts use of the email-address in cases where the recipient is the bad actor. Even rapid responses from abuse reporting to pushing out altered key or policy with extremely short TTLs will still likely be too slow to be an effective deterrent. Short TTLs with per-user records will likely increasing the related overhead further still. Eliot suggested list-servers (free email-address providers, newsletters, e-invites, photo-kiosks, etc.) be picky about who they allow to use their services, but did not provide a description of that process. The current practice exercised by list-servers is the use of double opt-in and banning those abusing their privileges. Neither of these approaches protects the reputation of the list- server signature, or the reputation of the signing domains that pass through the list-server without the signature being overlaid with verification results. A bad actor can issue a series of links, much as seen in the prior message, which look okay until being used in an abusive replay. When there is replay abuse, how should the sender react? What obligations do list-servers have with respect to their participants in regards to a replay abuse problem that may affect the reputation the signing domains sent through the list? -Doug P.S. Could you enclose your links in rather than [], thanks. ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
Douglas Otis wrote: On Jan 23, 2006, at 7:35 AM, Stephen Farrell wrote: Please correct where I've missed things, or gotten stuff wrong. Where a particular message seems to contain a bunch of potentially The mailing-list summary missed what should be serious concerns related to replay abuse, whether it is a list-server, free email-address provider, newsletter, or large domain. To whatever extent replay is an issue that we need to tackle, its an issue that's not specific to mailing lists, which is why I omitted it here. Stephen. ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
On Jan 23, 2006, at 10:03 AM, Stephen Farrell wrote: To whatever extent replay is an issue that we need to tackle, its an issue that's not specific to mailing lists, which is why I omitted it here. Unless or until there is a better solution, a signature overlay strategy may impact conclusions reached in the handling of thin list-servers. It could be prudent, although perhaps somewhat premature as this strategy has not been reviewed by the group, to offer a precaution in this regard. -Doug ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
From: Stephen Farrell - Are there any documented surveys on the things that mail lists actually do? If so, I'd be interested in that for my own education. But we might also be able to use such a document to decide which use cases to try support. I don't think we need to get the ultimate survey document, but if there's something we can all agree lists some good-to-support cases that'd be enough. Of course, since no-one's posted a link that I spotted so far, that probably doesn't exist. Do you mean a survey of common mailing list features, or basic mailing list mail flow operations? H, ok. I am seeing a trend here that is kinda throwing me for a loop. For all intent and purpose, the proposed DKIM/SSP protocol or any similar protocol applies to all internet email operations, regardless of what specific middle ware you have. We can't selectively choose one mail processor type over another. They all have to work the same way in relationship to the DKIM/SSP protocol. We have a pretty wide spectrum of products for mail operations, from old UUCP, SMTP, List Servers, News Servers, Gateways, Groupware, News/Email Gates, Fidonet, QWK, offline readers, online readers, etc, etc. If we plan to add DKIM/SSP, it has to work and interface consistently with everything where it is applicable and required. One can't break the other, and one can't benefit while the other does not. Again, if it is applicable. The best we can do is to provide a basic EMAIL security technical protocol, of course, with good engineering hindsight, and let the authors fit it into whatever mail operations they have following 100% the specs and guidelines. Maybe that is what you are looking for, a summary of general mail operations? I just hope that LS operations does not become the exception to the DKIM/SSP specifications. Note, I'm not saying that the specs should not suggest guidelines as to what a LS author might consider. That would be great. i.e. as a possible suggestion: List Servers MAY consider restricting the type of DKIM policies it wishes to honor. But under no circumstance, it MUST NOT break the integrity of DKIM messages. The only squeaky issue is the idea of stripping for policies that might allow it. This might be acceptable because network control lines (headers) has always traditionally been under the control of the network mail processors. But is stripping acceptable for a DKIM domain? This is a big item because it will help define the complexity of List Server DKIM processing. If we declare no stripping of existing signatures, even if an optional policy is used, then that forces the hand (a particular design requirement) we list servers authors have to do. Allowing us to strip will simplify a big part of the Relaxed Policies issues. Anyway, List Server or not, the same applies to any other middle ware processor. How about Mail Filter Agents (MFA)? Automated responders? and others. They all need to follow DKIM/SSP in the same way. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
Hector Santos wrote: From: Stephen Farrell - Are there any documented surveys on the things that mail lists actually do? If so, I'd be interested in that for my own education. But we might also be able to use such a document to decide which use cases to try support. I don't think we need to get the ultimate survey document, but if there's something we can all agree lists some good-to-support cases that'd be enough. Of course, since no-one's posted a link that I spotted so far, that probably doesn't exist. Do you mean a survey of common mailing list features, or basic mailing list mail flow operations? I'm not sure, probably the former. Let me try explain again. Mailing lists (and others) do things that break signatures, for good, bad and indifferent reasons. If we want to define a protocol that allows for both original and mailing list signatures, so that the one doesn't have to interfere with the other, then we have to have some understanding of how lists (and others) break signatures. Probably a bunch of people on this list already know all about this. I don't, at least not sufficiently well to judge some of the options. So I'm asking for a pointer to the how mailing lists break signatures report, if it exists so I can learn a bit more. Now, if that did exist, it might also be useful to folks who already know all about this area in that it would give us a way to say if you do this it breaks when the message is handled by things like those in section 9.1.32, or, we defined this field so that you can still verify even if you go through a server like that in section 8.2.3 which is fairly common. Being able to point at bits of such a report might help us go quicker. However, I can well imagine that this doesn't exist in any usable form, but it'd be nice if it did. Stephen. ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
- Original Message - From: Douglas Otis [EMAIL PROTECTED] On Jan 23, 2006, at 10:03 AM, Stephen Farrell wrote: To whatever extent replay is an issue that we need to tackle, its an issue that's not specific to mailing lists, which is why I omitted it here. Unless or until there is a better solution, a signature overlay strategy may impact conclusions reached in the handling of thin list-servers. It could be prudent, although perhaps somewhat premature as this strategy has not been reviewed by the group, to offer a precaution in this regard. Doug, Thin, slim, fat or gross, its all the same. Its common sense. If you believe a replay problem exist with DKIM/SSP, then you have to believe the replay problem exist now without it too. So what is the difference? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
Jim Fenton wrote: Thanks for the summary, Stephen. Stephen Farrell wrote: - There are arguments that supporting both original and mail-list signatures would be useful, but there are also difficulties with this in particular adding the mail-list signature will often break the original signature. (If the mail-list signature only covers the content and certain headers like List-Id then this might work better). I didn't find the original mention of this, but I'm not clear on why adding a mail-list signature would break the original. It's just an additional header field, and unless the original signature was constructed to prevent that (by including DKIM-Signature in the h= headers) there shouldn't be a problem. What might break the original signatures is the modifications to the message that necessitated the mail-list signature. You're right. Better if I'd said The mailing list may change fields of the message before signing, thus breaking the original signature. - Some particular headers may cause difficulty when a mailing list is re-signing an originally signed message (e.g. Reply-To, Subject). [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001821.html] I didn't get quite this meaning from Frank's message. I don't know what the difficulty is; the list just has to make any modifications it's going to make before it re-signs. Like Frank, I would prefer if lists didn't do a lot of things they currently do to messages. Nevertheless, I realize that some lists are advertising-supported, so it's a behavior we're going to have to deal with. Agreed. Better if I'd said: Changes to some particular headers (e.g. Subject, Reply-To) and/or the body may cause difficulty when a mailing list is re-signing an originally signed message. Which is almost the same as the above I guess and probably not worth saying twice:-) Cheers, Stephen. ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
Jim Fenton: Thanks for the summary, Stephen. Stephen Farrell wrote: - There are arguments that supporting both original and mail-list signatures would be useful, but there are also difficulties with this in particular adding the mail-list signature will often break the original signature. (If the mail-list signature only covers the content and certain headers like List-Id then this might work better). I didn't find the original mention of this, but I'm not clear on why adding a mail-list signature would break the original. It's just an additional header field, and unless the original signature was constructed to prevent that (by including DKIM-Signature in the h= headers) there shouldn't be a problem. What might break the original signatures is the modifications to the message that necessitated the mail-list signature. When the list server's DKIM signature covers a FROM: header with an address in some unrelated domain, would not this be considered a third-party signature? This would be avoided by having the list sign only the headers that identify the list. Wietse ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
- Original Message - From: Jim Fenton [EMAIL PROTECTED] To: Stephen Farrell [EMAIL PROTECTED] I didn't find the original mention of this, but I'm not clear on why adding a mail-list signature would break the original. It's just an additional header field, and unless the original signature was constructed to prevent that (by including DKIM-Signature in the h= headers) there shouldn't be a problem. What might break the original signatures is the modifications to the message that necessitated the mail-list signature. Right, so there are 3 designs a LS can take when content modifications is desired by the list admin: - Strip, No Resign (NEUTRAL, WEAK) - Strip, Resign(NEUTRAL) - Resign (NEUTRAL, STRONG) Example: 1) An email is submitted to the list from a domain with a WEAK SSP. The email is signed by the original domain. If the LS is intent on content change, then its only recourse is a STRIP. If the email was not signed, then the LS can do what it wants as normal but *not* resign it. 2) An email is submitted to the list from a domain with a NEUTRAL SSP. The email is signed by the original domain. If the LS is intent on content change, then it STRIP and/or RESIGN it. If the email was not signed, then the LS can do what it wants as normal including resigning it if it wants. 3) An email is submitted to the list from a domain with a STRONG SSP. The email is required to be signed by the original domain. If the LS is intent on content change, then the LS can only RESIGN it. It can not strip it. So the logic is established and consistent with the SSP protocol. The downlinks verifications will be safe as well. - Some particular headers may cause difficulty when a mailing list is re-signing an originally signed message (e.g. Reply-To, Subject). I didn't get quite this meaning from Frank's message. I don't know what the difficulty is; If the DKIM signature includes the hashing if a Reply-To: header, then this will cause a problem for modern LS that use the Reply-To: as RFC-ready MUA ergonomic kludge to resolve the issue of layman users who naturally hit the reply button with the intent of replying back to the list, but inadvertingly send it directly to the author. So LS offer the options to fix the Reply-To: field as the List Address and this makes it very easier for users to naturally reply back to the list. Otherwise, the user has to be aware of clicking Reply to All (like I had to do now) in order to get the list address among the reply list. But this causes redundancy with multiple copies, which I really do not want, but I am too lazy to remove the extra addresss :-) This is an basically a RFC-ready Mail Reader issue that is trained on a EMAIL vs NEWS concepts where the natural action for the reply button is: EMAIL - REPLY-TO:, FROM: NEWS - ALL Without a Reply-To:, you have to click the unnatural Reply to All button in other to get the list address. Anyway, if the hash includes a Reply-To: then it breaks this feature offering of a List Server. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
On Mon, Jan 23, 2006 at 02:30:55PM -0500, Wietse Venema allegedly wrote: When the list server's DKIM signature covers a FROM: header with an address in some unrelated domain, would not this be considered a third-party signature? It could be. It's certainly something concrete that a verifier can act on. We merely need to describe the desired actions. This would be avoided by having the list sign only the headers that identify the list. That presents the same sort of risks that -l does. I would must prefer the list sign the whole content and the spec define the verifier semantics when a 3rd party signature is seen with, eg, a List-ID covered by the second signature. If well defined, those semantics should be able to achieve the functional affect of your suggestion without the risk of sending unsigned material. Mark. ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
On Jan 23, 2006, at 11:55 AM, Hector Santos wrote: Right, so there are 3 designs a LS can take when content modifications is desired by the list admin: - Strip, No Resign (NEUTRAL, WEAK) - Strip, Resign(NEUTRAL) - Resign (NEUTRAL, STRONG) This appears this is using terminology that does not exist in the SSP draft, and related to a dropped policy described here as (NEUTRAL, WEAK), 'o=?'. -Doug ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
Stephen, Ok, I see. I can provide my feature list. But all I was saying is that, why should it matter? :-) DKIM/SSP is an RFC 822 extended EMAIL protocol. Mailing List or List Servers and all other mail processors are augmented technology that fit on top of the 822/821 model So regardless of a extended mail processor features, its I/O, outer edge, must be consistent with the expectations of the email system. So you have: AUTHOR/822 whatever RECIPIENT/822 Whatever could of been a dozen transformations. Who knows!? But the governing rule of thumb is that what went in, should be what comes out and we shoot for 100% maintaining the integrity. So lets make Whatever a group of items that includes, all the basic parts, including a List Server as well: MUA/MTA -- | MSA -- MFA -- LS -- MTA-- MDA | -- MUA No matter what features you have, the input must equal the output. That's the goal in all this. The MUA/MTA comes with a DKIM/SSP header. Nothing in the middle should break it, and its known to do something that could break it, then either the adjusts itself to DKIM or not. But to do it correctly, it has to adjust, especially if something in the middle is changing content. Do you really want a list of features? g The basic features of a general list server are pretty simple: - Subscription control - open, close, open/confirm - Submission Control/Options - Allow Posting? - Allow Any Poster? - Moderated? - Stripping - Attachments - HTML - Expansion/Distribution Options - Set Reply-To Field to List Address - Keep Original To: Address - Auto-Unsubscribe for failed transactions - Body Headers/Footers - Additional 822 Headers - Digest - Frequency - Size - Request Files - Help via EMAIL - Others options Pretty basic stuff, and the above is a short list, but I tried to show some items that might affect DKIM/SSP. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com --- Original Message - From: Stephen Farrell [EMAIL PROTECTED] To: Hector Santos [EMAIL PROTECTED] Do you mean a survey of common mailing list features, or basic mailing list mail flow operations? I'm not sure, probably the former. Let me try explain again. Mailing lists (and others) do things that break signatures, for good, bad and indifferent reasons. If we want to define a protocol that allows for both original and mailing list signatures, so that the one doesn't have to interfere with the other, then we have to have some understanding of how lists (and others) break signatures. Probably a bunch of people on this list already know all about this. I don't, at least not sufficiently well to judge some of the options. So I'm asking for a pointer to the how mailing lists break signatures report, if it exists so I can learn a bit more. Now, if that did exist, it might also be useful to folks who already know all about this area in that it would give us a way to say if you do this it breaks when the message is handled by things like those in section 9.1.32, or, we defined this field so that you can still verify even if you go through a server like that in section 8.2.3 which is fairly common. Being able to point at bits of such a report might help us go quicker. However, I can well imagine that this doesn't exist in any usable form, but it'd be nice if it did. Stephen. ___ ietf-dkim mailing list http://dkim.org
Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)
Signing the From: header is currently required, but suppose it weren't: Then bad guys can take list messages and resend them with forged return addresses and still have a valid signature. Does anyone think this is a good idea? I think the way we all expect to use DKIM is that a message comes in, we check the signature, then we look up the signing domain in some sort of reputation system, be it a local whitelist or something fancier, then if the reputation is good we accept the mail, if it's bad we reject it, and if there's no reputation, we fall back and do what we would have done otherwise. With this model, I have a lot of trouble envisioning a scenario where I would want list mail signed by anything other than the list. If there is old list software that doesn't sign and it happens to pass signed messages, fine, but if the list software is DKIM aware at all, I want it to sign so I can recognize list mail. R's, John ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
Good analysis. A few comments embedded below. Aumont - Comite Reseaux des Universites wrote: Lets try to identify the different possible cases when a signed message is received by the mailing list server. There are 3 actions that the mailing list server can do : - 1/./. : Add a mailing list server signature or not - ./1/. : Remove existing signature or not - ././1 : Modify the message in a way that breaks DKIM signatures or not So we must examine benefits and problems for 8 cases : --- 0/0/0 : -The list server does not add a signature/ -does not remove the existing signature / -does not modify the message / The message is distributed with a valid signature. The original sender reputation will be used by final RCPT to evaluate the message : the mailing list server is transparent forwarder but final receipient can't use DKIM signature in order to prove that the message was relayed by the list. --- 0/0/1 -The list server do not add a signature/ -do not removes the existing signature,/ -modify the message,/ BAD : the message is distributed with invalid signature, this valid message will probably be suspicious for many rcpt --- 0/1/0 and 0/1/1 -The list server does not add a signature/ -removes the existing signature, / -does not modify the message or not The message is distributed unsigned. If the sender SSP specifies that all messages from this sender must be signed then this message is suspicious. Case 0/0/1 should be included here as well, because invalid signatures need to be considered exactly the same as missing signatures, neither better nor worse. See http://www.mhonarc.org/archive/html/ietf-dkim/2006-01/msg00085.html for the rationale for this. --- 1/0/0 -The list server adds a signature. -does not remove the existing signature,/ -does not modify the message A) the mailing list server adds a signature i= (signer) and From: are different. The signature may be invalid if the sender SSP does not allow third party signature. B) Possible scenario for replay attack A BAD actor could exploit a un-moderated opt-in mailing list in order to subscribe, send a spam to the list, receive its own spam signed by the listserver in order to replay it. This would affect the list server reputation but also the original sender reputation unless he's signature is removed or altered by the distribution processus. We shouldn't make any assumptions about the way the reputation system operates; remember that it could be a local, manually-maintained white list as well. Accreditation could be used here as well, especially by larger list providers. A and B are true for any of 1/x/x (if the original message is modified or not and if the original signature is removed or not). How can this signature be used by the final rcpt ? What is it usefull for ? It can be used to prove that the message was relayed via the mailing list but usualy, when this is needed the list archives can prove it. Checking the archives works fine after the fact, but doesn't help in the handling of the message. If I want to treat certain messages preferentially, perhaps because they come from the ietf-dkim mailing list, I'd like to make that decision based on a signature. Active participants in a list are likely to treat the list preferentially, and it's very easy to see who they are. So an attacker might try to spoof the list to get someone to read a message. The list reputation can be used but to my mind, the original sender reputation seems to be the reputation that should be used. Other cases are variant of 1/x/x and 0/x/x that cumul problems from both categories. At the end, I can't identify the reason why a mailing should add a signature to a message, may be because I didn't understand how third party signature can be used with a signer (i=) different from the message Sender. Also I can't see how MUA could deal with message with multiple From: . It is definitively not a common usage and it will not be accepted by users because it suppose some modification in MUA. We should stay away from multiple From: addresses; MUA behavior is inconsistent (we have done a few experiments). -Jim ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
- Original Message - From: Hallam-Baker, Phillip [EMAIL PROTECTED] List traffic is one of the few cases where the recipient has affirmatively opted in to receive it. Which presents the #1 design change to a list subcription processor in order to close a DKIM/SSP threat entry point. I agree with Mark, mail agents should be processing identified list traffic in a very different manner to ordinary unsolicited traffic. I basically see three basic models: - address expander, From, Return Path remains the same. This offers passthru (no content change) operations. Typically, no separate storage. - address expander with content change, From, Return Path remains the same. Typically, no separate storage. - Address expander with content change and return path to a new List Management address agent. A separate storage is used to offer extended list features. John calls them Thin vs Thick. Cool, but they are really list expanders vs list servers because list expanders can be part of the SMTP process or POST SMTP mail filter process, which typically have nothing to do with a possible separate List Server process and/or application. We need to define rules for a compliant mailer so mailing list authors know what to code to. But the mailing lists that are going to bite us are the legacy ones that are not in compliance. The design issues we see for our List Server are: 1) Controlling the Subscription process to regulate restrictive DKIM/SSP policies. This basically means the NEVER, EXCLUSIVE policies, the most beneficial features of DKIM/SSP, will be used to blocked subscription attempts by these specific domain SSP declarations. The list server must offer this if it wishes to assist in securing domains. I have more about EXCLUSIVE in more detail below. 2) For us, the List Server will not perform any DKIM verification. Only SSP policy verification. Our SMTP inbound processor will perform this DKIM verification job. 3) New options to control the type of DKIM/SSP messages allowed. This could be a list of SSP declaration to be allowed by the LS mailing list setup. In my opinion, I don't realistically see DKIM domain implementaters interested in protecting their interest allowing relaxed DKIM SSP domains to be used on public mailing lists. It will promote exploitation with obviously broken integrity issues. Nonetheless, we do see a design that takes into account relaxed policies. The bottom line is what the domain declares for his SSP. Sender-Signing Policy (SSP): NONE (no policy) o=? WEAK (signature optional, no third party) o=~ NEUTRAL (signature optional, 3rd party allowed) o=- STRONG (signature required, 3rd party allowed) o=! EXCLUSIVE (signature required, no 3rd party) o=. NEVER (no mail expected) o=^ USER - NONE List Server MUST not sign the message. Period! It is can what it wants to the mail. But it must NOT sign it. May be part of restrictive SSP policy list for List Server if the mailing list owner REQUIRES all domain mail to be DKIM compliant. - WEAK (signature optional, no third party) May be part of Allowed SSP policy list for List Server. List Server MUST not sign the message. If the message is signed, options should offered to avoid content change. - NEUTRAL (signature optional, 3rd party allowed) May be part of Allowed SSP policy list for List Server. If the message is signed, options should be offered to avoid content change. If content change is required, LS must resign message as a 3rd party. If the message is not signed, the LS may choose to resign the message as a 3rd party. - STRONG (signature required, 3rd party allowed) May be part of Allowed SSP policy list for List Server. With the required signed message (SMTP verified), options should be offered to avoid content change. If content change is required, LS must resign message as a 3rd party. - NEVER (no mail expected) The LS Subscription Process should pre-empt this highly restrictive DOMAIN SSP declaration. The subscription process must handle both interactive and automated subscribe attempts. The automated attempt should be handled by the SMTP DKIM verifier. - EXCLUSIVE (signature required, no 3rd party) May be part of Allowed SSP policy list for List Server. Overall, similar to NEVER, the EXCLUSIVE policy should be subscription restricted. However, if the LIST SERVER can behave in a thin-like, address expansion, passthru no mail content change manner, then an EXCLUSIVE policy may be used for the mailing list. This brings up another potential SSP declaration that identified a different sender. This is closer to a STRONG policy but more about a particular 3rd party service taking control of the signing process. It might have to break SMTP rules by lying who the sender actually is. But as long as it is legal relationship and contract between domain owner and the actual signer, and it is consistent DKIM/SSP protocol, I
Re: [ietf-dkim] DKIM and mailing lists
(Sorry if what I say has been said, catching up on list mail) On January 18, 2006 at 16:53, Eliot Lear wrote: * Some guidance will need to be given about protection of the Subject:, Sender:, and any other headers that are protected. This goes beyond mailing list maintainers. If the signing domain protects either, then the mailing list system should be reticent to make changes. But should the signing domain sign these things in the first place? Mutation of header fields can be dealt with if the signer is able to save the contents of the fields it signs, and those saved versions are what is used during verification. Verifiers can then restore the save versions if verification passes. Currently, DKIM does not support this, and the saving capibility is limited. You do get into problems if multiple signatures exist where a given header field is different for each saved version for each signature. Such descrepencies could be dealt with if role information is provided. --ewh ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
On January 19, 2006 at 03:10, Hector Santos wrote: Sender-Signing Policy (SSP): NONE (no policy) o=? WEAK (signature optional, no third party) o=~ NEUTRAL (signature optional, 3rd party allowed) o=- STRONG (signature required, 3rd party allowed) o=! EXCLUSIVE (signature required, no 3rd party) o=. NEVER (no mail expected) o=^ USER ... Wouldn't be easier of the signer can assert a role so such checks are not necessary by a list server? If the list server makes no assertion against an (RFC-2822) originating address, it should be able to sign all messages it distributes. This would avoid list servers having to do SSP checks on each message and avoid the problems of bad implementations getting the logic wrong on when to sign and not to sign. From an audit, and accountability, perspective it would be useful that all list server software DKIM sign messages regardless of any originating-address-based SSP. This way, list server software can always assert what messages it distributes out regardless of the originating author/sender. --ewh ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
Earl Hood wrote: On January 19, 2006 at 03:10, Hector Santos wrote: Sender-Signing Policy (SSP): NONE (no policy) o=? WEAK (signature optional, no third party) o=~ NEUTRAL (signature optional, 3rd party allowed) o=- STRONG (signature required, 3rd party allowed) o=! EXCLUSIVE (signature required, no 3rd party) o=. NEVER (no mail expected) o=^ USER ... Wouldn't be easier of the signer can assert a role so such checks are not necessary by a list server? No. SSP is not for signed mail, it's for unsigned mail. If the list server makes no assertion against an (RFC-2822) originating address, it should be able to sign all messages it distributes. Correct. Nothing needed to provide this, though the i= isn't explictly saying what role (binding) it's providing (if any). This would avoid list servers having to do SSP checks on each message and avoid the problems of bad implementations getting the logic wrong on when to sign and not to sign. Receivers in general only need to do SSP if the message is unsigned. List servers are no different. From an audit, and accountability, perspective it would be useful that all list server software DKIM sign messages regardless of any originating-address-based SSP. This way, list server software can always assert what messages it distributes out regardless of the originating author/sender. Yep. That would indeed be very nice. Mike ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
On 01/19/2006 15:50, Michael Thomas wrote: Earl Hood wrote: On January 19, 2006 at 03:10, Hector Santos wrote: Sender-Signing Policy (SSP): NONE (no policy) o=? WEAK (signature optional, no third party) o=~ NEUTRAL (signature optional, 3rd party allowed) o=- STRONG (signature required, 3rd party allowed) o=! EXCLUSIVE (signature required, no 3rd party) o=. NEVER (no mail expected) o=^ USER ... Wouldn't be easier of the signer can assert a role so such checks are not necessary by a list server? No. SSP is not for signed mail, it's for unsigned mail. If it's a third party signature you still need to check SSP for EXCLUSIVE policy. If the list server makes no assertion against an (RFC-2822) originating address, it should be able to sign all messages it distributes. Correct. Nothing needed to provide this, though the i= isn't explictly saying what role (binding) it's providing (if any). This would avoid list servers having to do SSP checks on each message and avoid the problems of bad implementations getting the logic wrong on when to sign and not to sign. Receivers in general only need to do SSP if the message is unsigned. List servers are no different. ditto. Scott K ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
On 01/19/2006 17:50, Michael Thomas wrote: Scott Kitterman wrote: On 01/19/2006 15:50, Michael Thomas wrote: Earl Hood wrote: On January 19, 2006 at 03:10, Hector Santos wrote: Sender-Signing Policy (SSP): NONE (no policy) o=? WEAK (signature optional, no third party) o=~ NEUTRAL (signature optional, 3rd party allowed) o=- STRONG (signature required, 3rd party allowed) o=! EXCLUSIVE (signature required, no 3rd party) o=. NEVER (no mail expected) o=^ USER ... Wouldn't be easier of the signer can assert a role so such checks are not necessary by a list server? No. SSP is not for signed mail, it's for unsigned mail. If it's a third party signature you still need to check SSP for EXCLUSIVE policy. That doesn't alter what I said. You fundamentally cannot get out of making checks if you're missing a (first party) signature. That's SSP's purpose in life. OK. Then I misunderstood what you said, because I agree with that. Scott K ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
Hi Serge, Aumont - Comite Reseaux des Universites wrote: I think deployment of DKIM require a good support of DKIM by some of the major mailing list software. I am one of the author of Sympa mailing list software and I feel concerned by this. What a mailing list manager must do with DKIM ? I'll leave it for others who know more about mailing lists to give you a detailed answer, but at the BoF in Vancouver a couple of people made the good point that this WG should provide positive guidance for mailing list managers (and I guess developers) on, e.g. how to preserve DKIM signatures. So I expect that we'll try to either get a section of our overview deliverable or even a separate document written up on just this topic. However, its a bit early yet as you can imagine - hopefully that'll happen during/after the summer (all going well). ps : internet2.edu is just starting a working group about mailing list and DKIM If there's a public archive, it might be good to post the URL here once that's setup. Cheers, Stephen. ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
Doug, All, Douglas Otis wrote: http://tools.ietf.org/wg/dkim Some of these ideas are explored in this draft: http://tools.ietf.org/wg/dkim/draft-otis-dkim-options-00.txt Just a quick note in case anyone gets confused. As of now, *none* of the I-Ds listed on the tools page [1] are official DKIM WG drafts. The next revisions to the threats [2] and base [3] drafts will very soon become official WG documents, but the others remain, for now, as individual submissions (and I'm not sure how exactly they got listed on [1]). Regards, Stephen. [1] http://tools.ietf.org/wg/dkim [2] http://tools.ietf.org/wg/dkim/draft-fenton-dkim-threats-02.txt [3] http://tools.ietf.org/wg/dkim/draft-allman-dkim-base-01.txt ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
Mr. Aumont, I think deployment of DKIM require a good support of DKIM by some of the major mailing list software. I am one of the author of Sympa mailing list software and I feel concerned by this. What a mailing list manager must do with DKIM ? >From my understanding, the minimum is to preserve existing DKIM-Signature: header and not modify the message in a way that will alter the signature. For this issue, existing specification are quite clear (the difficulties are only related to headers that must be preserved where most availible libraries to modify message headers don't garanty headers lenght line and headers order). My memory matches that of Stephen's that this was an issue raised in the BoF, and that there was at least a tacit understanding that the matter would be addressed by the working group. I think there is already some guidance in the base draft. Thus far discussions seem to conclude along the following lines: If a mailing list manager is going to mangle a message that was signed it SHOULD resign it. This has all the UI problems that Doug mentioned in his message. The original spec had a length attribute just so that the text of a message could be preserved while some sort of mailing list blurb could be added. This is not a perfect solution. For one, if a mailing list manager is too smart and attempts to modify multipart/alternative components, the game is lost because you have to delve deep into the message to do that. Fortunately I don't know of mailing list software that does this. Some guidance here would be useful. Some guidance will need to be given about protection of the "Subject:", "Sender:", and any other headers that are protected. This goes beyond mailing list maintainers. If the signing domain protects either, then the mailing list system should be reticent to make changes. But should the signing domain sign these things in the first place? Eliot ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
I think deployment of DKIM require a good support of DKIM by some of the major mailing list software. I am one of the author of Sympa mailing list software and I feel concerned by this. What a mailing list manager must do with DKIM ? This is a rather contentious point. One model which we might call the thin model considers mailing lists to be essentially mail forwarders, so the identity of the mail is that of the original sender. This encourages list software to minimize the changes they make to mail on the way through to avoid breaking the signature, and perhaps to add its own signature on the way through. IIM had a few hacks intended to help this, a length to tell the recipient that the signature doesn't cover all of the message, and duplicated headers so that it can log what, e.g., the Subject line said before the list added a [listname] tag. I've never seen a persuasive description of what recipients are supposed to do with mismatched subject lines and chunks of unsigned trailing material but I expect people who think it's a good idea can explain it. Another way to be sure the signature stays intact would be to encapsulate every incoming signed message like a one-message MIME digest, but list reading users would probably not enjoy that. The other thick model considers the mailing list to be the originator of the message. In this model, the list software would strip off the signature from the incoming message, do whatever it does to the message, and re-sign it on the way out. This better matches modern list software that does things like reordering and deleting MIME parts and flattening HTML to plain text. There are a variety of plausible things it might do with the inbound signature, ranging from discarding it (on the theory that it's the list's reputation that matters for list mail, not the reputation of the contributors) to using a proposed header to log the fact that the inbound message had a good signature, and signing that. Depending on your view of what a list is and the way your list software works, you could try and implement either of these. One thing I can definitely promise is that people will have religious beliefs as deep and irrational as the ones they have about Reply-To: headers, so no matter what you do, you can be sure that someone will tell you that you are an idiot for not doing it his way. R's, John ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
Mark Delany wrote: Given the religion, I wonder whether both are entirely reasonable and leave the choice to the particular list implementor. I know I don't want to take on the argument of which is reasonable so applying guidance for both and for clients in the face of both is important. Particularly for whether or not you protect the Subject line and how at all to limit length, and or resign. There are some serious UI issues there. Eliot ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
Given the religion, I wonder whether both are entirely reasonable and leave the choice to the particular list implementor. Sure. I imagine that after a while it will become apparent which is more useful. I have my suspicions about which that will be, but I'm not confident enough of them to tell people not to try other approaches. R's, John ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
On Wed, Jan 18, 2006 at 11:38:53PM +0100, Eliot Lear allegedly wrote: Mark Delany wrote: Given the religion, I wonder whether both are entirely reasonable and leave the choice to the particular list implementor. I know I don't want to take on the argument of which is reasonable so applying guidance for both and for clients in the face of both is important. Particularly for whether or not you protect the Subject line and how at all to limit length, and or resign. There are some serious UI issues there. The very early thinking back at DK-00 was that a participating list might sign List-ID. The idea being that List traffic is distinctly different and that a verifier/UA might sensibly treat such traffic differently in the presence of a List-ID. Subsequent revisions went down the path of generalizing that to Sender. In retrospect, I'm not sure I'm a fan of that generalization as List traffic is so different that it need not be squeezed into a generalized category that otherwise is almost completely absent in real-life traffic. Mark. ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
Mark Delany wrote: On Wed, Jan 18, 2006 at 11:38:53PM +0100, Eliot Lear allegedly wrote: Mark Delany wrote: Given the religion, I wonder whether both are entirely reasonable and leave the choice to the particular list implementor. I know I don't want to take on the argument of which is reasonable so applying guidance for both and for clients in the face of both is important. Particularly for whether or not you protect the Subject line and how at all to limit length, and or resign. There are some serious UI issues there. The very early thinking back at DK-00 was that a participating list might sign List-ID. The idea being that List traffic is distinctly different and that a verifier/UA might sensibly treat such traffic differently in the presence of a List-ID. Subsequent revisions went down the path of generalizing that to Sender. The basic problem is that mailing lists are for all intents and purposes forging content when they don't change the From address but insist on adding trailers and subject line changes, blah, blah, blah. The best would be for them to stop doing that, but in an imperfect world we're going to be left with several unpleasant choices. John seems to be characterizing that as religious, but I think of it as wanting to have some semi-viable options short of demanding a flag day and going away pouting. In retrospect, I'm not sure I'm a fan of that generalization as List traffic is so different that it need not be squeezed into a generalized category that otherwise is almost completely absent in real-life traffic. Regardless of what the absolute numbers are, they are a significant fraction for the people who will be pounding out these standards. Or vetoing them. I'm all for not spending needless time on turd polishing, but I doubt its an option to present a rough-hewn turd either. Mike ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
On Jan 18, 2006, at 2:17 PM, Mark Delany wrote: On Wed, Jan 18, 2006 at 09:24:20PM -, John Levine allegedly wrote: This is a rather contentious point. One model which we might call the thin model considers mailing lists The other thick model considers the mailing list to be the Depending on your view of what a list is and the way your list software works, you could try and implement either of these. Given the religion, I wonder whether both are entirely reasonable and leave the choice to the particular list implementor. When DKIM signatures are used in conjunction with acceptance assessments, how are compromised systems within the AdmD or message replay abuse handled? Large domains and list-servers may become a major component of a message replay abuse problem. Access to a valid signature should be made increasing difficult to suppress the emergence of a replay abuse problem. When the administrator is informed there is a problem, there should be an ability to squelch the problem quickly. To be effective, this may require questionable messages receive special dispensation. The thick model, as John describes it, appears the most amenable for offering a solution. A general strategy for dealing with the replay abuse problem may be to adopt an overlay MDA signature with the obfuscation of the MSA/MUA and mediator signatures. A single character offering binding advice signing role added to the signature can simplify several aspects of this situation. Indicating the role of the signer also allows a strategy to ensure only a reasonable number of signatures are retained. -Doug ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
The basic problem is that mailing lists are for all intents and purposes forging content when they don't change the From address but insist on adding trailers and subject line changes, blah, blah, blah. I don't find forging to be a useful description of what mailing lists do. It's true, they send mail from someplace other than the normal place associated with the From: address, but that's no more forgery than my sending a postcard on vacation with my normal return address but funny foreign stamps and postmarks. It's also not the only situation where a third party sends legitimate mail on someone's behalf, with another familiar example being the mail-an-article feature on newspaper sites. I have several hundred small business users that receive mail addressed to their various company domains hosted here. Although I provide outbound SMTP relay service, maybe half use it and the other half just send through their own ISP accounts, so mail for those domains goes out through Road Runner, Verizon, and a dozen other little ISPs you never heard of. Would a DKIM signature match the From: address? Not likely, it's all they can do to get their POP accounts set up, so their ISPs will sign it. But it's not forged. Our lives would be simpler if everyone would mail only in ways that matched our favorite simple security model, but disparaging real mail sent in inconvenient ways as forging isn't going to make that happen. R's, John ___ ietf-dkim mailing list http://dkim.org
RE: [ietf-dkim] DKIM and mailing lists
What is a mailing list? To me it is a script driven reply to all central repository. Sounds like a resigning requirement but since I neither design nor manage one twill leave it up to the market. thanks, Bill -Original Message- From: [EMAIL PROTECTED] on behalf of Mark Delany Sent: Wed 1/18/2006 5:59 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] DKIM and mailing lists On Wed, Jan 18, 2006 at 11:38:53PM +0100, Eliot Lear allegedly wrote: Mark Delany wrote: Given the religion, I wonder whether both are entirely reasonable and leave the choice to the particular list implementor. I know I don't want to take on the argument of which is reasonable so applying guidance for both and for clients in the face of both is important. Particularly for whether or not you protect the Subject line and how at all to limit length, and or resign. There are some serious UI issues there. The very early thinking back at DK-00 was that a participating list might sign List-ID. The idea being that List traffic is distinctly different and that a verifier/UA might sensibly treat such traffic differently in the presence of a List-ID. Subsequent revisions went down the path of generalizing that to Sender. In retrospect, I'm not sure I'm a fan of that generalization as List traffic is so different that it need not be squeezed into a generalized category that otherwise is almost completely absent in real-life traffic. Mark. ___ ietf-dkim mailing list http://dkim.org ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
John Levine wrote: The basic problem is that mailing lists are for all intents and purposes forging content when they don't change the From address but insist on adding trailers and subject line changes, blah, blah, blah. I don't find forging to be a useful description of what mailing lists do. Then try indistinguishable from forging. It's true, they send mail from someplace other than the normal place associated with the From: address, but that's no more forgery than my sending a postcard on vacation with my normal return address but funny foreign stamps and postmarks. Speaking of unuseful descriptions... a more apt analogy would be for the Ugandan Post Office adding a bunch of content obfuscating the fact that you'd been thrown in the klink. The point is that from a receiver's standpoint there's no difference when that happens. With DKIM, you can at least tell what was added and what wasn't in some cases. It's also not the only situation where a third party sends legitimate mail on someone's behalf, with another familiar example being the mail-an-article feature on newspaper sites. I don't argue about the utility, but there are also a lot of indistinguishable abuses as well. It would be nice to have a means to be a Well Behaved Mangler, and I think there's provision within the spec to achieve that at least in some common cases. Whether that's enough is debatable of course, but anything that predicates a flag day is a dead letter. My suspicion is that couching this in terms of right and wrong approaches is exactly the wrong thing to do here because it factors out the timing aspect: as in, right solution at the right time. We need to get over one hump at a time. Mike ___ ietf-dkim mailing list http://dkim.org
RE: [ietf-dkim] DKIM and mailing lists
List traffic is one of the few cases where the recipient has affirmatively opted in to receive it. I agree with Mark, mail agents should be processing identified list traffic in a very different manner to ordinary unsolicited traffic. We need to define rules for a compliant mailer so mailing list authors know what to code to. But the mailing lists that are going to bite us are the legacy ones that are not in compliance. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Delany Sent: Wednesday, January 18, 2006 5:59 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] DKIM and mailing lists On Wed, Jan 18, 2006 at 11:38:53PM +0100, Eliot Lear allegedly wrote: Mark Delany wrote: Given the religion, I wonder whether both are entirely reasonable and leave the choice to the particular list implementor. I know I don't want to take on the argument of which is reasonable so applying guidance for both and for clients in the face of both is important. Particularly for whether or not you protect the Subject line and how at all to limit length, and or resign. There are some serious UI issues there. The very early thinking back at DK-00 was that a participating list might sign List-ID. The idea being that List traffic is distinctly different and that a verifier/UA might sensibly treat such traffic differently in the presence of a List-ID. Subsequent revisions went down the path of generalizing that to Sender. In retrospect, I'm not sure I'm a fan of that generalization as List traffic is so different that it need not be squeezed into a generalized category that otherwise is almost completely absent in real-life traffic. Mark. ___ ietf-dkim mailing list http://dkim.org ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM and mailing lists
I don't find forging to be a useful description of what mailing lists do. Then try indistinguishable from forging. I dunno about you, but I have little trouble telling mailing list mail from random forgeries when I look at it. If your favorite anti-spam technique or security model behaves badly when presented with list mail, I would consider that to be a flaw in the model rather than blame people for using mail in a way that has been common and productive for about 30 years. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I shook hands with Senators Dole and Inouye, said Tom, disarmingly. ___ ietf-dkim mailing list http://dkim.org
