John Levine writes:
Why? Because two users who otherwise are signing and validating their
messages can't control an intermediate third party's mailing list which
isn't signing its own outgoing messages. In such cases, you seem to
prefer that the original poster's signature self destruct -- that is,
be unavailable to the receiver at all.
Putting silly statements into the mouths of people who disagree with
you is rarely a persuasive debating technique.
Indeed.
I can't speak for Dave, but nothing I've seen so far changes my
conclusion that attempts to make signatures survive mailing lists and
other mutations are fundamentally a bad idea. They add vast amounts
of complexity for at most an occasional and transitory, and more
likely an illusory benefit.
Then I must conclude that you think that MASS is a
fundamentally bad idea as MTA's -- and everything else
in the mail routing path -- manifestly make mutations to
messages. And your notion that appending a byte count
to a message is a "massive" amount of complexity...
where to begin.
I don't know all of the ways that list software might mutate a
message, and neither does anyone else. We still don't have anything
close to a concrete proposal to take an IIM signature and a message
and tell us whether the message is close enough to the signature that
we can conclude that the differences are only due to a trip through a
mailing list. And I don't think we ever will, either. Feel free to
prove me wrong, preferably with C code I can run, but I'm not holding
my breath.
Sourceforge is your friend.
The experiments I've seen with DK have shown that even rather
simple-looking fuzzy matches can let through heavily mutated messages,
while some common mutations like virus scanner tag lines can be really
hard to deal with. I don't see any reason to think that IIM would be
any different in those regards.
Huh? Both DK and IIM have a nofws canonicialization.
IIM allows a body count too. That's the *only* difference
in this regard. So I really don't know what you're
talking about.
As far as I'm concerned, there are exactly two kinds of message
forwards. There's the simple dot-forward kind in which the message is
unmodified other than perhaps having a few headers added at the top.
And then there's everything else, mailing lists, MUAs that smash as
they forward, whatever.
MTA's modify messages too. Sendmail, for example. Try
feeding it a line of 2049 'a's and see what happens.
And sendmail is hardly in outlier in this regard.
For the first kind, I hope we agree that it's easy to make a signature
scheme work. For the second kind, it's not, so my advice is don't
even try.
No it's not "easy". I don't agree. There's complexity
all around.
The whole point of message signatures is to know who's responsible for
the message. For mailing list messages, the responsible party is the
list.
I disagree. When I view a message from John Levine
on ietf-mailsig(_at_)imc(_dot_)org, I think the responsible
party is John Levine, not 1000 monkeys diverted
from their day job of pounding out Shakespeare.
You can't tell anything about the quality of a list by checking
internal signatures. A list with no internal signatures might be
manually moderated by someone who calls all the submitters on the
phone to check that the messages are real. A list with 100% internal
signatures could be 100% from dead Nigerian generals.
This is true of *any* intermediate in the path. Really.
So, please, if you believe that it's useful to have signatures pass
through lists, show us that it works. Show us running code that can
handle mutations from common list managers (try Yahoo Groups, mailman,
listserv, sympa, lyris, and majordomo) but can't be trivially spoofed.
Give us some rules to tell us what we're supposed to do with list mail
that has various combinations of good and bad nested signatures. At
this point, all I see is smoke.
Sourceforge is your friend.
Mike