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