Anything regarding t=y?
Based on SPF where this idea was borrowed from, it is basically a 100%
ignored option.
It is clearly a threat entry point allowing anyone to try to create a
DKIM signature and all they have to do is add t=y with the hope the
receiver will ignore all fail validations.
--
HLS
Murray S. Kucherawy wrote:
At the DKIM Interoperability Event in Dallas a couple of weeks ago I was
nominated as scribe during the discussions among the participants about
what parts of RFC4871 people found troublesome. This is the
distillation of those notes. They should be considered for possible
inclusion in a future "DKIM Errata" draft, if any.
1. "s=" in key records: There is no explicit guidance about what to do
with clearly bogus values. Examples given:
s=*:email
s=foo:email:bar
The normative text covering "s=" doesn't say what to do if one of the
colon-separated words is a word not enumerated in the "currently defined
service types". It also doesn't specify what to do with absurd values
like the first example. The consensus is to ignore any colon-separated
value not recognized and only pay attention to "*" and "email" for DKIM
e-mail implementations.
2. Empty bodies: Although the "simple" body canonicalization says
precisely what to do in the case of an empty message body, "relaxed"
does not. The consensus is that the "relaxed" body canonicalization of
the null body is the null input, but it was conspicuous that "simple"
was explicit while "relaxed" was not.
3. Multiple replies to TXT records: RFC4871 defines the handling of such
cases as "undefined", but it still came up in conversation several
times. Also noteworthy is that SSP has not yet added any discussion on
this topic.
4. Empty local parts can be problematic: RFC4871 discusses the "g="
(key) vs. "i=" (signature) comparison including the default for the
local-part to be used when "i=" is undefined, but it's possible a signer
could explicitly say "i=(_at_)example(_dot_)com" and there's no way for "g=" to
match that other than using a wildcard (or the default).
5. "x=" must be compared to a local time base instead of to "t=": I'm
not remembering the context about why I was asked to include this, so
maybe someone can refresh my memory here.
6. "h=" (key) vs. "a=" (signature): One participant felt the requirement
to corellate these two values was not sufficiently normative.
7. There is insufficient guidance about whether the domain in "i=" or
the domain in "d=" should be used when generating a domain reputation
query based on a DKIM signature verification. At the end of this
discussion, participants were asked to think about this and try to
generate language for inclusion in later specifications to provide such
guidance.
--
Murray S. Kucherawy =========================================
msk(_at_)sendmail(_dot_)com
Principal Engineer Sendmail, Inc. Emeryville,
CA, USA
(510) 594-5400
http://www.sendmail.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html