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