On Mon, 2004-11-29 at 16:25, Michael Thomas wrote:
Dave Crocker writes:
> > Presuming you're referring to features like canonicalization, body
> > length count, and header copying,
> However canonicalization is merely related to minor syntax changes. The
> other two are trying to protect against some types of semantic changes
> not others.)
I'll bite: what's the bright line distinction?
The distinction Dave Crocker seems to be making is using the signature
validation to directly act as sender authorization. In this view, a
list server that alters the beginning of the subject line or appends an
unsubscribe comment at the bottom of the message must offer, as the
sender, their own signature. With this view, signature validation
itself acts as an immediate form of sender authorization.
Only when the list server is itself checking the validity of the
signatures, prior to their modification, would there be any potential
for an assurance that the original sender was not spoofed. A financial
institution of course will not care if their message's signature
survives going through a list server. It would seem that a means of
conveying that the list server did verify the initial signature and
included this verification within the message's resigning would provide
a form of assurance by proxy. Perhaps adding a header that specifically
clarifies this event encompassed within the message's new signature
would offer an alternative measure.
This does move the signature protection away from the understanding of
the typical user. They would expect the From header to be the
significant header of concern. So this distinction seems to be based
upon what is important. Dave has stated that an intelligent process
must act on behalf of the user as a means of protection, especially when
these headers are not normally visible. The alternative is to bolster
the confidence in what is seen by the user. This is made difficult when
a predominate vendor's MUAs replace the content of the From with just
the pretty name. : (
From a reputation perspective, direct sender authorization makes sense
with a view of delegating responsibility onto those that actually
control access to the mail channel. From a user's perspective, that
wishes to rely upon the From header, and that has long paid attention to
the mailbox and not the pretty name, I can understand the angst.
Protecting a signature generated from the perspective of the From header
does create additional challenges as addressed within IIM.
So this seems to be where there is a fork in the road. The MASS group
must decide which path to follow. The From or the Sender...