[mail-vet-discuss] Draft as of 9/4/2007

[Eliot Lear]

Charles Lindsey wrote:
> On Mon, 15 Oct 2007 06:11:46 +0100, Eliot Lear <lear at cisco.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