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