Charles Lindsey wrote:
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).
There are two cases where forwarders could break signatures:
* expansion of an alias
* list munging
Both of these concepts are (re)introduced in Section 5.3.6 of RFC-1123
ages ago. The former should not be broken, because it's a straight
envelope transformation. In reality there are things that could break
the signature, like garbage added to the bottom of a message and
SpamAssassin-like parsers. In both cases, we're still on an adoption
curve. If we don't solve these problems it really doesn't matter what
A-R has to say, because the underlying information will be relatively
useless.
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.
We can debate that on the DKIM list, but ultimately it matters to me
what you're engineering for. I would argue that DKIM did not engineer
for the problem you wish addressed, and that you are better off relying
on other solutions that exist today, such as GPG/PGP/S/MIME/....
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.
How about simply dropping or bouncing messages with broken signatures
prior to forwarding them? Put another way, and perhaps this addresses
John's issue a bit more, if the A-R header is meant only to be trace
information, then let's put a MUST NOT in there for the MUAs and I'd be
happy.
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'.
If you could expand on this more, that might be fine, but now we're
defining two headers.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html