On Mon, 08 Jun 2009 19:30:38 +0100, Doug Otis
<doug(_dot_)mtview(_at_)gmail(_dot_)com>
wrote:
On Jun 8, 2009, at 3:24 AM, Charles Lindsey wrote:
For sure, individual recipients may wish to check signatures etc.
for themselves, espeicially if they have doubts about the policies
applied by their local assessors. If the local assessor has
unnecessarily removed some A-R that is actually covered by the
signature, then that becomes impossible.
The use of the DKIM l=, z= and x= features provide a means for
recipients to separately evaluate DKIM signatures without reliance on
intermediary assessors. In addition, the A-R header does not capture
the IP address when assessing path registration protocols, which means
that safe recipient reassessment might only be possible in the case of
DKIM or reverse DNS.
I accept that my remarks concerning the retention of A-R headers are
directed at the case where those headers are confirming the analysis of
some DKIM signature. Different considerations may well apply when the A-R
is reporting on some other security mechanism.
The safest solution would be to remove _all_ A-R pre-existing A-R
headers from different environments ...
But that's not what the standard says.
Wrong. See RFC 5451 section 5, complete removal is suggested for
maximum security. It also suggests:
When you first made your claim, you were relying on Section 4.1. Now I
have shot that one down, you have transferred to Section 5.
But section 5 merely says you MAY remove A-R headers, but then immediately
goes on to warn you of two situations where this might be counter
productive. Both of those situations arise in the scenarios I have been
discussing.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html