The beauty of SPF is its simplicity. I use spamassassin, pyzor2, dcc,
spf, and more as part of my whole spam filtering process. The SPF
install guide mentions something about taking probably "an hour or two"
to get up and running. Forget about that once you add an XML package
thats bigger than the whole rest of the mailserver just for one feature.
SPF is great at identifying mail to reject before even wasting time
accepting the whole message. XML and whatever else are free to check in
more detail down the road after the mail has been accepted. The
SPF-Received information may very well help the other checks, but why
should SPF be over-complicated just to placate a company that can't
follow an internet standard to save their life?
On Sun, 2004-05-30 at 11:02, George Mitchell wrote:
Before we waste any more time on XML, could we take a quick poll on
whether we want to use it at all? I request all of the members of this
list respond (once) to the list in this thread, stating simply whether
you believe the SPF specification should include the use of XML. I'll
start off:
I am opposed to the use of XML in conjunction with SPF.
-- George Mitchell
-------
Sender Policy Framework: http://spf.pobox.com/
The Inbox Event at the Marriott San Jose features SPF.
June 2: Email Accountability Symposium (free)
June 3: SPF Strategy BOF (free) where industry will coordinate deployment
timeline
Times: 6:30pm - 8pm, both sessions. http://www.inboxevent.com/
Archives at http://archives.listbox.com/spf-discuss/current/
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
--
Scott Taylor - <security(_at_)303underground(_dot_)com>
Arnold's Laws of Documentation:
(1) If it should exist, it doesn't.
(2) If it does exist, it's out of date.
(3) Only documentation for useless programs transcends the
first two laws.