On Thu, 28 Oct 2004, David Woodhouse wrote:
In that case, surely William's comparison matrix is inaccurate? It says:
The comparison matrix was based on IIM version 00 draft. The draft has
changed to version 01 an I need to review it fully and if necessary make
the changes to the matrix (with assistance of Jim I hope). There was also
version 00 of TEOS released although I think I got it right the last time
(after many many changes to that column).
"Signature is not affected if additional text is added to email body"
IIM: "No (signature would not verify)".
Due in part to my lack of time, I'd discarded IIM as a serious proposal
for that reason alone, and hadn't read the draft in detail. Surviving
mailing lists is one of the _most_ important criteria in my opinion.
I'll try to find some time to read it now.
My understanding is that IIMs latest proposal includes count on number of
bytes in the text so the signature probably survive simple additionl of
text at the end. I kindof knew they would be doing it back from last IETF
but I'm not certain its enough to deal with mail lists fully.
On the other hand it's also a fundamental requirement that a scheme
should have a way to advertise to the world that all mail from a given
address will be signed. Without that you can't just reject unsigned mail
up-front. And according to William's table, IIM lacks that too.
If I'm not mistaken they've added "null key" record that is supposed to
serve this purpose. In any case policy records are easy to add by means
of SPF modifier when we need it.
We are not trying to make every mailing list work without
modification to re-sign. But making some lists work through simple
mechanisms like this seems like a small amount of effort well spent.
Yeah -- making _every_ mailing list work would be an impossible task.
But most mailing lists don't do much to the mail as it passes through,
and what they do normally do is easy enough to deal with. It would be
negligent for us not to bother, for no better reason than "oh, the
complexity of it".
There are so many mail lists around that even if all mail list vendors
updated their software all at once (which I doubt and would estimate
it will take then 1-2 years) getting the lists to upgrade will take
another 1-5 years (number of people setup list on some old machine which
may not be easy to upgrade to new software version, they'll be hisitant
to move mail list to new hardware).
I'm sorry but I have to totally agree with David, there is no way mail
sigining system can work if the signatures do not survive mail list
processing and really do provide end-end verification (and not just
hop-hop).
Why so? I see lots of mail with both From: and Resent-From: headers, and
why should I not want to verify that the author really did write the
message?
As far as I know very few mail lists actually change "From:" and even
fewer (is it none?) add Reset-From.
That's true -- I agree. My point was that there's a trade-off to be had.
We can have something really simple, or we can accept a modicum more
complexity in order to make it more useful.
We do have to be aware that some MUAs won't actually display the address
in the From: header either, mind you -- but users of really broken MUAs
are always going to have problems.
Which exactly are the MUAs that don't display From header?
The only thing I know is that one rather large company responsible for
most MUAs in use likes to make easy-phish-target products that only
display the "pretty name" and not the email address. There is however
some hope that this will be changing soon.
I want that too. That's why I want my own signature on a mail to survive
even if a mailing list resends it and signs it for itself, or if someone
else resubmits it with Resent-* headers to the mail system.
I agree.
Multiple signatures really aren't hard to do. It's _not_ that complex.
Let's not strive for simplicity at the cost of useful functionality.
Yes, If somebody wants to verify multiple signatures - let them do it,
that is their problem not ours that they want to do extra processing.
But in my opionion all signatures should be end-end and verify by any
subsequent email server in the path.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net