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