+1 Jon.
I want to get my input and implementation considerations on these tags.
Overall, optimized processing and lower receiver abuse are the goals.
T=
This is the only one I see that has no place in production ware and
should not become a perpetuate tag used by a domains. Unfortunately,
since it is present in the specs, it can't be ignored. Our plan was
to provide a local policy for a domain "t=y time period" that correlates
to ongoing faults. When first seen, if the signature fails, the domain
t=y domain will recorded. If it continues, then an operator option will
be provided to flag it. This tag was proposed to be remove long ago.
I thought we had majority consensus on this during the threat analysis.
X=
Our plan was to use this as an fault optimizer. If present, it will help
reduce DNS lookups and rehash overhead. I refer to Mr. Thomas on this.
L=
This tag has useful ideas however it comes with some replay abuse
potential but I don't think the handling can not be overcome.. It all
depends on how receivers provide operators the options to deal with
fault overall. If used to promote abusive failure (i.e. bad guy is
trying to force receivers to turn off DKIM, and uses T=Y as well) then
domain policy if available can help here. I personally think high value
domains (banks, eCommerce with direct 1 to 1 communications with their
users) will use it less, if at all, than list systems or some
newsletter/ad emailer broadcasting 1 to many communications. So I am
on the fence on this, but I think it is a useful feature that can be
used positively. I vote to keep.
K=
I was expecting to use to key tag to serve as a preemptive safety
feature for high value domains. The idea is that the vendor wants to
sign up a new customer and offer email as part of their business
communications. The vendor can ask the user for his email address and
with the right tools provided, quickly do a lookup to see if the user's
principal domain receiver supports DKIM and proper verification. If
not, the vendor might offer and assign their own special service domain
email account or outsource the email service who can provide secured
communications between the vendor and the user. or they might just tell
the user to get an gmail.com for their communications. In short, the
utility of tag will help proper expected interoperability. If the
user's domain does not support a newer or recommended hashing method,
the high value domain vendor might not want to risk unsecured
communications with the user.
--
HLS
Jon Callas wrote:
This is especially true for the features that are undeniably
controversial. l= leaps to mind as undeniably controversial. Some
people loathe it, some people love it. (I am, as I've always been, in
the middle where I see both sides of that one.) But the fact that it
is truly controversial is why is should stay. Removing a controversial
feature because it is controversial flies at the very process of rough
consensus, and I think we just shouldn't go there.
I thus now believe that if a feature is in 4871, it should stay in
4871bis unless there is strong consensus to remove it. Surely there
must be one or two of those, but the mere presence of a large
discussion indicates that it needs to say.
Jon
------------------------------------------------------------------------
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html