[ietf-dkim] Final update to 4871bis for working group review
dotis at mail-abuse.org
Fri Jul 8 11:26:55 PDT 2011
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.
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
More information about the ietf-dkim