Folks, I think we've enough to be doing to process the current set of issues with SSP without taking on additional work to get consensus on text like this.
So, by all means develop a summary, but unless its intended to put it in the SSP I-D, this is not something where we expect or need WG consensus, so it'd maybe be better to do it on say some DKIM marketing list rather than take up cycles here, or else to wait until we've resolved most of the issues and the list is quieter. Thanks, S. Dave Crocker wrote: > Folks, > > Here is a revised version of the SSP Summary Description, based on comments > received: > > > > > The IETF's DKIM working group has followed its specification of a base > method > for associating a responsible identity to an email, via cryptographic > signing. > The new specification is for Sender Signing Practices (SSP). The SSP > specification describes itself as defining a mechanism "senders may use to > advertise how they sign their outgoing mail, and how verifiers should > access > and interpret those results." That is, SSP permits potential DKIM > signers to > publish statements about how they use DKIM, and also to publish > directions for > DKIM validators (receivers) on how they are to handle a class of received > messages. > > The SSP mechanism permits a potential signer -- that is, the owner of a > domain > name -- to publish an SSP-specific DNS record -- a TXT record in an > SSP-specific branch under the domain name. On the receive-side, the domain > name under which the DNS query is made is taken from the author's mailbox > address -- the rfc2822.From <addr-spec> portion of an address -- in a > received > message. > > By associating an organization's verifiable identity to a message, the > reputation of that organization can then be used by a message-receiving > engine, for determining message handling, such as whether to deliver the > message to the designated recipient. This is what DKIM Base permits. > > By contrast, SSP seeks to detect misbehaviors, specifically related to > unauthorized use of the email address in a message's RFC2822.From field > <addr-spec>. SSP does not seek to deal with other identity fraud, such > as in > the human-readable RFC2822.From <display-name>, the Subject field, or in > the > message body, or any use of "cousin" domains that can be confused with a > target domain. > > SSP is motivated by a desire on the part of message senders, to inform > message > recipients about constraints on the senders' practices. The premise is > that > receivers with this additional information will be able to detect, and > possibly reject, a class of mail that is not legitimate. At best, the > mechanism is approximate, in that a legitimate message might begin with a > legitimate signature that becomes broken during transit. When SSP is used, > such messages will be treated by the recipient as exceptions. > > The current SSP draft provides for two basic conditions which will > trigger a > query: > > 1. Unsigned message. When a receiver gets a message that has no DKIM > signature, they can query the DNS for an SSP record that is associated with > the domain name in the (first) rfc2822.From field header mailbox address. > > > 2. Signed message. When a receiver gets a message that is signed, and > lists one identity in the signature's i= parameter -- the identity on > behalf > of which the message is signed -- but another in the (first) address in the > From field, then perform the SSP query, described in step 1. > > The publisher of an SSP record can say that: > > 1. All mail that they send is signed by them > > 2. All mail that they send is signed by them and they do not send > mail via > intermediaries -- called "third parties" -- such as mailing lists that may > modify and re-sign the message. > > Messages that fail an SSP analysis are handled as exceptions. The > publisher of > an SSP record may request that such mail be treated to: > > 1. Further consideration, where the exceptional status is only one > factor > in determining handling. > > 2. Rejected. > > SSP also permits the publisher to declare that the record applies to all of > its sub-domains, although there is a DNS limitation on reconciling deeply > nested sub-domains with this record. > > The SSP specification defines a 10-step "check procedure" that is a > decision > tree for performing SSP analysis. > > As an example of implications, the SSP rejection semantics would mean > that a > SSP-conformant receiving site would reject a message that has a broken > author > signature,even if it still had a valid signature by an operator with a good > reputation. SSP is likely to have a number of other interactions with email > handling practice. > > Given that adoption of a new mechanism like DKIM's base signing takes many > years, adoption by any arbitrary sender/receiver pair is unlikely for many > years, absent prior arrangement. So most publishers of SSP records will be > sending to sites that are not checking them. Equally it should be assumed > that receivers will almost always obtain a failed SSP DNS query, for every > message with a new (un-cached) domain name in the From field. > > > d/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
