Barry Leiba wrote: >> Namely, codify the existing specification and specifically adding >> simple text that imply: >> >> Forwarders SHOULD|MUST NOT break ADSP domain messages. >> >> or >> >> Forwarders SHOULD|MUST take into account ADSP Domains >> before stripping and resigning or signing ADSP domain messages. >> >> Why is this not a legitimate consideration for rechartering - Codify >> the existing RFC specifications? Can you explain why it would not be >> thus not even include it in your suggestions? > > Oversight. It's certainly a valid way to proceed, and it should be > included in the discussion. > > You'll need to clarify where you think this text should go. Note that > RFC 5617 does not "update" RFC 4871, using "update" in the RFC sense. > That means that no one implementing DKIM base is told to go read ADSP > and get more implementation information there. They can do ADSP or > not, as they please.
> > That also means that if we add your text to ADSP, it won't help > implementations that do DKIM base only. > +1, Please make a note of this point you made here with the notes I have made and the one I will surmise below. >> I even suggested a far fetch possibility to "deprecate" RFC 5617, if >> thats all even IETF procedurally possible, to help remove this >> on-going dispute. I can understand this would be extreme, but there >> was a agreement but another person with this. > > This is basically John Levine's suggestion, in his branch-off thread > ("How about that..."): > >> Re the ADSP data collection, I'd like to add a third option to move it >> to Historic if ADSP turns out to be as useful as I think, but I >> realize this is unlikely to be a popular suggestion. > > "Historic" is the proper way to take a protocol out of current use. > There's also a stronger mechanism, if we should decide that it was > SUCH a bad idea that we really wanted to tell people, "NOOOOO! DON'T > USE IT!": we could make an "ADSP Considered Harmful" RFC that > officially updates 5617. > > I personally think it's way too early to consider any of this now, > which is why the ADSP step in the proposed charter starts with data > collection and analysis. +1. I respect the idea that ADSP and another "add-on" or "extended" DKIM technology is 100% optional. However, the "data collection and analysis" have shown me that this only applies or the written guidelines only applies to receivers. The implementation problems begin with intermediaries, more specifically, remailers, forwarders, middle ware such as a mailing list server. I can make our SMTP receiver ignore or not support ADSP, but I can't ignore it for our remailers (Mail List Server). Do you see the difference here? All I have ask that we address this issue regarding remailers. > But I will change my working version of the proposal to make it clear > that we have flexibility in what to do after the analysis is done: > > * Collect data on the deployment and interoperability of the > Author Domain Signing Practices protocol (RFC 5617), and > determine if/when it's ready to advance on the standards track. > Take action as appropriate -- update it at Proposed Standard, > advance it to Draft Standard, move it to Historic, or some other > action that the working group decides. > > How's that? I have no issue with this wording as long we encompass all the possible solutions with a strong look as to why there is a barrier to wide adoption. We want field testing and data collection, but its like a chicken and egg situation. It is prohibitive for anyone to even bother with ADSP because of the remailer issue. I think many people want to support it ,but they can't. No one can. Therefore I see little chance of anyone collecting data because the "experiment" or R&D process is crippled from the outset. Finally, the text I proposed was based on my offlist question and your offlist suggestions to me. That is why this specific issue note with suggested correction was posted: http://mipassoc.org/pipermail/ietf-dkim/2009q4/012648.html proposed additional text for Deployment Guide 6.5. "Before any forwarder attempts to modifies messages and add a new signature to the message, it SHOULD look at the ADSP record for the 5322.From domain. If the domain has an ADSP record with "dkim=all" or "dkim=discardable", the forwards SHOULD NOT forward the message. Note: Forwarders who do not support ADSP should be aware bounce mail may be result. For mailing list systems, false subscriber removal notifications can occur when subscribers MDA receivers are supporting ADSP. See section 6.1 for ADSP support recommendations." With this, it it my opinion, that implementators will have more information to work with when they begin their software redesigns or operators change their scripts, etc. Allow them to decide add this or not. Then we begin to see how effective or ineffective ADSP will be. One last note: This was not new. The old expired 2006 DSAP provided some guidance here as well: http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-12 3.3. Mailing List Servers Mailing List Servers (MLS) applications who are compliant with DKIM and DSAP operations, SHOULD adhere to the following guidelines: Subscription Controls MLS subscription processes should perform a DSAP check to determine if a subscribing email domain DSAP policy is restrictive in regards to mail integrity changes or 3rd party signatures. The MLS SHOULD only allow original domain policies who allow 3rd party signatures. Message Content Integrity Change List Servers which will alter the message content SHOULD only do so for original domains with optional DKIM signing practices and it should remove the original signature if present. If the List Server is not going to alter the message, it SHOULD NOT remove the signature, if present. There has been a number of people then and even today who agree that the above are helpful notes and/or begins to mitigate this long time issue for remailers as well as for domains who wish is to be protected by SSP (ADSP). Thats all and I will try to make this my final input on this. Thanks -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html