[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