[ietf-dkim] Removing A-R headers

Murray S. Kucherawy msk at cloudmark.com
Thu Jun 11 01:59:30 PDT 2009


> 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.

This still seems blatantly off-topic to me (not to mention already being adequately discussed in RFC5451).



More information about the ietf-dkim mailing list