Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Doug, I am in no way married to the word DISCARDABLE. We used it in SSP-02 because it matched ASP. It has occurred to me that we've spent FAR too much time arguing about exactly what word to use. I'm deeply tempted to switch to numbers, special characters, or random gibberish strings so that people have to read the actual description. eric --On February 8, 2008 9:55:56 AM -0800 Douglas Otis [EMAIL PROTECTED] wrote: On Feb 7, 2008, at 4:54 PM, Eric Allman wrote: The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE. Except that DISCARDABLE doesn't prohibit 3PS. It doesn't even say that messages without any signatures MUST or even SHOULD be discarded. All it says is how the purported author domain views the messages that it sends out. The furthest it goes is to say that the purported Author Domain encourages the recipient(s) to discard it. Eric, Agreed. This changes strict (the exclusivity) assertion into something that does not express a domain's intentions on exclusivity. This assertion simply increases the likelihood of having the domain's messages discarded. You have previously mentioned the motivation was to accommodate high profile domains finding themselves victims of phishing attacks. Using the term discardable appears to be sending the wrong message. It seems unlikely these high profile domains want their messages silently discarded, as this assertion implies. Discarding of messages does several things: - Destroys evidence of a serious crime - Reduces delivery integrity for important transactional messages - Makes resolving compatibility far more problematic Can you see changing this into terminology that does not attempt to suggest a verifier action? Going out on limb, I'll add a modified furthermore statement. (Frankly, this furthermore statement seems to belong in a BCP that happens later.) Using Hector's term exclusive- exclusive: All mail from the domain is signed with an intent to avoid agents that may damage or remove signatures. Furthermore, in lieu of a trusted third-party signature, if a message arrives without a valid Author Signature due to modification in transit, submission via a path without access to a signing key, or other reason, the domain encourages the recipient(s) to reject the message or issue a DSN when the RFC 2821 MAILFROM domains match. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
On Feb 8, 2008, at 12:18 PM, MH Michael Hammer (5304) wrote: It's an assertion that the sender would prefer that the recipient not deliver some small fraction of legitimate email as well as some small fraction of illegitimate email, rather than delivering those small fractions of legitimate and illegitimate email. I'm not sure that I would agree with framing it as some small fraction of illegitimate email. Tracking phishing attacks against our brands since we have started signing, a receiver checking DKIM and/or SPF would have easily identified 100% of those fraudulent emails. You're tracking at the wrong thing then, clearly. Checking my personal mailbox for mails using your brand: From: AmericanGreetings.com [EMAIL PROTECTED] From: americangreetings.com [EMAIL PROTECTED] From: americangreetings.com [EMAIL PROTECTED] From: AmericanGreetings.Com [EMAIL PROTECTED] From: americangreetings.com [EMAIL PROTECTED] From: AmericanGreetings.Com [EMAIL PROTECTED] From: AmericanGreetings.Com [EMAIL PROTECTED] From: AmericanGreetings.Com [EMAIL PROTECTED] From: americangreetings.com [EMAIL PROTECTED] There were also dozens of other mails that used the americangreetings.com brand in the body or subject of the message, but not in the From: field. So, in the data I'm looking at, the small fraction of illegitimate mail that would have been caught by SSP or anything similar would be 0%. (None of the americangreetings related stuff is actually phishing, of course, but many of the issues are quite similar to those of brands that actually are phished). In the senders opinion, it is more important that mail claiming to be from them not be delivered than for it to be delivered. I think a more appropriate phrasing would be: In the senders opinion, it is more important that mail claiming to be from them and not conforming to certain parameters not be delivered than for it to be delivered - even at the risk of some legitimate mail being discarded. That's a less clear way of saying much the same thing. You want recipients to not deliver some small subset of the mail that uses your brand without your permission, even at the cost of not delivering some small subset of mail using your brand with your permission. The english meaning of discardable matches the semantics pretty well. If we want implementors to easily understand and deploy the specification, and more importantly the limits of them doing so, thats fairly important. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
On Feb 8, 2008, at 12:26 PM, Douglas Otis wrote: Don't expect all high profile domains wish to suffer a reduction in delivery integrity when attempting to better protect their domain's recipients. Domains that do not with to suffer a reduction in delivery integrity are not candidates for use of any variant of SSP (and, as such, their needs are out of scope). Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Atkins Sent: Friday, February 08, 2008 2:28 PM To: DKIM List Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive It's an assertion that the sender would prefer that the recipient not deliver some small fraction of legitimate email as well as some small fraction of illegitimate email, rather than delivering those small fractions of legitimate and illegitimate email. I'm not sure that I would agree with framing it as some small fraction of illegitimate email. Tracking phishing attacks against our brands since we have started signing, a receiver checking DKIM and/or SPF would have easily identified 100% of those fraudulent emails. In the senders opinion, it is more important that mail claiming to be from them not be delivered than for it to be delivered. I think a more appropriate phrasing would be: In the senders opinion, it is more important that mail claiming to be from them and not conforming to certain parameters not be delivered than for it to be delivered - even at the risk of some legitimate mail being discarded. The english meaning of discardable matches the semantics pretty well. If we want implementors to easily understand and deploy the specification, and more importantly the limits of them doing so, thats fairly important. Cheers, Steve Whatever we decide to call it, SSP should allow a reasonable range of assertions from both 1st party domains as well as 3rd party domains. As long as there is clarity of the intended meaning of the assertions I'm comfortable that the marketplace of receivers will sort things out. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Steve Atkins wrote: You can't say receiver checking DKIM and/or SPF would stop 100% of fraudulent emails and then redefine fraudulent emails as mails stopped by receiver checking of DKIM and/or SPF. DKIM+SSP will only ever stop a tiny fraction of illegitimate emails, and pretending otherwise doesn't lead to an honest evaluation of the benefits and drawbacks of it. I dunno, you can also get paralyzed by the enormity of the problem too and do nothing. DKIM and SSP chip away at a very large problem, and I don't think we've ever tried to sell it as anything else. Instead of restating the obvious about no silver bullets, perhaps it would be better to think in terms what small little new thing we can do to chip away at the problem? We are looking like we're getting close to last call with nothing new left on our charter ;-) Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
On Feb 7, 2008, at 4:54 PM, Eric Allman wrote: The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE. Except that DISCARDABLE doesn't prohibit 3PS. It doesn't even say that messages without any signatures MUST or even SHOULD be discarded. All it says is how the purported author domain views the messages that it sends out. The furthest it goes is to say that the purported Author Domain encourages the recipient(s) to discard it. Eric, Agreed. This changes strict (the exclusivity) assertion into something that does not express a domain's intentions on exclusivity. This assertion simply increases the likelihood of having the domain's messages discarded. You have previously mentioned the motivation was to accommodate high profile domains finding themselves victims of phishing attacks. Using the term discardable appears to be sending the wrong message. It seems unlikely these high profile domains want their messages silently discarded, as this assertion implies. Discarding of messages does several things: - Destroys evidence of a serious crime - Reduces delivery integrity for important transactional messages - Makes resolving compatibility far more problematic Can you see changing this into terminology that does not attempt to suggest a verifier action? Going out on limb, I'll add a modified furthermore statement. (Frankly, this furthermore statement seems to belong in a BCP that happens later.) Using Hector's term exclusive- exclusive: All mail from the domain is signed with an intent to avoid agents that may damage or remove signatures. Furthermore, in lieu of a trusted third-party signature, if a message arrives without a valid Author Signature due to modification in transit, submission via a path without access to a signing key, or other reason, the domain encourages the recipient(s) to reject the message or issue a DSN when the RFC 2821 MAILFROM domains match. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
On Feb 8, 2008, at 1:41 PM, Michael Thomas wrote: Steve Atkins wrote: You can't say receiver checking DKIM and/or SPF would stop 100% of fraudulent emails and then redefine fraudulent emails as mails stopped by receiver checking of DKIM and/or SPF. DKIM+SSP will only ever stop a tiny fraction of illegitimate emails, and pretending otherwise doesn't lead to an honest evaluation of the benefits and drawbacks of it. I dunno, you can also get paralyzed by the enormity of the problem too and do nothing. DKIM and SSP chip away at a very large problem, and I don't think we've ever tried to sell it as anything else. Instead of restating the obvious about no silver bullets, perhaps it would be better to think in terms what small little new thing we can do to chip away at the problem? We are looking like we're getting close to last call with nothing new left on our charter ;-) My original observation was that discardable was a reasonable term for mail for which the sender prefer the recipient not deliver a small fraction of legitimate email and a small fraction of non-legitimate email rather than deliver either. There was an assertion made that the small fraction of non- legitimate email here was actually 100% of the non-legitimate email. That assertion was shown to be false, so we can ignore that digression and return to where I came in, which was: It's an assertion that the sender would prefer that the recipient not deliver some small fraction of legitimate email as well as some small fraction of illegitimate email, rather than delivering those small fractions of legitimate and illegitimate email. In the senders opinion, it is more important that mail claiming to be from them not be delivered than for it to be delivered. The english meaning of discardable matches the semantics pretty well. If we want implementors to easily understand and deploy the specification, and more importantly the limits of them doing so, thats fairly important. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Atkins Sent: Friday, February 08, 2008 4:49 PM To: DKIM List Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive My original observation was that discardable was a reasonable term for mail for which the sender prefer the recipient not deliver a small fraction of legitimate email and a small fraction of non-legitimate email rather than deliver either. Let's set aside your preference for a small fraction of all mail rather than my preference to examine a larger percentage of a smaller subset with regard to DKIM signing. Flip the question around regardless of which view one chooses to take. The question is really: If a domain chooses to sign DKIM with respect to a From field email address that purports to be from that domain and that domain has the ability to make an assertion (of any sort) through SSP with regard to it's practices: Is the potential benefit afforded a receiver by checking that SSP assertion AND taking whatever (unspecified) action worth the effort of doing so? If receivers are likely to have little or no benefit/interest in checking SSP then the rest of the discussion is moot. In other words, is the juice worth the squeeze? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8
Eric, I sincerely appreciate your response and I do hope you are on your way to full recovery from your surgery. I had a hip replacement a few years back and it was the first time in a long time I was forced into a prolonged 'vacation' from work. :-) It been a long road to where we are now. A road where we tuned nearly every stone and discussed, and even worked out. There were some remaining issues, but ones that I don't believe were not addressable. The best I can describe the concerns is that we lost the potential for protocol consistency fraud. For example, you pointed out SSP-01 DKIM=ALL offered 3rd party signatures and this could be deemed weaker, I agree with that point. However, I never indicated that a VALID 3rd party was ever classified as secured, but the lack of one is were the power of the concept is found. The concept is really nothing new compare to other fraud detection concepts, things we all do in some form or another, include SMTP. A simple example is a traffic cop requesting and analyzing your driver license. The officer is first going to make sure that the attributes indicated on the card matches what he sees in person. If the driver is a 20 year old woman and the license says 60 year old man, then this among other thing he can compare raises a red flag. Anything that doesn't conform to expectations is always the first thing people notice. As you know, this is a basic model in lots of things we do. In our SMTP world, an excellent example is PORT 25 and its relaxed SMTP compliance versus PORT 587 and its strict SMTP compliance requirements. i.e, EHLO checking under port 25 is recognized as low benefit for many historical reasons. Under port 587, EHLO correctness is a requirement. Same with other expects between the two protocols. In short, PORT 587 has less tolerance towards legacy operations - by design. You must login. You must have certain headers, etc. Even in standard SMTP port 25 operations, we have basic x822 header requirements that some systems may be very strict about if they don't exist in the DATA block or post SMTP processing. But there is no BCP for this. But with DKIM/SSP we can take control of this now and not allow it to become yet another relaxed protocol. So again, the power here is in protocol inconsistency fraud detection. Once things are all compliant then the other things comes into play, because there is really not much more DKIM/SSP can do from this point. This is where other layers may come into play, including reputation ideas and anything else. I never argued against reputation. I just felt that one group was trying to based DKIM/SSP on it only and not even given the SSP concept a chance. Unfortunately, the entire process has been commandeered in what appears to be a strategic goal to simply water it down to a level of total uselessness. So to me the idea of an Evaluator would be first a fundamental protocol consistency Evaluator that would be part of the DKIM/SSP framework across all supportive/compliant systems. It would be 100% independent from any subjective or heuristics or reputation analysis or any one group detecting their questionable inherent policies or implementations methods. It really has nothing to do with good guys vs bad guys because as we know, bad guys too can exhibit compliant behavior. But that is we want here - we want to make sure everyone (bad and good) are all playing in the same field of following the basic fundamental protocol. Just like we expect with other any standard client/server communications protocol. We want this model because if we can't expect compliance with the GOOD, than we can't expect it from the BAD, and if we allow DKIM/SSP to become this, we would be back to square one of relaxed SMTP legacy transactions where receivers lack enforcement and know hows but more importantly has no new information to rely on beyond the normal level of operations to consider. DKIM/SSP changes all that, this is what lead me to technology and I of the belief this will be a major benefit for the SMTP industry. But this is only going to work with a standard protocol out of the box all must follow if they wish to implement it. I think this is all separate from having extra evaluators (i.e, reputations, spam-assassin, etc). If we start with standard relaxed higher level system, then we will have lost an unique opportunity we haven't had in SMTP. Thanks -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Eric Allman wrote: Hector, Some of what you say is correct, but other descriptions of changes in SSP-02 don't match what we were trying to do. It may well be that we didn't get the wording right yet. First, a confession: most of the major changes in -02 are my doing. In particular, I think I pushed some things onto Jim that went further than he had wanted. I think it's unfair to ask Jim
RE: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8
Eric wrote: It is my sincere hope that we will quickly gain enough experience that new documents can be produced providing further guidance (not requirements) for how the Evaluator should interpret SSP for broadest interoperability. +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
MH Michael Hammer (5304): If a domain chooses to sign DKIM with respect to a From field email address that purports to be from that domain and that domain has the ability to make an assertion (of any sort) through SSP with regard to it's practices: Is the potential benefit afforded a receiver by checking that SSP assertion AND taking whatever (unspecified) action worth the effort of doing so? If receivers are likely to have little or no benefit/interest in checking SSP then the rest of the discussion is moot. In other words, is the juice worth the squeeze? Spammers can use DKIM and SSP too. Therefore and the juice is not worth the squeeze unless the receiver actually knows the domain. Perfect DKIM+SSP by a total stranger is relatively meaningless. But we've already visted that station many times in the past. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Atkins Sent: Friday, February 08, 2008 3:56 PM To: DKIM List Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive On Feb 8, 2008, at 12:18 PM, MH Michael Hammer (5304) wrote: It's an assertion that the sender would prefer that the recipient not deliver some small fraction of legitimate email as well as some small fraction of illegitimate email, rather than delivering those small fractions of legitimate and illegitimate email. I'm not sure that I would agree with framing it as some small fraction of illegitimate email. Tracking phishing attacks against our brands since we have started signing, a receiver checking DKIM and/or SPF would have easily identified 100% of those fraudulent emails. You're tracking at the wrong thing then, clearly. Checking my personal mailbox for mails using your brand: From: AmericanGreetings.com [EMAIL PROTECTED] From: americangreetings.com [EMAIL PROTECTED] From: americangreetings.com [EMAIL PROTECTED] From: AmericanGreetings.Com [EMAIL PROTECTED] From: americangreetings.com [EMAIL PROTECTED] From: AmericanGreetings.Com [EMAIL PROTECTED] From: AmericanGreetings.Com [EMAIL PROTECTED] From: AmericanGreetings.Com [EMAIL PROTECTED] From: americangreetings.com [EMAIL PROTECTED] There were also dozens of other mails that used the americangreetings.com brand in the body or subject of the message, but not in the From: field. So, in the data I'm looking at, the small fraction of illegitimate mail that would have been caught by SSP or anything similar would be 0%. (None of the americangreetings related stuff is actually phishing, of course, but many of the issues are quite similar to those of brands that actually are phished). I'm referring to mail that would be checked by DKIM against the From email address (not the pretty name). My bad for assuming the scope of the discussion was limited to what DKIM and DKIM-SSP can actually address. If that isn't the scope then we might as well say that asserting something in SSP doesn't stop people from speeding in automobiles. This isn't about silver bullets. DKIM addresses particular issues. If you prefer a constraining where clause then consider any of my comments on the list as constrained by For those things addressed through the use of DKIM signing and DKIM-SSP.. Having said that, there are receivers out there that do look for mismatches between From pretty name and email address or mismatched links in the body of the email. This is one of the reasons that we have structured our emails the way we have. If there were a mechanism that allowed me to automatically communicate this I would do a little jig. Instead I have one-on-one discussions with various receivers. I use the term phishing because APWG and others feel that the term is inclusive of these sorts of activities (malware links, etc). As with other terminology I'm perfectly willing to use other terms that might be commonly accepted. In the senders opinion, it is more important that mail claiming to be from them not be delivered than for it to be delivered. I think a more appropriate phrasing would be: In the senders opinion, it is more important that mail claiming to be from them and not conforming to certain parameters not be delivered than for it to be delivered - even at the risk of some legitimate mail being discarded. That's a less clear way of saying much the same thing. You want recipients to not deliver some small subset of the mail that uses your brand without your permission, even at the cost of not delivering some small subset of mail using your brand with your permission. The assertions you are looking at are not the ones we seek within DKIM-SSP. I'd be perfectly willing to see a broader means of making assertions that would protect against other forms of abus of our brandsas far as I know those are out of the scope of the discussion here. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
On Feb 8, 2008, at 1:19 PM, MH Michael Hammer (5304) wrote: I'm referring to mail that would be checked by DKIM against the From email address (not the pretty name). My bad for assuming the scope of the discussion was limited to what DKIM and DKIM-SSP can actually address. If that isn't the scope then we might as well say that asserting something in SSP doesn't stop people from speeding in automobiles. This isn't about silver bullets. DKIM addresses particular issues. If you prefer a constraining where clause then consider any of my comments on the list as constrained by For those things addressed through the use of DKIM signing and DKIM-SSP.. Having said that, there are receivers out there that do look for mismatches between From pretty name and email address or mismatched links in the body of the email. This is one of the reasons that we have structured our emails the way we have. If there were a mechanism that allowed me to automatically communicate this I would do a little jig. Instead I have one-on-one discussions with various receivers. You can't say receiver checking DKIM and/or SPF would stop 100% of fraudulent emails and then redefine fraudulent emails as mails stopped by receiver checking of DKIM and/or SPF. DKIM+SSP will only ever stop a tiny fraction of illegitimate emails, and pretending otherwise doesn't lead to an honest evaluation of the benefits and drawbacks of it. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Steve Atkins: My original observation was that discardable was a reasonable term for mail for which the sender prefer the recipient not deliver a small fraction of legitimate email and a small fraction of non-legitimate email rather than deliver either. There was an assertion made that the small fraction of non- legitimate email here was actually 100% of the non-legitimate email. That assertion was shown to be false, so we can ignore that digression and return to where I came in, which was: It's an assertion that the sender would prefer that the recipient not deliver some small fraction of legitimate email as well as some small fraction of illegitimate email, rather than delivering those small fractions of legitimate and illegitimate email. In the senders opinion, it is more important that mail claiming to be from them not be delivered than for it to be delivered. The english meaning of discardable matches the semantics pretty well. If we want implementors to easily understand and deploy the specification, and more importantly the limits of them doing so, thats fairly important. +1. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wietse Venema Sent: Friday, February 08, 2008 6:37 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive MH Michael Hammer (5304): If a domain chooses to sign DKIM with respect to a From field email address that purports to be from that domain and that domain has the ability to make an assertion (of any sort) through SSP with regard to it's practices: Is the potential benefit afforded a receiver by checking that SSP assertion AND taking whatever (unspecified) action worth the effort of doing so? If receivers are likely to have little or no benefit/interest in checking SSP then the rest of the discussion is moot. In other words, is the juice worth the squeeze? Spammers can use DKIM and SSP too. Therefore and the juice is not worth the squeeze unless the receiver actually knows the domain. Perfect DKIM+SSP by a total stranger is relatively meaningless. I'm asking in terms of the overall implementation. In a world where all domains are strangers the juice is definately not worth the squeeze. That is the chicken and egg of kickstarting adoption. Is the same true where half (or pick a percentage of your choice)the domains are strangers? At what point do the benefits of checking outweigh the costs of checking? But we've already visted that station many times in the past. Wietse While it may be absolutely correct with no context - relatively meaningless at a micro level until behavior starts to be examined and matched to that signature. At a macro level it may be that receivers assign a reputation of newly signing domains based on general experience with the class (or segments based on type of mail received from that class) newly signing domains. It may be that DKIM+SSP will be matched to previous mail flows by IP address or other characteristics associated with a sender. Until DKIM+SSP is in the wild it is hard to say how that will play out. If we are trying to use DKIM+SSP to directly identify bad then I'm not sure how useful it will be. There are plenty of ways for bad actors to act bad. On the other hand, if DKIM+SSP allows some determination of good reputation (tied to behavior of that signing domain) - even if over time - then it may be useful in some cases. If that then enables a comparison of the two (where bad is purporting to be the good actor within certain parameters)it may be useful in other cases. It will certainly be interesting to see what happens when DKIM+SSP good reputation turns to bad, especially when it involves subversion of a domains own security processes. Much talk of how reputation is gained but little of it's loss. How sticky will good reputation based on DKIM+SSP or other metrics be? Without SSP, how (or even why) will receivers choose to take advantage of DKIM? I'm not talking a handful of domains, I'm talking more general adoption by receivers. If potential 1st party or 3rd party legitimate signers (not the bad guys) don't have some expectation as to how receivers will interpret and act on their signing, how strong an incentive do they have to begin signing? I'm also assuming that their expectation has to be a positive outcome or they have a disincentive to sign. It's a given that spammers will try to use/abuse DKIM and DKIM+SSP to cloak themselves with. It's the nature of the beast. This ties into other issues surrounding mail,domain host compromise and other abuse. I fully realize that even if DKIM+SSP can afford protection for certain things it doesn't protect from all bad things. That's another given. My understanding with regard to DKIM and other authentication approaches is that the goal is to stake out defined areas and practices which can identify/protect legitimate (even if limited or only after reputation is built) mail and hopefully drive out bad actors from those areas. So if it isn't 3PS (01) and it isn't ASP (02) then what is it that is to be identified/protected by SSP? There are at least three large receivers that are checking DKIM and assigning pass/fail to those signatures, even if they may not currently be taking action on those determinations . I have to assume that there is a perceived potential benefit on their part to checking for signatures as well as checking of signatures. Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP help receivers (the 3 aforementioned as well as others) leverage their evaluation of received email whether signed (valid or not) or unsigned? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Wietse Venema wrote: MH Michael Hammer (5304): Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP help receivers (the 3 aforementioned as well as others) leverage their evaluation of received email whether signed (valid or not) or unsigned? known to be good whitelisting can be done with DKIM-BASE alone. SSP etc. is about the ABSENCE of valid signatures, and can help to strengthen the known to be good whitelisting process. You've said this several times, but I don't think that's the range of all possibilities. Ag.com is a pretty good example of somebody that I as a receiver don't know but if they're willing to say discard this if it's not signed, all other things being equal why wouldn't I? In any case, this is pretty squarely into the secret sauce of receiver filter logic, so I'm not sure what the point is about needing agreement; filters are certainly allowed to be more cautious which is how I read you. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
MH Michael Hammer (5304): Is the potential benefit afforded a receiver by checking that SSP assertion AND taking whatever (unspecified) action worth the effort of doing so? If receivers are likely to have little or no benefit/interest in checking SSP then the rest of the discussion is moot. In other words, is the juice worth the squeeze? Wietse: Spammers can use DKIM and SSP too. Therefore [..] the juice is not worth the squeeze unless the receiver actually knows the domain. Perfect DKIM+SSP by a total stranger is relatively meaningless. MH Michael Hammer: I'm asking in terms of the overall implementation. In a world where all domains are strangers the juice is definately not worth the squeeze. That is the chicken and egg of kickstarting adoption. The far majority of email is from strangers. Specifically, there is an awful lot of email with me as recipient from apparent senders that I have no relationship with. I have no reason to believe that my experience differs radically from that of other people. Is the same true where half (or pick a percentage of your choice)the domains are strangers? At what point do the benefits of checking outweigh the costs of checking? Honestly, I know of no reasons why spammers would start to send less email. There is a lot of spam out there that has nothing to do with domain spoofing and everything with gullible greedy recipients. So if it isn't 3PS (01) and it isn't ASP (02) then what is it that is to be identified/protected by SSP? It's primarily about whitelisting what's known to be good. When I get mail that claims to be from a total stranger then it does not matter if it is 100% DKIM/SSP compliant. Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP help receivers (the 3 aforementioned as well as others) leverage their evaluation of received email whether signed (valid or not) or unsigned? known to be good whitelisting can be done with DKIM-BASE alone. SSP etc. is about the ABSENCE of valid signatures, and can help to strengthen the known to be good whitelisting process. When I get mail that claims to be from a total stranger then it does not matter if it is 100% DKIM/SSP compliant. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Michael Thomas: Wietse Venema wrote: MH Michael Hammer (5304): Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP help receivers (the 3 aforementioned as well as others) leverage their evaluation of received email whether signed (valid or not) or unsigned? known to be good whitelisting can be done with DKIM-BASE alone. SSP etc. is about the ABSENCE of valid signatures, and can help to strengthen the known to be good whitelisting process. You've said this several times, but I don't think that's the range of all possibilities. Ag.com is a pretty good example of somebody that I as a receiver don't know but if they're willing to say discard this if it's not signed, all other things being equal why wouldn't I? You do what you want to do. I would hope that receivers don't discard mail simply because the domain owner says so. Instead, I would hope that their hint goes into a weighting process together with other indicators. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
On Feb 8, 2008, at 6:13 PM, Michael Thomas wrote: Wietse Venema wrote: MH Michael Hammer (5304): Is DKIM checking sufficient in itself without SSP? How might DKIM- SSP help receivers (the 3 aforementioned as well as others) leverage their evaluation of received email whether signed (valid or not) or unsigned? known to be good whitelisting can be done with DKIM-BASE alone. SSP etc. is about the ABSENCE of valid signatures, and can help to strengthen the known to be good whitelisting process. You've said this several times, but I don't think that's the range of all possibilities. Ag.com is a pretty good example of somebody that I as a receiver don't know but if they're willing to say discard this if it's not signed, all other things being equal why wouldn't I? Because a noticeable chunk of what you'd be discarding would be legitimate mail that your users wanted. If an ISP pays more attention to what senders want than what their paying users want, they don't deserve to be in the business. The driving factor for receivers is delivering mail that their users want, and not delivering mail that their users object to. That is at direct odds to the design of SSP (which is to not deliver some small fraction of email both legitimate and otherwise). In any case, this is pretty squarely into the secret sauce of receiver filter logic, so I'm not sure what the point is about needing agreement; filters are certainly allowed to be more cautious which is how I read you. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Return to issues?
Is there any possibility that we can return to the discipline of tracking individual issues using the issue tracker and our diligent issue scribe, Eliot Lear? I see a lot of discussion that is going around and around but not getting to closure. Again, if you raise an issue, please start the subject line with NEW ISSUE. Once the issue number is issued, please replace that with ISSUE # (or something like that) so that Eliot keeps his sanity. I have to work with him from time to time and would prefer he remain sane. I'd also like to see if, with SSP-02, we can close a bunch of the issues that are currently on the tracker. WG Chairs, can you take a shot at that (perhaps just confirming that some of the items marked ACCEPT(CHECK) are indeed closed? -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Wietse Venema wrote: Michael Thomas: Wietse Venema wrote: MH Michael Hammer (5304): Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP help receivers (the 3 aforementioned as well as others) leverage their evaluation of received email whether signed (valid or not) or unsigned? known to be good whitelisting can be done with DKIM-BASE alone. SSP etc. is about the ABSENCE of valid signatures, and can help to strengthen the known to be good whitelisting process. You've said this several times, but I don't think that's the range of all possibilities. Ag.com is a pretty good example of somebody that I as a receiver don't know but if they're willing to say discard this if it's not signed, all other things being equal why wouldn't I? You do what you want to do. I would hope that receivers don't discard mail simply because the domain owner says so. Instead, I would hope that their hint goes into a weighting process together with other indicators. Look, if you want to design your own products based on these heuristics, thats fine, but don't tell us what or how we should implement technology especially mandating via specs on methods that are without of doubt, highly questionable, subjective and puts systems and domains at risk for even greater abuse. The system MUST be based on PURE TRUE OR FALSE LOGIC and not anyone's GUESS work. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Steve Atkins wrote: On Feb 8, 2008, at 6:13 PM, Michael Thomas wrote: Wietse Venema wrote: MH Michael Hammer (5304): Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP help receivers (the 3 aforementioned as well as others) leverage their evaluation of received email whether signed (valid or not) or unsigned? known to be good whitelisting can be done with DKIM-BASE alone. SSP etc. is about the ABSENCE of valid signatures, and can help to strengthen the known to be good whitelisting process. You've said this several times, but I don't think that's the range of all possibilities. Ag.com is a pretty good example of somebody that I as a receiver don't know but if they're willing to say discard this if it's not signed, all other things being equal why wouldn't I? Because a noticeable chunk of what you'd be discarding would be legitimate mail that your users wanted. If an ISP pays more attention to what senders want than what their paying users want, they don't deserve to be in the business. This seems to presuppose that the owner of the author domain doesn't have any control over their own signing practices. If I publish discardable, and it's broken or unsigned that's pretty much my problem if it's legit. And I'd like to understand where you get a noticeable chunk as we've been running DKIM signing for almost 2 years now and even with diverse mail use patterns of your average mega-corp we still get 99%+ verification rates. And we most certainly do not fit the bill for discardable. For somebody who really fits the bill for discardable, I imagine that the false positives would be down in the noise of the other reasons you get false positives. The driving factor for receivers is delivering mail that their users want, and not delivering mail that their users object to. Sure. And a domain that tells me that I ought to consider tossing something that isn't signed is dropping a pretty big hint that your users are pretty likely to object to it. And if they're wrong, that's their own problem to correct. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Return to issues?
Jim Fenton wrote: Is there any possibility that we can return to the discipline of tracking individual issues using the issue tracker and our diligent issue scribe, Eliot Lear? I see a lot of discussion that is going around and around but not getting to closure. Again, if you raise an issue, please start the subject line with NEW ISSUE. Once the issue number is issued, please replace that with ISSUE # (or something like that) so that Eliot keeps his sanity. I have to work with him from time to time and would prefer he remain sane. I'd also like to see if, with SSP-02, we can close a bunch of the issues that are currently on the tracker. WG Chairs, can you take a shot at that (perhaps just confirming that some of the items marked ACCEPT(CHECK) are indeed closed? I believe that all of the issues that I raised can be closed as far as I'm concerned. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DEAD HORSE: SSP failure scenarios
Because a noticeable chunk of what you'd be discarding would be legitimate mail that your users wanted. If an ISP pays more attention to what senders want than what their paying users want, they don't deserve to be in the business. This seems to presuppose that the owner of the author domain doesn't have any control over their own signing practices. Not at all. It means that the author domain has some control but not perfect control over its signing practices, and there will always be paths that break SSP, e.g., mail-an-article, roaming users sending through hotel MTAs, mailing lists, forwarders that replace Sender lines, we all know what they are. And I'd like to understand where you get a noticeable chunk as we've been running DKIM signing for almost 2 years now and even with diverse mail use patterns of your average mega-corp we still get 99%+ verification rates. I'm not sure how average a megacorp Cisco is. I'll bet Cisco users send way less HTML mail that most other businesses, for example. What do you do about lists like this one that mutate the headers in ways that break signatures? I gather you may have some kludge to patch it up, but I don't think you can expect everyone else to do that. Sure. And a domain that tells me that I ought to consider tossing something that isn't signed is dropping a pretty big hint that your users are pretty likely to object to it. And if they're wrong, that's their own problem to correct. Look back at Steve's previous messages. If the domain's bad advice makes the ISP drop mail its users want, the users will blame the ISP, not the SSP record. This would make a reasonable ISP rather gunshy about believing the advice in random SSP records. There are certainly heavily phished domains that merit discarding, but given what a small fraction of the total universe of mail they are, it's much more likely that most of the domains that publish SSP discardable will instead be due to admins who don't understand what it means. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
