Jim,
Note the change in Subject line. I believe we need to focus on some
very basic issues, in order to decide whether to include heuristic
hacks that work around *some* mailing list behavior.
In the short run, requiring that mailing lists do this in order
for verification to work is a serious deployment problem.
It will take some amount of time for mailing lists to begin
checking signatures and signing; if that's too long people may
give up on message signatures.
This is true for any change to an established service. For that
matter, it is true for any service at all.
For the current discussion, we need adoption by sending sites and
receiving sites (and, here, the different between adoption by mtas vs.
muas is irrelevant). Mailing Lists are just one more example of
adoption.
Treating mailing lists as a special concern introduces significant
additional complexity to the specification, makes end-to-end
performance significantly more problematic -- by defining the
end-points as crossing an intermediate UA -- and is just as likely to
frustrate user expectations as it is to aid them.
We should make some attempt to get
message signing to work with at least some mailing lists to make
it more effective before the lists upgrade.
We should also make some attempt to get message signing to work with
at least some personal Forwarding or Resending.
Or maybe we shouldn't.
Maybe survivial of the signature across re-postings is not a goal.
Maybe we should define a simple, clean service, that has a constrained
goal and constrained specification. That way it will be easier to
understand and implement and it will work predictably. This will make
adoption and use far easier.
I am trying to imagine designing any other Internet protocol that has
special features to hack around transient adoption concerns.
I agree, but this is a different issue entirely. In the absence
of mailing lists that re-sign, the original sender signature will
be the only one available.
The problem is that, in a very real sense, it will not be valid and it
should not be!
Let's step back and ask what the purpose of this signature is.
The purpose of the mailsig mechanism is:
Provide an assertion of message transit origination
accountability that can be validated.
The use of this accountability is during message reception,
to assess likely acceptability.
We are not trying to replicate pgp or s/mime. We are trying to serve
an entirely different purpose. We are trying to say who is
responsible for injecting this message into the message transfer
service.
The mailing list processor is responsible for injecting the message
into the transfer service. Therefore the only signature that is valid
for mail coming from it is the mailing list signature. The original
authors are not accountable for the potentially arbitrary behavior of
mailing list processors.
Let's not design a specification that pretends otherwise.
I consider a valid signature that is based on the 2822 From
address to be more valuable than another one applied later because
it signs the address that I will be looking at in my MUA;
There is no automatic requirement that the recipient user see anything
about the signature.
Really.
This is an example of just how different the current goal is from pgp
and s/mime.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com