[ietf-dkim] Final update to 4871bis for working group review

[Douglas Otis]

On 7/8/11 4:43 AM, Alessandro Vesely wrote:
> On 07/Jul/11 16:13, Dave CROCKER wrote:
>> On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote:
>>>> I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise
>>>> Postel's statement, do we?)
>>> You're either liberal in your application of the RFCs, or you're not.  I
>>> don't see how adding that word improves things here.
>> well, it keeps the thread going...
> You /have/ to be liberal, but that can be limited in degree and in
> time.  An app must be liberal in what it accepts, not only because a
> specification is subject to some variance in interpretation, but also
> because of unavoidable time differences in its adoption.  Since no RFC
> can be transmitted faster than the speed of light, a host which
> adopted an RFC at time t0 (see graph) has to wait at least until time
> t2 before a compliant signal from a distant source may reach it.
Alessandro,

Ensuring multiple header fields stipulated as occurring once not provide 
a deceptive DKIM result does not alter the intent of DKIM validation.  
It is important for DKIM compliance to ensure deceptive and invalid 
header field instances are excluded by the verification process from 
returning valid signatures.  Clarifying this stipulation to establish 
proper verification layering will not raise interchange issues.

These checks must be part of any DKIM compliance certification program 
or recipients are at risk.  Language in the base specification must make 
this requirement clear.  After all, it was missed and exploited with 
DKIM's implementation used by the WG mailing list, if anyone needs examples.

It would be unwise to invest either trust or services in an easily 
exploited system.

-Doug