--On 30 April 2010 18:24:43 +0000 John Levine <johnl(_at_)iecc(_dot_)com> wrote:
We need to be precise about what we mean by "trustworthy". Even if I
have "some way to identify trustworthy lists" as you put it above, I
have to be very clear about what I'm actually trusting that list to do.
When I sign up for a list, I trust it to send me mail that I am
willing to receive. Is there any other understanding of mailing
lists that people have?
There's a lot of detail in there. Implicit is that (for most people that
understand these things), the list will only accept email from certain
authorised senders. Problem is that very many lists don't currently
authenticate senders, and its hard to know which do.
Stripping DKIM signatures as a matter of course does nothing to resolve
that problem. In fact, it fossilises the problem. Adding signed A-R data is
equivalent to making the claim that the list does authenticate senders.
That's not worthless, even though it's not proof of authentication. It
might be particularly valuable if the sender can sign elements of the email
that are not likely to be mutated by the list.
I wonder, for example, whether it would be possible to send a message to a
list with two signatures. One signing the entire message, so that the list
can authenticate the sender. The second would sign some headers that won't
be mutated, plus a header that says something like "you should only trust
this signature if it's part of a DKIM signed message from
list(_at_)example(_dot_)org". Effectively, you're delegating authority to
example.org,
but perhaps with some limitations like an expiry date, content of the
subject line, etc. I guess this requires some new techniques - like
negotiation between the signer and the list about which headers the list
might modify.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html