Let me rephrase that At my shop I see dkim everyday that uses all of the features provided. As a verifyer I dont use all of those features in my ruleset at present. These tags are being used rightly or wrongly in the wild by signers. Also note that spammers tend to properly use dkim as opposed to small email providers. Bill Oxley ________________________________________ From: Eliot Lear [[email protected]] Sent: Saturday, June 13, 2009 8:51 AM To: [email protected] Cc: Oxley, Bill (CCI-Atlanta); [email protected] Subject: Re: [ietf-dkim] Why bother removing features?
And beyond what Dave said, if a feature is unused you can't take it to draft. Eliot On 6/13/09 1:51 PM, Dave CROCKER wrote: > > [email protected] wrote: > >> Okay, I would like to keep what we have, removing pieces is not a good idea, >> people don't have to use the tags if they don't want to and we MAY have a >> need for them in the future. >> > > There is an infinite array of features that we may have need for in the > future. > So that's not an encouraging line of argument for retaining any particular > feature. > > Features carry costs. > > Perhaps you missed my earlier note, which touches on the significant costs of > retaining unused features: > > > >> Date: Thu, 11 Jun 2009 12:29:56 +0200 >> From: Dave CROCKER<[email protected]> >> To: DKIM IETF WG<[email protected]> >> Subject: [ietf-dkim] Why bother removing features? >> >> > ... > >> The problem with retaining unused features is that it makes it more >> difficult to >> explain DKIM use, it adds to the cost of developing DKIM support, and it >> invites >> interoperability problems later. >> >> >> 1. Explaining things >> >> Since we are still seeking adoption by more email services, we still have a >> significant education task to perform. This is both about the nature of DKIM >> and the particulars of using it. And it is both for developers and for >> operators. The latter especially need not just the value proposition but the >> operational impact, which means discussion of usage scenarios. >> >> The more features in a protocol, the more difficult it is to explain how >> things >> work, due to combinatorial interactions. Phrases like "use it however you >> want" >> do not help because operations folk need to be told the answer, not assigned >> the >> task of developing one. >> >> At its core, DKIM is really rather simple: Give the receiver a validated >> identifier that asserts a degree of responsibility for a message. The >> validation is accomplished by signing the message body and some of the header >> fields. The public key is in the DNS. Done. >> >> With its full set of additional features, DKIM's nature becomes potentially >> confusing and its operational use even more so. >> >> >> 2. Unused feature are costly >> >> Actually, of course, /all/ features are costly. There is no such thing as an >> additional feature that is entirely free. Each feature requires coding, >> testing >> (internally and with other implementations), documenting and (potentially) >> operations and support. Unused features have the distinctive characteristic >> of >> developing no serious operational experience, so that the basis for >> documenting >> use is poor. This leads to the next concern... >> >> >> 3. Unused features invite interoperability problems long after initial >> adoption >> >> Unused feature are like time-bombs. No matter how diligent developers are, >> the >> usual interoperability shake-out for protocol code won't happen, because >> some of >> this requires real-world use. So when (if) use finally starts happening, >> there >> is certain to be a round of interoperability problems. Having this occur >> long >> after DKIM is adopted winds up making DKIM look unstable/unreliable. Just >> the >> sort of thing one does not want ever, but especially for a security feature >> primarily targeted at email operations. >> >> So, tight specifications that have only the core features, known to be >> needed, >> benefit from being easier to explain, cheaper to deploy and operate and >> safer in >> the long-run. >> > > > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
