A domain wishing to protect their transactional mail may decide to
publish "strict" to limit the acceptance of "non-compliant" messages.
Compliance now requires the i= to not include a localpart, or for the
localpart to match with the From header.
This unnecessary requirement may produce "false positive" detections
of bad acts when signing domain uses i= as intended in the base draft,
which is to indicate on who's behalf the message was signed.
Options to mitigate "false positives" would be to:
1- Exclude the i= parameter
2- Add another signature specifically signing the From as well
Option 1 eliminates _any_ significance the i= parameter could have and
makes signature ambiguous.
Option 2 reduces significance of the i= parameters when the From
header is signed "because it was there".
A requirement to have verifiers enforce which headers a domain should
be signing seems over-reaching. However, in the case of the g=
restricted keys, there is already an expectation that verifiers will
qualify valid localparts.
Solution:
When the "strict" policy is asserted, limit "restricted" keys to being
compliant only when signing the From header.
This would not change restrictions already imposed on "restricted"
keys, but would allow the i= parameter to be used as intended by the
base draft, or in _any_ manner desired by the signer.
This minor modification would allow strict polices to:
a- protect transactional messages
b- allow the domain to run a mailing list, for example
c- allow unambiguous signing of the domain's messages
d- allow the identity expressed in the i= parameter to be opaque
when desired
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html