Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Hector Santos wrote: Pray tell, are you aware this tells the MTA who are processing the payload at the SMTP DATA state (not POST SMTP), to issue a 250 positive message accept response code with the true purpose of silently discarding it? So its more of a PUBLIC REJECT notification PRIVATE DISCARDING OF MAIL (no notification) operational behavior? Sorry, I meant: PUBLIC ACCEPT notification PRIVATE DISCARDING OF MAIL (no notification) -- 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
At 09:14 24-02-2008, Hector Santos wrote: Pray tell, are you aware this tells the MTA who are processing the payload at the SMTP DATA state (not POST SMTP), to issue a 250 positive message accept response code with the true purpose of silently discarding it? Yes. So its more of a At 09:23 24-02-2008, Hector Santos wrote: PUBLIC ACCEPT notification PRIVATE DISCARDING OF MAIL (no notification) operational behavior? Yes. Of course, this would also conflict the current direction of MTA of doing more dynamic SMTP level analysis of mail by mandating a DKIM/ASP design of delaying the payload analysis to POST SMTP. If you mean DKIM/ASP verification, that can be done during the SMTP session. Regards, -sm ___ 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 Sun, Feb 24, 2008 at 2:46 PM, SM [EMAIL PROTECTED] wrote: At 09:14 24-02-2008, Hector Santos wrote: Pray tell, are you aware this tells the MTA who are processing the payload at the SMTP DATA state (not POST SMTP), to issue a 250 positive message accept response code with the true purpose of silently discarding it? Yes. Agreed. All you are doing at this point is releasing the responsibility for the delivery of the message from the sending MTA. What you do with the message after that is your own business. You ARE accepting the message, dropping it on the floor is a matter of policy, not RFC's. Regards, Damon ___ 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
How very strange I wonder what explains the over 2k bounce messages of undeliverability due to content in my honey trap mail account that has been spoofed in the last 3 days alone. It appears that cheap software, designer shoes and On line degrees don't apply to the RFC's. It seems that organizations around the world don't adhere to the specs. That is why commercial messages need to be delivered to the inbox in some other method from edge to edge than smtp via a community service bureau or other entity. This WOULD allow a 99.999% delivery rate of valid messages while killing 99.999% of spam. Also it would free up considerable bandwith as commercial mail would only need one copy of a message to be delivered to each ISP instead of spraying millions hoping for a high receive rate. thanks, Bill -Original Message- From: [EMAIL PROTECTED] on behalf of Thom O'Connor Sent: Wed 2/20/2008 7:43 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive Eric Allman wrote: 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. Hi Eric, I understand this sentiment, and your point here is notable. However, it is very important that the terminology in use here is accurate and appropriate. The global messaging user-base wants and expects guidance on implementation that should be clear and direct. The truth of the matter is, the discarding of email should be expressly discouraged. No message should ever be discarded - RFC 2821 suggests this though does not explicitly disallow or discourage it: http://www.ietf.org/rfc/rfc2821.txt Delivery SMTP systems MAY reject (bounce) such messages rather than deliver them. The discarding of email is one of the key causes of some significant loss of trust in email as a reliable means of communication. While it may be argued that spam may have caused email receiving domains to react in this way as a defense mechanism, it is actually the overreaction - perhaps due to a lack of guidance - that has allowed providers to think that discarding messages is a satisfactory response to the spam or malware threat. Perhaps, if our techniques were 100% accurate in ensuring that no valid message was ever lost, discarding could be appropriate. These techniques will not likely ever reach 100% accuracy. If we (where we is the email industry here that seeks to maintain and even expand the usefulness of email itself, rather than seeing our users resort to making a phone call or using IM when they need a sure method of communication) should be clear about this then, one appropriate value for the SSP record would be reject or something equally directive, perhaps verify. And if we are to really seek to be clear on the Signing Practice in use, then perhaps we may even include a none value: none - The domain signs no email. unknown - The domain may sign none, some, or all email. all - All mail from the domain is signed with an Author Signature. reject (or verify) - All mail from the domain is signed with an Author Signature. Furthermore, 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 it if it does not verify. There are certainly valid reasons that a domain may request this higher level of requested interpretation - signature-based verification moves email towards an (optional) higher level of reliability and identity verification with legal and commercial implications. Douglas Otis wrote: 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. 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. This line of thinking is on target, though we really need to get better at using words our users will understand. exclusive is ambiguous, and I would argue, not an easily understood concept. Signature did not verify would seem to be an error message that could possibly be understood by a normal user in a DSN message
Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt Discardable/Exclusive
Eric Allman wrote: 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. Hi Eric, I understand this sentiment, and your point here is notable. However, it is very important that the terminology in use here is accurate and appropriate. The global messaging user-base wants and expects guidance on implementation that should be clear and direct. The truth of the matter is, the discarding of email should be expressly discouraged. No message should ever be discarded - RFC 2821 suggests this though does not explicitly disallow or discourage it: http://www.ietf.org/rfc/rfc2821.txt Delivery SMTP systems MAY reject (bounce) such messages rather than deliver them. The discarding of email is one of the key causes of some significant loss of trust in email as a reliable means of communication. While it may be argued that spam may have caused email receiving domains to react in this way as a defense mechanism, it is actually the overreaction - perhaps due to a lack of guidance - that has allowed providers to think that discarding messages is a satisfactory response to the spam or malware threat. Perhaps, if our techniques were 100% accurate in ensuring that no valid message was ever lost, discarding could be appropriate. These techniques will not likely ever reach 100% accuracy. If we (where we is the email industry here that seeks to maintain and even expand the usefulness of email itself, rather than seeing our users resort to making a phone call or using IM when they need a sure method of communication) should be clear about this then, one appropriate value for the SSP record would be reject or something equally directive, perhaps verify. And if we are to really seek to be clear on the Signing Practice in use, then perhaps we may even include a none value: none - The domain signs no email. unknown - The domain may sign none, some, or all email. all - All mail from the domain is signed with an Author Signature. reject (or verify) - All mail from the domain is signed with an Author Signature. Furthermore, 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 it if it does not verify. There are certainly valid reasons that a domain may request this higher level of requested interpretation - signature-based verification moves email towards an (optional) higher level of reliability and identity verification with legal and commercial implications. Douglas Otis wrote: 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. 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. This line of thinking is on target, though we really need to get better at using words our users will understand. exclusive is ambiguous, and I would argue, not an easily understood concept. Signature did not verify would seem to be an error message that could possibly be understood by a normal user in a DSN message. Sincerely, respectfully, -thom ___ 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
Eliot Lear wrote: Wietse Venema wrote: 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. Ain't nothing wrong with this approach. If someone wants to zero out the other indicators, it's up to them. I for one will want to consider reputation of the sender along with SSP results (to say the very least). The rest of this thread seems to me moot based on the current direction of SSP-02. Well I think that's perfectly prudent too. What I was reacting to is this notion that I have to know the domain in question to assign those weights -- whatever it means to know. The ag example is a good one where I'm nearly certain that I don't know them = layer 7, but I'm happy having them give me SSP advice for those layers to act on. I don't need to have some prior relationship with them to make that negative assertion be useful. 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
Michael Thomas: Eliot Lear wrote: Wietse Venema wrote: 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. Ain't nothing wrong with this approach. If someone wants to zero out the other indicators, it's up to them. I for one will want to consider reputation of the sender along with SSP results (to say the very least). The rest of this thread seems to me moot based on the current direction of SSP-02. Well I think that's perfectly prudent too. What I was reacting to is this notion that I have to know the domain in question to assign those weights -- whatever it means to know. The ag example is a good one where I'm nearly certain that I don't know them = layer 7, but I'm happy having them give me SSP advice for those layers to act on. I don't need to have some prior relationship with them to make that negative assertion be useful. I admit, the need to know is mainly for whitelisting, which I view as the primary purpose of DKIM and what's built on top of it. 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
Wietse Venema wrote: Michael Thomas: Well I think that's perfectly prudent too. What I was reacting to is this notion that I have to know the domain in question to assign those weights -- whatever it means to know. The ag example is a good one where I'm nearly certain that I don't know them = layer 7, but I'm happy having them give me SSP advice for those layers to act on. I don't need to have some prior relationship with them to make that negative assertion be useful. I admit, the need to know is mainly for whitelisting, which I view as the primary purpose of DKIM and what's built on top of it. When do whitelist them? After you manually review the rejection or acceptance logs or On Hold Logs? or for the lack of a complaint from user? Or are you relying on an automated 3rd party whitelist system? -- 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
Wietse Venema wrote: 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. Ain't nothing wrong with this approach. If someone wants to zero out the other indicators, it's up to them. I for one will want to consider reputation of the sender along with SSP results (to say the very least). The rest of this thread seems to me moot based on the current direction of SSP-02. Eliot ___ 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
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 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
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
