There seems to be quite a bit here I don't understand.
Douglas Otis wrote:
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.
"Compliance" must be equivalent to "being not Suspicious".
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.
I need an example to understand what would constitute a false positive.
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".
All DKIM signatures MUST sign the From header field (RFC 4871, section 5.4).
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.
There is an expectation in the sense that the local-part of the signing
address MUST match the g= value.
Solution:
When the "strict" policy is asserted, limit "restricted" keys to being
compliant only when signing the From header.
Again confused. The From header field is always signed.
If you can describe the proposal in more precise terms, I'd be in a
better position to respond.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html