On Jun 10, 2009, at 9:58 AM, Michael Thomas wrote:
J.D. Falk wrote:
Charles Lindsey wrote:
What I think it makes clear that we are in serious need of some
document to provide Best Practice for how mailing list expanders
should handle DKIM, and I think that is something that this WG
needs to take on board.
Feel free to use my article on CircleID as a starting point:
http://www.circleid.com/posts/dkim_for_discussion_lists/
It's so simple and obvious (once you move from theory to practice)
that I'm
not sure if it's worth the WG's time.
There is *NO* *REASON* to strip signatures. NONE.
In fact it is HARMFUL.
This is true for mailing lists when signature recovery is employed. :^)
In addition, acceptance of indirect A-R records should be handled with
caution. Keep in mind that A-R headers themselves are not secure,
and that trust in "authserv-id" (that recipients may have been asked
to enter into their MUA to enable annotations) need to have originated
from their specific trust environment. Unlike the d= parameter in
DKIM, administrators of trust environments can assign an arbitrary and
hopefully unique "authserv-id". Imagine the fun and mischief this ad-
hoc assignment permits, especially when identifiers have been
encoded. There are no A-R "authserv-id" police, nor is there a means
to confirm legitimate use of "authserv-id" indirectly. As such, the
scope of specific "authserv-ids" should be restricted to the immediate
receiving account. To offer improved security, non-local "authserv-
id" A-R headers for the account should be removed or defanged to
inhibit acceptance of possibly deceptive A-R headers. It is common
for filtering rules to move messages into folders shared by accounts,
nor is there assurance that A-R headers have not been reordered when
multiple A-R headers are discovered.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html