On Jun 28, 2004, at 2:32 PM, David Lawless wrote:
I'm giving up on SPF for a few months. All of the SPF
implementations are buggy and extremely difficult to implement.
No SA on this earth has two days to screw around downloading one
Perl module after another only to discover yet another
undocumented dependency.
Using CPAN, I got all the perl modules swiftly. What took me the
longest time was modifying my mail start-up script (I've put sendmail,
mimedefang, clamav, and now spf-milter all in one startup script which
I am coming to regret). I guess since I already had one milter in
place (so didn't need to recompile sendmail) and I had a user for
running milters under (so didn't have to create a new user), and since
I am comfortable with using CPAN.pm for installing modules, I think I
got mine up and running in under an hour. (Sadly, I still haven't
documented the set-up yet.)
But if you are having the problems you describe, then maybe you are
right to give it a rest for a while.
I finally got the Milter working with a 'fallback' record only
to discover that you can't whitelist senders using the
'access.db', and that no other simple whitelisting capability
exists.
Whitelisting does exist at least for the recommended sendmail set-up.
In a default set up, the file /var/spf-milter/whitelist can be created
that includes a list of CIDR specified nets. This is described in the
INSTALL file for the milter. But perhaps you are trying to achieve
something else.
I do agree that I would like more flexible whitelisting. I would
prefer the milter to reject after RCPT TO so that I could whitelist
recipients such as postmaster and abuse. But I don't care enough about
this to learn enough about writing milters to do it myself.
Alternatively, I'm confident that it would be easy to code SPF queries
into MIMEDefang, but I'd prefer to reject before DATA (and MIMEDefang,
by its very nature works on the data).
--
Jeffrey Goldberg http://www.goldmark.org/jeff/