On Wed, 2004-03-31 at 14:51, Meng Weng Wong wrote:
On Wed, Mar 31, 2004 at 03:55:58PM -0600, Gordon Fecyk wrote:
| > Pretty much the entire thing needs to be implemented; there's just one
| > level of conformance as far as parsing/interpretation go. What the
| > receiver chooses to do with the result is up to him, of
| > course, but the way the result is obtained is unequivocal.
|
| The lookups are one thing, parsing the results is the problem. You're
asking
| the receipient to enforce a complex set of rules that can vary from sender
to
| sender. No wonder the IETF fogies have their skivvies in a knot. "Where's
| the debugger?" was the question asked at the 59th IETF, and I don't think
| there's an answer yet.
|
| The minimum you've defined is too much at once, leaving too much room for
| implementation mistakes and incorrect assumptions. What might help, if the
| minimum can't be changed, is a skeleton source code implementation that
| leaves platform-specific things undefined while keeping the highest level
| calls consistent. "SPF for Dummies" in source code, if you will.
Does anyone have a count of the number of lines of perl, python, c, etc
for libspf and libspf-alt?
I've observed that the people only complain about writing a parser
before they've written it; after they write it they say "well, that
wasn't so bad."
libspf is ~3800 lines less debugging and license headers and includes
its own native DNS query functions.
I think Gordon needs to just sit down and write and he'll see it for
himself. I remember the first time I saw the SPF RFC I was bitching
two, particularly at the macros, yet here I am, and I must say, well,
that wasn't so bad.
Cheers,
James
--
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855