Dave Crocker wrote:
Folks,
This note is about an old topic that seems to remain unresolved. I'm
posting it to see where the working group is on the matter:
Rather, DKIM's task is to allow an organization to say this it has some
responsibility for the message; that is, come to them if there is a
problem.
I always had trouble with this "responsibility declaration." Something
was never right about it especially with the "ignore if failure"
semantic, with no really strong agreement on Policy. I can't see how
one would want to take responsibility when there is hardly any
protection for abuse. I don't want people "coming to us" when they see
abuse that had nothing to do with us. In fact, I will go on the record
to suggest this can open new legal issues, such as malpractice claims.
I need to be very careful about what I am going to tell people about
what DKIM offers and the last thing I want to tell them is we are
responsible for issues related to it, or that they will responsible for
all mail signed with DKIM.
In looking at the range of features that have been added to SSP, I keep
thinking that this distinction is not clear. It seems to me that there
is tendency to want to build "the content is valid" mechanisms into SSP.
Well, I think it is part of it, but not as important as policy or domain
expectations for their DKIM usage.
I say that because the integrity part of the design will always be a
risk in damage. But with Policy, it is more about protecting the domain
itself from unauthorize usage.
In any case, there is "No Tendency." it is the current SSP draft
specification. If the integrity fails or signature fails, the design is
such that it should then check SSP. Against my technical
recommendations, it is the only time SSP is checked.
SSP should be designed so it can be checked any time. Especially for a
mailings list subscription service where the DKIM ready list server can
validate a subscribing domain for usage on its list server as a 3rd
party or middle ware or outsourcing distribution point.
--
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