-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
domainkeys-feedbackbase01(_at_)yahoo(_dot_)com
Sent: Wednesday, December 01, 2004 10:21 AM
To: ietf-mailsig
Subject: Re: Web pages for MASS effort
Now, my guess is that right now we need signatures that can survive
alterations but once enough mail list servers and other intermediate
systems signing, we may well begin to slowly change to more secure
signatures.
The first problem with this strategy is that it punished early
adopters.
As a
sender, what possible interest have I in going from a system where my
signature
does survive to one where some of my signatures don't survive. The
second
problem is that it doesn't disadvantage late adopters. If I'm the last
sender
on the planet to change, does that hurt me? No.
I would actually argue the converse. As a sender why would I want to
accept accountability for whatever changes any intermediary makes to my
message from now until some theoretical later date when every
intermediary who alters my content can be convinced to start signing
mail themselves.
I like the idea William suggested of giving the original Sender the
opportunity to decide whether they want the signature to survive changes
like the ones made by mailing lists. This is especially important if the
signature indicates authorization. While some domains may be willing to
extend their authorization to mailing lists that their users may send
to, other domains will only want to authorize a message if the content
was last touched by someone with whom they have a contractual
relationship of some type.
What that means is that everyone wants to be the last to change, ergo,
no
one
changes and you entrench a hack forever. As a follow-on, it removed
the
incentive for MLMs to change too.
The days are long gone (if they even ever existed) when the internet
changes
due to wishful thinking, a BCP or even codification via an RFC.
Adopters
are
pragmatic, resource starved and self-serving. A standard that implies
a
transition plan need to reflect that reality if it wants any hope of
success.
Just to give one of many examples, wasn't the "MX fallback to A
records"
meant
to be a transition mechanism that was to "slowly disappear" starting
with
RFC974 in 1986? Finally in 2001, that presumption appears to be given
up
as a
lost cause in RFC2821.
Mark.