On 11/07/2005 14:09, Douglas Otis wrote: > On Nov 7, 2005, at 4:27 AM, Scott Kitterman wrote: > > On 11/06/2005 17:35, Douglas Otis wrote: > >> On Nov 5, 2005, at 9:16 PM, Dave Crocker wrote: > >>> However, the best way to gauge this probably is for you to specify > >>> the text that you propose to have changed in the charter. > >> > >> While there appears to be some support for imposing a requirement > >> that From header always be associated with the transmitting domain, > >> there is a lack of appreciation that an open-ended authorization > >> becomes the target of abuse. ... > > > > If you change lack of appreciation to lack of agreeing with you > > that this is > > the end of the world, I suppose that's not to far off. > > Attributing the signing-policy as referenced from the From domain is > but one approach. It has an unfortunate side-effect. There are > unfair reputation schemes that will use any authorization to accrue > reputation based upon the email-domain rather than the signing-domain > as desired and fair. The effect of this misapplication of reputation > makes allowing third-party signers highly problematic. Of course not > allowing third-party signers would cause message losses with respect > to many services, such as list-servers. The eventual remedy would be > to introduce double From email-addresses, where the author is now > once again unverified, and will perhaps create a great deal of > confusion and change to the MUAs and list-services attempting to deal > with multiple From addresses. While it would not be the end of the > world, it would be a mess and will create an unfair shifting of > accountability. > > >> There is an alternative to that approach. This alternative should > >> provide far greater abatement of abuse with a charter as follows: > > > > snipped for brevity > > > > I think this would be a really bad idea. I like the current draft > > charter a > > lot better. > > A better review of how this opportunistic scheme could be implemented > should offer several pragmatic justifications, as well as avoiding > problematic open-ended policies (allowing third-party signatures.) > In the end, the prevention of spoofs for critical domains would > actually be more comprehensive and meaningful. > I disagree that what you are proposing would work better for critical domains.
More importantly, at the moment, the work you propose could easily be added on later. There is no need to execute a last second re-direction of the charter to do what you want. It can be done later if it, in fact, needs to be done. In the, IMO unlikely, event that your approach is deployed and more successful than SSP, I'd expect people would quit publishing SSPs and the SSP draft could be relegated to historic. Since you haven't garnered a lot of support, I'd suggest you leave this for round 2. Scott K _______________________________________________ ietf-dkim mailing list http://dkim.org
