ietf-dkim
[Top] [All Lists]

[ietf-dkim] Re: DKIM and mailing lists

2006-01-21 06:19:14
Mark Delany wrote:

I think we're in trouble if the list signs something that is
already signed.
[...]
a signed List-ID proves it came via the List that I've
subscribed to. An unadorned List-ID could, shall we say, be
forged.

So far it was my impression that DKIM tries to establish some
accountability as near to the "originator" as possible.  As a
simple rule that's "if it already has a valid signature, don't
touch it".

If you try to decompose this into more MON -> *mediator -> MRN
pieces what you get is SPF.  Apparently you and Jim think that
lists are reliable filters, catching all kinds of bad actors.

IMHO they are not, they can screw up like everybody else.  And
many of them are FUBAR adding bogus subject tags, adding bogus
footers to text/plain, adding controversial PRA header fields,
and adding bogus Reply-To list header fields.

Some go so far as to force their footer into any content type
that's not text/plain by manufacturing a multipart/mixed with
their funny footer in an additional text/plain part.

Any decent mail2news gateway like GMaNe undoes some of these
dubious list manipulations, it removes the bogus subject tags
and the weird text/plain footers.  I'd love it if GMaNe would 
also strip all Reply-To list, I'm used to Re:news -> to list,
Re:Mail -> to author, Re:both -> guess, but I digress.

In that muddy waters DKIM should try to stay out of trouble and
make it as simple as possible at least for those lists wishing
to do "the right thing".  Whatever that might be, certainly not
adding funny footers, subject tags, and Reply-To list.

"Got valid signature -> don't touch it" is a simple rule.  It's
as near to "end-to-end" as possible with DKIM.  For something
that's radically NOT "end-to-end" folks know where to find SPF
(with zero impact on mailing lists).

If DKIM-aware lists would be forced to do different things for
submitters depending on their SSP of the day it's messy.

If an existing signature is valid that should be all the list
needs to know:  No lookup of the SSP trying to determine what
it says today about third party signatures.

Even if such distinctions are not well made today, we should
enable the possibility rather than preclude it and then have
to deal with it in five years time with another DKIM-like WG.

Well, I can't nail it, but my gut feeling is that it's wrong.

Fortunately there's no such thing as "sign some - third party
never" in SSP, so at least for unsigned mails the situation is
clear for DKIM-aware lists.
                           Bye, Frank


_______________________________________________
ietf-dkim mailing list
http://dkim.org