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.
b) must match an email-address associated an entity introducing the
message contained within the following headers:
From, Sender, Resent-From, Resent-Sender.
c) may not match with any header and may not be defined.
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)
The number of DNS transactions required to support SSP is affected by
the number of From email-addresses being protected. Currently SSP is
defined to reference SSP only for the first From email-address.
2) SSP references should be done for:
a) Only the first From email-address. (as currently defined)
b) All From email-addresses.
c) More than one From email-address is not be SSP compliant and is to
be considered to produce an invalid signature.
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.
RFC 4871 Section B.1.1 4th paragraph makes this statement:
[An outsourcing company can supply g= restricted keys] "using a unique
selector that authorizes a specific From header field Local-part. For
example, a client with the domain "example.com" could have the
selector record specify "g=winter-promotions" so that this signature
is only valid for mail with a From address of "winter-promotions(_at_)example(_dot_)com
"."
This comment is within the appendix and there is nothing within RFC
4871 nominative section that limits use of a g= restricted keys to the
just the From header, although this seems implied by section B.1.1.
Currently SSP is defined where g= restricted keys are compliant with
"all".
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.
b) SSP "all" or "strict" compliant regardless of the identity signed
on-behalf-of.
c) SSP "strict" compliant only when on-behalf-of the first From header
email-address. (as currently defined)
1-c
2-d
3-a
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html