On Feb 2, 2008, at 3:18 AM, Eliot Lear wrote:
Douglas Otis wrote:
This draft goes to the opposite extreme of the ASP draft and
increases the restrictions for "all" compliance as well. This draft
indicates _ALL_ messages are to include a signature with an i=
parameter matches that of an identity within the From header. This
is not the defined use for RFC 4871.
The ASP approach creates fewer corner cases. At least with the ASP
draft, any risk of misuse remains within the control of a domain to
rectify.
IMHO, unless the SSP draft is changed to comply with RFC 4871, the
WG should consider adopting the ASP draft instead.
Please indicate the paragraph in RFC 4871 that this draft would
conflict with.
RFC 4871:
,---
3.5. The DKIM-Signature Header Field
...
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed (dkim-quoted-printable;
OPTIONAL, default is an empty Local-part followed by an "@" followed
by the domain from the "d=" tag). The syntax is a standard email
address where the Local-part MAY be omitted. The domain part of the
address MUST be the same as or a subdomain of the value of the "d=" tag.
'___
RFC 4871 clearly indicates the i= parameter is _intended_ to identify
the user or agent for which the message is being signed. When a
signature is added on-behalf-of an entity whose email-address is found
within the Sender header, and where the message happens to include a
From address within the same domain, the definition for Author
Signature within the SSP makes the signature specified by RFC 4871 non-
compliant with an "all" or "discardable" policy assertions, however
the definition within ASP does not. SSP stipulations changes RFC 4871
signature handling to not use the i= parameter when there might be
such a conflict with the From header. Not surprisingly, RFC 4871
never suggested the i= parameter not be used when there might be a
conflict with an address within the From header. This definition
ensures the i= parameter will:
1) be falsified to include the From header email-address.
2) exclude the local-part to remain ambiguous.
3) necessitate multiple signatures to overcome ambiguities created by
option 2.
SSP-02:
,---
2.6. Author Address
The "Author Address" is an email address in the From header field of
a message [RFC2822]. If the From header field contains multiple
addresses, the message has multiple Author Addresses, which may
potentially cause the Evaluator to perform multiple SSP Checks for a
given message.
2.8. Author Signature
An "Author Signature" is any Valid Signature where the identity of
the user or agent on behalf of which the message is signed (listed in
the "i=" tag or its default value from the "d=" tag) matches an
Author Address in the message.
'___
The SSP Author Signature definition essentially makes use of the i=
parameter when the identity is not found within the From header
problematic. As the i= parameter is the only field that pertains to
actual agent, it might be obfuscated by the signing domains using
temporal hashing, but could be useful for tracking, for example. Per
the Author Signature definition in SSP, this type of use will require
multiple signatures. The additional overhead of multiple signatures
is not necessary and represents a waste of resources or the
prohibition of many uses for the i= parameter.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html