On Mon, 2005-10-17 at 22:38 -0500, Earl Hood wrote:
On October 17, 2005 at 16:22, Jim Fenton wrote:
50% of the ones if counted based on actual use by people. Actually
the situation is such that those for who its not visible header field,
can very often change it to make it visible through some additional
seetting and at the same time they are also the ones that are a lot
less likely to be fooled by forgery in the first place...
The people we're trying to help are the ones who won't can't do that
additional setting to make Sender visible. And I'm not satisfied with
helping 50% of the clients.
This seems to be a bad policy to follow. Just because some MUAs
render fields a certain way should not be a basis for how a standard
should be designed.
I agree. The reasons for dropping the effort to rigidly bind signatures
to a header is also the same reason SSP as defined is a bad idea. It
would be expensive to support. Delegating to third-party domains is
also highly problematic. It also means when declaring that all emails
are signed with SSP, this will not protect those messages where other
headers are legitimately significant for the signer, but which do not
include the From/Sender. It also means that with the SSP scheme, a
portion of a signers messages may be deleted because of conflicting
policies that may have been set by other domains. This too will likely
create expensive support issues.
It seems two different rule sets are needed. If you want to stop
spoofing for exigent cases, then a policy statement could prohibit all
parameters and headers that may indicate the originator of the message.
When attempting to declare that all messages from your domain are
signed, then the normal header significance per RFC2822 should determine
which domain policy should apply. Otherwise, a portion of valid
messages from a domain can not be protected by a policy assertion and
are then subject to the policies of other domains.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org