You all seem very comfortable saying that for all or strict a signature that doesn't match one of the designated message headers is automatically non-compliant, and that the message itself is non-compliant if that signature is the only one on the message.
There's a fair bit of mail out there that doesn't fit this scenario, i.e. which is signed by an entity other than those in the designated headers. Are you assuming that it's fine for that mail to be treated as suspicious/non-compliant, or that any domains for which this may be the case will never publish SSP records? I suspect that by the time you eliminate all domains that may have this problem you won't be left with very many that can safely publish SSP records, so either a lot of valid mail will be going into the bit-bucket or hardly anyone will be able to safely use SSP. Ellen > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ietf-dkim- > [EMAIL PROTECTED] On Behalf Of Charles Lindsey > Sent: Tuesday, January 22, 2008 6:12 AM > To: DKIM > Subject: Re: [ietf-dkim] What is your view on these three SSP topics? > > On Tue, 22 Jan 2008 02:32:28 -0000, Douglas Otis <[EMAIL PROTECTED]> > wrote: > > > As SSP is currently defined, a restricted or unrestricted key must be > > on-behalf-of the From header to be compliant with SSP "strict". > > > > 1) To be SSP "strict" or "all" compliant, the identity associated with a > > signature: > > > > a) must match an email-address within the From header. > +1 > > > > b) must match an email-address associated an entity introducing the > > message contained within the following headers: > > > > From, Sender, Resent-From, Resent-Sender. > +1 > > > > c) may not match with any header and may not be defined. > +0 > > > > d) may not match with any header and may not be defined except for SSP > > "strict" which is limited to not being defined or matching the first > > email-address within the From. (as currently defined) > -1 > > Add: > e) Each entity with a "strict" or "all" SSP within the following > headers > From, Sender, Resent-From, Resent-Sender > must be matched by an associated signature (if, in some complicated > case, > this requires the presence of several signatures, then so be it). > +2 > > > > 2) SSP references should be done for: > > > > a) Only the first From email-address. (as currently defined) > -1 > > > > b) All From email-addresses. > +1 > > Add: > bb) All From email-addresses PLUS the Sender address, if any > +2 > > > > c) More than one From email-address is not be SSP compliant and is to be > > considered to produce an invalid signature. > -1 > > > > d) More than two From addresses is not be SSP compliant and is to be > > considered to produce an invalid signature. When two From addresses are > > used, both domains should be checked for SSP compliance. > -1 > > > > 3) Keys restricted by a g= parameter are treated as valid and are: > > > > a) SSP "all" or "strict" compliant only when on-behalf-of a From header > > email-address. > +1 > > Add: > a) SSP "all" or "strict" compliant only when on-behalf-of a From, > Sender, > Resent-From or Resent-Sender header email address. > +2 > > > > b) SSP "all" or "strict" compliant regardless of the identity signed > > on-behalf-of. > -1 > > > > c) SSP "strict" compliant only when on-behalf-of the first From header > > email-address. (as currently defined) > -1 > > -- > Charles H. Lindsey ---------At Home, doing my own thing------------------- > ----- > Tel: +44 161 436 6131 > Web: http://www.cs.man.ac.uk/~chl > Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, > U.K. > PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 > AB A5 > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
