[ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
dotis at mail-abuse.org
Mon Jun 22 08:43:39 PDT 2009
On Jun 22, 2009, at 2:51 AM, Charles Lindsey wrote:
> On Fri, 19 Jun 2009 17:55:57 +0100, Douglas Otis <dotis at mail-
>> It dangerous to consider A-R headers of unknown origins as somehow
>> inherently safe......
> Unless they are included in a signature.
Unverifiable DKIM signatures will not confirm the origin of an A-R
> An A-R record always includes an idication of the domain that
> purported to have place it there. If it is signed by that same
> domain (as would be the case in the scenarios we are discussing),
> then more reliance can be placed on it (depending on your opinion of
> that signer - but you opinion of the manager of a mailing list you
> have subscribed to is likely to be quite high).
There is no assurance that RFC 5451 "authserv-id" have any
relationship with an RFC 4871 d= values. There is also no assurance
that bogus A-R headers would have been removed. Amongst the
confused advice about retaining A-R headers, there is also not a
certain practice of not signing A-R headers, even when A-R headers are
not added. Do you expect there will be d= requirements imposed upon
authserv-ids, since that is not how A-R validation works?
> I agree that an unsigned A-R is dubious, but even then if it
> purports to have been placed there by a domain which
> a) the message has been passed through, and
> b) you are prepared to trust to have removed any pre-existing
> bogus A-R purporting to have been placed there by that domain
> then it should be pretty safe (and this was indeed the case for the
> example we were discussing).
What this would be trusting may not be common practice. In addition,
there is no defined relationship between authserv-id and d= values or,
for that matter, domains in general.
A mailing list might use a signing domain of "foo.tld" and the
authserv-id of "bar.unique".
By allowing inclusion of A-R headers having unknown origins remains a
risky practice since a recipient's MUA might trust these headers.
A safe practice would remove all foreign A-R headers. Exceptions made
when signed by verified DKIM signatures still requires trusting the
DKIM signature not to introduce misleading A-R headers. Again, there
is no direct relationship between RFC 5451 "authserv-id" and RFC 4871
More information about the ietf-dkim