Dave Crocker writes:
If 'p1' represents the fraction of
messages that are signed, and 'p2' represents the fraction of
mailing lists that re-sign messages. In order to avoid damaging
the reputation of the mailing list, assume it only sends signed
messages when it receives a signed message.
This is really an excellent, additional demonstration of why we need
to view mailing lists as end-points for signing mechanisms:
mailing lists are going to have their own signing policies and we
need to avoid the confusion that will ensue from having multiple
authorities claiming responsibility for the message.
I think of this exactly the opposite: by signing a piece of
mail, the signer is claiming some responsibility (what
responsibility is defined by the contents of the signature
block), and in order to keep your reputation you better be
careful about what you sign for. This is *wholly*
irrespective of where you are in the ultimate end to end
paths of mail. Trying to delineate functional units within
the path at this point is so many angels on a pinhead, IMO,
because so many things do not fit those old procrustean
categories. Many MTA's badly mangle mail. Many lists do
not. And everything in between.
Let's remember that this mechanism is only concerned with basic
transfer across the net, rather than long-term, broad responsibility
for the content.
Nobody's forgot that. But "transfer across the net" includes
the intermediate hops through mailing lists too.
I am making it sound like this entire line of effort is a hack to get
around a particular set of transition issues, rather than constituting
a clean mechanism for performing a necessary, core function.
Email deployment is messy. It is the world we live in. I
don't understand why this is the least bit controversial.
Previous security efforts may have a dubious track record,
but wishful thinking about transition -- as if that were a
small concern -- is far worse.
Mike