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
