On Wed, 3 Nov 2004, Dave Crocker wrote:
On Mon, 01 Nov 2004 16:29:58 -0800, Jim Fenton wrote:
I agree that mailing lists should re-sign messages. But I expect
that it will take quite a while before that happens, and in the
meanwhile, I want the original signature to work wherever possible.
and it will take quite awhile for other sending software to start
signing, too. shall we try to compensate for them, too, somehow?
The thing about SPF is that it allows policy to say that if email did not
have such property or came from such source, then its bad and this makes
it possible to use this against those why try to impersonate you (i.e.
phishing and other major problems).
So for MASS to be successfull (and being more then we could achieve with
automation of S/MIME or PGP signing), we need to allow those individuals
and companies that do sign all messages to make an assertion about it to
the public and let the recepient reject mail supposedely from those
company/individual that is not properly signed. But to be able to make
such an assertion the sender needs to feel safe that his signature would
survive the mailing and not be rejected because its has been screed by
some intermediate system.
what is significant about the current thread is the nature of the
analysis that needs to be done, to handle the changes a mailing list
can introduce into a previously-signed message.
I agree that we need to do look more into how mail lists change emails
and which mail list software does it and how it can be fixed if need to.
internet standards that rely on these kinds of statistical and case
analyses make for complex, problematic implementation and testing.
But its a lot worth when you don't do the analysis and end up proposing
something that will be unworkable in real life because it fails with
existing deployed base.
Folks -- we are working in a topic that has an unbroken track record
of failing to gain ANY large-scale successes in the entire history of
the IETF, in spite of repeated attempts.
This track record calls for taking the most narrow, focused approach
we can. This means the specification should be absolutely minimalist.
I disagree. PGP for example is pretty minimalist approach and still it
failed adoption. S/MIME has lots of features and itstill failed. My
believe is that both failed because they were trying to force the end-user
and MUAs to make most changes and automated approach by smaller depoyed
MTA base may have better chance to succeed.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/