On Jan 22, 2008, at 3:12 AM, Charles Lindsey wrote:
On Tue, 22 Jan 2008 02:32:28 -0000, Douglas Otis <dotis(_at_)mail-
abuse.org> wrote:
1) To be SSP "strict" or "all" compliant, the identity associated
with a signature:
[...]
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
What benefit is derived by imposing an explicit i= parameter
requirement on an originating header for "all" or "strict" compliance?
RFC 4871 does not require signatures to identify specific entities,
and may produce ambiguous signatures lacking an i= local-part.
For SSP to impose a requirement that signatures _MUST_ identify
specific entities is beyond the WG charter.
A solution to assure compatibility with RFC 4871 would be 1-c.
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
How many From email-addresses should be allowed?
What benefit is derived imposing policy for Sender headers?
Would a From header referenced policy override a Sender header
referenced policy?
Currently, a small percentage of emails are signed using DKIM. Sender
header policy requirements substantially increases overhead related to
SSP.
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.
Allowing compliance with headers other than From permits a holder of a
g= restricted key to sign a message purporting to be "From" anyone
within the signing domain. In other words, g= restricted keys would
be of little value for protecting recipients with existing MUAs.
A solution where g= restricted keys can not be abused would be to
preclude compliance for any header other than From.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html