On Mon, 15 Oct 2007 06:11:46 +0100, Eliot Lear <lear(_at_)cisco(_dot_)com>
wrote:
... As long as your forwarders don't break signatures you should
be good. I could see a use case for SPF where the check will fail
because the forwarder isn't in the list, but then I have to weigh that
against the MASSIVE hole that opens up that would make SPF useless.
But forwarders DO break signatures (the worst culprit is mailing list
expanders which can be expected to do it all the time).
And, as I have been arguing on the DKIM list, somtimes you would like to
now whether the message submitted to the list really did come from its
purported sender, as-well-as or instead-of knowing whether it arrived at
you via the list.
My argument in this case has always been that the list administrator
should add an A-R to say that the about-to-be-broken signature passed when
it arrived at his expander, and then include that A-R in the signature
when he signs it himself.
So when it arrives at your border, then the A-R added at the border
certifies (to you) not only that the message came from THE LIST, but also
that THE LIST (and none other) has asserted that the now-broken signature
passed when it arrived at him (which might not be true if the list admin
is a rogue, but it is the best you are going to get in the circumstances).
But it only works if the A-R added by the list admin is still there when
you receive it.
So rather than removing A-R headers (just in case some 'stupid' user
believes them), border systems should either rename them as something
else, or add some further header to make it clear which ones were
'guaranteed' and which ones were 'suspicious'.
--
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