Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
--On 29 July 2010 20:53:40 +0200 "J.D. Falk" wrote: > On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote: > >> --On 26 July 2010 18:24:34 +0200 "J.D. Falk" >> wrote: >> >>> I think it's because, when you implement most protocols, if your end is >>> broken then you can't even talk to the other end. With ADSP, if your >>> end is broken then you can still talk SMTP and even sign with DKIM, but >>> the other end may silently discard your message. There's no feedback. >> >> About 90% of the email sent to my personal email address ends up in a >> Gmail junk mail folder, that I never check. There's no feedback there, >> either. > > As far as SMTP is concerned, that mail was successfully delivered. > huh? The complaint is that the message is silently discarded somewhere downstream, and the sender gets no feedback. How can it matter what the technical means of achieving this are? -- 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] New Version Notification for draft-levine-dbr-00 (fwd)
On 07/29/2010 11:53 AM, J.D. Falk wrote: > On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote: > >> --On 26 July 2010 18:24:34 +0200 "J.D. Falk" >> wrote: >> >>> I think it's because, when you implement most protocols, if your end is >>> broken then you can't even talk to the other end. With ADSP, if your end >>> is broken then you can still talk SMTP and even sign with DKIM, but the >>> other end may silently discard your message. There's no feedback. >> >> About 90% of the email sent to my personal email address ends up in a Gmail >> junk mail folder, that I never check. There's no feedback there, either. > > As far as SMTP is concerned, that mail was successfully delivered. How is this different than border mta's that 500 the message or 200 and silently discard? This happens billions of times every day and has been for more than 10 years. At least with ADSP, a FBL has a little bit more concrete reason of why it did that. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jul 29, 2010, at 11:53 AM, J.D. Falk wrote: > On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote: > >> --On 26 July 2010 18:24:34 +0200 "J.D. Falk" >> wrote: >> >>> I think it's because, when you implement most protocols, if your end is >>> broken then you can't even talk to the other end. With ADSP, if your end >>> is broken then you can still talk SMTP and even sign with DKIM, but the >>> other end may silently discard your message. There's no feedback. >> >> About 90% of the email sent to my personal email address ends up in a Gmail >> junk mail folder, that I never check. There's no feedback there, either. > > As far as SMTP is concerned, that mail was successfully delivered. In both cases, yes. If the recipient chooses to discard the email there's no obligation to notify the sender - and I can't think of any existing case where the recipient does so - let alone notify a third party. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jul 29, 2010, at 5:09 PM, Ian Eiloart wrote: > --On 26 July 2010 18:24:34 +0200 "J.D. Falk" > wrote: > >> I think it's because, when you implement most protocols, if your end is >> broken then you can't even talk to the other end. With ADSP, if your end >> is broken then you can still talk SMTP and even sign with DKIM, but the >> other end may silently discard your message. There's no feedback. > > About 90% of the email sent to my personal email address ends up in a Gmail > junk mail folder, that I never check. There's no feedback there, either. As far as SMTP is concerned, that mail was successfully delivered. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
--On 26 July 2010 18:24:34 +0200 "J.D. Falk" wrote: > > I think it's because, when you implement most protocols, if your end is > broken then you can't even talk to the other end. With ADSP, if your end > is broken then you can still talk SMTP and even sign with DKIM, but the > other end may silently discard your message. There's no feedback. > About 90% of the email sent to my personal email address ends up in a Gmail junk mail folder, that I never check. There's no feedback there, either. -- 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] New Version Notification for draft-levine-dbr-00 (fwd)
> Your spec limits the use of the DBR to Author Domains... is there a > compelling reason to not just let it apply to any domain? I don't see the point of using it on other domains. Nobody expects the signature to match anything else. R's, John > > Ellen > > On Tue, Jul 27, 2010 at 11:35 AM, John Levine wrote: > >>> Mailing lists are a separate issue. I don't think it's helpful for a >>> 3rd party to vouch that lists are lists, and that's not what John's >>> draft does. >> >> The goal of my draft was to provide a way publish lists of domains for >> which there is a net benefit to the recipient from dropping unsigned >> mail. I believe this is what people want from ADSP, but it can't >> provide for reasons we needn't rehash. >> >> I do think there could be benefits from identifying categories of >> senders, e.g., this is a bank, this is a government, and maybe this is >> a discussion list. It's pretty obvious how you could add them to VBR, >> but that's not what I did here. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On 7/27/10 5:35 PM, John Levine wrote: >> Mailing lists are a separate issue. I don't think it's helpful for a >> 3rd party to vouch that lists are lists, and that's not what John's >> draft does. >> > The goal of my draft was to provide a way publish lists of domains for > which there is a net benefit to the recipient from dropping unsigned > mail. I believe this is what people want from ADSP, but it can't > provide for reasons we needn't rehash. > Rather than the Author Domain making an ADSP assertion, the Author Domain instead subscribes to a vouching service where ADSP is therefore ignored or over ruled? Does this mean Author Domains are unwilling to publish "discardable", whereas a vouching service would be? Why is a vouching service in a better position to make a decision that are in conflict with what the Author Domain would have or has published? What makes this a hard decision? It seems this will result in denying use of any informal third-party service. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
>Mailing lists are a separate issue. I don't think it's helpful for a >3rd party to vouch that lists are lists, and that's not what John's >draft does. The goal of my draft was to provide a way publish lists of domains for which there is a net benefit to the recipient from dropping unsigned mail. I believe this is what people want from ADSP, but it can't provide for reasons we needn't rehash. I do think there could be benefits from identifying categories of senders, e.g., this is a bank, this is a government, and maybe this is a discussion list. It's pretty obvious how you could add them to VBR, but that's not what I did here. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jul 27, 2010, at 10:33 AM, Douglas Otis wrote: > Companies are good at shooting themselves in the foot in respect to > helping bad actors phish. (blush) The other foot injury involves their > email being rejected or discarded. Unfortunately, these two goals are > in conflict when making ADSP assertions. Unless the targeted > organizations or institutions forgo all informal third-party services, > such as mailing-lists, it is not possible to get ADSP right. > Ironically, following recommendations being proposed for mailing-lists > is likely to make phishing worse. Mailing lists are a separate issue. I don't think it's helpful for a 3rd party to vouch that lists are lists, and that's not what John's draft does. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On 7/27/10 9:36 AM, J.D. Falk wrote: > On Jul 26, 2010, at 9:13 PM, Douglas Otis wrote: > > A vouching service is unlikely to offer a fix either. How would a > > vouching service know better than the Author Domain? > > They wouldn't, so a smart vouching service would be working WITH the > author domain to get it right. But that's a business decision, not a > protocol decision. J.D. Companies are good at shooting themselves in the foot in respect to helping bad actors phish. (blush) The other foot injury involves their email being rejected or discarded. Unfortunately, these two goals are in conflict when making ADSP assertions. Unless the targeted organizations or institutions forgo all informal third-party services, such as mailing-lists, it is not possible to get ADSP right. Ironically, following recommendations being proposed for mailing-lists is likely to make phishing worse. These conflicts are not resolved by adding another layer of management unless the question being asked is extended with respect to messages lacking Author Domain signatures. The considerations should not be what is easy for senders, but whether excluding phishing is easy for recipients. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jul 26, 2010, at 9:13 PM, Douglas Otis wrote: > A vouching service is unlikely to offer a fix either. How would a > vouching service know better than the Author Domain? They wouldn't, so a smart vouching service would be working WITH the author domain to get it right. But that's a business decision, not a protocol decision. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On 07/26/2010 09:24 AM, J.D. Falk wrote: > On Jul 25, 2010, at 11:36 AM, Murray S. Kucherawy wrote: > >> I've engaged some of you off-list trying to understand why ADSP is >> fundamentally different than the private agreements known to exist between >> PayPal and some large email service providers. I get the philosophical >> arguments, but from a standards body perspective I remain stymied. >> >> I'm finally beginning to buy that something akin to DBR may be necessary, >> but it's still weird to me that the point is that the average sysadmin can't >> be trusted to do ADSP right. But then why, for example, can he/she be >> trusted to do DNS or SMTP or even TCP/IP right without some sort of vouching >> or reference service asserting competence? >> >> The whole point of standards is to publish a mechanism for accomplishing >> something so that two parties that have never interacted in that specific >> way before can do so without some kind of out-of-band prior arrangement. In >> that sense these statements about ADSP create some cognitive dissonance that >> I haven't been able to resolve yet. > > I think it's because, when you implement most protocols, if your end is > broken then you can't even talk to the other end. With ADSP, if your end is > broken then you can still talk SMTP and even sign with DKIM, but the other > end may silently discard your message. There's no feedback. But that's basically true of the entire mail system these days. It's also why getting ARF/FBL's widespread would be a generally Good Thing. ADSP doesn't really change anything one way or the other. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On 7/26/10 6:24 PM, J.D. Falk wrote: > I think it's because, when you implement most protocols, if your end is > broken then you can't even talk to the other end. With ADSP, if your end is > broken then you can still talk SMTP and even sign with DKIM, but the other > end may silently discard your message. There's no feedback. > It's not lack of feedback causing unsubscribes on mailing lists. Don't blame sysadmin for these problems. ADSP, as currently defined, is unable to accommodate informal third-party services when attempting to offer protection from phishing. Rather than adhering to the "practice" aspect of ADSP assertions, ADSP's "discardable" changed this into advice on message handling, analogous to the "-all" of spf. Avoiding use of subdomains avoids confusing recipients recognition of the trusted domain, where use of unprotected subdomains just shifts the phishing problem. There is no getting this right. A vouching service is unlikely to offer a fix either. How would a vouching service know better than the Author Domain? I would not want to be on the hook when getting this wrong. It would be better to allow senders the latitude for getting this right, and making their own explicit determinations. We have the technology. :^) -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jul 25, 2010, at 11:36 AM, Murray S. Kucherawy wrote: > I've engaged some of you off-list trying to understand why ADSP is > fundamentally different than the private agreements known to exist between > PayPal and some large email service providers. I get the philosophical > arguments, but from a standards body perspective I remain stymied. > > I'm finally beginning to buy that something akin to DBR may be necessary, but > it's still weird to me that the point is that the average sysadmin can't be > trusted to do ADSP right. But then why, for example, can he/she be trusted > to do DNS or SMTP or even TCP/IP right without some sort of vouching or > reference service asserting competence? > > The whole point of standards is to publish a mechanism for accomplishing > something so that two parties that have never interacted in that specific way > before can do so without some kind of out-of-band prior arrangement. In that > sense these statements about ADSP create some cognitive dissonance that I > haven't been able to resolve yet. I think it's because, when you implement most protocols, if your end is broken then you can't even talk to the other end. With ADSP, if your end is broken then you can still talk SMTP and even sign with DKIM, but the other end may silently discard your message. There's no feedback. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
> As we all know, admins can and do screw up anything, but with most > mistakes, the damage directly affects them. If you screw up your MX, > your own incoming mail won't work. If you screw up your ADSP, your > mail will work fine, while other people's mail systems will > mysteriously lose mail. This is such a bizarre take. If my web server starts putting out 500 internal errors because of misconfiguration, the clients "lose" their http content too. That most certainly directly affects my http server just like it does mail: I'm not putting those servers out on the net for giggles, it's because I *want* my content to be distributed. So the argument that there is not fate sharing is bogus on its face. If mail operators can't be bothered to configure mail correctly, it's their problem. They shouldn't be mollycoddled because that just encourages more bad behavior. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On 7/25/10 5:48 PM, John Levine wrote: > > I'm finally beginning to buy that something akin to DBR may be > > necessary, but it's still weird to me that the point is that the > > average sysadmin can't be trusted to do ADSP right. But then why, > > for example, can he/she be trusted to do DNS or SMTP or even > > TCP/IP right without some sort of vouching or reference service > > asserting competence? > > It's a perfectly reasonable question. To me, the problem with ADSP > is that if we imagine the process of delivering a message to be a > running race, ADSP is a gun pointed at your foot offered to you at > the finish line. > > As we all know, admins can and do screw up anything, but with most > mistakes, the damage directly affects them. If you screw up your > MX, your own incoming mail won't work. If you screw up your ADSP, > your mail will work fine, while other people's mail systems will > mysteriously lose mail. For domains targeted in phishing attacks, ADSP allows system admins to do it "right" only when no informal third-party service is ever used. These informal services, such as mailing-lists, are not suitable for transparent authorization, and result in message loss when the "discardable" assertion is made. When "all" is made, results are not actionable due to uncertainty from possible informal service use. Unfortunately, the remedy recommended for informal services is to deploy unprotected subdomains. This is clearly the "wrong" thing when attempting to mitigate phishing. Such a tactic invites more phishing and more victims amidst increased confusion. A reputation or vouching service will be unable to properly determine a domain's signing compliance, and whether informal third-party services are ever used. Without a simple relationship assertion between targeted domains and informal third-party services being supported, reputation or vouching will also remain problematic, where just blame being redirected. Any recommendation from vouching or reputation services would be "ready-fire-aim" with system-admin's feet still suffering, but now beyond their control, while phishing continues unabated. The number of domains being phished takes the problem beyond the realm of any effective manual response. A scheme that allows informal third-party services, only after confirmation of a header field, allows recipients a proactive means to recognize different message sources. There is an article discussing this at: http://us.trendmicro.com/imperia/md/content/us/trendwatch/researchandanalysis/64_avoiding_the_whack-a-mole_anti-phishing_strategy__july_22__2010_.pdf -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
>I'm finally beginning to buy that something akin to DBR may be >necessary, but it's still weird to me that the point is that the >average sysadmin can't be trusted to do ADSP right. But then why, >for example, can he/she be trusted to do DNS or SMTP or even TCP/IP >right without some sort of vouching or reference service asserting >competence? It's a perfectly reasonable question. To me, the problem with ADSP is that if we imagine the process of delivering a message to be a running race, ADSP is a gun pointed at your foot offered to you at the finish line. As we all know, admins can and do screw up anything, but with most mistakes, the damage directly affects them. If you screw up your MX, your own incoming mail won't work. If you screw up your ADSP, your mail will work fine, while other people's mail systems will mysteriously lose mail. Experience with SPF -all suggests that people who get it wrong will insist that it's somenoe else's problem to fix, by baroque workarounds like SRS and recent proposals to intuit that a message with a broken signature is coming through a legitimate mailing list and that the list verified the signature. Also, regardless of what the spec says, few recipients would ever use it as anything more than a mild hint to a scoring system. Standards work well when the benefit from implementing them correctly is shared, and the pain of screwing up is also shared. ADSP offers trivial benefits to the vast majority of domains that are not phishing targets and to the recipients of mail from them, and pain that predominantly falls on the other end from the one that screwed up. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
(More review of old chatter...) > -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of J.D. Falk > Sent: Tuesday, June 22, 2010 11:07 AM > To: DKIM List > Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr- > 00 (fwd) > > > I still don't get why it's ok for John Levine to publish a list which > > says that it's ok to discard unsigned mail from paypal.com, but st00pid > > for paypal.com to publish the same thing. That is the essence of his > > jihad against adsp. > > Because presumably verifiers will trust John's process for compiling > this list more than they'd trust any random schmoe with the ability to > create TXT records. > > (If paypal were representative of all domains, this wouldn't be a > concern.) > > Personally, I think we'll need lists like this for a while in order to > gain more experience and determine best practices, and THEN we can > decide whether to change (or even scrap) ADSP to reflect those > practices. I've engaged some of you off-list trying to understand why ADSP is fundamentally different than the private agreements known to exist between PayPal and some large email service providers. I get the philosophical arguments, but from a standards body perspective I remain stymied. I'm finally beginning to buy that something akin to DBR may be necessary, but it's still weird to me that the point is that the average sysadmin can't be trusted to do ADSP right. But then why, for example, can he/she be trusted to do DNS or SMTP or even TCP/IP right without some sort of vouching or reference service asserting competence? The whole point of standards is to publish a mechanism for accomplishing something so that two parties that have never interacted in that specific way before can do so without some kind of out-of-band prior arrangement. In that sense these statements about ADSP create some cognitive dissonance that I haven't been able to resolve yet. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
--On 25 June 2010 16:21:00 -0400 "John R. Levine" wrote: >> I don't recollect you proposing wording that included "silently" so it >> isn't even possible for a person going back and look at the discussions >> to know what you meant. >> >> We are therefore left with what you wrote and which the working group >> came to a consensus on. > > Whatever. I find it hard to see how anyone could interpret the RFC and > the discussion leading up to it as a hidden consensus to send spam every > time a receiver saw "dkim=discardable", but I'm clearly not going to > persuade you otherwise. It's nothing of the sort. The question isn't whether one SHOULD notify the recipient, but whether one MAY do so. > 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] New Version Notification for draft-levine-dbr-00(fwd)
--On 25 June 2010 14:39:04 -0400 "John R. Levine" wrote: >> We seem to agree that discard means "throw away". > > Evidently. But I do have the advantage of knowing what I meant when I > wrote the section we're arguing about. Right, but knowing what you meant isn't the point. You're arguing about what you wrote. > -- 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] New Version Notification for draft-levine-dbr-00(fwd)
--On 26 June 2010 01:58:42 + John Levine wrote: >> +1. OpenDKIM actually implements a reject (55x error) with the >> intent of giving the sender/victim an opportunity to detect a >> problem, an idea for which there is some obvious demand, though I >> imagine we should make that configurable and maybe even default it to >> an actual accept-but-throw-away form of "discard". > > That seems reasonable to me, but keep in mind that's the exact behavior > that got people bounced off an IETF list when an unrelated domain marked > its users' mail as discardable. > Yes, in light of the MLM problem, the best thing to do is to 5xx messages which don't appear to be from mailing lists, but to discard (silently or otherwise) those that do. -- 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] New Version Notification for draft-levine-dbr-00(fwd)
Hi Franck, At 19:49 25-06-10, Franck Martin wrote: >Can openDKIM issue a 4xx code if not a single valid DKIM signature is found? I suggest discussing about that on the OpenDKIM mailing list. Opendkim supports fine-grained policy control (see http://www.opendkim.org/opendkim-lua.3.html ). Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
Silly question, may be. Can openDKIM issue a 4xx code if not a single valid DKIM signature is found? This could be issued if no valid DKIM signature is found and connecting IP is v6. And would the sender retry with a V4 address then? - Original Message - From: "John Levine" To: ietf-dkim@mipassoc.org Sent: Saturday, 26 June, 2010 1:58:42 PM Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd) >+1. OpenDKIM actually implements a reject (55x error) with the >intent of giving the sender/victim an opportunity to detect a >problem, an idea for which there is some obvious demand, though I >imagine we should make that configurable and maybe even default it to >an actual accept-but-throw-away form of "discard". That seems reasonable to me, but keep in mind that's the exact behavior that got people bounced off an IETF list when an unrelated domain marked its users' mail as discardable. R's, John ___ 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] New Version Notification for draft-levine-dbr-00(fwd)
>+1. OpenDKIM actually implements a reject (55x error) with the >intent of giving the sender/victim an opportunity to detect a >problem, an idea for which there is some obvious demand, though I >imagine we should make that configurable and maybe even default it to >an actual accept-but-throw-away form of "discard". That seems reasonable to me, but keep in mind that's the exact behavior that got people bounced off an IETF list when an unrelated domain marked its users' mail as discardable. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Jon Callas
> Sent: Friday, June 25, 2010 12:21 PM
> To: MH Michael Hammer
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-
> 00(fwd)
>
> My interpretation is that gives you the license to do whatever makes
> sense to you, as a receiver. If you *want* to silently drop a message
> that doesn't meet policy, that's all the standards ammo you need to
> justify your decision.
>
> On the other hand, if you want to log, audit, quarantine, filter, or
> even bend, fold, spindle, or mutilate the message, you have
> justification as well. DiscardABLE doesn't mean they MUST be discarded.
> Encouragement is even weaker than a SHOULD, and it's the sending domain
> that encourages it.
+1. OpenDKIM actually implements a reject (55x error) with the intent of
giving the sender/victim an opportunity to detect a problem, an idea for which
there is some obvious demand, though I imagine we should make that configurable
and maybe even default it to an actual accept-but-throw-away form of "discard".
As the language in RFC5617 is soft ("encourages", "discardABLE"), the assertion
that doing anything other than accept-but-throw-away is indicative of lunacy
could easily be lost on the reader. If it's really a major problem, maybe the
WG should do an update draft that hardens the language and explains clearly
that "discard" in this context means "250 + bitbucket".
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Friday, June 25, 2010 4:21 PM > To: MH Michael Hammer (5304) > Cc: ietf-dkim@mipassoc.org > Subject: RE: [ietf-dkim] New Version Notification for draft-levine-dbr- > 00(fwd) > > > I don't recollect you proposing wording that included "silently" so it > > isn't even possible for a person going back and look at the discussions > > to know what you meant. > > > > We are therefore left with what you wrote and which the working group > > came to a consensus on. > > Whatever. I find it hard to see how anyone could interpret the RFC and > the discussion leading up to it as a hidden consensus to send spam every > time a receiver saw "dkim=discardable", but I'm clearly not going to > persuade you otherwise. > Folks should interpret the RFC how it is written. For a failure on "discardable" the receiver is encouraged to discard the message. Thus it is written thus it is interpreted. By omission it is left to the receiver to decide whatever else they might or might not do in conjunction with a decision to discard messages. That is beyond the scope of what is written in RFC5617. I did not say receivers MUST nor did I say receivers SHOULD, I said that they COULD as one approach to the issue of making it clear that any non-delivery is at the direction of the sending domain. A receiver might choose to only do so for a financial domain such as Paypal. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
Hi Mike, At 11:44 25-06-10, MH Michael Hammer (5304) wrote: >And the rest of the world has the disadvantage of only knowing what is >written in the RFC. There is thread about the word at http://mipassoc.org/pipermail/ietf-dkim/2008q1/009572.html The authoritative answer is in Section 4.2.1 of RFC 5617. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> I don't recollect you proposing wording that included "silently" so it > isn't even possible for a person going back and look at the discussions > to know what you meant. > > We are therefore left with what you wrote and which the working group > came to a consensus on. Whatever. I find it hard to see how anyone could interpret the RFC and the discussion leading up to it as a hidden consensus to send spam every time a receiver saw "dkim=discardable", but I'm clearly not going to persuade you otherwise. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > All messages from this domain are signed with an Author Domain > Signature and are discardable, i.e., if a message arrives without > a valid Author Domain Signature, the domain encourages the > recipient(s) to discard it. My interpretation is that gives you the license to do whatever makes sense to you, as a receiver. If you *want* to silently drop a message that doesn't meet policy, that's all the standards ammo you need to justify your decision. On the other hand, if you want to log, audit, quarantine, filter, or even bend, fold, spindle, or mutilate the message, you have justification as well. DiscardABLE doesn't mean they MUST be discarded. Encouragement is even weaker than a SHOULD, and it's the sending domain that encourages it. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFMJQG3sTedWZOD3gYRApWAAJsH1AWP0XGOkW0EozjuYpwnAfJ42gCgwIOP XqQP7bkgzshHDKBZqoTcoa0= =mNiP -END PGP SIGNATURE- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On Jun 25, 2010, at 11:39 AM, John R. Levine wrote: >> We seem to agree that discard means "throw away". > > Evidently. But I do have the advantage of knowing what I meant when I > wrote the section we're arguing about. This is, I think, the third or fourth time we've been through the "what does discard mean?" thread. Is there any way we can add interpretation notes to the existing RFC, to clarify what it means, so we can avoid going over the same terminology issues repeatedly (and, as a bonus, make the spec clearer for implementors)? Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Friday, June 25, 2010 2:39 PM > To: MH Michael Hammer (5304) > Cc: ietf-dkim@mipassoc.org > Subject: RE: [ietf-dkim] New Version Notification for draft-levine-dbr- > 00(fwd) > > > We seem to agree that discard means "throw away". > > Evidently. But I do have the advantage of knowing what I meant when I > wrote the section we're arguing about. > And the rest of the world has the disadvantage of only knowing what is written in the RFC. I don't recollect you proposing wording that included "silently" so it isn't even possible for a person going back and look at the discussions to know what you meant. We are therefore left with what you wrote and which the working group came to a consensus on. > > Now I'm really getting confused John. On the one hand you argue that > > there are hordes of panting implementers anxiously awaiting the > > opportunity to publish borked (a technical term) ADSP records (compared > > to their mailing practices) thus creating a situation where their very > > important mail will be discarded by any receiver that follows the > > instructions of those implementers. (If the mail was not important then > > there would not be many - if any - complaints to receivers and this > > discussion would be moot.) > > That's why, as I have consistently argued since day 1, the correct thing > for implementers to do is to ignore ADSP completely, since there is > nothing you can do with it that will produce better results than ignoring > it. > > > So ADSP is a broken spam filter? Why would you present yourself as the > > co-author of a broken spam filter? > > As I think I made pretty clear at the time, I crowbared my way into the > ADSP effort to try to minimize the damage. If it were up to me, we would > have abandoned the effort without producing any RFC at all, but there > were too many people who believed (and apparently some who still believe) > that it's a magic bullet against something. > > R's, > John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> We seem to agree that discard means "throw away". Evidently. But I do have the advantage of knowing what I meant when I wrote the section we're arguing about. > Now I'm really getting confused John. On the one hand you argue that > there are hordes of panting implementers anxiously awaiting the > opportunity to publish borked (a technical term) ADSP records (compared > to their mailing practices) thus creating a situation where their very > important mail will be discarded by any receiver that follows the > instructions of those implementers. (If the mail was not important then > there would not be many - if any - complaints to receivers and this > discussion would be moot.) That's why, as I have consistently argued since day 1, the correct thing for implementers to do is to ignore ADSP completely, since there is nothing you can do with it that will produce better results than ignoring it. > So ADSP is a broken spam filter? Why would you present yourself as the > co-author of a broken spam filter? As I think I made pretty clear at the time, I crowbared my way into the ADSP effort to try to minimize the damage. If it were up to me, we would have abandoned the effort without producing any RFC at all, but there were too many people who believed (and apparently some who still believe) that it's a magic bullet against something. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Friday, June 25, 2010 11:44 AM > To: MH Michael Hammer (5304) > Cc: ietf-dkim@mipassoc.org > Subject: RE: [ietf-dkim] New Version Notification for draft-levine-dbr- > 00(fwd) > > > Help me out here John, where exactly is that "silently drop" section? I > > see the discarding part but the "drop silently" part seems to be a bit > > silent. > > Sheesh, Mike. Discard is an ordinary English word which I used in its > ordinary English sense. I suppose there might be people who say > "Attention! I have thrown a used coffee cup into the wastebasket!" each > time they do so, but I hope I don't know any of them. > We seem to agree that discard means "throw away". Where we seem to disagree is that I take it as face value and recognize that RFC5617 says nothing beyond that. You are reading between the lines or the super-secret lemon juice portion of the spec to determine that any discarding must be silent and that the Receiver MUST NOT do anything else beyond throwing it away silently. > > Ooh, "we're sending you this useless notification instead of what might > > have been spam". Just when we thought that had been stamped out. > > > So you have decided to join the group that claims DKIM and ADSP are > > about fighting spam rather than being an authentication mechanism. > > If by fighting spam, you mean not sending mail which is certain to be > useless and unwanted, I guess I plead guilty. > Now I'm really getting confused John. On the one hand you argue that there are hordes of panting implementers anxiously awaiting the opportunity to publish borked (a technical term) ADSP records (compared to their mailing practices) thus creating a situation where their very important mail will be discarded by any receiver that follows the instructions of those implementers. (If the mail was not important then there would not be many - if any - complaints to receivers and this discussion would be moot.) On the other hand you are now arguing that a notification to the intended recipient that there was a problem based on the published requirements of the sending domain is certain to be useless and unwanted. Most interesting. I believe this is what's known as cognitive dissonance. Either the mail is important and there will be complaints (to receivers) or it is not important and nobody will care on the receiving end if it gets discarded (silently). > If we can turn our minds back a decade or so, you may recall that some > spam filters replaced a suspect message with an announcement saying "so > and so sent you spam, which we caught, and we're sending you this message > instead." We all got a zillion of them. Did you ever do anything with > any of those messages other than delete them? I certainly didn't. > > If you don't trust a filtering technique to work, don't use it. But for > heaven sakes, don't excuse broken spam filters by sending more spam. > So ADSP is a broken spam filter? Why would you present yourself as the co-author of a broken spam filter? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On 06/25/2010 08:44 AM, John R. Levine wrote: >> Help me out here John, where exactly is that "silently drop" section? I >> see the discarding part but the "drop silently" part seems to be a bit >> silent. > > Sheesh, Mike. Discard is an ordinary English word which I used in its > ordinary English sense. I guess you've never played Rummy. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> Help me out here John, where exactly is that "silently drop" section? I > see the discarding part but the "drop silently" part seems to be a bit > silent. Sheesh, Mike. Discard is an ordinary English word which I used in its ordinary English sense. I suppose there might be people who say "Attention! I have thrown a used coffee cup into the wastebasket!" each time they do so, but I hope I don't know any of them. > Ooh, "we're sending you this useless notification instead of what might > have been spam". Just when we thought that had been stamped out. > So you have decided to join the group that claims DKIM and ADSP are > about fighting spam rather than being an authentication mechanism. If by fighting spam, you mean not sending mail which is certain to be useless and unwanted, I guess I plead guilty. If we can turn our minds back a decade or so, you may recall that some spam filters replaced a suspect message with an announcement saying "so and so sent you spam, which we caught, and we're sending you this message instead." We all got a zillion of them. Did you ever do anything with any of those messages other than delete them? I certainly didn't. If you don't trust a filtering technique to work, don't use it. But for heaven sakes, don't excuse broken spam filters by sending more spam. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> -Original Message- > From: John Levine [mailto:jo...@iecc.com] > Sent: Thursday, June 24, 2010 6:24 PM > To: ietf-dkim@mipassoc.org > Cc: MH Michael Hammer (5304) > Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr- > 00(fwd) > > >Nothing in the ADSP spec says that the ISP has to silently drop the > >mail. > > Actually, it does. Read it again. > http://tools.ietf.org/search/rfc5617 Section 3.3 All messages from this domain are signed with an Author Domain Signature and are discardable, i.e., if a message arrives without a valid Author Domain Signature, the domain encourages the recipient(s) to discard it. 4.2.1. Record Syntax discardable All mail from the domain is signed with an Author Domain Signature. Furthermore, 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. Help me out here John, where exactly is that "silently drop" section? I see the discarding part but the "drop silently" part seems to be a bit silent. Other than the "encourages recipient(s) to discard it" phrase, the document gives no other guidance as to what the receiver might or might not do. > >For all you know the ISP may choose to automatically send a notice to > >the intended recipient indicating that they dropped mail from > >example.com based on the published request from example.com and that > >if the enduser has any questions they should contact > >postmas...@example.com. > > Ooh, "we're sending you this useless notification instead of what might > have been spam". Just when we thought that had been stamped out. > So you have decided to join the group that claims DKIM and ADSP are about fighting spam rather than being an authentication mechanism. Interesting. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
>Nothing in the ADSP spec says that the ISP has to silently drop the >mail. Actually, it does. Read it again. >For all you know the ISP may choose to automatically send a notice to >the intended recipient indicating that they dropped mail from >example.com based on the published request from example.com and that >if the enduser has any questions they should contact >postmas...@example.com. Ooh, "we're sending you this useless notification instead of what might have been spam". Just when we thought that had been stamped out. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> If an organization doesn't understand the implications of publishing > ADSP (or doing anything else for that matter) then the basic damage > done is to themselves and their users. Their domain, their problem. I think that if you talk to ISPs whose customers call and ask why they didn't get the mail they were expecting, you will find that this assertion is mistaken. In practice, I expect that where a competent DbR and ADSP differ, the DbR would say to ignore the ADSP, they say it's discardable but they're wrong, not the other way around. Amazon is a fairly unusual case, signing everything (as far as I can tell) but not making any public assertions about it. >When random 3rd parties start publishing about domains that is a real >problem. If a random list publisher tells people to drop unsigned mail >by a particular domain - particularly in the absence of an ADSP record - >there is the possibility of them getting sued. This is a significantly >different case then something like SPAM and RBLs. Sigh. I wish people would refrain from giving legal advice in technical fora, particularly legal advice that, in the US at least, is obviously wrong. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
>Maybe we need an ADSP flag that says "I think I sign all my outbound >mail, and if a trusted third party vouches that I'm not entirely >clueless about DKIM then you should trust them and treat this as >"dkim=discardable", but otherwise don't pay too much attention to >this and treat it as "dkim=unknown"". You could certainly use my DbR proposal together with ADSP, and say to drop mail only if both ADSP and DbR say to drop it. Assuming the DbR list were competently run, I'm not sure there'd be any practical advantage, particularly since DbR allows you to check both DK and DKIM. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On 06/24/2010 10:10 AM, Mark Delany wrote: Conceivably "at risk" domains would first submit themselves to such a > service and ask it to discover and publish (and/or feedback) counter > examples. > > Since all you need is one counter example, getting 20 or 30 large, > trusted mail providers to participate in identifying such emails and > domains should be able to know pretty quickly when something has gone > awry with their IT audit. > > John's list then simply becomes a focal point of discovery rather than > a judgment call. That's essentially the same thing that I mentioned with my "clueless" list in a previous post. The question is: once you get checked into the clueless motel, how can you ever check out? This is the same weakness of DNSBL's, fwiw. Worse in this case, because it's really bound up in whether somebody's infrastructure is actually set up correctly, which is hard for the domain's owner and near impossible for an outside third party to determine. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Steve Atkins > Sent: Thursday, June 24, 2010 2:00 PM > To: DKIM List > Subject: Re: [ietf-dkim]New Version Notification for draft-levine-dbr- > 00(fwd) > > > On Jun 24, 2010, at 10:03 AM, MH Michael Hammer (5304) wrote: > > > If an organization doesn't understand the implications of publishing > > ADSP (or doing anything else for that matter) then the basic damage done > > is to themselves and their users. Their domain, their problem. > > ... and the problem of the recipients of their mail, and a support issue > for the ISP of those recipients. > Form response... (I'm putting it tersely) "You need to go speak with the folks at example.com as they are the ones creating the problem". If enough receiving domains stood their ground on this it would quickly become a non-issue. This is no different than receivers blocking MTAs that are open relays. THAT doesn't seem to be much of a topic for conversation these days. > When an ISP starts dealing with complaints about the quality of their > service[1] they will make the obvious operational decision and cease using > ADSP to discard email. > Nothing in the ADSP spec says that the ISP has to silently drop the mail. For all you know the ISP may choose to automatically send a notice to the intended recipient indicating that they dropped mail from example.com based on the published request from example.com and that if the enduser has any questions they should contact postmas...@example.com. I LOVE hypotheticals. For every seemingly reasonable hypothetical you come up with I'm sure that others can come up with one just as reasonable that shows an alternative outcome. > They might well continue discarding non-DKIM signed mail from some subset > of ADSP publishers. > That wouldn't be particularly useful for senders or receivers. How does this differ from the pre-ADSP situation where a handful of large senders cut private deals with a handful of large receivers? The whole point is to come up with a standard so that it is A) open and B) scalable. What you are suggesting is neither. > I think that's a perfectly reasonable operational result, but I don't > think it's the one that those signing with ADSP intended. > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> So my view of the service being discussed here isn't one where some > guy in upstate NY claims to have full knowledge of which domains > DKIM-sign all their outbound email. Rather, it's a service where the > manager of the service uses claims made by the sender about whether > they sign all of their email and then only lists those domains that > know what their doing. Why not have a negative service then? John's list can refute an ADSP of "at risk" domains by including a link of an exemplar unsigned email (ironically provable via SPF if necessary...) Sortof assume ADSP competence until shown otherwise rather than assumed incompetent until judged otherwise? That list would then be quite valuable as a way of letting such domains know that they are vulnerable *and* where their leak is. dig paypal.com._whatever... txt atRisk=y; claimsADSPAll=y; counterExample=http:// Conceivably "at risk" domains would first submit themselves to such a service and ask it to discover and publish (and/or feedback) counter examples. Since all you need is one counter example, getting 20 or 30 large, trusted mail providers to participate in identifying such emails and domains should be able to know pretty quickly when something has gone awry with their IT audit. John's list then simply becomes a focal point of discovery rather than a judgment call. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On Jun 24, 2010, at 10:03 AM, MH Michael Hammer (5304) wrote: > If an organization doesn't understand the implications of publishing > ADSP (or doing anything else for that matter) then the basic damage done > is to themselves and their users. Their domain, their problem. ... and the problem of the recipients of their mail, and a support issue for the ISP of those recipients. When an ISP starts dealing with complaints about the quality of their service[1] they will make the obvious operational decision and cease using ADSP to discard email. They might well continue discarding non-DKIM signed mail from some subset of ADSP publishers. I think that's a perfectly reasonable operational result, but I don't think it's the one that those signing with ADSP intended. Cheers, Steve [1] silently dropping mail that's wanted by the recipients is about the worst failure of an email provider, and ADSP is likely to be applied mostly to mail that the sender believes is important and wanted by recipients, as if the mail itself didn't have perceived high value then phishes based on it wouldn't be of high value either. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Michael Thomas > Sent: Thursday, June 24, 2010 12:53 PM > To: Martijn Grooten > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim]New Version Notification for draft-levine-dbr- > 00(fwd) > > On 06/24/2010 08:45 AM, Martijn Grooten wrote: > >> So why does a domain that performs that painful audit and > >> remediation need to then tell John's drop list that it's OK to > >> drop unsigned mail? It doesn't. It can just publish an ADSP > >> record and be done with it. No need to count on some unreliable, > >> unaccountable point of failure to mediate their business. > > > > What if it publishes an ADSP record but doesn't understand the > implications? Because, for instance, they send a lot of email to mailing > lists. Or because to some emails, an MTA adds some blurb to the body after > the DKIM signature has been computed. Or because they forget that in some > (rare) cases they do not sign their email. (The latter happened to GMail > who, without having published an ADSP record, had said that all of their > email was DKIM-signed. Some of it wasn't. At least one commercial spam > filter used GMail's claim to block unsigned email coming from GMail.) > > There are an infinite number of ways to shoot yourself in the foot. > They could also stop signing with DKIM on weekends so they can give > their DKIM signers some well earned rest and relaxation too. > > > So my view of the service being discussed here isn't one where some guy > in upstate NY claims to have full knowledge of which domains DKIM-sign all > their outbound email. Rather, it's a service where the manager of the > service uses claims made by the sender about whether they sign all of > their email and then only lists those domains that know what their doing. > > In this instance, not even the guy in upstate NY can keep things straight > with his > own small database. > I come in to the fray on the side of Michael. +1 If an organization doesn't understand the implications of publishing ADSP (or doing anything else for that matter) then the basic damage done is to themselves and their users. Their domain, their problem. The case where a domain owner contracts with 3rd parties such as eCert, Authentication Metrics, Return Path, Truedomain or others means that the 3rd party is acting on their behalf. If the 3rd party gets it wrong in this case then it is a contractual issue between the sending domain and the organization they contract with. When random 3rd parties start publishing about domains that is a real problem. If a random list publisher tells people to drop unsigned mail by a particular domain - particularly in the absence of an ADSP record - there is the possibility of them getting sued. This is a significantly different case then something like SPAM and RBLs. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On 06/24/2010 09:28 AM, J.D. Falk wrote: > On Jun 24, 2010, at 9:21 AM, Michael Thomas wrote: > >> Any service that doesn't have an *explicit* guarantee from the mail >> domain itself that it signs all mail is worse than incompetent, >> it's harmful. A third party can *never* prove the negative that the >> domain in question doesn't have sources of unsigned mail that they >> don't want discarded. The domain in question without a thorough >> audit probably doesn't have a clue itself if it's even vaguely >> largeish. >> >> So why does a domain that performs that painful audit and >> remediation need to then tell John's drop list that it's OK to >> drop unsigned mail? It doesn't. It can just publish an ADSP >> record and be done with it. No need to count on some unreliable, >> unaccountable point of failure to mediate their business. > > Why do you keep assuming that John's proof-of-concept drop list is the only > way a drop list can ever operate? So what is incorrect about what I wrote? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On 06/24/2010 09:36 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of Steve Atkins >> Sent: Thursday, June 24, 2010 8:43 AM >> To: DKIM List >> Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr- >> 00(fwd) >> >> The problem is that it's not possible to distinguish based solely on >> self-published data the domain that's done all that work, and actually >> understands the implications from the domain that's just published >> an ADSP record because they'd heard it was a good idea, with no >> understanding of the effect that would have on their email. > > I don't think it's guaranteed that this is the case even if you go to the > site and personally interview the people that work there. I agree it > increases your chances, but it's not a bulletproof solution either. And over > time, any such guarantee you do manage to eke out could easily (and perhaps > is likely to) erode. > > If the intent is to find something that works all the time, we should give up > now. > > If we're okay with approximations, I'm not sure self-publication should be so > easily disqualified. Right. If there's some value here, it would be a "clueless" service instead of a "drop" service. Ie, "they say they know what they're doing, but don't". But even that runs afoul of proving a negative because if the listed domain ever screwed up for any reason, the "clueless" list could latch on to that and never let go... how is it to know that the transgression has been remediated? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On 06/24/2010 08:45 AM, Martijn Grooten wrote: >> So why does a domain that performs that painful audit and >> remediation need to then tell John's drop list that it's OK to >> drop unsigned mail? It doesn't. It can just publish an ADSP >> record and be done with it. No need to count on some unreliable, >> unaccountable point of failure to mediate their business. > > What if it publishes an ADSP record but doesn't understand the implications? > Because, for instance, they send a lot of email to mailing lists. Or because > to some emails, an MTA adds some blurb to the body after the DKIM signature > has been computed. Or because they forget that in some (rare) cases they do > not sign their email. (The latter happened to GMail who, without having > published an ADSP record, had said that all of their email was DKIM-signed. > Some of it wasn't. At least one commercial spam filter used GMail's claim to > block unsigned email coming from GMail.) There are an infinite number of ways to shoot yourself in the foot. They could also stop signing with DKIM on weekends so they can give their DKIM signers some well earned rest and relaxation too. > So my view of the service being discussed here isn't one where some guy in > upstate NY claims to have full knowledge of which domains DKIM-sign all their > outbound email. Rather, it's a service where the manager of the service uses > claims made by the sender about whether they sign all of their email and then > only lists those domains that know what their doing. In this instance, not even the guy in upstate NY can keep things straight with his own small database. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On 06/24/2010 08:43 AM, Steve Atkins wrote: > > On Jun 24, 2010, at 8:21 AM, Michael Thomas wrote: > >> On 06/24/2010 07:49 AM, John Levine wrote: >> Are you making the assumption that all third party lists would be equally >>> credible? That's no more likely than all DNSBLs being equally credible. >>> >>> In both cases, the good ones will make sure their data is correct, >>> maybe by backchannels to the underying providers (see the Spamhaus PBL >>> for an example of that) or by some kind of feedback watching the mail >>> they make assertions about. The bad ones won't do that, and won't be >>> useful. (See any number of useless poorly run DNSBLs for an example >>> of that.) >> >> Any service that doesn't have an *explicit* guarantee from the mail >> domain itself that it signs all mail is worse than incompetent, >> it's harmful. A third party can *never* prove the negative that the >> domain in question doesn't have sources of unsigned mail that they >> don't want discarded. The domain in question without a thourough >> audit probably doesn't have a clue itself if it's even vaguely >> largeish. >> >> So why does a domain that performs that painful audit and >> remediation need to then tell John's drop list that it's OK to >> drop unsigned mail? It doesn't. It can just publish an ADSP >> record and be done with it. No need to count on some unreliable, >> unaccountable point of failure to mediate their business. > > The problem is that it's not possible to distinguish based solely on > self-published data the domain that's done all that work, and actually > understands the implications from the domain that's just published > an ADSP record because they'd heard it was a good idea, with no > understanding of the effect that would have on their email. Sure. And it's a bad idea to set your MX records to 127.0.0.1 because you heard it stops spam cold too. > Even paypal, who are one of the main forces driving ADSP, didn't > think through the most basic implications, and caused a lot of > legitimate email that was from their domains, yet not DKIM signed > to be received. If recipient use of ADSP were widespread then > that would have been a business failure rather than just an > embarrassment. If people actually deployed ADSP receivers, there'd be a big incentive for the publishers to get clue too. > Given that, the odds that any given ADSP-discardable record is > something that it makes operational sense to use is pretty low. > And no competent mailbox operator will want to allow untrusted > third parties to control the service they provide to their customers - > delivery of email. That's a bizarre use of "third party". The From sending domain isn't a "third party" under any definition I can think of. > A similar argument applies to third party lists, including those > run by John, ReturnPath and Spamhaus, with the critical difference > that each of those lists is a single entity, rather than the ADSP-discardable > pseudo-list, which is run by as many different people as their are > domains, so their accuracy can be tracked > over time, and their data only used once it's demonstrated itself to > be accurate enough to have operational benefits. A single entity that the domain in question has absolutely no idea about, and certainly no control over. Considering that their listing is exactly as accurate as the domain in question's own due diligence in the best case, and completely wrong in the average case, why would anybody trust it over the domain's own assertion? This looks to me like a business in search of a vict^H^H^H^Hcustomer. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Steve Atkins > Sent: Thursday, June 24, 2010 8:43 AM > To: DKIM List > Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr- > 00(fwd) > > The problem is that it's not possible to distinguish based solely on > self-published data the domain that's done all that work, and actually > understands the implications from the domain that's just published > an ADSP record because they'd heard it was a good idea, with no > understanding of the effect that would have on their email. I don't think it's guaranteed that this is the case even if you go to the site and personally interview the people that work there. I agree it increases your chances, but it's not a bulletproof solution either. And over time, any such guarantee you do manage to eke out could easily (and perhaps is likely to) erode. If the intent is to find something that works all the time, we should give up now. If we're okay with approximations, I'm not sure self-publication should be so easily disqualified. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On Jun 24, 2010, at 8:45 AM, Martijn Grooten wrote: >> So why does a domain that performs that painful audit and >> remediation need to then tell John's drop list that it's OK to >> drop unsigned mail? It doesn't. It can just publish an ADSP >> record and be done with it. No need to count on some unreliable, >> unaccountable point of failure to mediate their business. > > What if it publishes an ADSP record but doesn't understand the implications? > Because, for instance, they send a lot of email to mailing lists. Or because > to some emails, an MTA adds some blurb to the body after the DKIM signature > has been computed. Or because they forget that in some (rare) cases they do > not sign their email. (The latter happened to GMail who, without having > published an ADSP record, had said that all of their email was DKIM-signed. > Some of it wasn't. At least one commercial spam filter used GMail's claim to > block unsigned email coming from GMail.) > > So my view of the service being discussed here isn't one where some guy in > upstate NY claims to have full knowledge of which domains DKIM-sign all their > outbound email. Rather, it's a service where the manager of the service uses > claims made by the sender about whether they sign all of their email and then > only lists those domains that know what their doing. Maybe we need an ADSP flag that says "I think I sign all my outbound mail, and if a trusted third party vouches that I'm not entirely clueless about DKIM then you should trust them and treat this as "dkim=discardable", but otherwise don't pay too much attention to this and treat it as "dkim=unknown"". Or maybe that's what "dkim=all" already means. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On Jun 24, 2010, at 9:21 AM, Michael Thomas wrote: > Any service that doesn't have an *explicit* guarantee from the mail > domain itself that it signs all mail is worse than incompetent, > it's harmful. A third party can *never* prove the negative that the > domain in question doesn't have sources of unsigned mail that they > don't want discarded. The domain in question without a thourough > audit probably doesn't have a clue itself if it's even vaguely > largeish. > > So why does a domain that performs that painful audit and > remediation need to then tell John's drop list that it's OK to > drop unsigned mail? It doesn't. It can just publish an ADSP > record and be done with it. No need to count on some unreliable, > unaccountable point of failure to mediate their business. Why do you keep assuming that John's proof-of-concept drop list is the only way a drop list can ever operate? -- J.D. Falk Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
> So why does a domain that performs that painful audit and > remediation need to then tell John's drop list that it's OK to > drop unsigned mail? It doesn't. It can just publish an ADSP > record and be done with it. No need to count on some unreliable, > unaccountable point of failure to mediate their business. What if it publishes an ADSP record but doesn't understand the implications? Because, for instance, they send a lot of email to mailing lists. Or because to some emails, an MTA adds some blurb to the body after the DKIM signature has been computed. Or because they forget that in some (rare) cases they do not sign their email. (The latter happened to GMail who, without having published an ADSP record, had said that all of their email was DKIM-signed. Some of it wasn't. At least one commercial spam filter used GMail's claim to block unsigned email coming from GMail.) So my view of the service being discussed here isn't one where some guy in upstate NY claims to have full knowledge of which domains DKIM-sign all their outbound email. Rather, it's a service where the manager of the service uses claims made by the sender about whether they sign all of their email and then only lists those domains that know what their doing. Just my two cents. Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On Jun 24, 2010, at 8:21 AM, Michael Thomas wrote: > On 06/24/2010 07:49 AM, John Levine wrote: > Are you making the assumption that all third party lists would be equally >> credible? That's no more likely than all DNSBLs being equally credible. >> >> In both cases, the good ones will make sure their data is correct, >> maybe by backchannels to the underying providers (see the Spamhaus PBL >> for an example of that) or by some kind of feedback watching the mail >> they make assertions about. The bad ones won't do that, and won't be >> useful. (See any number of useless poorly run DNSBLs for an example >> of that.) > > Any service that doesn't have an *explicit* guarantee from the mail > domain itself that it signs all mail is worse than incompetent, > it's harmful. A third party can *never* prove the negative that the > domain in question doesn't have sources of unsigned mail that they > don't want discarded. The domain in question without a thourough > audit probably doesn't have a clue itself if it's even vaguely > largeish. > > So why does a domain that performs that painful audit and > remediation need to then tell John's drop list that it's OK to > drop unsigned mail? It doesn't. It can just publish an ADSP > record and be done with it. No need to count on some unreliable, > unaccountable point of failure to mediate their business. The problem is that it's not possible to distinguish based solely on self-published data the domain that's done all that work, and actually understands the implications from the domain that's just published an ADSP record because they'd heard it was a good idea, with no understanding of the effect that would have on their email. Even paypal, who are one of the main forces driving ADSP, didn't think through the most basic implications, and caused a lot of legitimate email that was from their domains, yet not DKIM signed to be received. If recipient use of ADSP were widespread then that would have been a business failure rather than just an embarrassment. Given that, the odds that any given ADSP-discardable record is something that it makes operational sense to use is pretty low. And no competent mailbox operator will want to allow untrusted third parties to control the service they provide to their customers - delivery of email. A similar argument applies to third party lists, including those run by John, ReturnPath and Spamhaus, with the critical difference that each of those lists is a single entity, rather than the ADSP-discardable pseudo-list, which is run by as many different people as their are domains, so their accuracy can be tracked over time, and their data only used once it's demonstrated itself to be accurate enough to have operational benefits. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
On 06/24/2010 07:49 AM, John Levine wrote: Are you making the assumption that all third party lists would be equally > credible? That's no more likely than all DNSBLs being equally credible. > > In both cases, the good ones will make sure their data is correct, > maybe by backchannels to the underying providers (see the Spamhaus PBL > for an example of that) or by some kind of feedback watching the mail > they make assertions about. The bad ones won't do that, and won't be > useful. (See any number of useless poorly run DNSBLs for an example > of that.) Any service that doesn't have an *explicit* guarantee from the mail domain itself that it signs all mail is worse than incompetent, it's harmful. A third party can *never* prove the negative that the domain in question doesn't have sources of unsigned mail that they don't want discarded. The domain in question without a thourough audit probably doesn't have a clue itself if it's even vaguely largeish. So why does a domain that performs that painful audit and remediation need to then tell John's drop list that it's OK to drop unsigned mail? It doesn't. It can just publish an ADSP record and be done with it. No need to count on some unreliable, unaccountable point of failure to mediate their business. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
In article <147cede9c1299e4aa...@lewes.staff.uscs.susx.ac.uk> you write: > > >--On 23 June 2010 13:09:30 + deepvo...@gmail.com wrote: > >> Since Amazon set it up in the first place, wouldn't they be keenly aware >> of the service signing issues? > >Well, if they're using ADSP, then they have a chance. But it's going to be >difficult for them to keep track of the third party assertions made about >their services. Are you making the assumption that all third party lists would be equally credible? That's no more likely than all DNSBLs being equally credible. In both cases, the good ones will make sure their data is correct, maybe by backchannels to the underying providers (see the Spamhaus PBL for an example of that) or by some kind of feedback watching the mail they make assertions about. The bad ones won't do that, and won't be useful. (See any number of useless poorly run DNSBLs for an example of that.) I'm not attempting to invent a way to ensure that all assertions are correct. It's a way to collect assertions into small enough groups that it's practical to do manual checks of the credibility of each group. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00(fwd)
--On 23 June 2010 13:09:30 + deepvo...@gmail.com wrote: > Since Amazon set it up in the first place, wouldn't they be keenly aware > of the service signing issues? Well, if they're using ADSP, then they have a chance. But it's going to be difficult for them to keep track of the third party assertions made about their services. I think it's worse to drop mail because Amazon are no longer doing what some third party thought they were doing, than it is to drop mail because Amazon published incorrect records. I might find some value in a list that asserts "You can trust the ADSP records for these domains" than a list that asserts "These domains always sign their email..." > > Mute point if they understand what they are doing. > > > Regards, > Damon Sauer. > > Sent from my Verizon Wireless BlackBerry > > -Original Message- > From: Douglas Otis > Sender: ietf-dkim-boun...@mipassoc.org > Date: Tue, 22 Jun 2010 17:37:26 > To: > Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 > (fwd) > > On 6/22/10 5:07 PM, John Levine wrote: >> Not quite, it's a third party's assertions that are somewhat but not >> really like ADSP >> >> As far as I know Amazon doesn't make any ADSP assertions, but it is my >> impression that they sign all their transactions with DK or DKIM, and >> they're certainly a phish target, so it would be reasonable to drop >> unsigned Amazon mail anyway. >> > What happens when Amazon has a service using a parent signature? As a > result of a third-party vouching service, their messages might be > discarded, and they won't become aware of the issue until damage is wide > spread. TINLA, but it seems having a service advocating for the > discard of someone elses's email could be a liability. How does one > determine whether a vouching service is authoritative for the domain in > question? Please don't say use another vouching service, because the > issue is _who_ should decide whether a message must have a valid > Author-Domain signature or be discarded. > > -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 -- 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] New Version Notification for draft-levine-dbr-00(fwd)
Since Amazon set it up in the first place, wouldn't they be keenly aware of the service signing issues? Mute point if they understand what they are doing. Regards, Damon Sauer. Sent from my Verizon Wireless BlackBerry -Original Message- From: Douglas Otis Sender: ietf-dkim-boun...@mipassoc.org Date: Tue, 22 Jun 2010 17:37:26 To: Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd) On 6/22/10 5:07 PM, John Levine wrote: > Not quite, it's a third party's assertions that are somewhat but not really > like ADSP > > As far as I know Amazon doesn't make any ADSP assertions, but it is my > impression that they sign all their transactions with DK or DKIM, and > they're certainly a phish target, so it would be reasonable to drop > unsigned Amazon mail anyway. > What happens when Amazon has a service using a parent signature? As a result of a third-party vouching service, their messages might be discarded, and they won't become aware of the issue until damage is wide spread. TINLA, but it seems having a service advocating for the discard of someone elses's email could be a liability. How does one determine whether a vouching service is authoritative for the domain in question? Please don't say use another vouching service, because the issue is _who_ should decide whether a message must have a valid Author-Domain signature or be discarded. -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] New Version Notification for draft-levine-dbr-00 (fwd)
On 6/22/10 5:07 PM, John Levine wrote: > Not quite, it's a third party's assertions that are somewhat but not really > like ADSP > > As far as I know Amazon doesn't make any ADSP assertions, but it is my > impression that they sign all their transactions with DK or DKIM, and > they're certainly a phish target, so it would be reasonable to drop > unsigned Amazon mail anyway. > What happens when Amazon has a service using a parent signature? As a result of a third-party vouching service, their messages might be discarded, and they won't become aware of the issue until damage is wide spread. TINLA, but it seems having a service advocating for the discard of someone elses's email could be a liability. How does one determine whether a vouching service is authoritative for the domain in question? Please don't say use another vouching service, because the issue is _who_ should decide whether a message must have a valid Author-Domain signature or be discarded. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On 6/22/10 11:40 AM, bill.ox...@cox.com wrote: > adsp is an assertion by a sender. John's list is a reputation of the sender's > adsp assertions (WAG) > On Jun 22, 2010, at 2:29 PM, Michael Thomas wrote: > The vbr scheme will not help to mitigate a phishing problem, since it allows the "authentication" of any number of other domains. As such, it will not help deal with ADSP issues caused by mailing lists either. The discard vbr represents roughly the same feature as ADSP dkim=discardable, but introduces other types of "authentication/" Allowing more ways to authenticate might allow a small number of emails to be delivered that might have been rejected when a signature is damaged in transport, but this is unlikely, and unlikely to help with mailing lists. Path registration schemes largely depend upon the treatment of headers and parameters holding domains other than the Author Domain. Any domain that uses VBR and a provider handling many other domains might confront a problem caused by treating _authorization_ as being "authentication." Just because something is authorized, does not mean that its origination has been authenticated. In an era where many legitimate accounts are being compromised, DKIM provides a margin of safety where servers commonly carry email for many different domains. The additional protection afforded by DKIM is lost when depending upon discard vbr. :^( -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
In article you write: >adsp is an assertion by a sender. John's list is a reputation of the sender's >adsp assertions (WAG) Not quite, it's a third party's assertions that are somewhat but not really like ADSP As far as I know Amazon doesn't make any ADSP assertions, but it is my impression that they sign all their transactions with DK or DKIM, and they're certainly a phish target, so it would be reasonable to drop unsigned Amazon mail anyway. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
> You can choose to trust his assertions (by querying his list on > verification failures) or ignore them (by not querying him in the > first place). At least that's the theory, I believe. Exactly. This is a scalability issue. You can afford to spend a fair amount of effort investigating the reliability of a VBR service before you decide whether to use it, just like you do investigating the reliability of a DNSBL, because you'll never use more than a handful of either. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
>> As threatened, here's an I-D that says how one would publish a list of >> domains for which it makes sense to discard unsigned mail. > >Looks like a good start, and almost shockingly simple. Any MTA/MFA support >yet? *grin* Give me another week. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
adsp is an assertion by a sender. John's list is a reputation of the sender's adsp assertions (WAG) On Jun 22, 2010, at 2:29 PM, Michael Thomas wrote: > On 06/22/2010 11:07 AM, J.D. Falk wrote: >> On Jun 22, 2010, at 11:28 AM, Michael Thomas wrote: >> >>> On 06/22/2010 09:46 AM, J.D. Falk wrote: On Jun 21, 2010, at 1:00 PM, John R. Levine wrote: > As threatened, here's an I-D that says how one would publish a list of > domains for which it makes sense to discard unsigned mail. Looks like a good start, and almost shockingly simple. Any MTA/MFA support yet? *grin* >>> >>> I still don't get why it's ok for John Levine to publish a list which >>> says that it's ok to discard unsigned mail from paypal.com, but st00pid >>> for paypal.com to publish the same thing. That is the essence of his >>> jihad against adsp. >> >> Because presumably verifiers will trust John's process for compiling this >> list more than they'd trust any random schmoe with the ability to create TXT >> records. >> >> (If paypal were representative of all domains, this wouldn't be a concern.) > > Well that's pretty ironic because paypal.com is listed in his database > as being discardable even after he got done telling them they were incompetent > for setting their ADSP record to discardable since they mix users and > transactional > mail all in the same sub domain. So it seems that John isn't any more > competent > than paypal.com by his own competency test. > >> Personally, I think we'll need lists like this for a while in order to gain >> more experience and determine best practices, and THEN we can decide whether >> to change (or even scrap) ADSP to reflect those practices. > > Who watches the watcher? > > I'm very dubious that John can do that without explict bidirectional human > correspondence. > Which is no different than paypal.com publishing their ADSP record since > the people who put up the ADSP record are extremely likely to be the same > people > telling John's list that they want to be set to discardable. What the value > add for > the middle man is here -- besides faithfully copying errors -- is a mystery. > > Mike > ___ > 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] New Version Notification for draft-levine-dbr-00 (fwd)
On 6/22/10 9:46 AM, J.D. Falk wrote: > On Jun 21, 2010, at 1:00 PM, John R. Levine wrote: > > >> As threatened, here's an I-D that says how one would publish a list of >> domains for which it makes sense to discard unsigned mail. >> > Looks like a good start, and almost shockingly simple. Any MTA/MFA support > yet? *grin* > If only it was simple. How do you envision the VBR scheme offering protection for phished domains? ADSP imposes a specific Author Domain policy related to DKIM. Whereas, the VBR-Info header might apply against _ANY_: i) DKIM signature domain, or ii) Return-Path, or iii) PRA. (from, sender, resent-*, etc.) Except for Author Domains, these other domains are typically not visible. Vouching information from a service selected by a vbr-info header can now include a discard recommendation, in addition good/bad ratings used to adjust spam scores. Without a DKIM signature, the vbr-info header can include anything, and make use of recycled domains in any of a number of invisible domains, such as the return-path, resent-sender, etc. How would vbr-info header and an additional discard status mitigate abuse when it can be based on many invisible domains? How will discard be different from returning extremely negative ratings? The duration of domains used to phish is often measured in hours, where an arbitrary use of path registration will not protect phished domains. Wack-a-Mole does not work very well. What protection will a Resent-Sender header offer when mitigating a phishing problem? Isn't vouching and reputation outside the DKIM WG? BTW, does MFA mean Mail Forwarding Agent? -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Michael Thomas > Sent: Tuesday, June 22, 2010 10:28 AM > To: J.D. Falk > Cc: DKIM List > Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 > (fwd) > > I still don't get why it's ok for John Levine to publish a list which > says that it's ok to discard unsigned mail from paypal.com, but st00pid > for paypal.com to publish the same thing. That is the essence of his > jihad against adsp. In the context of VBR, it's the same programming logic as him (or anyone) vouching for a particular domain as having trustworthy transactional or other mail. He's just asserting ADSP on someone else's behalf in this case. You can choose to trust his assertions (by querying his list on verification failures) or ignore them (by not querying him in the first place). At least that's the theory, I believe. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On 06/22/2010 11:07 AM, J.D. Falk wrote: > On Jun 22, 2010, at 11:28 AM, Michael Thomas wrote: > >> On 06/22/2010 09:46 AM, J.D. Falk wrote: >>> On Jun 21, 2010, at 1:00 PM, John R. Levine wrote: >>> As threatened, here's an I-D that says how one would publish a list of domains for which it makes sense to discard unsigned mail. >>> >>> Looks like a good start, and almost shockingly simple. Any MTA/MFA support >>> yet? *grin* >> >> I still don't get why it's ok for John Levine to publish a list which >> says that it's ok to discard unsigned mail from paypal.com, but st00pid >> for paypal.com to publish the same thing. That is the essence of his >> jihad against adsp. > > Because presumably verifiers will trust John's process for compiling this > list more than they'd trust any random schmoe with the ability to create TXT > records. > > (If paypal were representative of all domains, this wouldn't be a concern.) Well that's pretty ironic because paypal.com is listed in his database as being discardable even after he got done telling them they were incompetent for setting their ADSP record to discardable since they mix users and transactional mail all in the same sub domain. So it seems that John isn't any more competent than paypal.com by his own competency test. > Personally, I think we'll need lists like this for a while in order to gain > more experience and determine best practices, and THEN we can decide whether > to change (or even scrap) ADSP to reflect those practices. Who watches the watcher? I'm very dubious that John can do that without explict bidirectional human correspondence. Which is no different than paypal.com publishing their ADSP record since the people who put up the ADSP record are extremely likely to be the same people telling John's list that they want to be set to discardable. What the value add for the middle man is here -- besides faithfully copying errors -- is a mystery. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On 06/22/2010 09:46 AM, J.D. Falk wrote: > On Jun 21, 2010, at 1:00 PM, John R. Levine wrote: > >> As threatened, here's an I-D that says how one would publish a list of >> domains for which it makes sense to discard unsigned mail. > > Looks like a good start, and almost shockingly simple. Any MTA/MFA support > yet? *grin* I still don't get why it's ok for John Levine to publish a list which says that it's ok to discard unsigned mail from paypal.com, but st00pid for paypal.com to publish the same thing. That is the essence of his jihad against adsp. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jun 22, 2010, at 11:28 AM, Michael Thomas wrote: > On 06/22/2010 09:46 AM, J.D. Falk wrote: >> On Jun 21, 2010, at 1:00 PM, John R. Levine wrote: >> >>> As threatened, here's an I-D that says how one would publish a list of >>> domains for which it makes sense to discard unsigned mail. >> >> Looks like a good start, and almost shockingly simple. Any MTA/MFA support >> yet? *grin* > > I still don't get why it's ok for John Levine to publish a list which > says that it's ok to discard unsigned mail from paypal.com, but st00pid > for paypal.com to publish the same thing. That is the essence of his > jihad against adsp. Because presumably verifiers will trust John's process for compiling this list more than they'd trust any random schmoe with the ability to create TXT records. (If paypal were representative of all domains, this wouldn't be a concern.) Personally, I think we'll need lists like this for a while in order to gain more experience and determine best practices, and THEN we can decide whether to change (or even scrap) ADSP to reflect those practices. -- J.D. Falk Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On Jun 21, 2010, at 1:00 PM, John R. Levine wrote: > As threatened, here's an I-D that says how one would publish a list of > domains for which it makes sense to discard unsigned mail. Looks like a good start, and almost shockingly simple. Any MTA/MFA support yet? *grin* -- J.D. Falk Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
On 6/21/10 12:00 PM, John R. Levine wrote: > As threatened, here's an I-D that says how one would publish a list > of domains for which it makes sense to discard unsigned mail. > > Since I'm a big fan of running code, you can find such a list at > drop.services.net of domains that (in my opinion at least) sign all > their mail with DK or DKIM, and for whom it makes sense to drop > unsigned mail. John, What motivates using two domains in a query, which still excludes the relationship between the author-domain and third-party service? The tpa-label scheme is informative of a specific relationship between author-domain and third-party service, thereby allowing responses for specific threats and requirements of the author domain. Why not allow a means for domains to indicate they don't use some social network, without making the third-party service unusable for any other domain? A vouching (reputation) service that protects against spoofing using the vbr structure will likely confront difficult to resolve administrative problems. Thresholds for blocking a domain will likely cause collateral losses for other domains not normally phished when other domains are being heavily phished. Because DKIM signatures can be replayed, including ancillary conditions, such as requiring an List-ID or Sender header, better isolates poorly vetted messages without users seeing different email domains used. Of course, these headers depend upon the relationship between the third-party service and the author-domain. The tpa-label scheme allows selective inclusion of other header requirements based upon the author-domain. This information allows recipients to depend upon these headers when sorting messages having different levels of vetting. If these specific relationships are not met, the message would be refused. IMHO, it would be less problematic to use the tpa-label mechanism to make this type of query. The tpa-label scheme has been improved by isolating the hash labels. Unlike vbr, the tpa-label has less of an impact on the usable domain name. Allowable maximums are not reduced by the size of vouching domain and _vouch label. With tpa-labels, a vouching service can handle a domain size up to 241 characters. When a domain provides their own vbr vouching service, the maximal domain size may be a maximum length of 122 characters. This smaller size may not work well for international domain names. The added reference size of vbr also displaces information bound by a DNS response limit, and results in more of cache being consumed as well, while still omitting information specific to the third-party service and the author domain. With tpa-labels, a signer can utilize a vouching service by delegating their _tpa zone, or by using DNAME at this node. Domains can also self publish their own exception criteria in a manner transparent to recipients. In addition, except for the indirection and extra transaction, there does not appear to be a significant difference between discard by reference and ADSP dkim=discardable? -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
> dig txt paypal.com._drop.services.net > > does not give me anything... Right, because that's not the syntax of VBR. Try this: paypal.com._vouch.drop.services.net R's, John > > - Original Message - > From: "John R. Levine" > To: "DKIM List" > Sent: Tuesday, 22 June, 2010 7:00:15 AM > Subject: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd) > > As threatened, here's an I-D that says how one would publish a list of > domains for which it makes sense to discard unsigned mail. > > Since I'm a big fan of running code, you can find such a list at > drop.services.net of domains that (in my opinion at least) sign all their > mail with DK or DKIM, and for whom it makes sense to drop unsigned mail. > > R's, > John > > Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
dig txt paypal.com._drop.services.net does not give me anything... - Original Message - From: "John R. Levine" To: "DKIM List" Sent: Tuesday, 22 June, 2010 7:00:15 AM Subject: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd) As threatened, here's an I-D that says how one would publish a list of domains for which it makes sense to discard unsigned mail. Since I'm a big fan of running code, you can find such a list at drop.services.net of domains that (in my opinion at least) sign all their mail with DK or DKIM, and for whom it makes sense to drop unsigned mail. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
