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).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html