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
