One final note from me, as I want to state my current position regarding
4871bis, with respect to Last Call.
As the receiving verifier has all the information to _reliably_ [0]
determine which combination(s) [1] of From [2] and DKIM-Signature
verifies correctly, it has the means to provide any consuming
application with the right information. The mechanism(s) by which the
verification results can be communicated to a consumer (as per par. 6.2
of 4871bis) can be chosen by the verifier and does not restrict the
results to only TEMPFAIL, PERMFAIL and SUCCESS [3].
Second, today there is hardly any installed base of MUA's that present
any form of DKIM results to the end user, so most of this technology
still needs to be written and 4871bis contains sufficient warnings about
duplicate From and other fields; so in my view the argument of DKIM not
being 'compatible' with the currently installed base of MUA's does not
apply.
Third, DKIM is only one of multiple technologies that can and will be
deployed by both senders and receivers. This means that any policy
published by a sender regarding the use of DKIM does not have to provide
a sharp 'black' or 'white', 'keep' or 'discard' result. Senders that
wish to publish a policy need to take into account that the world is not
perfect and that there always will be lousy implementations of protocols
(be it RFC5321, RFC5322, RFC4871 or RFC4871bis). [4] It's better to
acknowledge this, than to rely on the 'MUST's in this particular DKIM
RFC. Policies that do not take this into account, can/may have dramatic
results.
Hence, I no longer see a problem in 4871bis not mandating the duplicate
header check.
/rolf
[0] irrespective of whether a From field has been prepended or appended
or no such thing at all
[1] (s) plural form, if there are multiple DKIM-Signatures and multiple
From fields.
[2] From is mentioned here only:
- because it is the only mandatory header field to be used to generate
the signature and
- for the case that there's a consuming application that would display
the From header, which in your view is the attack vector
Apart from that, there is no special reason to focus here on From
[3] although TEMPFAIL and PERMFAIL are mentioned in 4871, there is no
equivalent identifier for a positive result, is there? I suggest to make
the success status explicit in 4871bis
[4] The fact that a sender doesn't know in advance how well the receiver
implements the DKIM verification process will need to be taken into
account for any policy protocol that will be built on top of DKIM.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf