Re: [spfbis] SPF and EAI

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Jul 12, 2012 at 9:10 PM, Scott Kitterman <[e-mail]> wrote:

> The charter says "removal of unused features".  This is different than
> type SPF
> because type SPF was redundant, this is not.
>

I think the issue of redundancy is inapposite.  It's an unused feature,
pure and simple.  The statistics show far less less than 1% use.

Why do we need to keep something as complicated as macro expansion when
almost nobody is using it?

Perhaps more importantly: Why was it okay for us to decide Sender ID is de
facto obsolete, while even stronger evidence (by orders of magnitude)
against macros must be disregarded?  If it would help, I could add up the
number of lines in sid-milter that added Sender ID support for comparison.
It, too, was relatively small.

I don't think it's in our charter to break existing, published SPF record
> without a compelling case.  I don't think rarely used is at all
> compelling.  I
> don't think simplification is at all compelling either.
>

Purely from a procedural standpoint, I disagree.  SPF is currently
Experimental, and moving to Proposed Standard is an ideal time to chop out
things that fewer than two tenths of one percent of the deployed base is
using.  That comprises part of what we learned from the experiment.  I
don't agree that we are mandated to cater to such a tiny number of sites.

The remaining question is whether the working group believes use by 200 out
of 150,000 warrants keeping the feature.  To use your own argument, if in
5-7 years we've seen only this much use of SPF macros, I'm doubtful it's
going to increase.

But, to be fair, we don't have a hard-and-fast definition of "unused" when
going through this exercise, so it's left to consensus. Others will have to
weigh in.

We do have precedent, however, as a guide.  For example, when DKIM went to
Draft Standard, we chopped a few things (most notably "g=") because they
had seen almost zero adoption.  According to the RFC4871 interoperability
report, after 8.1M signed messages were processed, only 434 of keys were
found that had "g=" tags in them.  So the use wasn't zero, and someone
apparently found them potentially useful, but the decision was made that
there was not enough adoption to warrant keeping the complexity in the
specification.

However, we didn't remove "l=", much as we wanted to, because its use was
around 3.7%.  Same with "x=" (3.4%) and "z=" (5.9%).  Use of SPF macros
falls somewhere in between those and "g=".

There are other examples of this tactic going back as far as RFC821 (SAML
and SOML).

You argued that the complexity isn't that big based on lines of code.  It
wasn't for "g=" either.  I removed 162 lines of code that time from
OpenDKIM, and we removed a small section of the RFC.

As is often quoted around these parts: "“Perfection is achieved not when
there is nothing left to add, but when there is nothing left to take away."

-MSK