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