On Thu, 2004-11-11 at 13:24 -0500, csm(_at_)redhat(_dot_)com wrote:
I don't want to come across as overly critical or even negative here but
I really have to say this... as we look at possible architectures can we
please, PLEASE not turn the phone book into a lead weight... it's
already big enough and it does it's job pretty well... making it a
parsing engine as well seems to me to be the wrong approach. Can we just
ask it to print our new entries and nothing more? :-)
NB. This would also serve to minimize the impact on existing
infrastructure which is most definitely "a good thing" <tm>.
I'd like to nominate this chap for the new SPF council. He's absolutely
brilliant. Someone please second this nomination.
Cheers,
James
--
James Couzens,
Programmer
( ( (
((__)) __\|/__ __|-|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
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=0x7A7C7DCF
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part