3 months and 1300 mailing list posts ago, I wrote that I was going to survey some senders on SSP use cases and report results back to the list. At long last, here are the results.
We reached out to a large set of senders who are either heavily phished or have very valuable online brands they want to protect. Our results are therefore highly biased toward these organizations. They send high volumes of legitimate email using heavily phished domains. They will be among the earliest enterprises to deploy with aggressive SSP policies. All of these senders understand the inherent limitations in authenticating a domain used in email (cousin domains, friendly names, lack of client support, etc). They understand DKIM is not a 'silver bullet' solution but still believe DKIM offers a technology that over time will help reduce their current problems of domain spoofing. Developing SSP is very different from developing DKIM. DKIM is a technical challenge while the challenge of SSP is primarily to determine what senders want to communicate to receivers and what receivers want to know about senders policies/practices. SSP should provide a vocabulary to senders that meets their needs and is useful to receivers -- this is the most important requirement imho. Separation of SSP Requirements from SSP is very helpful. Here is their feedback. I have also requested that they join the list and provide direct input. This is *requirements* input, not proposing a solution. And if anyone attended the recent MAAWG conference in Toronto, this is the same information I presented to ISPs. Requirement #1. More aggressive practice options Senders are concerned the current options aren't aggressive enough to cause change in how spoofed email is handled. Without such a change implementing DKIM is of little value to them. The senders want to stop domain spoofing from impacting their brand and customers. They want more aggressive policy statements that will more aggressively encourage the receiver to drop spoofed email. It may be some time before they are 100% signing and common errors that cause signature failure for their mail are eliminated but they are focused on realizing this as soon as possible. When this happens, they want to be able to request that receivers drop signature failures or unsigned email. For some, the cost of phishing is so high and some day the risk of dropping messages will be so low that their inability to state a stronger policy will impact their ability to reduce the impact of domain spoofing. Another way to state this requirement is that there is a difference between, - I sign all email, and - I sign all email, treat unsigned or invalid signature with suspicion, and, - I sign all email AND have enough confidence in the reliability of signatures AND the risk of allowing spoofed email is high enough that I choose to accept the risk and therefore state that receivers should drop unsigned/invalid signature email. Requirement #2. I send no email. Many senders have a large number of domains that are never used in email. They want to be able to state this unambiguously. To the senders I surveyed, the 'I send no email' policy is a unique case from the other cases. I asked if they wanted this in addition to the SPF/SIDF '-all' policy and they universally said yes. Requirement #3. Feedback of invalid signature/unsigned mail Senders are concerned that the #1 item that will prevent them from moving to aggressive practices is the inability to identify errors. Errors on their part (failure to implement signing, improper signing), receiver errors (noncompliant implementations of DKIM validation) or anything else that Murphy's Law says will happen. They would like a feedback mechanism to be defined that provides this feedback. Defining this mechanism does not require it to be implemented by any receiver; failing to define this mechanism makes it impossible to implement easily for anyone. (Without going too far down the solution avenue, senders felt one possible solution to receiving an excessive number of invalid/unsigned feedback emails during a large-scale spoofing attack was to state that they only wanted feedback for emails which originated from their IP space as defined by their SPF record. Not a complete solution as envelope sender not equal From: and mailing list traffic doesn't originate from their IP space, but many felt this might be a good compromise solution.) Please consider these inputs and (hopefully) look for more direct input shortly. I hope these SSP requirements are useful for the SSP Requirements doc. I am unable to attend the IETF session today but I'm sure it will be a lively discussion. I've excerpted the most relevant sections from SSP Requirements and SSP below with some edits to be more specific about possible changes. Changes prepended with >>>> http://www.dkim.org/specs/draft-ietf-dkim-ssp-requirements-02.html 4.1. Problem Scenario 1: All Mail Signed with DKIM <snip> 3. A provides information that it signs all outgoing mail, but places no expectation on whether it will arrive with an intact signature. 4. B could use this information to bias its filters such that it looks somewhat more suspicious. >>> This is great for senders that sign their email but don't have confidence of high rate of receiver validation or that aren't too concerned with domain spoofing. 4.2. Problem Scenario 2: Illegitimate Domain Name Use <snip> 3. A provides information that it signs all outgoing mail, but places an expectation that it should arrive with an intact signature, and that the receiver should be suspicious if it does not. 4. B could use this information to bias its filters such that it looks much more suspicious. >>>> A set of senders really want B to drop this email. Giving them to vocabulary to state this is their desire. ISPs are of course free to do as they see fit, but providing them with more granular information is useful. 4.3. Problem Scenario 3: Domain Sends No Mail A domain may not intend to send mail at all. In such a case, it could be advantageous for a receiver to know the domain's intent and would be likely to treat such mail very suspiciously. >>>> Option to state "drop" vs "very suspiciously" desired. 6.3. Practice and Expectation Requirements <snip> 9. Practices and Expectations MUST be presented as an information service from the signing domain to be consumed as an added factor to the receiver's local policy. In particular, a Practice or Expectation MUST NOT mandate any disposition stance on the receiver. >>>> It's possible to state a desired disposition (drop) without mandating a disposition stance. An ambiguous expectation and a binary expectation is different from an expectation and a mandate. http://www.dkim.org/specs/draft-allman-dkim-ssp-02.txt 4.2. Record Syntax <snip> p= Outbound signing practices for the entity (plain-text; OPTIONAL, default is "unknown"). Possible values are as follows: unknown The entity may sign some or all email. all All mail from the entity is signed; unsigned email MUST be considered Suspicious. The entity may send messages through agents that may modify and re-sign messages, so email signed with a Verifier Acceptable Third-Party Signature SHOULD be considered non-Suspicious. strict All mail from the entity is signed; messages lacking a valid Originator Signature MUST be considered Suspicious. The entity does not expect to send messages through agents that may modify and re-sign messages. >>>> Notch above 'Suspicious' desired NON-NORMATIVE RATIONALE: Strict practices may be used by entities which send only transactional email to individual addresses and which are willing to accept the consequence of having some mail which is re-signed appear suspicious in return for additional control over their addresses. Strict practices may also be used by entities which do not send (and therefore do not sign) any email. >>>> Strict signing not equal to 'does not sign' use case to many senders. pat _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
