On Dec 4, 2004, at 10:27 AM, Dave Crocker wrote:
Jim,
There is no requirement that the recipient display the unsigned
content
at the end of a message. A verifying MTA may remove the unsigned
content at its discretion.
By having a mass signature apply only to an initial subset of the
message content, we are now faced with a cascading sequence of
possible mechanisms that cause problems or try to get around problems.
When we find ourselves starting to discuss whether some text is, or
is not, displayed to the user, as a means of enforcing a security
model, we really do need to step back and look for a simpler approach.
I don't know how to build a signature mechanism that self-destructs
when it goes through a mailing list, unless we do something based on
SPF or BATV or SES.
If it's possible to build a signature that self-destructs when it goes
through a mailing list or is remail-'d by a human, tell us about it.
If it's not possible to build a signature that self-destructs, I don't
know how you propose skipping a discussion of what's supposed to happen
when multiple signatures occur in a message and 'something' needs to
interpret the meaning of those multiple signatures. That 'something'
could be the MUA, the MASS-aware MTA that's adding SpamAssassin-like
headers to the message, a human, or other machanism.
It is bad enough that we are forced to compensate for possible format
changes along a path. Having to compensate for basic semantics
changes, such as the addition of blocks of text is far beyond the
limit of simplicity that a mechanism like this should define.
If you want the signature to not survive having text added ("to
unsubscribe, email me"), that's one requirement. If you want the
signature to not survive a mailing list, that's an additional
requirement. You're combining the two in your argument against the
current DK/IIM approach; I'm not sure why you're combining them.
Are you wanting an SPF/BATV/SES-like approach for MASS's signature?
We should make the goal of mass to be validation by a receive-side
filter. Any dependency or expectation of displays to the user --
nevermind concern for having the user somehow decide whether the
message is valid or not -- should be entirely beyond the scope of this
effort.
Umkay.
> Requiring those that make changes to resign the message does
ensure
> this process identifies those accountable. A header could be
included
> to allow signature validation to be cascaded.
I agree that it's desirable for those that make changes to re-sign
the
message. But I think it's undesirable to say that signatures will
just
fail for a large proportion of mailing lists unless that happens.
Why?
Signatures will initially "fail" for nearly all messages, since they
won't be signed. Why should we single out one class of message
posters and try to circumvent their responsibility?
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.
Then there's the other question you touch on, of whether a
signature is
added or the original signature is replaced. I'm in the "added"
camp
even though that means we have to define how messages are treated
when
different signatures succeed and fail.
Again we are faced with the question of value for the added complexity
at the receive side.
We have no history of obtaining successful, widescale use of any
signing mechanism for email. That should motivate us to make our
current work as simple as possible.
Multiple signatures and rules for interpreting them, guidance for what
to display to recipients, and any other sort of attempt at heuristic
robustness works against the goal of simplicity. It also obfuscates
the basic semantics of the signature, since it confuses who is
responsible.
-d
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com