I've read through ssp-02 once (I need at least a few times to catch the
nuances) and I appreciate the addition of ASP and "discardable". I want
to emphasize that my position regarding domains that wish to take a
strong stance is (and has been) based on what I am seeing with regard to
phishing/other attacks and abused high profile domains.
I do agree with Hector that the options provided appear similar to the
outcome with regard to SPF and ~all. I don't know that I'm as troubled
by that. Domain owners have to make decisions regarding the tradeoffs
between security and the uses to which they allow their domains name and
reputation are put to.
A few specific comments regarding draft-ietf-dkim-ssp-02.txt:
1)Despite the fact that some may perceive my overall stance as hostile
to 3rd party signatures, I am not. I am only against 3rd party
signatures when they conflict with the assertions of a domain owner and
attempt to represent something other than those expressed wishes. In
that regard, I am less than comfortable with the final sentence of 3.2.
It is my belief that most recipient domains are likely to find not
checking author domain SSP (for discardable) as an invitation to abuse.
I am certain that domain mail administrators choosing to ignore such
assertions will quickly get tired of users contacting them regarding
abusive emails so I am not going to contest the wording.
It may be useful to consider - if not now then at some later point - a
mechanism by which either individual authors (as permitted by the domain
owner) or domains using ASP can indicate specific 3rd parties allowed to
sign on their behalf, whether for the main domain or specific
subdomains. This would provide an additional link in the authentication
chain if you will. I appreciate the concerns of some that this might end
up as quite the furball so I am only pointing it out, not pushing it.
I'm not sure that referencing a web page with a list (as was suggested)
is a viable approach. Perhaps this is the intent for ssp-t-tag-flag
under 3.3 in conjunction with selectors. Such an approach might address
the concerns of ESPs and other potential 3rd party signers.
2) I'm surprised that Dave hasn't commented regarding A.3 and the use of
the phrase "forgeries". I'm still ameniable if we can collectively come
up with a better term for the practice involved.
3) I understand why the "Evaluator" module is considered out of scope
for this document other than referencing it. Is there an intent to come
out with a document with regard to the "Evaluator" module? My reason for
asking is that it may be useful to at least define a standard framework
for expressing "any other data sources it cares to use in order to make
a decision regarding how the message should be processed".
Such a framework would allow for interoperability among and between
modules implementing the "Evaluator" function without explicitly
defining the outcome or process of evaluation. Just a thought and not
something I am personally particularly interested in pushing at this
time.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html