[ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
Douglas Otis wrote: IIRC, Sendmail defined DISCARD in their Access Database Format, where to override rejection, assert OK; to permit relaying, assert RELAY; to always reject the message, assert REJECT; and to discard the message completely, assert DISCARD. And the Postfix man page for accesss defines DISCARD as: Claim successful delivery and silently discard the message. Log the optional text if specified, otherwise log a generic message. But the fact that Sendmail or Postfix define it this way does not necessarily mean that discard/discardable has the same meaning in the context of ADSP. If discardable needs further definition, it has to be defined in the context of ADSP in the next revision of the ADSP document. Unfortunately, ADSP did not define what was meant by discardable. This draft could add clarity with a section that defines its meaning. No, not in this BCP draft. It has to be defined in the next revision of the ADSP document. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
--On 26 May 2010 11:48:53 -0700 Michael Thomas m...@mtcc.com wrote: Perhaps I'm missing something. I'm working with the mental model that the underlying problem ADSP advocates would like to address is phishing or brand protection, as they're the only concrete problems I've seen mentioned. So you're on a tangent about something that's not even vaguely in our charter. ADSP doesn't claim to solve phishing, it just allows bit-for-bit domain names to be safely tossed if they don't have a signature. How that integrates into the larger anti-phishing modules is frankly where the secret sauce lies for vendors. Addressing an issue and solving it aren't the same things. Heck, neither is even a prerequisite for the other, given that some problems are self-resolving or solved accidentally. -- 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] list vs contributor signatures, was Wrong Discussion
--On 26 May 2010 14:00:54 -0700 Steve Atkins st...@wordtothewise.com wrote: Given that, it's not something that will provide any benefit once ADSP is deployed - maybe just the opposite, as it will effectively neuter the approach you're currently using. You may win the battle of preventing use of the string paypal.com in the non-displayed part of the From: field, yet lose the war of protecting your users from phishers. There's nothing undisplayed about the From header in my mail client. Mail clients that don't display the From header address probably should not be used. In future, I'll bet they'll display the DKIM/ADSP status, too. -- 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] list vs contributor signatures, was Wrong Discussion
--On 27 May 2010 21:57:54 -0400 John R. Levine jo...@iecc.com wrote: We have had ADSP deployed since the week before the February MAAWG meeting. I just asked our infrastructure guru to do a quick check and we are seeing about a million ADSP look-up's per day at this point. That's a good start. Now we need to figure out some way to find out who's doing those lookups, and what they're doing with them. It should be fairly easy to figure out how many unique IP addresses are doing the lookups, and give some view of the distribution. And then not too hard to figure out how many of those IP addresses don't belong to the top 5 or so mailbox providers. If paypal want to broaden the uptake of ADSP, then contributing DKIM/ADSP code or config recipes to open source MTA projects would be useful! -- 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] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 4:08 AM, Ian Eiloart wrote: --On 26 May 2010 14:00:54 -0700 Steve Atkinsst...@wordtothewise.com wrote: You may win the battle of preventing use of the string paypal.com in the non-displayed part of the From: field, yet lose the war of protecting your users from phishers. There's nothing undisplayed about the From header in my mail client. That's nice, but it is no longer typical. Far From: it Mail clients that don't display the From header address probably should not be used. As soon as you convince all of the major MUAs to change and as soon as those changes propagate into the user world, it will be reasonable to worry about whether displaying the information matters. That is, it will be reasonable to then ask whether users will assess the validity of that information and make intelligent decisions based on it. (Hint: user interface works makes pretty clear that they won't...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
--On 27 May 2010 14:57:06 -0700 Steve Atkins st...@wordtothewise.com wrote: On May 27, 2010, at 2:22 PM, Steve Atkins thinkoed: Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% rejected. That should be Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% not rejected. How many used �...@paypal.com? Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
--On 28 May 2010 13:26:28 -0700 Dave CROCKER d...@dcrocker.net wrote: On 5/28/2010 12:07 PM, Jeff Macdonald wrote: But I'd like to see if I understand the difference your are trying to highlight between a manually maintained list and a self published list. There is a key semantic difference which, I believe, makes for a key difference in utility. In a manually maintained list, there is an independent assessment of what domain names are worth worrying about. (The independence is from the owner of the domain. The assessment might be by a third part or it might be by the recipient.) The owner-based list is a statement by the domain owner, themselves, of what domains the recipient should handle in a particular way. An important problem with this latter model is how noisy it is. Both the domain owner and the transmission process introduce significant errors. By contrast, the former model can incorporate a conformance metric into the decision whether to list the domain. Actually, the difference is less than you think. It's quite possible to combine both models. Spamassassin, for example, allows you to maintain a list of domains for which you should treat SPF or DKIM matches or fails in a particular way. For example, you could tell spamassassin to blacklist SPF fails for certain domains, or whitelist messages DKIM signed by certain domains. Effectively, you're applying your own domain reputation system, and using SPF or DKIM published information to make the reputations more usable. Similarly, with ADSP you don't have to rely on published information, and when information is published, you don't have to guess whether the publisher is competent. You can maintain your own list of domains that you trust to get ADSP right, and use standard software to apply that judgement. Several benefits are gained from ADSP: 1. Code reuse: Although you may choose to maintain your drop list, you don't have to write software for your MTA, you can just configure it. 2. Discoverability: You can find out from ADSP publications that the sender cares about this stuff. OK, it's still a leap to add them to your drop list, but you do at least have somewhere to start. If a large sender and receiver come to a private agreement about DKIM use, then only they benefit. If they choose to use ADSP to implement that agreement, then other mail systems can also benefit. 3. Discussability: given that it's a standard, potential users can read about best practice, and senders and receivers have a common language to talk about how things should work. -- 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] list vs contributor signatures, was Wrong Discussion
That's a good start. Now we need to figure out some way to find out who's doing those lookups, and what they're doing with them. It should be fairly easy to figure out how many unique IP addresses are doing the lookups, and give some view of the distribution. And then not too hard to figure out how many of those IP addresses don't belong to the top 5 or so mailbox providers. That would be of some help, but the real question is what they're doing with it after they get it. The top mailbox providers presumably have reasonable DNS caches, so their lookups will be imperceptible anyway. Since few people in the world at large understand DKIM, much less ADSP, the large numbers of lookups that Brett reports must be coming from software packages that have a configuration that looks them up. It might be possible to intuit from the details of the lookups, e.g., the sequence of queries, what packages they are, at which point we could probably look and see what they're doing with them. If paypal want to broaden the uptake of ADSP, then contributing DKIM/ADSP code or config recipes to open source MTA projects would be useful! There's ADSP code in Spamassassin for anyone who wants it. They suggest that you configure it to ignore actual ADSP and hard code a handful of domains such as paypal.com and ebay.com. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 4:46 AM, Ian Eiloart wrote: --On 28 May 2010 13:26:28 -0700 Dave CROCKERd...@dcrocker.net wrote: On 5/28/2010 12:07 PM, Jeff Macdonald wrote: But I'd like to see if I understand the difference your are trying to highlight between a manually maintained list and a self published list. There is a key semantic difference which, I believe, makes for a key difference in utility. ... Actually, the difference is less than you think. It's quite possible to combine both models. You do not discuss combining the models. You discuss a tool that supports both. Juggling two things is not the same as combining them. In any event, the scope of this working group does not include design of filtering engines. It stops with providing filtering engines additional information. My previous point was -- and remains -- that the fundamental semantics of self-published information about a signer is entirely different from assessment information about that signer that is published by someone else. No software design eliminates that difference. Effectively, you're applying your own domain reputation system, and using SPF or DKIM published information to make the reputations more usable. That's not a reputation system. It's possibly useful information, but it's not reputation as the term is typically used in the industry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
Unfortunately, ADSP did not define what was meant by discardable. We said: 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. Keeping in mind that senders cannot force receivers to do anything, what else should we have said? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
Similarly, with ADSP you don't have to rely on published information, and when information is published, you don't have to guess whether the publisher is competent. You can maintain your own list of domains that you trust to get ADSP right, and use standard software to apply that judgement. Manual drop lists are a fine idea, but what do they have to do with ADSP? 1. Code reuse: Although you may choose to maintain your drop list, you don't have to write software for your MTA, you can just configure it. I'm happy to reuse the manual drop code in Spamassassin. I still don't see what it has to do with ADSP. 2. Discoverability: You can find out from ADSP publications that the sender cares about this stuff. OK, it's still a leap to add them to your drop list, but you do at least have somewhere to start. Here's a thought experiment: let's say you have your list of domains that are known to be phish targets that sign their mail, so you drop unsigned mail, and they all happen to publish ADSP. Someone's ADSP record goes away. Is it more likely that they've stopped signing their mail, or that their ADSP record is temporarily messed up? Why? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
--On 2 June 2010 08:35:56 -0400 John R. Levine jo...@iecc.com wrote: There's ADSP code in Spamassassin for anyone who wants it. They suggest that you configure it to ignore actual ADSP and hard code a handful of domains such as paypal.com and ebay.com. Why not do both? Look up, and log results for all domains. That'll give you evidence to base listing decisions on later. If you do decide to list a domain, then take action based on published policy. That gives the publisher the ability to change their policy without notifying you out of band. -- 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] ADSP and Discardable (was Re: Lists BCP draft review)
John Levine wrote: Unfortunately, ADSP did not define what was meant by discardable. We said: 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. Keeping in mind that senders cannot force receivers to do anything, what else should we have said? given the recent discussions, it seems to me that people want to have a definition of what 'discard' means in the context as described above. As a non-native English speaker (or what's the right term?) I suppose (but am not sure) the word 'discard' can have multiple meanings (apart from 'To throw away'). Otherwise 'silently discard' would be a pleonasm, isn't it? I suggest to put the subject 'discard and discardable' on the to-do list for a next revision of ADSP. If my analysis (that the word 'discard' means different things to different people) is correct, then there's still some discussion to go. After all, throwing away mail silently is contradictory to the original SMTP model (mail is delivered or a NDN comes back) and can have negative impact on the reliability of the e-mail system, as perceived by users of e-mail. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of John Levine Sent: Wednesday, June 02, 2010 9:21 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion snip Here's a thought experiment: let's say you have your list of domains that are known to be phish targets that sign their mail, so you drop unsigned mail, and they all happen to publish ADSP. Someone's ADSP record goes away. Is it more likely that they've stopped signing their mail, or that their ADSP record is temporarily messed up? Why? Signing their mail does not equal ADSP. Knowing they sign their mail does not equal ADSP. As you have pointed out, ADSP does not equal manual drop lists. The fact that someone's ADSP record - absent any other data points - goes away, tells us nothing other than their ADSP record went away. There could be any number of reasons as to why it went away. Are we now going to have to write a draft for casting goat bones to determine the meaning of standards implementations and operational practices? It's really quite simple. If there is no longer an ADSP record then ADSP is not applicable. Doesn't matter whether they are still signing or not signing. If a domains DNS records returned an NXDOMAIN on a lookup would you insist on doing something other than saying the domain doesn't exist? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
given the recent discussions, it seems to me that people want to have a definition of what 'discard' means in the context as described above. As a non-native English speaker (or what's the right term?) I suppose (but am not sure) the word 'discard' can have multiple meanings (apart from 'To throw away'). Otherwise 'silently discard' would be a pleonasm, isn't it? Your English is fine. Discard means throw away. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
On Wed, Jun 2, 2010 at 9:48 AM, John R. Levine jo...@iecc.com wrote: given the recent discussions, it seems to me that people want to have a definition of what 'discard' means in the context as described above. As a non-native English speaker (or what's the right term?) I suppose (but am not sure) the word 'discard' can have multiple meanings (apart from 'To throw away'). Otherwise 'silently discard' would be a pleonasm, isn't it? Your English is fine. Discard means throw away. Agree. Discard and silently discard mean the same thing, in my opinion. Though, I am guilty of using the phrase silently discard. Maybe in an attempt to be slightly over-specific. Cheers, Al ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
On 6/2/2010 8:08 AM, Al Iverson wrote: Agree. Discard and silently discard mean the same thing, in my opinion. Though, I am guilty of using the phrase silently discard. Maybe in an attempt to be slightly over-specific. I do not recall seeing a dictionary or technical definition of discard that says anything at all about whether the discarder says anything at all. Taken on its own and without further technical specifications 'discard' does not direct, imply or request that the action be silent or noisy, and if noisy who gets to hear it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 6:33 AM, MH Michael Hammer (5304) wrote: It's really quite simple. This is the crux of the disparity of views. Those of use who note that none of this is simple worry about adoption and success barriers, noting that new services have a long and problematic history and that more efforts fail than succeed. We also note that operational details often are far more complicated and/or costly than designers anticipate. In other words, as soon as the effort moves outside of a few people's minds, nothing about this is simple. (Well, given the track record of new protocols, in general and security-related protocols in particular, I suppose it is simple and reasonable to anticipate failure.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
--On 2 June 2010 10:48:03 -0400 John R. Levine jo...@iecc.com wrote: given the recent discussions, it seems to me that people want to have a definition of what 'discard' means in the context as described above. As a non-native English speaker (or what's the right term?) I suppose (but am not sure) the word 'discard' can have multiple meanings (apart from 'To throw away'). Otherwise 'silently discard' would be a pleonasm, isn't it? Your English is fine. Discard means throw away. And, to silently discard is to discard without informing anyone. It means, for example, that you don't also generate a bounce message, or a notification to the recipient. My guess is that the phrase the domain encourages the recipient(s) to discard it is intended to refer to a silent discard. Otherwise it would say bounce (which I take to mean discard and notify the sender). Bounce is an unlikely recommendation, since most people don't like to bounce messages of uncertain origin these days. I guess you might bounce if it you had an SPF pass. 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] ADSP and Discardable (was Re: Lists BCP draft review)
On 6/2/2010 8:50 AM, Al Iverson wrote: Taken on its own and without further technical specifications 'discard' does not direct, imply or request that the action be silent or noisy, and if noisy who gets to hear it. I'm perfectly fine with being more explicit, but I do think there's an implication of silent by the use of the word discard in the context of email delivery. Among some folk, perhaps. But this is not the sort of issue that should be relied on by implication or statistical likelihood of interpretation, if there is to be productive discussion and use of the term in a standards arena. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Jun 2, 2010, at 4:50 AM, Ian Eiloart wrote: --On 27 May 2010 14:57:06 -0700 Steve Atkins st...@wordtothewise.com wrote: Legitimate email from paypal: 72% rejected by ADSP 28% not rejected Phishing emails using paypal in the From line: 39% rejected by ADSP 61% not rejected. How many used �...@paypal.com? 100% of the legitimate email from paypal. 39% of the phishing email that used paypal in the From line. (A large fraction of the 61% of the phishing email that ADSP considered legitimate did use @paypal.com, though, IIRC. More use of friendly from and less use of associated domains than I've noticed in recent phishing mail in general.) Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
On Jun 2, 2010, at 8:08 AM, Al Iverson wrote: On Wed, Jun 2, 2010 at 9:48 AM, John R. Levine jo...@iecc.com wrote: given the recent discussions, it seems to me that people want to have a definition of what 'discard' means in the context as described above. As a non-native English speaker (or what's the right term?) I suppose (but am not sure) the word 'discard' can have multiple meanings (apart from 'To throw away'). Otherwise 'silently discard' would be a pleonasm, isn't it? Your English is fine. Discard means throw away. Agree. Discard and silently discard mean the same thing, in my opinion. Though, I am guilty of using the phrase silently discard. Maybe in an attempt to be slightly over-specific. In the email filter space there is sometimes a distinction. Discard is sometimes used to mean discard and notify. That is throw away the content of the message, but send a message to the intended recipient telling them you've done so. Virus filters often do this sort of thing. Silently discard clarifies that you really just mean throw it away, and throughout the development process that was the intended meaning of the word discard in the spec. The advantage of the notification is that it allows the recipient to be aware of false positives. The disadvantage is that, unlike virus filtering, phishing can be designed to work even though the main body of the message is discarded, by designing the message such that the right part of it (such as a URL) is passed through the notification process. The only way to entirely avoid that is to avoid identifying the message that was discarded in the notification, and that's just appallingly bad UX all around. Given the appalling false positive rates, I'm not sure that silently discard is *clearly* the right thing to do, but discard and notify has even bigger problems. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 9:12 AM, MH Michael Hammer (5304) wrote: For shame Dave. Taking one sentence out of context is something I would not have expected from you. After all this time, I am glad to hear that I can still surprise you... FWIW I took it out of context entirely knowingly. Frankly, I wasn't interested in the particular topic. As I said, I think that that captures the critical difference in what drives the two sides of these various-but-really-identical debates. The particular context wasn't the point. The difference in attitudes about /any/ of these topics is the point. The whole point of having a standard is to avoid the voodoo and guessing. Right. And a standard that is not adopted or used does not achieve this. Worrying very carefully about adoption barriers -- who will adopt it and why -- is essential to this, but we have not been succeeding in getting answers to hard questions here. You are absolutely correct that we should anticipate failures. That does not mean we should anticipate FAILURE from a reasonably crafted standard. Actually, yes it does. That is exactly my point. A side effect of living in Silicon Valley is seeing how often carefully crafted startups fail. Good ideas and a well-designed product are not sufficient to guarantee success, absent properly matching the /perceived/ needs of the folks who will use it /and/ the folks who will pay for it. We cannot protect foolish people from doing foolish things to themselves. This is another case of King Canute. The benefit of that perspective is acknowledging limitations. The danger is not putting in enough effort to make things appropriately usable and/or not putting enough effort into crafting a value proposition that is compelling to the target audience. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
John Levine jo...@iecc.com wrote: Similarly, with ADSP you don't have to rely on published information, and when information is published, you don't have to guess whether the publisher is competent. You can maintain your own list of domains that you trust to get ADSP right, and use standard software to apply that judgement. Manual drop lists are a fine idea, but what do they have to do with ADSP? 1. Code reuse: Although you may choose to maintain your drop list, you don't have to write software for your MTA, you can just configure it. I'm happy to reuse the manual drop code in Spamassassin. I still don't see what it has to do with ADSP. 2. Discoverability: You can find out from ADSP publications that the sender cares about this stuff. OK, it's still a leap to add them to your drop list, but you do at least have somewhere to start. Here's a thought experiment: let's say you have your list of domains that are known to be phish targets that sign their mail, so you drop unsigned mail, and they all happen to publish ADSP. Someone's ADSP record goes away. Is it more likely that they've stopped signing their mail, or that their ADSP record is temporarily messed up? Why? Or, I suspect most likely, they thought they were signing everything and then later something changed or they discovered they missed a piece of their infrastructure, so they've retracted the policy until they've corrected the problem. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
Scott Kitterman wrote: Dave CROCKER d...@dcrocker.net wrote: On 6/2/2010 8:08 AM, Al Iverson wrote: Agree. Discard and silently discard mean the same thing, in my opinion. Though, I am guilty of using the phrase silently discard. Maybe in an attempt to be slightly over-specific. I do not recall seeing a dictionary or technical definition of discard that says anything at all about whether the discarder says anything at all. Taken on its own and without further technical specifications 'discard' does not direct, imply or request that the action be silent or noisy, and if noisy who gets to hear it. IIRC, this is by design since there was no consensus around what exactly to do. Personally, I tend to favor not having messages silently vanish. +1 As stated before, I have not followed the entire discussion on ADSP in depth, so please bear with me. I could not find relevant items in the archives, but has there ever been suggested to have a 'rejectable' in addition to 'discardable' and 'all'? /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
Well, you'd process that mail as if... there were no ADSP policy because... there's no ADSP policy. I guess I agree, since I would use a credible manually maintained list and ignore the ADSP whether or not there was any. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 28, 2010, at 12:01 AM, Steve Atkins wrote: 1. Do we want to reduce the DKIM broken signature rate or do we want to make ADSP less vulnerable to it. Or both, I guess. I think both of those objectives are of interest. 2. If we want to reduce the DKIM broken signature rate, do we need to rework DKIM at all I don't think so. , or do we need to make operational recommendations to the generator and signer of the mail yes , or do we need to provide operational advice to forwarders and mailing list managers yes . For any of those we need to balance the improvement against the reduction in deployment and reduction in correct deployment the increased complexity will cause. The history of SPF-all and SRS is likely relevant there. Why is guidance for how to use something that already exist make things more complex? It should dramatically reduce complexity through clear recommendations. Re-writing DKIM would be a problem, and I for one am not in favor of that as I agree with Steve that it will have a negative impact on deployments, but surely implementation guidance would only have a positive impact on deployments. 3. If we want to make ADSP less vulnerable to it, this basically means reworking ADSP such that it says that receivers should accept unsigned mail in some cases - the various suggestions about accepting unsigned mail from trusted mailing lists or forwarders. This is bound to open up a bunch of theoretical security issues, and probably some real ones. I do not believe that is our only option. We can extend ADSP to provide a few new options over all and discardable that meet current use cases. Otherwise we could publish guidance to address expected use but I assume that guidance will leave it to the deployer to decide who and why they trust certain streams and/or policy assertions. 3a. If we go in that direction we're looking at making some fairly tricky security related decisions. We'd need a proper analysis of the security risks and operational benefits, which would require us to be more honest than we have been in the past about what the end goals are, and how some of the more obvious attack trees would affect those goals. Maybe you are contemplating a different part of the elephant but I don't see what you are getting at with this line of rhetoric. Any of those changes - i.e. doing anything other than accepting the seriously broken behaviour and just documenting it - would require buy-in from the chairs and other participants, and likely a charter clarification. I would not be surprised if we need a charter clarification to tackle adding options to ADSP, but aren't we already chartered to provide BCP guidance for the technologies that have come out of this WG? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On May 26, 2010, at 12:59 PM, Steve Atkins wrote: On May 26, 2010, at 7:45 AM, Brett McDowell wrote: On May 25, 2010, at 8:43 PM, Scott Kitterman wrote: Like I said, throw away anything that doesn't have our signature has some chance of broad adoption. Every extra word you add to the message makes it less likely that people will do it. I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third parties to create messages that render discardable moot. I agree that adding anything to throw away anything that doesn't have our signature add complexity to implementation and therefore, by definition, is a barrier to adoption. That's not what we are debating. What we are debating is whether such complexity is a necessary evil that we should provide a specification to support -- as an optional mechanism for stakeholders who want to opt-in to the authenticated email ecosystem. I *think* the answer is yes. But we haven't yet had the meaningful debate that will resolve that question. Let's debate whether transient trust through a MLM is actionable. Would a new header that enabled the MLM to report to the receiver that they indeed validated the original signature actually make any difference in the deliverability of that message to the receiver, and if yes, is that actually a good thing? I say yes and yes. But I expect that if we debate this specific point one of you might highlight an unintended consequence that would tip the balance away from pursuing such a model. Thoughts? Aesthetically I like the idea of some way for the MLM to tunnel authentication information through to the recipient. Perhaps that's common ground we just discovered. Let's build on that. But I don't think it's clear that doing so would change anything at the recipients MX. As a concrete example, if two subscribers to a mailing list send mail to the list, one DKIM signed and one not, and the list then signs each message and sends it to the recipient, is there any reason that the recipients MX would treat those two messages differently? Yes. But we need more information about the scenario in order to describe how. The following detail will illustrate how. A = sender of message from an ADSP=discardable domain but the message was not DKIM signed B = sender of message from an ADSP=discardable domain and the message was DKIM signed C = the MLM who is a participating MLM in the authenticated email ecosystem D = receiver of email from the MLM who is a participating receiver (DKIM/ADSP inbound) Note: this scenario takes place in after this IETF DKIM WG standardizes the new header I mentioned above. In this scenario C will report to D that the message from A was not signed on inbound and that the message from B was. This would lead D to deliver the message from B but not deliver the message from A. The MLM signed both messages before sending to D. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 28, 2010, at 1:08 AM, Steve Atkins wrote: Paypal is rather a special case, as they actively register many, many domains in a lot of TLDs that contain the word paypal or some misspelling of it, both proactively and in response to enforcement. I didn't consider those domains as triggering an ADSP rejection for a number of reasons. One is that many (most?) of them would have been acquired by paypal though enforcement action after the phishes were sent, and the other is that it's a behaviour (registering a huge number of domains purely to deny them to others) that's atypical and that doesn't scale. Havning said that, I did spot check quite a lot of the phishes that I'd tagged as not rejected and the vast majority weren't using domains I'd expect paypal to have proactively reserved (paypal.net, for instance) - they were mostly using the word paypal in the friendly from, the local part or a subdomain of the domain part. Of those that weren't of that form many were things like @paypal-access.com and suchlike. So I think those two numbers are likely accurate to within a few percent or better. Your numbers were so far off from what we see that I was perplexed, but now it's clear why. In reality we do register many of the domains you assumed we don't (like paypal.net) and we are not unique in that practice. We have over a thousand of these domains parked. The result of this simple error in assumption has skewed your data to the point where it is no longer representative. I feel compelled to point out this error since several people on the list have been quoting your data since you circulated it and are likely to draw erroneous conclusions from it. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 06/02/2010 11:41 AM, Steve Atkins wrote: Fourth, as I mentioned above, even if all you said was valid, registering thousands of domains in order to make ADSP sort-of work against phishing isn't something that scales, either in terms of domain name system nor the expense. If ADSP requires users to spend tend of thousands of dollars a year to maintain domain registrations in order for it to have a significant effect on phishing then it's not something that's really going to scale to more than a handful of senders. I'd be willing to bet a good chunk of money that Paypay -- and lots of other domains -- have this practice regardless, and preceding ADSP. ADSP use supplements that current best practice for phishing target domains. Which is sort of the point. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Jun 2, 2010, at 9:33 AM, MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of John Levine Sent: Wednesday, June 02, 2010 9:21 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion snip Here's a thought experiment: let's say you have your list of domains that are known to be phish targets that sign their mail, so you drop unsigned mail, and they all happen to publish ADSP. Someone's ADSP record goes away. Is it more likely that they've stopped signing their mail, or that their ADSP record is temporarily messed up? Why? Signing their mail does not equal ADSP. Knowing they sign their mail does not equal ADSP. As you have pointed out, ADSP does not equal manual drop lists. The fact that someone's ADSP record - absent any other data points - goes away, tells us nothing other than their ADSP record went away. There could be any number of reasons as to why it went away. Are we now going to have to write a draft for casting goat bones to determine the meaning of standards implementations and operational practices? It's really quite simple. Agreed. BTW, I'm actually agreeing to this statement in the context it was made :-) If there is no longer an ADSP record then ADSP is not applicable. Well, you'd process that mail as if... there were no ADSP policy because... there's no ADSP policy. Do we really need to publish informational guidance on this point? If yes, then let's do it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
On 6/2/10 10:10 AM, Scott Kitterman wrote: Dave CROCKERd...@dcrocker.net wrote: On 6/2/2010 8:08 AM, Al Iverson wrote: Agree. Discard and silently discard mean the same thing, in my opinion. Though, I am guilty of using the phrase silently discard. Maybe in an attempt to be slightly over-specific. I do not recall seeing a dictionary or technical definition of discard that says anything at all about whether the discarder says anything at all. Taken on its own and without further technical specifications 'discard' does not direct, imply or request that the action be silent or noisy, and if noisy who gets to hear it. IIRC, this is by design since there was no consensus around what exactly to do. Personally, I tend to favor not having messages silently vanish. The initial intent was to assert signing domain's policies rather than attempting any receiver recommendations. In this vein, a better an alternative to discardable could have been no-third-party-services-used such as N3PS. The discardable assertion did not emerge directly from the list. John explained discardable as his response to phished domain's concerns of being flooded with NDNs. ADSP did not produce a flood, as seen by the phisher's reactions of avoiding exact matches. Rather than asserting author domain signing policies, ADSP could be changed into offering receiver recommendations, which discardable attempts. Perhaps all could change to non-deliverable. However, could this result in bounces, in addition to rejections. After all, not all receivers evaluate DKIM prior to acceptance. Should these recommendation be rejectable and remain silent about accepted messages? To avoid this quagmire, the WG concluded that ADSP was to state the domain's signing policy. Clearly, discardable represents a clear departure. Will discardable ultimately prove helpful? It has already caused many to ignore handling for all, since all lacks the concise instruction offered by discardable. It seems discardable is in danger of ensuring an unproductive outcome for ADSP. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 28, 2010, at 12:28 AM, Steve Atkins wrote: On May 27, 2010, at 9:15 PM, John Levine wrote: On the other hand, John and Steve expect that the benefits PayPal is seeing in thwarted phishing messages will be short-lived, as phishers just change domain names, and send out just as many messages as before, fooling just as many recipients into thinking they're from PayPal. Actually, that's Steve. John sees utility in manual drop lists, but not in ADSP since there is no way to tell whether someone publishing ADSP understands what it means. Recent experience suggests that they often don't. It's not really my view either. I do think that there's some risk of manual drop lists becoming less effective, but I also think that it's more a risk than a certainty, and it's something that may be resolved by a couple of smart engineers - as it's a flexible approach that can be modified in response to opponent behaviour in days or hours. That flexibility (and lack of publication of the details) and direct involvement of smart people in real time to maintain it are some of the things that make the manual drop list approach much more viable than a static, self-publication approach. My problem with this position is that it seems to argue for proprietary one-off solutions vs. Internet standards for email authentication policy assertions. I would think that's a non-starter, especially for participants in this WG. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
In terms of public information, we are in production with DKIM verification/blocking today with two mailbox providers. We'd like to be in production with say... two hundred by some near-term date certain. Hence the need for ADSP. This is a non-sequitur, but we've been through it before so I won't keep beating the greasy spot where the horse used to be. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Jun 2, 2010, at 2:41 PM, Steve Atkins wrote: On Jun 2, 2010, at 10:59 AM, Brett McDowell wrote: On May 28, 2010, at 1:08 AM, Steve Atkins wrote: Paypal is rather a special case, as they actively register many, many domains in a lot of TLDs that contain the word paypal or some misspelling of it, both proactively and in response to enforcement. I didn't consider those domains as triggering an ADSP rejection for a number of reasons. One is that many (most?) of them would have been acquired by paypal though enforcement action after the phishes were sent, and the other is that it's a behaviour (registering a huge number of domains purely to deny them to others) that's atypical and that doesn't scale. Havning said that, I did spot check quite a lot of the phishes that I'd tagged as not rejected and the vast majority weren't using domains I'd expect paypal to have proactively reserved (paypal.net, for instance) - they were mostly using the word paypal in the friendly from, the local part or a subdomain of the domain part. Of those that weren't of that form many were things like @paypal-access.com and suchlike. So I think those two numbers are likely accurate to within a few percent or better. Your numbers were so far off from what we see that I was perplexed, but now it's clear why. In reality we do register many of the domains you assumed we don't (like paypal.net) and we are not unique in that practice. We have over a thousand of these domains parked. The result of this simple error in assumption has skewed your data to the point where it is no longer representative. There's no error in assumption. The data is fairly accurate as measured (and also reasonably representative of the behaviour of a mixed-use domain, I think). First, as I said above they were mostly using the word paypal in the friendly from, the local part or a subdomain of the domain part ... in other words your argument doesn't apply at all to most of the phishing email that ADSP failed to deal with. I don't think you are following me... the receivers who are performing ADSP look-ups and enforcing discardable would have blocked a ton of that email you are reporting would have made it through. Second... steve$ host -t txt _adsp._domainkey.paypal.net _adsp._domainkey.paypal.net has no TXT record steve$ host -t txt paypal.net paypal.net has no TXT record ... I wasn't going to mention it, but you brought it up. The MX for paypal.net will also give a 2xx response to any RCPT TO in the paypal.net domain. ...and I wasn't going to mention that I tried to work with you off-list to get more information about your phish from paypal.net but you didn't respond. If you get a chance, please do send that along. Third, as I mentioned above, even if you were publishing ADSP records for lookalike domains, most of those lookalike domains appear to have been acquired after enforcement of a phishing issue - meaning that there would have been no ADSP records when the phishing mails were sent, and your ownership of them now is irrelevant. As I've reported before, we have over 100 millions reasons (blocked attacks from our registered domains) why you are wrong about this assertion. Fourth, as I mentioned above, even if all you said was valid, registering thousands of domains in order to make ADSP sort-of work against phishing isn't something that scales, either in terms of domain name system nor the expense. If ADSP requires users to spend tend of thousands of dollars a year to maintain domain registrations in order for it to have a significant effect on phishing then it's not something that's really going to scale to more than a handful of senders. You have this backwards. Major brands register cousin domains for more reasons than phishing. This practice pre-dated ADSP and it will continue with or without ADSP. It's simply an operational fact that is relevant to any debate about how ADSP can/should be used. I feel compelled to point out this error since several people on the list have been quoting your data since you circulated it and are likely to draw erroneous conclusions from it. I understand you want to discredit the statistics and I understand you wanted to report statistics to discredit ADSP... actually I don't understand that but it is certainly consistent with your arguments - they show that as measured at my inbox, based on paypal related email, ADSP dkim=discardable as currently used by PayPal to combat phishing is significantly less useful than flipping a coin. 72% false positive, 61% false negative. but your processing assumptions about what would get through vs. what would bounce was wrong. These statistics are quite valid, and reasonably representative. now I'm just repeating myself... The only non-representative thing about them is that they're measured at my mailbox,
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 28, 2010, at 12:15 AM, John Levine wrote: On the other hand, John and Steve expect that the benefits PayPal is seeing in thwarted phishing messages will be short-lived, as phishers just change domain names, and send out just as many messages as before, fooling just as many recipients into thinking they're from PayPal. Actually, that's Steve. John sees utility in manual drop lists, but not in ADSP since there is no way to tell whether someone publishing ADSP understands what it means. ADSP seems to mean one thing to pundits and something else to the people actually using it. Who is right? Recent experience suggests that they often don't. Can you name someone with ADSP experience who doesn't understand what it means? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Wednesday, June 02, 2010 3:07 PM To: Steve Atkins Cc: DKIM List Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion On 06/02/2010 11:41 AM, Steve Atkins wrote: Fourth, as I mentioned above, even if all you said was valid, registering thousands of domains in order to make ADSP sort-of work against phishing isn't something that scales, either in terms of domain name system nor the expense. If ADSP requires users to spend tend of thousands of dollars a year to maintain domain registrations in order for it to have a significant effect on phishing then it's not something that's really going to scale to more than a handful of senders. I'd be willing to bet a good chunk of money that Paypay -- and lots of other domains -- have this practice regardless, and preceding ADSP. ADSP use supplements that current best practice for phishing target domains. Which is sort of the point. Mike Thousands of domains registered and counting. Been doing it well before ADSP and view it as only one of the things that owners of abused domains do. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On May 28, 2010, at 12:14 AM, John Levine wrote: So I understand your line of reasoning. But today, I believe ADSP can provide a benefit. Brett has data that supports that. Once again, we have a pernicious confusion between manually maintained drop lists and ADSP. Brett has data that supports the former, not the latter. I disagree, but here's some new data that might better illustrate the case for ADSP. In terms of public information, we are in production with DKIM verification/blocking today with two mailbox providers. We'd like to be in production with say... two hundred by some near-term date certain. Hence the need for ADSP. The case is even stronger from the mailbox providers' perspective since they would be working with orders of magnitude more senders. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Jun 2, 2010, at 3:26 PM, John R. Levine wrote: Recent experience suggests that they often don't. Can you name someone with ADSP experience who doesn't understand what it means? Not to pick on you specifically, since there are multiple examples, but I'd say that domains that publish dkim=discardable and who let their users subscribe and send messages to mailing lists don't understand what their ADSP is telling people. I suppose it's possible they do know and they don't care how much damage they cause to everyone else, but I'd rather think it was confusion than malice. You'd call it malice to prioritize consumer protection over the a very small population of employees being temporarily inconvenienced by having some of their messages to mail lists delivered to SPAM and in some corner cases, actually unsubscribed from lists... while we invest time and resources to (a) assess how MTA's, MUA's and MLM's actually deal with these mail streams and (b) work with the standards community to improve the ecosystem by shaving off the rough edges we find? Neither ignorance or malice, simply the will to be an early adopter of young standards with proven consumer protection capabilities coming from a respected source. Yes, we are learning by doing and we are contributing all of that back to the community. What surprises me is how our efforts have been received by the community who produced these standards in the first place. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 11:29 AM, Brett McDowell wrote: ADSP seems to mean one thing to pundits and something else to the people actually using it. Who is right? Recent experience suggests that they often don't. Can you name someone with ADSP experience who doesn't understand what it means? Since we've been seeing reports of breakage due to using ADSP records for domains that are not under sufficient control, it is clear that some fraction of the ADSP-using world does not understand what it is for, or at least what its limitations are. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
If the domain or subdomain involved has enduser (at all) accounts then it is likely a poor candidate for ADSP DISCARDABLE. ADSP DISCARDABLE should be used for domains that are subject to high levels of abuse and are used primarily for transactional or marketing email and where the mail flows are strictly controlled. I entirely agree. (So there!) The question remains how to reliably identify such domains. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Wednesday, June 02, 2010 3:38 PM To: MH Michael Hammer (5304) Cc: DKIM List Subject: RE: [ietf-dkim] list vs contributor signatures, was Wrong Discussion I can't help myself. This image of John sitting at a desk with his quill and inkwell manually maintaining his credible list by the light of a whale oil lamp keeps popping into my minds eye. How scalable is that list John? If ye towne cryer dost distribute such a liste to manye and divers mail servers, as scalable as ye do wante. This addresses distribution of the list, not maintaining the list. Ye olde add/change/delete issue. And of course there is the question of whether folks will trust (the generic) you as widely as a solid standards based approach for self-publication. I agree it would be useful to have a way to discover whose mail is signed and usefully discardable. But there's little reason to think that self-publication along the lines of ADSP will do it successfully. There's little reason to think it won't. Time wounds all heels. As I've said before, I believe ADSP is crippled intentionally so. There were compromises of various sorts in order to be able to get the document out. One need only look at the discussions around SSP drafts 1- I think it was 13 or so). Could it be fixed? Possibly. Will it be fixed? Doubtful. It is unlikely that there will be sufficient will or consensus from this working group for such an effort to be successful. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Wednesday, June 02, 2010 3:48 PM To: Brett McDowell Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion On 6/2/2010 11:29 AM, Brett McDowell wrote: ADSP seems to mean one thing to pundits and something else to the people actually using it. Who is right? Recent experience suggests that they often don't. Can you name someone with ADSP experience who doesn't understand what it means? Since we've been seeing reports of breakage due to using ADSP records for domains that are not under sufficient control, it is clear that some fraction of the ADSP-using world does not understand what it is for, or at least what its limitations are. If we apply this to other standards (SMTP, DNS, HTTP, etc) we would just have to power down the whole internet. The best that we can do is come up with something that makes a modicum of sense, fix things we didn't anticipate or understand because we needed operational experience and move on. There will always be some fraction of the user/implementer base that won't understand protocols, standards or RFCs. It kind of goes with the territory. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 12:58 PM, MH Michael Hammer (5304) wrote: Since we've been seeing reports of breakage due to using ADSP records for domains that are not under sufficient control, it is clear that some fraction of the ADSP-using world does not understand what it is for, or at least what its limitations are. If we apply this to other standards (SMTP, DNS, HTTP, etc) we would just have to power down the whole internet. The best that we can do is come up with something that makes a modicum of sense, fix things we didn't anticipate or understand because we needed operational experience and move on. There will always be some fraction of the user/implementer base that won't understand protocols, standards or RFCs. It kind of goes with the territory. Mike, this is the sort of discussion disconnect that prevents making progress. I'm copying the list because it's a broad-based problem we are all having in trying to discuss issues. First, a question was put forward and I offered an answer. It is simply not fair to then respond in a manner that dismisses that answer (or at least dismisses it in this way.) Second, the usual way that services get successful is to look for problems in their use and look for ways to correct them. Simply saying that there are always some problems is not helpful. Third, we do not have massive amounts of ADSP success which permits marginalizing a tiny amount of problems. We have tiny use, with notable breakage. Fourth, it has become increasingly clear to me, at least, that there is broad-based misunderstanding of what can reasonably be accomplished with DKIM and what can reasonably be accomplished with ADSP, versus what cannot. Failure to gain broad-based agreement about both capabilities and limits ensures an on-going mismatch in expectations. If proponents want simply to keep automatically saying that things are great and keep automatically rejecting any counter-points, then I'm not clear what the purpose of these discussions is. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Brett McDowell Sent: Wednesday, June 02, 2010 3:46 PM To: John R. Levine Cc: DKIM List Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion SNIP What surprises me is how our efforts have been received by the community who produced these standards in the first place. Brett, I'm sorry you are surprised. This space has been contentious going back something like 10 years (or more). Many of the participants go at it tong and hammer but we can still sit down for dinner or a drink at the usual gatherings. Truth be told, the Financial sector (including PayPal) as well as other key groups have been pretty much MIA from a lot of the discussions for a long time. Many of the points of contention have been discussed ad nauseum over the years without resolution or through compromises that gave us crippled outcomes like ADSP. Actually, IETF has been somewhat mild compared to MARID G. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
-Original Message- From: MH Michael Hammer (5304) Sent: Wednesday, June 02, 2010 4:21 PM To: 'Brett McDowell'; John R. Levine Cc: DKIM List Subject: RE: [ietf-dkim] list vs contributor signatures, was Wrong Discussion Actually, IETF has been somewhat mild compared to MARID G. Mike Apologies, that should read IETF-DKIM ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 1:21 PM, MH Michael Hammer (5304) wrote: Actually, IETF has been somewhat mild compared to MARIDG. Narrower topic. Smaller group. Made it a lot easier to be selective with the attacks... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
-Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Wednesday, June 02, 2010 4:06 PM To: MH Michael Hammer (5304) Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion On 6/2/2010 12:58 PM, MH Michael Hammer (5304) wrote: Since we've been seeing reports of breakage due to using ADSP records for domains that are not under sufficient control, it is clear that some fraction of the ADSP-using world does not understand what it is for, or at least what its limitations are. If we apply this to other standards (SMTP, DNS, HTTP, etc) we would just have to power down the whole internet. The best that we can do is come up with something that makes a modicum of sense, fix things we didn't anticipate or understand because we needed operational experience and move on. There will always be some fraction of the user/implementer base that won't understand protocols, standards or RFCs. It kind of goes with the territory. Mike, this is the sort of discussion disconnect that prevents making progress. I'm copying the list because it's a broad-based problem we are all having in trying to discuss issues. Simply stating that we are seeing some reports of breakage due to using ADSP records for domains that are not under sufficient control does not add much of anything meaningful to the discussion. This issue has been discussed for YEARS and now that we see it some people are acting shocked? I'm shocked I tell you. I seem to remember this very discussion at an excellent dinner following the FTC workshop in 2007. This same discussion was held years before that when SSP was just a gleam in everyone's eye. This is something that was predicted and predictable. At the end of the day, ADSP was a compromise that limited usefulness to a handful of corner cases implemented under extremely tight control at the risk of breakage and collateral damage if not carefully implemented. First, a question was put forward and I offered an answer. It is simply not fair to then respond in a manner that dismisses that answer (or at least dismisses it in this way.) Second, the usual way that services get successful is to look for problems in their use and look for ways to correct them. Simply saying that there are always some problems is not helpful. We know the answers for ADSP... see above. Third, we do not have massive amounts of ADSP success which permits marginalizing a tiny amount of problems. We have tiny use, with notable breakage. I'm still waiting for someone to produce use numbers (of domains) for ADSP. Just out of curiosity, what number do we have to reach to hit the technical term massive? Somehow I doubt that in it's current incarnation ADSP will ever have massive implementation. From another perspective, in the greater scheme of standards, ADSP is still very much wet behind the ears. It wasn't until October of 2008 that there was interoperability testing. Fourth, it has become increasingly clear to me, at least, that there is broad-based misunderstanding of what can reasonably be accomplished with DKIM and what can reasonably be accomplished with ADSP, versus what cannot. I agree with you on that. Something along the lines of pixie dust, unicorn horns, magic spam prevention, makes you taller and your teeth whiter... Failure to gain broad-based agreement about both capabilities and limits ensures an on-going mismatch in expectations. And thus the rise of 3rd party trusted intermediaries. If proponents want simply to keep automatically saying that things are great and keep automatically rejecting any counter-points, then I'm not clear what the purpose of these discussions is. I'm not a proponent and I'm not saying things are great. I believe I've stated a few times that I believe that ADSP is crippled and I don't see myself publishing discardable. When the counterpoints are along the lines of some people have some problems and the point is made if we were following the standard then we wouldn't be seeing your mail anyways, then my response is. then why aren't you discarding it? Either you believe in the standard you helped craft or you don't. So, is this a discussion about a BCP for MLMs or is this a discussion about revisiting the ADSP spec? The course of the discussion really depends on what the consensus is. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
-Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Wednesday, June 02, 2010 4:26 PM To: MH Michael Hammer (5304) Cc: DKIM List Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion On 6/2/2010 1:21 PM, MH Michael Hammer (5304) wrote: Actually, IETF has been somewhat mild compared to MARIDG. I appreciate that you understood what I meant rather than what I wrote. Narrower topic. Smaller group. Made it a lot easier to be selective with the attacks... Actually, I think it was because MARID involved much more of the characteristics of a religious war. This is merely about passionate philosophical positions. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Jun 2, 2010, at 12:28 PM, Brett McDowell wrote: On Jun 2, 2010, at 2:41 PM, Steve Atkins wrote: Second... steve$ host -t txt _adsp._domainkey.paypal.net _adsp._domainkey.paypal.net has no TXT record steve$ host -t txt paypal.net paypal.net has no TXT record ... I wasn't going to mention it, but you brought it up. The MX for paypal.net will also give a 2xx response to any RCPT TO in the paypal.net domain. ...and I wasn't going to mention that I tried to work with you off-list to get more information about your phish from paypal.net but you didn't respond. If you get a chance, please do send that along. I did[1]. It looks like your mailsystem is discarding email it shouldn't. There's a copy at http://tupid.org/paypal1.txt if you can't find it. It seems that paypal is not currently monitoring phishing, nor doing anything to deter it, on 99.9% of the domains they own, so have no real idea of what phishing is going on. Pointing those thousand domains at a catch-all mailserver with a wildcard MX and looking for bounces and spamfilter rejections might be a good way of getting metrics about how phishers respond to domains being owned by paypal over time. Those same metrics after adding SPF and ADSP records for those domains over time would be interesting. http://blog.wordtothewise.com/2010/05/how-to-disable-a-domain/ has some examples of how to set those up. That's the sort of data gathering I was suggesting you do, rather than just a bald count of DNS queries, when I looked at the numbers for my mailbox. (There's a copy of my raw data at http://tupid.org/paypal1.sql.txt if anyone is interested in running their own model against it.) (I'm not going to respond to the other misunderstandings unless someone really wants me to. I'm guessing most people are long past tl;dr at this point.) Cheers, Steve [1] May 28 13:54:47 fruitbat postfix/smtp[31990]: DA551814E6: to=bmcdow...@paypal.com, relay=gort.ebay.com[216.113.167.215]:25, delay=0.74, delays=0.17/0/0.45/0.11, dsn=2.0.0, status=sent (250 ok: Message 769193797 accepted) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
You'd call it malice to prioritize consumer protection over the a very small population of employees being temporarily inconvenienced by having some of their messages to mail lists delivered to SPAM and in some corner cases, actually unsubscribed from lists... You're welcome to take whatever risks you want with your own mail. That's not the issue. I was thinking of the perverse case where another organization sent discardable mail to a different list, and unrelated people rejected it and got bounced off. Yes, they both were arguably doing something wrong, but it was startling to find second order damage from ADSP to someone who wasn't publishing it. If it's not clear, I think it's wonderful that Paypal signs all their mail so that we can reasonably safely dump the unsigned stuff. I have my mail system set up to do that, albeit configured locally, not by ADSP. The basic problem with ADSP is that we shipped an untested prototype, and at this point the only way to test it is to try experiments and hope they don't do too much damage before we have a chance to tweak and mitigate the problems. I appreciate that Paypal's intentions are entirely virtuous, and that you deal with problems pretty quickly for a large organization. But since you're the elephant in this particular room, the visibility of accidental damage would be particularly great. I am concerned that since the distinction between DKIM and ADSP is unclear to many people, they may take away the impression that if they sign with DKIM, their mail will get lost. Since Paypal's practices are for the most part so good, it's very useful to be able to talk to people who are scratching their heads about DKIM and say do what Paypal does. It's harder to say do what Paypal does, except don't do that. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Jun 2, 2010, at 4:05 PM, Dave CROCKER wrote: If proponents want simply to keep automatically saying that things are great and keep automatically rejecting any counter-points, then I'm not clear what the purpose of these discussions is. If opponents want simply to keep automatically saying that things are terrible and keep automatically rejecting any counter-points, then I'm not clear what the purpose of these discussions is. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On 06/02/2010 02:11 PM, John R. Levine wrote: The basic problem with ADSP is that we shipped an untested prototype, and at this point the only way to test it is to try experiments and hope they don't do too much damage before we have a chance to tweak and mitigate the problems. I appreciate that Paypal's intentions are entirely virtuous, and that you deal with problems pretty quickly for a large organization. This is the list's fault pure and simple. It's subscriber heuristics -- and please do not tell me they are anything but -- failed. While we shouldn't expect much from mailing list operators and/or developers, we are most certainly under no obligation to route around their buggy software as if it were sacrosanct. This is a two way street. Instead of kvetching about ADSP, you might tell the list owners that their list software heuristics are broken. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On Jun 2, 2010, at 4:36 PM, MH Michael Hammer (5304) wrote: So, is this a discussion about a BCP for MLMs or is this a discussion about revisiting the ADSP spec? The course of the discussion really depends on what the consensus is. Let's break these up. Murray tried and I think succeeded to some degree of getting a clear thread that is dedicated only to the MLM BCP. What makes that a refreshingly productive thread is that we have an I-D to review and comment on. Perhaps we are at (or long past) the point of diminishing returns in debating the efficacy of ADSP until we have an I-D that covers fixing/enhancing ADSP to make it more useful. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine Sent: Wednesday, June 02, 2010 2:11 PM To: Brett McDowell Cc: DKIM List Subject: Re: [ietf-dkim] the danger of ADSP, was list vs contributor The basic problem with ADSP is that we shipped an untested prototype, and at this point the only way to test it is to try experiments and hope they don't do too much damage before we have a chance to tweak and mitigate the problems. I appreciate that Paypal's intentions are entirely virtuous, and that you deal with problems pretty quickly for a large organization. If we all agree that that's a valid characterization of ADSP, I suggest we move to get it downgraded from Proposed Standard to Experimental. There's certainly a lot of rhetoric suggesting it's an experiment that's in the process of failing, though the experiment is also arguably not complete. At any rate, I'm happy to participate in an effort to specify something that actually stands a chance of working, and test it in widely available software. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On Jun 2, 2010, at 2:58 PM, Murray S. Kucherawy wrote: The basic problem with ADSP is that we shipped an untested prototype, and at this point the only way to test it is to try experiments and hope they don't do too much damage before we have a chance to tweak and mitigate the problems. I appreciate that Paypal's intentions are entirely virtuous, and that you deal with problems pretty quickly for a large organization. If we all agree that that's a valid characterization of ADSP, I suggest we move to get it downgraded from Proposed Standard to Experimental. There's certainly a lot of rhetoric suggesting it's an experiment that's in the process of failing, though the experiment is also arguably not complete. +1 At any rate, I'm happy to participate in an effort to specify something that actually stands a chance of working, and test it in widely available software. Also, there have been a couple of suggestions along those lines that at least sound promising, but that weren't based on ADSP. I'm not sure where the best place to discuss them might be (and ASRG isn't it). Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On 6/2/2010 2:58 PM, Murray S. Kucherawy wrote: If we all agree that that's a valid characterization of ADSP, I suggest we move to get it downgraded from Proposed Standard to Experimental. I don't recall seeing anything that looks like we all agree on such a point. That some do is fine,but we also know that many do not. So we all really need to back away from this sort of drama. There's certainly a lot of rhetoric suggesting it's an experiment that's in the process of failing, though the experiment is also arguably not complete. We should all be far more concerned that legitimate questions about limits to usability and observed failure scenarios cannot be reasonably discussed. That's a good way to ensure that serious barriers to widespread successful use will not be resolved. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Wednesday, June 02, 2010 3:07 PM To: DKIM List Subject: Re: [ietf-dkim] the danger of ADSP, was list vs contributor At any rate, I'm happy to participate in an effort to specify something that actually stands a chance of working, and test it in widely available software. Also, there have been a couple of suggestions along those lines that at least sound promising, but that weren't based on ADSP. I'm not sure where the best place to discuss them might be (and ASRG isn't it). A completely new spec with the goal of domain protection tied to DKIM is (theoretically) a good fit for this WG, I would think. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
If we all agree that that's a valid characterization of ADSP, I suggest we move to get it downgraded from Proposed Standard to Experimental. There's certainly a lot of rhetoric suggesting it's an experiment that's in the process of failing, though the experiment is also arguably not complete. At this point, I think a reasonable message is to tell people that it's fine to publish whatever ADSP they think best describes their mail stream. But don't use it to manage your inbound mail unless you're willing to hand control of your mail to people of unknown competence and/or virtue. Some senders will be fine, some will not. I'm trying to come up with as many perverse ADSP scenarios as I can. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ADSP intent vs. usage (was Re: list vs contributor signatures, was Wrong Discussion)
On Jun 2, 2010, at 1:26 PM, John R. Levine wrote: Recent experience suggests that they often don't. Can you name someone with ADSP experience who doesn't understand what it means? Not to pick on you specifically, since there are multiple examples, but I'd say that domains that publish dkim=discardable and who let their users subscribe and send messages to mailing lists don't understand what their ADSP is telling people. Perhaps another way to put it is that they're not using ADSP discardable in the way that ADSP's designers intended. This appears to present two options, both of which have been attempted in this thread: 1. assume that the domain owner is wrong 2. assume that the ADSP design is wrong I think there's also a third option, which I haven't seen explored in depth yet (though I may have missed it): 3. find out why the domain owner thought that their implementation would be okay -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
On Jun 2, 2010, at 10:55 AM, John R. Levine wrote: My guess is that the phrase the domain encourages the recipient(s) to discard it is intended to refer to a silent discard. I don't think any of us expected the recipient to send a notification. I certainly didn't, since the assumption would be that the message was probably from a hostile sender. +1 Also, there's documented precedent within the IETF. RFC 863 has a clear definition: A discard service simply throws away any data it receives. RFC 5321 (and 2821, and 821) applied that definition to email, with specifics for programmers: 2.3.6. Buffer and State Table SMTP sessions are stateful, with both parties carefully maintaining a common view of the current state. In this document, we model this state by a virtual buffer and a state table on the server that may be used by the client to, for example, clear the buffer or reset the state table, causing the information in the buffer to be discarded and the state to be returned to some previous state. 5321 uses discard or discarded in other places, too. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On Jun 2, 2010, at 4:08 PM, Dave CROCKER wrote: On 6/2/2010 2:58 PM, Murray S. Kucherawy wrote: If we all agree that that's a valid characterization of ADSP, I suggest we move to get it downgraded from Proposed Standard to Experimental. I don't recall seeing anything that looks like we all agree on such a point. That some do is fine,but we also know that many do not. Count me as not agreeing. We always knew ADSP discardable wasn't appropriate for domains with users who send messages to mailing lists, and is equally inappropriate for all sorts of other legitimate uses of email. It's possible that the draft doesn't contain a strong enough warning that discardable = mail could be discarded, but that doesn't mean the whole thing is entirely broken. I'd really like to hear from a domain owner who published a discardable policy even though they knew they had users who send messages to mailing lists. I'd like to know why they thought it was okay. Then, we'll know. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
Also, there's documented precedent within the IETF. RFC 863 has a clear definition: ... 2.3.6. Buffer and State Table ... 5321 uses discard or discarded in other places, too. Well, one must always respect the lawyerly exercise of doing an audit to find precedent. But there's some distance between respect and agreement. The problem is that an existence proof is quite different from being able to assess/predict dominant human interpretation of the term. In other words, just because someone, somewhere, sometime used the word in a particular way, it says nothing about what most people, most of the time, will take it mean. I thought the issue here was the latter, not the former. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On 6/2/10 2:43 PM, Michael Thomas wrote: Instead of kvetching about ADSP, you might tell the list owners that their list software heuristics are broken. Michael, Mailing lists are on higher ground, since they are not introducing the new mechanism. ADSP is dealing with an issue significantly impacting less than one percent of email domains. Mailing lists, on the other hand, serve a much higher percentage. Domains wanting to make restrictive ADSP assertions while using third-party services, should enumerate which are to be excluded. This enumeration helps prevent breakage without needing to elicit cooperation from non-participants. This enumeration is possible within a single transaction that only occurs with the infrequent corner cases. The goal of reducing the success of phishing is far better met when not requiring targeted domains to use more domains or sub-domains as their only means to isolate policy. Especially when this leaves personal interactions exposed and creates increased recipient confusion. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On 6/2/2010 3:36 PM, J.D. Falk wrote: We always knew ADSP discardable wasn't appropriate for domains with users who send messages to mailing lists, and is equally inappropriate for all sorts of other legitimate uses of email. This suggests attempting an exercise. The exercise is to try to document the boundaries for using ADSP. It requires being careful in describing failure scenarios and careful is assessing their likelihood. As for attempting careful caveats so far, they are scattered around: http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.7.3 Whether they are too generic is a reasonable question to explore. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On 06/02/2010 03:47 PM, Douglas Otis wrote: On 6/2/10 2:43 PM, Michael Thomas wrote: Instead of kvetching about ADSP, you might tell the list owners that their list software heuristics are broken. Mailing lists are on higher ground, since they are not introducing the new mechanism. When we let existing heuristics dictate what we can design on the net, then we have failed. Heuristics by their nature are then things that need to deal with their own shortcomings. The problem here is not with ADSP. It's bad assumptions made by heuristics. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On Jun 2, 2010, at 4:10 PM, Michael Thomas wrote: On 06/02/2010 03:47 PM, Douglas Otis wrote: On 6/2/10 2:43 PM, Michael Thomas wrote: Instead of kvetching about ADSP, you might tell the list owners that their list software heuristics are broken. Mailing lists are on higher ground, since they are not introducing the new mechanism. When we let existing heuristics dictate what we can design on the net, then we have failed. Heuristics by their nature are then things that need to deal with their own shortcomings. The problem here is not with ADSP. It's bad assumptions made by heuristics. The heuristic here is that a 5xx ESMTP response means that the recipient is rejecting email from the sender, I believe. It's not really an obscure bit of existing practice, rather it's both best and common. Once we're at the point where we're describing that as something that can safely be ignored if we want to then I have to wonder what mail system we're planning to layer all this stuff on top of. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On 06/02/2010 04:25 PM, Steve Atkins wrote: On Jun 2, 2010, at 4:10 PM, Michael Thomas wrote: On 06/02/2010 03:47 PM, Douglas Otis wrote: On 6/2/10 2:43 PM, Michael Thomas wrote: Instead of kvetching about ADSP, you might tell the list owners that their list software heuristics are broken. Mailing lists are on higher ground, since they are not introducing the new mechanism. When we let existing heuristics dictate what we can design on the net, then we have failed. Heuristics by their nature are then things that need to deal with their own shortcomings. The problem here is not with ADSP. It's bad assumptions made by heuristics. The heuristic here is that a 5xx ESMTP response means that the recipient is rejecting email from the sender, I believe. It's not really an obscure bit of existing practice, rather it's both best and common. No. The heuristic is because I got a reject(s) from this subscriber delivering his list mail, I'm going to kick him. That's a heuristic. It's not working right. You could probably get the same bad outcome with a determined attacker not using ADSP at all. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
This suggests attempting an exercise. The exercise is to try to document the boundaries for using ADSP. It requires being careful in describing failure scenarios and careful is assessing their likelihood. As for attempting careful caveats so far, they are scattered around: http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.7.3 We put some warnings in RFC 5617, Appendix B, including this one: B.5. Domains with Independent Users and Liberal Use Policies When a domain has independent users and its usage policy does not explicitly restrict them to sending mail only from designated mail servers (e.g., many ISP domains and even some corporate domains), then it is only appropriate to publish an ADSP record containing unknown. Publishing either all or discardable will likely result in significant breakage because independent users are likely to send mail from the external paths enumerated in Appendix B.1. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list ADSP, was Lists BCP draft available
But I don't think it's clear that doing so would change anything at the recipients MX. As a concrete example, if two subscribers to a mailing list send mail to the list, one DKIM signed and one not, and the list then signs each message and sends it to the recipient, is there any reason that the recipients MX would treat those two messages differently? Yes. I still don't get it. The sorting rules I use on mailing lists are based on the list's identity using List-ID: headers or subject tags, not the individual sender. People will, I hope, correct me if I'm wrong, but I'm pretty sure that's typical of existing practice. It's possible to add all sorts of extra stuff to messages to pass through all sorts of complex assertions, but my list sorting works perfectly well now. What problem for the list recipient are we solving with this proposed extra mechanism? To address one possibility, none of the lists I'm on have significant problems with bad guys sneaking messages onto the lists by pretending to meet the criteria for posting messages to the list. Back in the Krazy Kevin era, 15 years ago, that was a problem but list owners and managers have dealt with it quite successfully. If the claim is that it'll become a problem again, I think it's fair to ask why, since list owners and managers have dealt with it in the past, they wouldn't continue to do so. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
On Jun 2, 2010, at 4:42 PM, John Levine wrote: This suggests attempting an exercise. The exercise is to try to document the boundaries for using ADSP. It requires being careful in describing failure scenarios and careful is assessing their likelihood. As for attempting careful caveats so far, they are scattered around: http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.7.3 We put some warnings in RFC 5617, Appendix B, including this one: B.5. Domains with Independent Users and Liberal Use Policies When a domain has independent users and its usage policy does not explicitly restrict them to sending mail only from designated mail servers (e.g., many ISP domains and even some corporate domains), then it is only appropriate to publish an ADSP record containing unknown. Publishing either all or discardable will likely result in significant breakage because independent users are likely to send mail from the external paths enumerated in Appendix B.1. It would be interesting to see the result of someone publishing ADSP records following the advice in that document. It'd be a good first step on looking at operational experience. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] My discardable statistics
I've been saving the DKIM signatures on mail sent to my inbox for about the past year, so I did a little analysis on them. There's a total of 71,000 signed messages that got to the procmail delivery filter, signed by a total of 474 domains. I went through and looked up the ADSP records for all of them. I found 51 ADSP records: 24 dkim=all 19 dkim=unknown 8 dkim=discardable A few had t=s but none of the discardables did. Let's take a look at those eight records. The number on each line is the number of messages: 135 paypal.com dkim=discardable 23 paypal.co.uk dkim=discardable 7 intl.paypal.com dkim=discardable 6 mail.julianhaight.com dkim=discardable 4 undp.org dkim=discardable 4 info.paypal.com dkim=discardable 2 info.paypal.ca dkim=discardable 1 info.paypal.co.uk dkim=discardable Six of them are Paypal, who presumably know what they're doing. Of the other two, mail.julianhaight.com is Julian's personal domain. All of the mail from that domain came through a mailing list, which tells us that he didn't follow the advice in RFC 5617. It appears that undp.org really is a branch of the United Nations, and their mail management isn't very good. All four of those messages came from the UNDP's mail servers, all four of them had return addresses that appear to be individual users at undp.org, and all four of them are spam or phish, presumably from botted PCs. Two of the DKIM signatures verify, two don't, haven't looked hard enough to tell why not, but they were broken when they arrived at my MTA. (Look at the spamassassin lines, added at SMTP time.) They're all in my spam archive, so you can look at them yourself: http://spample.iecc.com/yjf/21798071 http://spample.iecc.com/yvh/22631217 http://spample.iecc.com/oga/22622255 http://spample.iecc.com/gdx/22039445 Looking at the headers, this mail appears to have taken the same path that real user mail would have taken, so discardable is wrong here, too. Note that even though the mail is spam, the From: line addresses are in the domain of the sending system, so for ADSP purposes, they're OK, or would be if the signatures were good. I admit that this isn't a very big sample, but it does say that of all the people who sent me mail in the past year, Paypal is the only one who used ADSP discardable in a way that would would be useful for inbound mail handling. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the danger of ADSP, was list vs contributor
The basic problem with ADSP is that we shipped an untested prototype, ... The problems with ADSP aren't just for lists, but whatever. Instead of kvetching about ADSP, you might tell the list owners that their list software heuristics are broken. Oh, OK, that shouldn't be hard. I'll get right on it as soon as I'm done telling all the forwarders to rewrite the envelopes so I can use SPF -all. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
havnt been keeping up with all of the threads so forgive me if I am repeating earlier arguments ADSP is crippled, intentionally so. Its usefulness is limited to financial transaction types of transactions that may well be easily duplicated with a whale lamp, quill and parchment rbl management. DKIM is useful to determine who actually sent the mail. 1/2 of SPAM has valid DKIM signatures, the other half (bots) dont use it. It is a decent indicator that is useful along with all of the other tools on the belt. Its not a standalone fixall. carry on, Bill On Jun 2, 2010, at 4:21 PM, MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Brett McDowell Sent: Wednesday, June 02, 2010 3:46 PM To: John R. Levine Cc: DKIM List Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion SNIP What surprises me is how our efforts have been received by the community who produced these standards in the first place. Brett, I'm sorry you are surprised. This space has been contentious going back something like 10 years (or more). Many of the participants go at it tong and hammer but we can still sit down for dinner or a drink at the usual gatherings. Truth be told, the Financial sector (including PayPal) as well as other key groups have been pretty much MIA from a lot of the discussions for a long time. Many of the points of contention have been discussed ad nauseum over the years without resolution or through compromises that gave us crippled outcomes like ADSP. Actually, IETF has been somewhat mild compared to MARID G. 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] the danger of ADSP, was list vs contributor
Instead of kvetching about ADSP, you might tell the list owners that their list software heuristics are broken. Oh, OK, that shouldn't be hard. Actually, I doubt it will be hard. The casualties of ADSP causing third party kicks causes the blame to laid where it deserves: the list software. I have little doubt that they'll squawk and scream and throw tantrums about ADSP and in the end fix their broken software. Mike, we've already seen the first stages right here, actually ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] shared drop lists
My problem with this position is that it seems to argue for proprietary one-off solutions vs. Internet standards for email authentication policy assertions. That's certainly a reasonable concern. I expect that if it turns out there are more discardable domains than Paypal, people would use shared drop lists, just like they use shared blacklists and whitelists of IP addresses and domains now. Last year Paul Hoffman, Arvel Hathcock and I published RFC 5518 on Vouch by Reference, which we intended as a way to publish whitelists of responsible domains, originally DKIM signing domains but also usable for domains that pass SPF -all. It would only take a small tweak to VbR to use it to publish shared drop lists. VbR is deliberately really simple; it's a single DNS lookup, prepend the name you're looking up to _vouch and the VbR service's name. The result is a txt record saying what kind of mail it's vouching for, with the list currently being all, list, or transaction. We could add discardable as a VbR field, and do lookups like this, for a list called drop.services.net. $ dig info.paypal.ca._vouch.drop.services.net txt ; DiG 9.6.1-P1 info.paypal.ca._vouch.drop.services.net txt ;; QUESTION SECTION: ;info.paypal.ca._vouch.drop.services.net. IN TXT ;; ANSWER SECTION: info.paypal.ca._vouch.drop.services.net. 7200 IN TXT transaction discardable (This really works, by the way. Try it!) There'd be some other minor tweaks to VbR to bypass an optimization in VbR that puts hints in the mail about where to look, obviously not useful if you're looking up mail that you suspect is a phish. At this point my published drop list contains paypal domains, who publish ADSP, and ebay and amazon who don't publish ADSP, but who send transaction mail all of which is as far as I can tell signed. Looking at the rest of the signatures in my archive, I don't see anyone other reasonable candidates yet. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
wakes up MH Michael Hammer (5304) wrote: I'm still waiting for someone to produce use numbers (of domains) for ADSP. Just out of curiosity, what number do we have to reach to hit the technical term massive? Somehow I doubt that in it's current incarnation ADSP will ever have massive implementation. I recently surveyed the domains from which Cisco has received valid DKIM signatures: dkim=unknown: 205 domains dkim=all: 135 domains dkim=discardable: 63 domains There are perhaps some other domains that are publishing 'discardable' because they don't send any mail, but we wouldn't have seen them in this study. There's only a weak motivation (involving better DNS caching) for publishing dkim=unknown, so it's hard to gauge ADSP deployment by that number. In order to publish all or discardable, the domain's practices need to align with that, so unless there's a way to tell that a domain is signing all their mail and not publishing ADSP then it's challenging to gauge ADSP deployment for either of these categories. Addressing a question from elsewhere else in this massive thread, my home MTA runs the stock version of spamassassin that comes with Fedora 12. I haven't tweaked anything. Assuming my reading of the configuration files is correct, spamassassin is querying ADSP for incoming mail, and applying a positive bump to the spamminess score when a message comes from a domain with dkim=all, and a bigger bump for dkim=discardable. This could account for many of the adsp lookups that people are seeing. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
