Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
"John R. Levine" wrote: >> Colorful, but those were not my/our words or sentiment. >> >> Once again, our use case is: > >Maybe, I'm dim, but I don't see any practical difference between what >you're saying and what I'm saying, other than perhaps that you have a far >more optimistic idea of what people will deploy that doesn't directly >benefit them. > >Like I said, "throw away anything that doesn't have our signature" has >some chance of broad adoption. Every extra word you add to the message >makes it less likely that people will do it. > I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third parties to create messages that render discardable moot. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
On 5/25/10 4:18 PM, John R. Levine wrote: > Like I said, "throw away anything that doesn't have our signature" has > some chance of broad adoption. Every extra word you add to the message > makes it less likely that people will do it. > "Don't deliver" rather than "throw it away" retains email integrity with feedback necessary for ceasing abusive sources. For example, what prevents ISPs from publishing bogus PTR records in their reverse DNS entries? Removing uncertainty of non-compliance better ensures how reports of abuse will be handled. Uncertainty is caused by not allowing domains a means to unilaterally make exceptions on their behalf. The information such an exception mechanism provides better conform to current email infrastructure, and will be safer to act upon. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 10, 2010, at 3:09 PM, Steve Atkins wrote: > On May 10, 2010, at 11:59 AM, John R. Levine wrote: > >>> Apart from ADSP rules, a broken signature must be treated as if there was >>> no >>> signature at all. That in itself is not the problem. The problem with >>> broken >>> signatures is that people will not buy into a technology (DKIM) if it will >>> not cover a significant part of their e-mail. >> >> Of course. That's why MLMs should sign their mail, or equvalently the MSA >> they use should sign it. Problem solved, right? >> >> Free bonus: MLMs can sign the list mail even if the contributor didn't >> sign it. > > +1. It's pretty much a non-issue (unless you believe that DKIM is > magic fairy dust that will prevent all "fraudulent use of your brand"). I believe we can disagree without being disagreeable. I'm sure there is no one on this list (or in the world) who thinks DKIM is magic fairy dust that will prevent all fraudulent use of a brand. I would like to think we are all on this list making a good faith effort to explore and debate the right way to deal with the status quo, including the option of sustaining it. I personally don't agree with the position that the status quo should be sustained, but I respect both that position and those who articulate it. FWIW, -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
> Colorful, but those were not my/our words or sentiment. > > Once again, our use case is: Maybe, I'm dim, but I don't see any practical difference between what you're saying and what I'm saying, other than perhaps that you have a far more optimistic idea of what people will deploy that doesn't directly benefit them. Like I said, "throw away anything that doesn't have our signature" has some chance of broad adoption. Every extra word you add to the message makes it less likely that people will do it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
On May 25, 2010, at 1:46 PM, John R. Levine wrote: >> Step three: fix the status quo for *participating* MLM's by offering up a >> new technical solution that enables MLM's to assert that they've validated >> the original sender's signature. > > Not to pick on Paypal specifically, since this is a general failure of ADSP, > but: Colorful, but those were not my/our words or sentiment. Once again, our use case is: > On Apr 26, 2010, at 1:19 PM, McDowell, Brett wrote: >> >> From my perspective, I'd like to enable (not mandate or expect universal >> compliance with) the deployment scenario where the sender's DKIM signature >> is either maintained without adulteration or "proxied" by the list so the >> transient trust can be carried through the mailing list intermediary to the >> destination (per Murray's note which I'm also going to respond to). That's >> my use case. By sharing this use case I'm not trying to deprecate or >> undermine John Levine's original use case. But there is a diversity of >> valid/appropriate behavior by mailing lists vis-a-vis DKIM that we need to >> consider (which is why I'm so pleased to see Mike H. take our discussion in >> this direction). >> >> -- Brett There are mailbox providers who want to leverage email authentication technologies to protect their users from phishing. I'm not making that up. What we have done with Google and Yahoo! is well known, but who here actually believes those are the only two deployments in the world today (or in-process)? I don't think it's in the best interest of the Internet to leave these use cases with no alternative but to pursue closed, proprietary mechanisms. It is my opinion that the standards community (if not IETF, then who?) could view these use cases as an opportunity to evolve the standards in a way that will gain more adoption and utility. The only thing we would be doing is evolving the existing standards to enable -- not compel or coerce -- consumer protection use cases. Everything I've articulated since joining the mail list has been rooted in the concept of choice. This authenticated messaging ecosystem is optional, not mandatory. Any effort to make it mandatory is doomed. So why not provide the option? Why not spec out a means for MLM's to participate in a DKIM/ADSP=discardable flow in a way that supports consumer protection use cases? -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 25, 2010, at 3:38 PM, Brett McDowell wrote: > On May 10, 2010, at 3:09 PM, Steve Atkins wrote: > >> On May 10, 2010, at 11:59 AM, John R. Levine wrote: >> Apart from ADSP rules, a broken signature must be treated as if there was no signature at all. That in itself is not the problem. The problem with broken signatures is that people will not buy into a technology (DKIM) if it will not cover a significant part of their e-mail. >>> >>> Of course. That's why MLMs should sign their mail, or equvalently the MSA >>> they use should sign it. Problem solved, right? >>> >>> Free bonus: MLMs can sign the list mail even if the contributor didn't >>> sign it. >> >> +1. It's pretty much a non-issue (unless you believe that DKIM is >> magic fairy dust that will prevent all "fraudulent use of your brand"). > > I believe we can disagree without being disagreeable. I'm sure there is no > one on this list (or in the world) who thinks DKIM is magic fairy dust that > will prevent all fraudulent use of a brand. If ADSP is not there to prevent "fraudulent use of your brand", what is it for? While I don't think ADSP proponents actually believe it is magical brand protection fairy dust, that is the operational model we're using when we're discussing the usage of ADSP. ADSP does not, and can not, provide significant operational value in dealing with phishing, which is the only concrete example anyone has brought forward. So we're left with "brand protection", which is still plausible because it's so vague. (If it were described as "Brand protection as applied to the section of the byte sequence in the From: field that isn't the part usually displayed to the end user" that would be less vague, but more obviously useless). > I would like to think we are all on this list making a good faith effort to > explore and debate the right way to deal with the status quo, including the > option of sustaining it. I personally don't agree with the position that the > status quo should be sustained, but I respect both that position and those > who articulate it. Yes, this summary may be blunt and possibly even disagreeable, but there comes a point when developing something that's going to affect many, many people that you have to mention the elephant in the room - which is that while lots of people involved have invested quite a bit of effort and professional credibility in putting it together there's still no definition of what problem it's supposed to solve, and the end result appears to be pretty much useless for any concrete phishing or brand protection scenario. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists "BCP" draft
On 5/25/10 5:01 AM, Alessandro Vesely wrote: >> I think that Murray was suggesting that in addition to rejecting all >> > mail from domain A it would be polite to also warn anyone from >> > domain A who subscribes to the list that their mail would be >> > rejected (which seems good UX design to me). >> > That warning is an/alternative/ to refusing signups. The BCP > distinguishes between participating and non-participating MLMs, and > that warning belongs to the former kind. I'd expect a participating > MLM has also fixed the double-footer problem, while most lists have no > problems with double subject-tags. Hence, the warning may merely > recall that posts from the discardable address will be rejected unless > they include the correct footer, and the subject-tag appears exactly > once, the latter especially for new posts. (Notice that such practice > is may also help to avoid light-minded posts.) > > We cannot suggest anything to DKIM-unaware MLMs. Hence, the "refuse > signups" option, that would apply in this case, has to be put through > by subscribers themselves. > It should be possible for sending domains to detect mailing-list conversations. When desired, they can then immediately publish third-party authorization labels to allow ADSP exceptions. The exception approach retains their ability to quickly mitigate any reported abuse. >>> >>Since ADSP causes problems for innocent bystanders, I think it's >>> >>reasonable to decline A's mail in the first place. This is doubly >>> >>true since the ADSP RFC rather specifically says that you shouldn't >>> >>mark a domain discardable if its users send mail to lists. >>> Disagree. This suggests ADSP makes a deliver-ability distinction between "discardable" and "all". It does not. Appendix B makes a general statement about what might invalidate DKIM signatures, without mention of "discardable". Appendix B.3 warns "discardable" may cause their email to be discarded (dropped), and makes no specific mention of mailing lists. Appendix B.5 refers to _both_ "all" and "discardable" as causing significant breakage for messages sent through paths lacking Author Domain Signatures. >> > >> > It causes no problems at all to innocent bystanders in that case - the >> > recipient at domain B is a willing participant who has chosen both >> > to pay attention to ADSP and to respond to it by rejecting, rather than >> > discarding, mails labeled "discardable". >> ADSP "all" might be rejected, where ADSP "discardable" might be discarded. Neither ensures delivery without an Author Domain Signature. A reasonable use for "discardable" would be for domains that don't send email. DSN of rejected mail should be used to report abuse and to escalate take-downs of illegal activity. It is amazing ISPs feel safe in using reverse DNS PTR records to qualify their outbound servers, but then ignore clear evidence of wrong doing that should lead to a similar consequences for ignoring reported ADSP assertions that clearly indicate their lack of authorization. > That user will probably contact postmas...@b and ask for the relevant > list to be whitelisted. If a list's operators seek such explicit > whitelisting at their subscribers' MXes, then they might want to > leverage ADSP that way. > Why should some user be trusted? Only the Author Domain should be allowed to make these exceptions. Ideally this should be done with a single transaction mechanism. SPF will not serve this role. Often SPF must authorize servers carrying messages for thousands of domains. By not knowing with certainty which email headers or parameters should be in compliance, and by not having border MTA IP addresses captured by Authentication-Results, SPF is far less practical at mitigating abuse and potentially dangerous messages. On the other hand, ADSP in conjunction with a third-party authorization mechanism provides a clear and certain indication of non-complaint email, which should offer far greater protection with less overhead. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists "BCP" draft available
> Step three: fix the status quo for *participating* MLM's by offering up > a new technical solution that enables MLM's to assert that they've > validated the original sender's signature. Not to pick on Paypal specifically, since this is a general failure of ADSP, but: We want everyone to throw away mail from us that doesn't have our signature. no, wait, ... We want everyone to throw away mail from us that doesn't have our signature EXCEPT if it has an A-R header showing that it was signed when a MLM received it. no, wait, ... We want everyone to throw away mail from us that doesn't have our signature EXCEPT if it has an A-R header showing that it was signed when a MLM received it AND it has a signature from the MLM to show it's actually from the MLM no, wait, ... We want everyone to throw away mail from us that doesn't have our signature EXCEPT if it has an A-R header showing that it was signed when a MLM received it AND it has a signature from the MLM to show it's actually from the MLM AND the signature is known to the recipient to sign mail from real MLMs. no, wait, etc. I entirely endorse Paypal's efforts to make it easy to identify their mail and easy to throw away the forgeries. But you (and anyone else whose transaction mail is a forgery target) shoot yourself in the foot every time you make the message more complex, since that makes it less likely that people will go along. In particular, all of the normal mail from paypal.com says one thing, log in and look at your account, so losing the occasional message isn't a big deal since you can find what it said on the web site. Now you're saying, well, actually, there's some paypal.com mail that says other stuff that you can't reconstruct, and that mail may well show up without our signature. Really, really, don't do that. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists "BCP" draft
On May 24, 2010, at 7:55 PM, Steve Atkins wrote: > On May 24, 2010, at 6:38 PM, John Levine wrote: > Refusing signups from those domains is probably a bit extreme, though. >>> >>> What about a warning at signup time if a "discardable" ADSP record is >>> found for the registrant's domain? >> >> That doesn't help. In the IETF's scenario, domain A sent mail which >> was marked discardable to the list, and recipients at domain B were >> rejecting it and the people at B got bounced off the list. I'd have >> to squint awfully hard to come up with an argument that it is wrong to >> reject unsigned discardable mail at SMTP time. > > I think that Murray was suggesting that in addition to rejecting all > mail from domain A it would be polite to also warn anyone from > domain A who subscribes to the list that their mail would be > rejected (which seems good UX design to me). Yup, I think this would be an appropriate addition to the BCP document. -- J.D. Falk Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 24, 2010, at 9:08 AM, John R. Levine wrote: >> I guess the list should be rejecting his email! Then, perhaps, his >> organisation would get around to deploying a non-discardable domain. > > I've suggested it. They know they have a problem, but they won't yet say > what they're going to do about it. > I'll be happy to report on our decision once we've implemented it. FWIW, I agree with the recommendations made on this list, at least in the short-term. Step one: was to start using anything that wasn't under an ADSP=discardable assertion (so here I am using a me.com account). Step two: is to do something along the lines of what's been recommended here (a non-discardable domain). Step three: fix the status quo for *participating* MLM's by offering up a new technical solution that enables MLM's to assert that they've validated the original sender's signature. > As you may recall, they suggested that lists sign an A-R header and all > recipient systems track what lists they're subscribed to and do > complicated processing to see whether list mail was signed when it showed > up at the list. That is a mischaracterization of what I proposed. What I actually proposed was: > On Apr 26, 2010, at 1:19 PM, McDowell, Brett wrote: > >> On Apr 26, 2010, at 10:05 AM, MH Michael Hammer (5304) wrote: >> >>> I think we are having the wrong discussion. The real question is: >>> >>> "What are appropriate practices for mailing lists in handling DKIM >>> signed mail?" >> >> Agreed. >> >> From my perspective, I'd like to enable (not mandate or expect universal >> compliance with) the deployment scenario where the sender's DKIM signature >> is either maintained without adulteration or "proxied" by the list so the >> transient trust can be carried through the mailing list intermediary to the >> destination (per Murray's note which I'm also going to respond to). That's >> my use case. By sharing this use case I'm not trying to deprecate or >> undermine John Levine's original use case. But there is a diversity of >> valid/appropriate behavior by mailing lists vis-a-vis DKIM that we need to >> consider (which is why I'm so pleased to see Mike H. take our discussion in >> this direction). >> >> -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
--On 24 May 2010 13:41:37 -0700 Steve Atkins wrote: > >> >> I think that's probably the most principled thing to do. >> >> For self-protection, there's also the option of NOT sending the message >> with a VERPed sender address. That would mean that a subsequent >> rejection should not count against the recipient. If the list is using >> some other mechanism to count rejections, then that mechanism should >> not be used. > > If the recipient is rejecting mail from the list, then the list should > stop attempting to send mail to that recipient. It should not try and > guess why the mail is no longer wanted. No, there are plenty of reasons that a recipient might reject *some* email from a list, but not the rest. For example, the recipient site might be more fussy about RFC compliance in the email. I've been unsubscribed from Yahoo lists because they relayed mail with ';' separating email addresses in sender headers. > > We really don't want people to use ADSP (or, much worse, DKIM) as > an excuse for not handling bounces nor for sending unwanted email. No, and of course a site needn't reject ADSP mail with broken signatures. Indeed, to protect it's members from unwanted unsubscriptions, it might be better to drop the email than reject it. But, then the sender might never discover what they're doing wrong. If the recipient rejects the message, then the list should be able to bounce back to the sender, since it was originally properly signed. >>... > Cheers, > Steve -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists "BCP" draft
--On 25 May 2010 01:38:53 + John Levine wrote: >>> Refusing signups from those domains is probably a bit extreme, though. >> >> What about a warning at signup time if a "discardable" ADSP record is >> found for the registrant's domain? > > That doesn't help. It doesn't help if this is instead of rejecting the mail. But I don't think that was the intention. A message to this effect might be very useful: "You've joined the list, and will get messages from it. However, you can't post to the list using your email address because..." Now, if the subscriber doesn't intend to post to the list, they're fine. If they do, then surely it's helpful to warn in advance that they can't. > In the IETF's scenario, domain A sent mail which > was marked discardable to the list, and recipients at domain B were > rejecting it and the people at B got bounced off the list. I'd have > to squint awfully hard to come up with an argument that it is wrong to > reject unsigned discardable mail at SMTP time. > Since ADSP causes problems for innocent bystanders, I think it's > reasonable to decline A's mail in the first place. This is doubly > true since the ADSP RFC rather specifically says that you shouldn't > mark a domain discardable if its users send mail to lists. > > R's, > John > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html -- 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] Lists "BCP" draft available
--On 24 May 2010 14:33:13 -0700 Steve Atkins wrote: > > On May 24, 2010, at 2:28 PM, Murray S. Kucherawy wrote: > >>> -Original Message- >>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >>> boun...@mipassoc.org] On Behalf Of Steve Atkins >>> Sent: Monday, May 24, 2010 1:42 PM >>> To: DKIM List >>> Subject: Re: [ietf-dkim] Lists "BCP" draft available >>> > Not at all. If we can agree that lists should reject discardable >>> mail > out of self defense, that's a good point to add to the BCP. >>> >>> +1 >>> >>> Refusing signups from those domains is probably a bit extreme, though. >> >> What about a warning at signup time if a "discardable" ADSP record is >> found for the registrant's domain? > > Seems like a reasonable UX design to me but probably > more a choice for the developer than a BCP, I think. > > (I think that refusing signups from ADSP using domains > may also be a reasonable choice for the developer or list > admin in some cases. But not something to put in a BCP.) Why not? At least mention that it might be polite to make such a warning. After all, the person signing up might have no clue at all that their domain is 'discardable'. I guess we can't claim that it's common practice, never might best common practice. But it is, surely, a good idea. > Cheers, > Steve > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html -- 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] Lists "BCP" draft available
On May 24, 2010, at 5:27 AM, Ian Eiloart wrote: >> We have one concrete failure scenario, in which someone who publishes >> dkim=discardable sends mail to a MLM that as usual breaks the signature, >> a subscriber's mail system carefully follows the ADSP and rejects that >> mail, causing the subscriber to be bounced off the list. (This really >> happened, on an IETF list.) The advice is obvious a) put a shim in >> front of your MLM to reject discardable mail and b) the usual advice not >> to use ADSP at all, but it definitely needs publishing. > > The other piece of advice should be to actually discard, rather than > rejecting, discardable email. That would have protected the subscriber from > automatic unsubscription. The advice should be to discard the mail vs. bouncing it back to the MLM. That solves the use case of subscribers being auto-unsubscribed to mail lists without undermining all the other use cases that led the IETF to standardize ADSP in the first place. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Lists "BCP" draft available
On May 20, 2010, at 6:01 PM, McDowell, Brett wrote: > B) I'm going to re-subscribe to this (and all outside-the-firewall mailing > lists) with a personal email address to avoid the current situation (of my > messages going to SPAM or the bit bucket due to the firm ADSP=discardable > policy on paypal.com and MLM's inability to sustain DKIM signatures in a form > receivers need to see it in order to verify the paypal.comsignature). It's a > temporary work-around and we are developing a long-term solution for our > employees that I'll write about once it's live so other ADSP=discardable > organization can learn from our experience. This is just a quick follow-up to let folks know that I'll be using this personal account for public mail lists until we have addressed the "DKIM+ADSP=discardable breaks MLM's/MLM's break DKIM+ADSP=discardable" problem in a more systemic manner. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] more on discardable, was Lists "BCP" draft
On 25/May/10 03:55, Steve Atkins wrote: > On May 24, 2010, at 6:38 PM, John Levine wrote: > Refusing signups from those domains is probably a bit extreme, though. >>> >>> What about a warning at signup time if a "discardable" ADSP record is >>> found for the registrant's domain? >> >> That doesn't help. In the IETF's scenario, domain A sent mail which >> was marked discardable to the list, and recipients at domain B were >> rejecting it and the people at B got bounced off the list. I'd have >> to squint awfully hard to come up with an argument that it is wrong to >> reject unsigned discardable mail at SMTP time. > > I think that Murray was suggesting that in addition to rejecting all > mail from domain A it would be polite to also warn anyone from > domain A who subscribes to the list that their mail would be > rejected (which seems good UX design to me). That warning is an /alternative/ to refusing signups. The BCP distinguishes between participating and non-participating MLMs, and that warning belongs to the former kind. I'd expect a participating MLM has also fixed the double-footer problem, while most lists have no problems with double subject-tags. Hence, the warning may merely recall that posts from the discardable address will be rejected unless they include the correct footer, and the subject-tag appears exactly once, the latter especially for new posts. (Notice that such practice is may also help to avoid light-minded posts.) We cannot suggest anything to DKIM-unaware MLMs. Hence, the "refuse signups" option, that would apply in this case, has to be put through by subscribers themselves. >> Since ADSP causes problems for innocent bystanders, I think it's >> reasonable to decline A's mail in the first place. This is doubly >> true since the ADSP RFC rather specifically says that you shouldn't >> mark a domain discardable if its users send mail to lists. > > It causes no problems at all to innocent bystanders in that case - the > recipient at domain B is a willing participant who has chosen both > to pay attention to ADSP and to respond to it by rejecting, rather than > discarding, mails labeled "discardable". That user will probably contact postmas...@b and ask for the relevant list to be whitelisted. If a list's operators seek such explicit whitelisting at their subscribers' MXes, then they might want to leverage ADSP that way. BTW, is "discard" exactly synonym with "drop"? I'd recommend dropping mail only in cases of negligibly low FP rates _and_ high risk, e.g. viruses. Deliver-as-junk is used as a makeshift, and I tend to associate "discardable" with such behavior. Is that what RFC 5617 means by it? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
