On Tue, Jan 27, 2004 at 08:40:42PM -0600, wayne wrote:
| There are probably at least a factor of 100 more domains that have
| published SPF records than MTAs that are checking SPF records.
| Maintaining backwards compatibility with SPF records is far more
| important.
I'm publishing SPF records for some domains now, and will add more soon.
I do not have MTA checking SPF yet for a few reasons. Right now I am
using Postfix. I also do not like having to "cobble things together"
to run a server, which means I want at worst a clean patch to Postfix
to handle SPF right in the same process. I'd rather it be integrated
into the Postfix source, but Wietse and most of the big players in the
Postfix community seem to be opposed to it. I am presently considering
other options because I suspect I will have poor support if I use some
SPF checking.
I have been considering writing my own daemon for incoming mail. It
is an outgrowth of an earlier plan to write an LMTP delivery daemon to
handle some things in simple ways that would have required a massive
sized DB map in Postfix.
I don't know whether I want to put any real effort into Postfix at this
time. I'm not going back to sendmail or qmail (been there, done that,
carrying the scars). Exim might be a possibility, but I don't know if
I want to put the effort into it if I'm going to end up doing my own.
And besides, I'd rather keep Postfix around for the outgoing part of
things, anyway.
| Secondly, I would guess that almost all of the MTAs that are checking
| SPF records are using buggy code and will need to upgrade sometime in
| the realitvely near future anyway.
Getting a quality libspf out, with a clear API that virtually any MTA
can use (e.g. the patch into the MTA to make it call libspf should be
a relatively simple affair and have few bugs), should relieve that
problem in time.
| I would expect some more tweaks to the SPF spec before it is finalized
| for spf1. I would be shocked if any changes invalidated SPF more than
| a handful of records. For example, there might be stricter limits
| placed on the number of DNS lookups an SPF record can have, in order
| to prevent DoS attacks and such. The wording of the Recevied-SPF:
| mail header will probably be tightened up. I could see adding an
| *optional* modifier for people to specify an email policy that goes
| beyond checking of the envelope-from header if a spec for such a
| policy could be drawn up. (Such a email policy modifier MUST NOT
| change the semantics of the rest of the SPF spec, but SPF records make
| a convient place to let people know about the existance of such a
| policy.)
|
| I think the window for even minor tweaks and changes to the spf1 spec
| is closing rapidly. If there are serious bugs or problems with it,
| you best speak now or forever hold your peace.
At least until version 2 work begins.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
-------
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.4.txt
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡