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
