[ietf-dkim] In the spirit of moving forward...
There was very little response to my last straw poll about where we go with the MLM draft next. It certainly wasn't enough to be able to claim "rough consensus" from a group this size. I have some feedback on the actual text from Jeff, Daniel and Dave to incorporate, and I haven't forgotten that. But there remains the issue of whether or not to split it into two or three documents covering specific topics (a non-DKIM MLM BCP, a DKIM-specific MLM BCP, and a DKIM value-add for MLMs informational), and whether or not to just drop the whole affair because there's not enough we can really say anyway. Given my druthers I'd like to proceed with it the way it is since absent rough consensus to change course, the right thing to do seems to be to press on. (After thinking about that a bit, I have to admit that it's also the most attractive to me since it's the least amount of work...) Is anybody going to be really upset if I go that route and then work toward a WGLC later this year? -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
Based on that (rather precise) description, aren't ADSP's requirements a proper subset of the DKIM requirements? If so, I'm not sure I agree with "badly conflicting", but it does frame future discussion quite nicely. For example, if DKIM enables the identification of mail streams, isn't the one ADSP covers just a specific instance of a mail stream? From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins [st...@wordtothewise.com] Sent: Tuesday, September 14, 2010 3:01 PM To: DKIM List Subject: Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault The problem is that the two things have badly conflicting requirements. DKIM is based on a domain-based identifier that's independent of the From: domain, and that's where much of it's value comes from. ADSP is based on a domain-based identifier that must remain identical to the From: field at all times, and that's where it's sole value comes from. ADSP intrinsically conflicts with the original design case for DKIM, despite being piggy-backed on to it. So any document that puts forth even basic good practices for DKIM usage for monitoring sender reputation (use d= to differentiate mail streams) is going to be anathema to ADSP requirements (d= must be the same as the From: domain). And any ADSP-driven set of requirements (mailing lists should not only re-sign any mail they re-send, they should alter the From: address to match) is going to be considered nonsensical by people who consider DKIM a way to tie an identity cookie to a message. And, as we've seen, any compromise document is hated by pretty much everyone, even assuming you can get there. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
+1. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Steve Atkins wrote: > On Sep 14, 2010, at 12:35 PM, J.D. Falk wrote: >> Yes, I know it requires more effort, but what we've been doing so far >> clearly isn't working. > The problem is that the two things have badly conflicting requirements. DKIM > is based on a domain-based identifier that's independent of the From: domain, > and that's where much of it's value comes from. ADSP is based on a > domain-based identifier that must remain identical to the From: field at all > times, and that's where it's sole value comes from. ADSP intrinsically > conflicts with the original design case for DKIM, despite being piggy-backed > on to it. > > So any document that puts forth even basic good practices for DKIM usage for > monitoring sender reputation (use d= to differentiate mail streams) is going > to be anathema to ADSP requirements (d= must be the same as the From: domain). > > And any ADSP-driven set of requirements (mailing lists should not only > re-sign any mail they re-send, they should alter the From: address to match) > is going to be considered nonsensical by people who consider DKIM a way to > tie an identity cookie to a message. > > And, as we've seen, any compromise document is hated by pretty much everyone, > even assuming you can get there. > > Cheers, > Steve > > > ___ > 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+ADSP = FAIL, and it's our fault
> But what everyone has been telling me is that it would be better in > fact to go and deploy something before drafting the I-D and debating > it here. This is the main reason why I went quiet on these lists > since the Barcelona MAAWG meeting (until this week). Yes indeedy. Keeping in mind that no good deed goes unpunished, you can be sure that whatever Paypal does, you'll get complaints about it, but it sure would be nice to have running code we can poke and try out and see how useful it is. R's, John Minor niggle: the order of writing the code and the I-D is not critical. It's not a bad to do them at the same time, so that you can circulate the I-D among people whose opinons you value and get possibly helpful suggestions before the concrete around the code hardens too much. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] where's the code, was draft-ietf-dkim-mailinglists-02 review
Give the IETF's traditions, the usual way to show that you care about something is to write the code to do it. So if you don't write code for senders you aren't allowed to express an opinion about sender policy? Anyone can express an opinion about anything, but there's a reason that the IETF has a tradition of favoring rough consensus and running code. (See RFC 4677, particularly sections 8 and 9.) The draft we're working on is a BCP, where C stands for Current. A BCP describes what people have done and found to work, not paper designs. If a proposal is a good idea, it really shouldn't be hard to persuade someone, somewhere, to implement it and try it out. (That's the E for Engineering in IETF.) For one thing, the net is complex enough that one is usually surprised at unexpected side effects and interactions. For another, it puts at least a small minimum bar for people to demonstrate that they find something useful. For all the claims that checking transitive trust is important, I have yet to see anyone who actually does it. This very list puts a signed A-R header on messages, I presume because Dave wrote or borrowed the code to do so. Is anyone checking that signed header and use it to manage their mail? As far as I can tell, the answer is no. (Doubtless I will hear very soon if I've overlooked something.) Mailing lists have been around for decades, and the possibility of people forging submissions has been around just as long. I've seen a variety of hacks in the MLM to help identify contributors and control what mail the MLM passes along, but I don't ever, in all those decades, recall anything to do it at the subscriber end. If it were a problem, you'd think that someone, somewhere, would have tried to solve it before, however imperfectly. Perhaps this is a hitherto unseen problem that needs solving, but Occam's razor says that if we consistently don't see something, the reason is because it's not there. Having said all that, it remains perfectly reasonable to write up any of these hypothetical propsals as I-Ds and ask the group to publish them as Experimental RFCs, to provide a public spec for anyone interested in implementing them, something I'd support. If it turns out people do implement them and find them useful, we can revisit them and consider them for standards track, as they're doing in EAI. So start writing those I-Ds. It's even kind of fun, writing down your ideas and trying to make them so clear that even someone like me won't misunderstand them. R's, John smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
On Sep 14, 2010, at 12:35 PM, J.D. Falk wrote: > ...but not for the reasons the anti-ADSP folks keep bringing up. > > DKIM is failing because every discussion about actually /using/ DKIM > inevitably gets stuck in the same old argument about ADSP. Doesn't even > matter what the argument is about anymore; it stops all forward progress > every time. And we keep letting it happen -- actively participating, even, > including me. > > Continuing to argue these same points over and over is disrespectful of our > colleagues both on and off this list, and of the IETF process. > > So I'm going to stop, and I beg you all to join me. > > Stop arguing, and start writing drafts. Let us discuss the drafts instead of > attacking each others' intractable positions for the Nth time. If you think > ADSP will bring about the end of all human communication, WRITE A DRAFT > EXPLAINING WHY. If you think something else, write that instead. > > Yes, I know it requires more effort, but what we've been doing so far clearly > isn't working. The problem is that the two things have badly conflicting requirements. DKIM is based on a domain-based identifier that's independent of the From: domain, and that's where much of it's value comes from. ADSP is based on a domain-based identifier that must remain identical to the From: field at all times, and that's where it's sole value comes from. ADSP intrinsically conflicts with the original design case for DKIM, despite being piggy-backed on to it. So any document that puts forth even basic good practices for DKIM usage for monitoring sender reputation (use d= to differentiate mail streams) is going to be anathema to ADSP requirements (d= must be the same as the From: domain). And any ADSP-driven set of requirements (mailing lists should not only re-sign any mail they re-send, they should alter the From: address to match) is going to be considered nonsensical by people who consider DKIM a way to tie an identity cookie to a message. And, as we've seen, any compromise document is hated by pretty much everyone, even assuming you can get there. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of McDowell, Brett > Sent: Tuesday, September 14, 2010 2:28 PM > To: J.D. Falk > Cc: DKIM List > Subject: Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault > > ...and implement what you think should work before making an issue of > it in IETF. +ULONGMAX We're long past the point where arguing as furiously as possible about theory yields useful results. It's time for some data to back up our various ideas. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
...and implement what you think should work before making an issue of it in IETF. That's been my #1 lesson this year (I'm new to IETF). I originally was actually worried about blowback by the community if a large entity like ourselves and few other household names just went off and deployed something with capabilities that overlap with proposals being floated in the IETF, without participating in those debates or aligning with those proposals. But what everyone has been telling me is that it would be better in fact to go and deploy something before drafting the I-D and debating it here. This is the main reason why I went quiet on these lists since the Barcelona MAAWG meeting (until this week). On Sep 14, 2010, at 3:35 PM, J.D. Falk wrote: > ...but not for the reasons the anti-ADSP folks keep bringing up. > > DKIM is failing because every discussion about actually /using/ DKIM > inevitably gets stuck in the same old argument about ADSP. Doesn't even > matter what the argument is about anymore; it stops all forward progress > every time. And we keep letting it happen -- actively participating, even, > including me. > > Continuing to argue these same points over and over is disrespectful of our > colleagues both on and off this list, and of the IETF process. > > So I'm going to stop, and I beg you all to join me. > > Stop arguing, and start writing drafts. Let us discuss the drafts instead of > attacking each others' intractable positions for the Nth time. If you think > ADSP will bring about the end of all human communication, WRITE A DRAFT > EXPLAINING WHY. If you think something else, write that instead. > > Yes, I know it requires more effort, but what we've been doing so far clearly > isn't working. > > > ___ > 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+ADSP = FAIL, and it's our fault
On 09/14/2010 09:35 PM, J.D. Falk wrote: > ...but not for the reasons the anti-ADSP folks keep bringing up. > > DKIM is failing because every discussion about actually /using/ DKIM > inevitably gets stuck in the same old argument about ADSP. Doesn't even > matter what the argument is about anymore; it stops all forward progress > every time. And we keep letting it happen -- actively participating, even, > including me. > > Continuing to argue these same points over and over is disrespectful of our > colleagues both on and off this list, and of the IETF process. > > So I'm going to stop, and I beg you all to join me. +1. > Stop arguing, and start writing drafts. Let us discuss the drafts instead of > attacking each others' intractable positions for the Nth time. If you think > ADSP will bring about the end of all human communication, WRITE A DRAFT > EXPLAINING WHY. If you think something else, write that instead. > > Yes, I know it requires more effort, but what we've been doing so far clearly > isn't working. +1. Period. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
J.D. Falk wrote: > ...but not for the reasons the anti-ADSP folks keep bringing up. > > DKIM is failing because every discussion about actually /using/ > DKIM inevitably gets stuck in the same old argument about ADSP. Should you tell you something. Ignorance doesn't work either. > Doesn't even matter what the argument is about anymore; it stops > all forward progress every time. And we keep letting it happen -- > actively participating, even, including me. The problem was that we allowed an author who never believed in policy to take over SSP, removed all the 3rd party considerations and renamed it ADSP. But he thought that would kill all the 3rd party signer issues. > > Continuing to argue these same points over and over is disrespectful > of our colleagues both on and off this list, and of the IETF process. So what you really asking if POLICY in general should be throw out, disrespecting all that that believe it would be useful? > So I'm going to stop, and I beg you all to join me. And this this has been the problem, shut policy advocates using Consensus by Osmosis - that hasn't worked either, maybe it should tell you something. > Stop arguing, and start writing drafts. We did. DSAP and TPA and SSP was written. Policy opponents killed those efforts. Two RFC standards were written for the Policy functional requirements and Threads Analysis which included Policy considerations. Policy opponents killed those which to ignore the security concerns with unrestricted resigners. The issue it doesn't go away. Murray drafted the MLM I-D and that still isn't acceptable by the policy opponents. > Let us discuss the drafts instead of attacking each > others' intractable positions for the Nth time. You promise not to attack Policy Advocates if they reintroduce new or rehash 3rd party signer protocol I-Ds? > Yes, I know it requires more effort, but what we've been doing > so far clearly isn't working. That I agree - opening minds on 3rd party signing issues might help, or perhaps getting a new editor for ADSP to fix its bugs might work too. Either way, you have to open your mind on POLICY otherwise it is a waste of time, but the issues don't go away. Moving DKIM to experimental status might work too until we figure out how to add a protocol protection security layer to it. It doesn't have one. -- 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] draft-ietf-dkim-mailinglists-02 review
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy > Sent: Tuesday, September 14, 2010 3:27 PM > To: DKIM List > Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review > > > -Original Message- > > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > > boun...@mipassoc.org] On Behalf Of John R. Levine > > Sent: Tuesday, September 14, 2010 12:23 PM > > To: J.D. Falk > > Cc: DKIM List > > Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review > > > > >> How about: "It is important to us that this arrive at your inbox > > signed by us and unmodified. You should not keep it if that is not the > > case." > > > > Well OK. Now I'm hearing that it's the signature that's important, not > > the message. No disagreement there. > > Since the signature's success is predicated on [some part of] the body > being immutable in transit, are those distinct? > > If someone cares enough to implement DKIM discardable I would be surprised if they weren't signing the entire message body. The message (stream overall) is important in the sense that the domain is trying to fend off abuse. That is a necessary precondition but not sufficient. The signature is important because that is how the legitimate (in the sense that it is signed by the domain and validates) is distinguished from the potentially illegitimate. The corpus of legitimate but failed to validate could be considered collateral damage if you will. It may be a high price but it is perceived as less than the damage of letting the illegitimate stuff through. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM+ADSP = FAIL, and it's our fault
...but not for the reasons the anti-ADSP folks keep bringing up. DKIM is failing because every discussion about actually /using/ DKIM inevitably gets stuck in the same old argument about ADSP. Doesn't even matter what the argument is about anymore; it stops all forward progress every time. And we keep letting it happen -- actively participating, even, including me. Continuing to argue these same points over and over is disrespectful of our colleagues both on and off this list, and of the IETF process. So I'm going to stop, and I beg you all to join me. Stop arguing, and start writing drafts. Let us discuss the drafts instead of attacking each others' intractable positions for the Nth time. If you think ADSP will bring about the end of all human communication, WRITE A DRAFT EXPLAINING WHY. If you think something else, write that instead. Yes, I know it requires more effort, but what we've been doing so far clearly isn't working. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of John R. Levine > Sent: Tuesday, September 14, 2010 12:23 PM > To: J.D. Falk > Cc: DKIM List > Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review > > >> How about: "It is important to us that this arrive at your inbox > signed by us and unmodified. You should not keep it if that is not the > case." > > Well OK. Now I'm hearing that it's the signature that's important, not > the message. No disagreement there. Since the signature's success is predicated on [some part of] the body being immutable in transit, are those distinct? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
>> How about: "It is important to us that this arrive at your inbox signed by >> us and unmodified. You should not keep it if that is not the case." Well OK. Now I'm hearing that it's the signature that's important, not the message. No disagreement there. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 9:52 AM, Murray S. Kucherawy wrote: > I don't think ADSP "discardable" means simply "throw it away" because it > leaves out the "ifs" that are supposed to be in front of it. That simplified > interpretation presupposes the message will pretty much always arrive signed > but not verifiable, meaning you basically don't believe DKIM can be trusted > to work. > > How about: "It is important to us that this arrive at your inbox signed by us > and unmodified. You should not keep it if that is not the case." > > ...which is how I read the RFC. And what the proponents intended when we wrote it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of John R. Levine > Sent: Tuesday, September 14, 2010 8:14 AM > To: McDowell, Brett > Cc: DKIM > Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review > > > I agree with Mike's assessment. > > I remain unable to reconcile "this is very important" and "throw it > away" applied to the same message. I don't think ADSP "discardable" means simply "throw it away" because it leaves out the "ifs" that are supposed to be in front of it. That simplified interpretation presupposes the message will pretty much always arrive signed but not verifiable, meaning you basically don't believe DKIM can be trusted to work. How about: "It is important to us that this arrive at your inbox signed by us and unmodified. You should not keep it if that is not the case." ...which is how I read the RFC. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
MH Michael Hammer (5304) wrote: >> John R. Levine >> I remain unable to reconcile "this is very important" and "throw >> it away" applied to the same message. > You are unable to reconcile those two because you are leaving out the > third part of the equation. That is: > > "there is a high risk of abuse for this domain when a message is not > authenticated". +1, which is important because for many systems, authenticated sessions skips many or all email security checks. For our SMTP system, once authenticated, all SMTP level checks are skipped. It is the unsolicited unauthenticated sessions where security checks best applies. -- 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] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 9:40 AM, Scott Kitterman wrote: > On Tuesday, September 14, 2010 09:18:23 am John R. Levine wrote: >> As I keep saying over and over, discardable really means discardable: if >> in doubt, throw it away. It does NOT, repeat NOT, mean high value mail. >> It means low value mail. > > I think your view is to narrow. It means that the domain owner prefers it be > discarded if not signed. This means they view the risks of having legitimate > mail discarded as lower than the risks associated with having unsigned mail > delivered. Agreed. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
Michael Thomas wrote: >> John R. Levine wrote: >> I remain unable to reconcile "this is very important" and "throw it away" >> applied to the same message. > The problem here is that you shouldn't be mixing up human values of > "importance" > or not, with the mechanical policy that "if something is unsigned, don't > deliver it". ADSP does the later, not the former. And if notions of > "importance" were > accidentally brought into the language of the ADSP RFC, they should be removed > because it's neither needed, or enlightening in any way. +1, well said Mike and its not the first time of course. The deterministic properties that POLICY offered has been, for lack of a better word, "deemphasized" with the focus on allowing unrestricted resigners hence we are left with only a guessing game and/or need to get receivers to use a common reputation service, with an propensity to serve only certain high value domains to have a greater "meaning" over the general population of domains. Low or high value, all domains have to be treated with a fundamental equal mechanical, deterministic process first before we can even deal with indeterminate conditions. -- 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] draft-ietf-dkim-mailinglists-02 review
John R. Levine wrote: >> It does not mean low value mail and I don't think you will find a >> sending mplementing dkim=discardable that would agree with you. > > Then in the RFC we utterly failed to make it clear what dkim=discardable > means. Sigh. You wrote it! > Once again, we see that ADSP is so broken By design > that even people who like it don't understand what it is for. We don't like it. We liked SSP. But SSP was taken from us and we ended up with a terrible intentionally design morph to stop policy with little to no regard to how it integrates with the rest of the world, namely list system. You could only tell people to ignore it or move it to experimental. No, POLICY isn't the problem - ADSP is! Hey, you wrote it - FIX IT! -- 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] draft-ietf-dkim-mailinglists-02 review
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of John R. Levine > Sent: Tuesday, September 14, 2010 11:14 AM > To: McDowell, Brett > Cc: DKIM > Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review > > > I agree with Mike's assessment. > > I remain unable to reconcile "this is very important" and "throw it away" > applied to the same message. > You are unable to reconcile those two because you are leaving out the third part of the equation. That is: "there is a high risk of abuse for this domain when a message is not authenticated". Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 13, 2010, at 8:43 PM, John R. Levine wrote: >> But if that stuff was signed before entering our whatevers, how can we >> verify the signature when pulling it out? This question may entirely >> invalidate assumptions that nobody ever actually made about somebody >> else's theoretical wiping policy! > > Not to stretch this metaphor too far, but I believe that the assertion > that people care whether mail inbound to MLMs was signed remains utterly > unsupported. I support it, in the context of supporting the "transient trust" use case (aka the A-R approach). > > Give the IETF's traditions, the usual way to show that you care about > something is to write the code to do it. So if you don't write code for senders you aren't allowed to express an opinion about sender policy? That's just silly. We are all stakeholders in this ecosystem and we all have a right to our opinion and perspective, regardless of how we engage/influence the Internet Mail ecosystem. > For the lists I run, I've > modified MJ2 to put a signature on outgoing mail with the list's domain > and a private field to say which list it was. I can't say I've seen any > improvement in delivery which was already close to 100%, but it certainly > hasn't hurt anything and it's made it easier to process Yahoo FBLs. > That's one of the reasons I'd want a list BCP to tell lists to sign their > mail; I've tried it, albeit at small scale, and it works. We know from > reports that at least one MTA misimplements ADSP to reject on discardable > failures, which suggests that a robust MLM should be prepared to deal with > that, most simply by pre-discarding anything that might cause that > problem. I haven't implemented that because, so far at least, none of my > susbcribers appear to use ADSP so it's pretty low on my list of things to > worry about. > > Based on recent correspondence, it appears that one of the most vehement > advocates of modifying MLMs to work around ADSP and to pass through info > to retroactively check contributor signatures hadn't noticed that I put > S/MIME signatures on my list mail and that even though it adds a footer to > each message, Mailman passes the signatures through so his MUA can verify > them. Care? Get real. You lost me. > > R's, > John > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On 09/14/2010 08:13 AM, John R. Levine wrote: >> I agree with Mike's assessment. > > I remain unable to reconcile "this is very important" and "throw it away" > applied to the same message. The problem here is that you shouldn't be mixing up human values of "importance" or not, with the mechanical policy that "if something is unsigned, don't deliver it". ADSP does the later, not the former. And if notions of "importance" were accidentally brought into the language of the ADSP RFC, they should be removed because it's neither needed, or enlightening in any way. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 13, 2010, at 5:30 PM, Douglas Otis wrote: > On 9/13/10 1:03 PM, McDowell, Brett wrote: >> The ADSP=discardable deployer is not conveying apathy regarding the >> deliverability of their mail, quite the opposite IMO. They are saying (to >> paraphrase) "please attempt to verify the DKIM signature on this message >> against the key record in our DNS for this domain/subdomain, and if you >> cannot verify the signature then please discard the message as a means of >> protecting your subscriber from phishing attacks, otherwise please deliver >> the message and do so knowing we put this much effort into ensuring the >> goodness of the mail before we sent it" > For MLMs making modifications that invalidate DKIM signatures, posting > should be blocked for domains making an ADSP dkim=discardable > assertion. Such an assertion might cause other subscribers to refuse > messages from an Author Domain with the discardable assertion and cause > delivery and message queuing to be problematic. Otherwise, those > refusing these messages run a risk of being unsubscribed. That would be an undesired outcome and therefore a "reject" by the MLM would be more appropriate (until we have a RFC in place and adopted that enables the "transient trust"/"chain of trust" notion I've been advocating for). And yes, I'm going to write one but perhaps only after I work with more mailbox providers to implement the notion now. > > -Doug > ___ > 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] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 11:13 AM, John R. Levine wrote: >> I agree with Mike's assessment. > > I remain unable to reconcile "this is very important" and "throw it away" > applied to the same message. > Scott nailed it when he said: This means they view the risks of having legitimate mail discarded as lower than the risks associated with having unsigned mail delivered. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 10:32 AM, John R. Levine wrote: >> It does not mean low value mail and I don't think you will find a >> sending mplementing dkim=discardable that would agree with you. > > Then in the RFC we utterly failed to make it clear what dkim=discardable > means. Sigh. > > Once again, we see that ADSP is so broken that even people who like it > don't understand what it is for. > > R's, But John, you clearly never wanted ADSP to exist and you've made enough statements publicly about your motivation for becoming a co-author that it should come as no surprise if folks don't interpret your comments regarding ADSP with the same deference one normally expects in response to comments coming from a co-author. I suspect your fellow authors didn't realize you'd use this label change of "discardable" as ammunition after-the-fact to lobby for ADSP's disuse. Perhaps it's time to issue an update to ADSP which clarifies how the spec should be interpreted, by those who actually use it. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On 09/13/2010 07:43 PM, John R. Levine wrote: Based on recent correspondence, it appears that one of the most vehement advocates of modifying MLMs to work around ADSP and to pass through info to retroactively check contributor signatures hadn't noticed that I put S/MIME signatures on my list mail and that even though it adds a footer to each message, Mailman passes the signatures through so his MUA can verify them. Care? Get real. fwiw, this list appears to be breaking your signatures (as I expect it will do to my signature as well.) I agree with your assertion that S/MIME is very MLM friendly. Most of the lists I am on do not break my signatures (even lists that add footers and modify subjects,) and those that do can be easily configured to work nicely. Kudos to the designers of S/MIME and MIME :-) In fact, most of my frustration with DKIM is because I naively expect it to work like S/MIME. This isn't the fault of DKIM. My expectations are just unreasonable. Jesse smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
It does not mean low value mail and I don't think you will find a sending mplementing dkim=discardable that would agree with you. Then in the RFC we utterly failed to make it clear what dkim=discardable means. Sigh. Once again, we see that ADSP is so broken that even people who like it don't understand what it is for. R's, John smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
> I agree with Mike's assessment. I remain unable to reconcile "this is very important" and "throw it away" applied to the same message. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 9:31 AM, MH Michael Hammer (5304) wrote: > > >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of John R. Levine >> Sent: Tuesday, September 14, 2010 9:18 AM >> To: Ian Eiloart >> Cc: DKIM >> Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review >> >>> There are all sorts of reasons for publishing ADSP=discarable, from > "the >>> domain isn't used to send email" (analagous to "spf -all") >> >> Quite right, in which case I hope you'll agree that throwing mail away > is >> exactly the right thing to do. >> >>> to "our domain is widely spoofed (because of its sensitive nature), > and >>> we absolutely do sign all our email". >> >> That would be dkim=all, not dkim=discardable. >> >> As I keep saying over and over, discardable really means discardable: > if >> in doubt, throw it away. It does NOT, repeat NOT, mean high value > mail. >> It means low value mail. >> > > -1 > > It does not mean low value mail and I don't think you will find a > sending mplementing dkim=discardable that would agree with you. In the > case of the domain actually sending mail, what is being said is that the > risk of phishing/badness/abuse is great enough that when in doubt, > discard it if it fails to validate or does not have a signature. This is > significantly different than "it means low value mail". > > Mike I agree with Mike's assessment. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Sep 14, 2010, at 9:15 AM, Hector Santos wrote: > Ian Eiloart wrote: > >> If the MLM owner knowingly breaks a signature, and either discards the >> message or forwards it into a system that is likely to discard it, and do >> not notify the sender, then the forwarder must be responsible for any harm >> done. They really should reject such messages. > > +1 and nothing short of this is just poor mail system integration and > product engineering. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP breaks forwarding
>> Early drafts of what turned into ADSP used the word "strict" which I >> changed to "discardable" to make it clear that if you set this flag, >> you're saying the mail is unusually unimportant, to the extent that if >> there's doubt about its legitimacy, just throw it away. > > At the time, "strict" was meant to be the equivalent of DK's "-", wasn't it? > IMHO, "discardable" has been an addition rather than a substitution. Hey, I wrote it, I know what I did. I changed strict to discardable to better describe what it means, and try to discourage the wrong impression that it means mail is important. > that, and assuming that "discardable means discardable", as you wrote[1], is > it correct to _reject_ on _all_? We don't offer any suggested handling for dkim=all. "Well, it might be a forgery, or it might have a signature broken in transit, or they might be mistaken and not really sign all their mail. Your guess is as good as mine." > Hear, hear. Does such criterion also apply to, say, courtesy forwarding? If the courtesy forward recodes the message and breaks the signature, as your example does, I suppose so. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Tuesday, September 14, 2010 09:18:23 am John R. Levine wrote: > As I keep saying over and over, discardable really means discardable: if > in doubt, throw it away. It does NOT, repeat NOT, mean high value mail. > It means low value mail. I think your view is to narrow. It means that the domain owner prefers it be discarded if not signed. This means they view the risks of having legitimate mail discarded as lower than the risks associated with having unsigned mail delivered. This is a relative assessment. Your "low value mail" assertion only addresses one part of that equation. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
Ian Eiloart wrote: > If the MLM owner knowingly breaks a signature, and either discards the > message or forwards it into a system that is likely to discard it, and do > not notify the sender, then the forwarder must be responsible for any harm > done. They really should reject such messages. +1 and nothing short of this is just poor mail system integration and product engineering. The key word is "knowingly" because it is intentional neglect at that point if it pursues to add something NEW without all the engineering considerations extracted from the R&D. Here is what we are doing: For List Server: - Check ADSP at subscription points - notify denial - Check ADSP at list submission - reject with 1 time notification - One time scan script to check for any ADSP domains - dotting the i, crossing the t. Overall, ADSP domains are restricted and ASDP domains are protected from abuse. For SMTP Server: - DATA level DKIM Script - Extract 5322.From - Check ADSP - if DISCARDABLE or ALL and not signed - if DISCARDABLE return ACCEPT-DISCARD - return REJECT - if DISCARDABLE - Extract DKIM.D - if 5322.From != DKIM.D - If Has List-ID, return ACCEPT-DISCARD - return REJECT - if signed - DKIM verify - A-R record - Return PASS Overall, it has consideration for legacy list server. It will not cover those who do not add a LIST-ID. Check ADSP would also be made an option just in case it becomes deprecated. The ACCEPT-DISCARD will probably be made an option with a default of true, otherwise it would be a REJECT. -- 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] ADSP breaks forwarding
On 14/Sep/10 03:18, John R. Levine wrote: > Early drafts of what turned into ADSP used the word "strict" which I > changed to "discardable" to make it clear that if you set this flag, > you're saying the mail is unusually unimportant, to the extent that if > there's doubt about its legitimacy, just throw it away. At the time, "strict" was meant to be the equivalent of DK's "-", wasn't it? IMHO, "discardable" has been an addition rather than a substitution. Given that, and assuming that "discardable means discardable", as you wrote[1], is it correct to _reject_ on _all_? [1] http://mipassoc.org/pipermail/ietf-dkim/2008q1/009557.html > The final version said > > if a message arrives without a valid Author Domain Signature due to > modification in transit, submission via a path without access to a > signing key, or any other reason, the domain encourages the recipient(s) > to discard it. > > I think it's a reasonable interpretation to say that if you expect > your list software might break the signature, you're doing the sender > a favor by pre-discarding it since that's what the recipients should > do anyway. Hear, hear. Does such criterion also apply to, say, courtesy forwarding? Consider the following test I made: Authentication-Results: ns1.qubic.net; dkim=pass (1024-bit key) header...@tana.it header.b=CGKfNJdO; dkim-adsp=pass ... Subject: Test quoted printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.64 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns1.qubic.net id o7SAsR9R006644 The message was signed as quoted-printable, hence they (dk.elandsys.com) obviously had verified it /before/ converting back to 8bit. Thereafter, they should not forward adsp-encumbered messages, unless wrapped inside entirely new messages, with their own "From" (as they actually do, for the autoresponder.) Is that correct? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of John R. Levine > Sent: Tuesday, September 14, 2010 9:18 AM > To: Ian Eiloart > Cc: DKIM > Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review > > > There are all sorts of reasons for publishing ADSP=discarable, from "the > > domain isn't used to send email" (analagous to "spf -all") > > Quite right, in which case I hope you'll agree that throwing mail away is > exactly the right thing to do. > > > to "our domain is widely spoofed (because of its sensitive nature), and > > we absolutely do sign all our email". > > That would be dkim=all, not dkim=discardable. > > As I keep saying over and over, discardable really means discardable: if > in doubt, throw it away. It does NOT, repeat NOT, mean high value mail. > It means low value mail. > -1 It does not mean low value mail and I don't think you will find a sending mplementing dkim=discardable that would agree with you. In the case of the domain actually sending mail, what is being said is that the risk of phishing/badness/abuse is great enough that when in doubt, discard it if it fails to validate or does not have a signature. This is significantly different than "it means low value mail". Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
> There are all sorts of reasons for publishing ADSP=discarable, from "the > domain isn't used to send email" (analagous to "spf -all") Quite right, in which case I hope you'll agree that throwing mail away is exactly the right thing to do. > to "our domain is widely spoofed (because of its sensitive nature), and > we absolutely do sign all our email". That would be dkim=all, not dkim=discardable. As I keep saying over and over, discardable really means discardable: if in doubt, throw it away. It does NOT, repeat NOT, mean high value mail. It means low value mail. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On 9/14/10 2:36 AM, Ian Eiloart wrote: > --On 13 September 2010 21:18:41 -0400 "John R. Levine" > wrote: > >> > The final version said >> > >> > if a message arrives without a valid Author Domain Signature due to >> > modification in transit, submission via a path without access to a >> > signing key, or any other reason, the domain encourages the > recipient(s) >> > to discard it. >> > >> > I think it's a reasonable interpretation to say that if you expect your >> > list software might break the signature, you're doing the sender a favor >> > by pre-discarding it since that's what the recipients should do anyway. >> > > Absolutely not. The condition doesn't apply when you receive the message, > so the signer is NOT encouraging you to discard it, and the general rules > apply: you should deliver the message or notify the sender (or the sending > MTA). > > It may be that the message can be bounced, with a non delivery > notification. For example, if the return path matches the content of a > signed header, and they're both in the domain of the signer, then you're > probably not issuing collateral spam. If you are issuing collateral spam in > this instance, then the fault probably lies with the controller of the > sender domain (for allowing intra-domain spoofing). > > If the MLM owner knowingly breaks a signature, and either discards the > message or forwards it into a system that is likely to discard it, and do > not notify the sender, then the forwarder must be responsible for any harm > done. They really should reject such messages. Agree. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
--On 13 September 2010 21:18:41 -0400 "John R. Levine" wrote: > The final version said > >if a message arrives without a valid Author Domain Signature due to >modification in transit, submission via a path without access to a >signing key, or any other reason, the domain encourages the recipient(s) >to discard it. > > I think it's a reasonable interpretation to say that if you expect your > list software might break the signature, you're doing the sender a favor > by pre-discarding it since that's what the recipients should do anyway. > Absolutely not. The condition doesn't apply when you receive the message, so the signer is NOT encouraging you to discard it, and the general rules apply: you should deliver the message or notify the sender (or the sending MTA). It may be that the message can be bounced, with a non delivery notification. For example, if the return path matches the content of a signed header, and they're both in the domain of the signer, then you're probably not issuing collateral spam. If you are issuing collateral spam in this instance, then the fault probably lies with the controller of the sender domain (for allowing intra-domain spoofing). If the MLM owner knowingly breaks a signature, and either discards the message or forwards it into a system that is likely to discard it, and do not notify the sender, then the forwarder must be responsible for any harm done. They really should reject such messages. A real life exemplar: we're currently migrating a lot of non-modifying list exploders into modifying Mailman lists. Most of these lists are internal, but not all of them. In an ideal world, I'd check the domains of all subscribers to see whether any publish ADSP=discardable before making the changes. In practice, I suspect that I'm unlikely to do that. However, I'd much prefer that message get bounced back to the sender than discarded as a result of the change that I'm making. That way, they have a better chance to spot the problem, and a better chance to diagnose it. There are all sorts of reasons for publishing ADSP=discarable, from "the domain isn't used to send email" (analagous to "spf -all"), to "our domain is widely spoofed (because of it's sensitive nature), and we absolutely do sign all our email". I'd suggest that it's not reasonable to discard the latter email when it carries a good signature. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
--On 13 September 2010 10:21:55 -0700 Michael Thomas wrote: > Unless you have a MLM that > is completely purpose-built with SMTP, or has bits and pieces of itself > inserted into > milter-like parts of the SMTP stream, your average MTA is going to have > no clue whether it's destined for a MLM or anything else. I disagree. I use Mailman 2.x and Exim. Mailman has a rudimentary SMTP server, and Exim punts mail to that SMTP server in order to achieve delivery. Exim knows exactly which emails are being delivered to Mailman. In Mailman 3, things will look even better. Exim will be able to make a call forward to Mailman to determine (a) whether the list exists, and (b) whether the sender is permitted to post messages to the list. Exim will know whether the message is signed, and can do simple DNS lookups to find ADSP records. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
