On Thu, 2004-12-09 at 11:50, wayne wrote:
In <16824(_dot_)40492(_dot_)723484(_dot_)512812(_at_)mtcc(_dot_)com> Michael
Thomas <mike(_at_)mtcc(_dot_)com> writes:
So it seems that a lot of people are taking it as axiomatic
that a Sender: signature provides some utility.
Personally, I see very little utility in protecting the Sender:
header, and far far less in protecting the Resent-* headers. I see a
lot of utility in protecting the From: header, the envelope from
(2821.MAILFROM), and the HELO domain.
How does this get deployed? The From is a function of the Originator
and can be a domain independent of the Submitter domain.
The highly deployable signature schemes being considered add a private
function to the Submitter. Although the Submitter sets the MAILFROM and
HELO, there is value in allowing the HELO be independent of the
mailbox-domain indicated in Sender (also set by the Submitter).
Binding signature information to the From when different from that of
the Sender offers deployment issues. This binding happens automatically
when the From is within the Sender domain. Allowing the From and Sender
to differ where the signature is obtained independently from that of the
Submitter domain offers deployment issues as that implies some type of
agreement between the Submitter and a potentially vast range of From
domains. How are the private keys handled for this case?
Reliable assertions as to the entity granting access offers several
advantages with respect to accountability. There are already existing
schemes that attempt to validate the Originator, but again these have
deployment issues.
-Doug