On Thu, Dec 04, 2003 at 12:47:08PM -0800, Justin Mason wrote:
|
| I agree, FWIW. The current spec is quite complex, with places
| where recursing lookups are required (include, exec, mx, ptr etc.).
|
| On top of the complexity of implementing a client to implement lookups per
| the spec, there's also the danger that an unforeseen combination of rules
| in an SPF record will result in timeouts or other issues that can cause
| runtime problems in an implementing MTA or scanner. So the complexity of
| the spec will lead to complexity of code.
The goal of the SPF project is to achieve fast widespread adoption.
I believe that minimizing the total amount of time spent by humans on
implementing SPF is the best way to reach that goal.
There are two constituencies which will spend time on SPF: readers (SPF
clients) and writers (SPF publishers).
The reader constituency spends time
- building SPF client libraries (thanks David, Mark, Stuart and others
for the MTA plugins), and
- installing those libraries. This time is more or less
implementation-independent, so this subgroup factors out.
The writer constituency spends time
- figuring out SPF
- putting the correct SPF entries into DNS
So far we've been using the term "complexity" rather loosely.
Complexity can be divided between readers and writers in a number of
ways. What's complex for one is simple for the other.
Most of the people on this mailing list instinctively identify with the
reader constituency. I am not surprised that readers see the additional
mechanisms as complex and undesirable. The additional mechanisms do
make the reader's job harder.
But the prospective SPF publishers on this list have pointed out that
the added mechanisms actually simplify things for them. Having to use
an IP-only scheme can become a maintenance nightmare and open the door
to scenarios like "oops, I changed the IP address of the mailserver and
then I forgot to update the SPF records until an hour later, so
thousands of users bounced mail."
There are a great many more writers than readers. If the spec has "a,
mx, ptr", an SPF client author may spend ten hours implementing them,
but save SPF publishers a thousand hours. If the spec has only "ip4,
ip6", an SPF client author may save those ten hours, but at the cost of
thousands of publisher hours. What good is an application that was easy
to write if nobody uses it?
I should point out that in this thread alone we've collectively written
over 1500 lines of debate.
By comparison, Mail::SPF::Query, which fully implements the spec, has
500 lines of code.
| It strikes me that a record-generating app, which takes the complex
| concepts of "mx", "ptr" etc. and generates simple records, would reduce
| this danger.
I will put something that does this on the website.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡