Doug,

Thank you.

Now Issue 1519.

Eliot

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.
>
> 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
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to