Signature compliance changes when a From domain's SSP indicates
"strict".
When a message has a valid unconstrained signature of the From domain,
verifiers should consider this domain's signature authoritative for
the domain's policies. The only instance where the i= parameter
should play a role in "strict" policy compliance would be when the key
restricts local-parts via the g= parameter.
As SSP's "strict" is currently defined, although a message might be
signed by the From domain using an unrestricted key, when the i=
parameter is not "on-behalf-of" the From header, it will not provide
compliance with a "strict" policy. The From domain should validate
sources within their domain prior to signing. Hopefully this
signature will also indicate the validated source. A "strict" policy
should not interfere in a signature's ability to indicate which source
had been validated.
SSP's "strict" creates an unnecessary i= parameter requirement that
will cause:
- unexpected corner cases such as when -
a) office administrators send "on-behalf-of" their boss (Sender)/From
...
Mitigating corner cases will require:
- use of ambiguous signatures where the i= parameter is excluded
- use of multiple signatures
SSP policy should strive to minimize disruption. There is no
justification for "strict" policy compliance to invalidate any
unrestricted signature of the From domain. After all, unrestricted
keys are able to sign any header and _must_ be utilized by trustworthy
systems. When unrestricted keys are used, it is also reasonable to
assume that the domain's signing policies were applied prior to
signing. SSP's "strict" definition unreasonably constrains how the i=
parameter might be utilized for unrestricted keys. It is not
reasonable to assume domains will have mitigated the exceptions
created by the SSP definition for "strict" and its additional i=
parameter requirements. It is only reasonable to assume DKIM
practices are based upon RFC 4871. As currently defined, SSP is not
compliant with RFC 4871.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html