[ietf-dkim] Removing A-R headers
doug.mtview at gmail.com
Wed Jun 10 11:47:54 PDT 2009
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:
>> 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.
More information about the ietf-dkim