J.D. Falk wrote:
> Whoever wants to take on this project should feel free to > borrow from the article I wrote in June: > > http://www.circleid.com/posts/dkim_for_discussion_lists/ J.D, the issue with your suggestions is that once again, there is ignorance of RFC 5617 ADSP policies by list receivers and especially resigners. At least I don't see any implication for RFC 5617 support in your outline. IMTO, before any automated concept can work well, the supportive DKIM network must expect protocol consistency to be established among all DKIM nodes. The receiver MTA or node that will receive and provide DKIM verification processing SHOULD honor RFC 5617 if they are going to resigned, then it MUST support RFC 5617. Consider this real situation that happen a few weeks ago. It opened my eyes in how RFC 5617 MUST be interpreted and has altered how it must be implemented for our mail API system. This occurred with the DKIM-DEV list I am subscribed to. I forget the exact reasons but the end result is that my MDA began to reject my copy of the DKIM-DEV list distributed mail I thought the sender was white listed as I receiving mail fine in the past. But something changed on either end and I received an automated final warning notification that my subscription would be moved if I don't response to the notification (click the url and confirm I am a real person). It was odd the notification got thru but normal distribution were rejected. So I fixed that by adding more white listing rules for this list sender. That got me thinking about RFC 5617 support as it was being implementing as part of our SMTP level scripting filter language. Out of the box, our inbound MTA will run the "DKIM SCRIPT" at the SMTP level. So imagine, if a resigned mail was received from mipassoc.org for a author domain that happens to have a ADSP = "DISCARD" or "ALL", then this would be a failed DKIM/ADSP transaction. It was already troubling that a list server would not honor RFC 5617, but now I saw how the list server can now begin to send notifications to subscribers for rejected mail. If the inbound MTA issues a 55x rejection, then what will happen is the MLS will begin to send notifications threatening to auto-remove subscribers who's MDA are rejecting the resigned mail. So I see three possible mitigating options: 1) Update RFC 5617 1.a) All DKIM-BASE compliant receivers SHOULD supprt RFC 5617 1.b) All DKIM Resigners MUST respect RFC 5617 1.c) All receivers who support RFC 5617 MUST use post message acception silent discarding of mail and not use a SMTP level rejection to avoid bounce issues and mail list subscription removals. 2) Extend RFC 5617 with an explicit 3rd party signing option. 3) Deprecate RFC 5617 If list server developers or operators are not expected to support or honor RFC 5617, then we SHOULD declare RFC 5617 has as non interoperable with DKIM-BASE, deprecate it and remove it from standard track. Ideally, I think #1 is required if we are going to keep it. I think should also be considered as well. But I don't think we can stick with RFC 5617 if resigners are not going to support it when random receivers might support simply because its there! So #3 is an option I am hoping the opponents of policy will finally see a legitimate reason to get rid of ADSP. I saw that because I would rather to get rid of ADSP if its not going to be properly recognized honored by resigners. -- Hector Santos, CTO Santronics Software, Inc. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
