early SPF in pre-queue check, or later with pypolicyd-spf ?

First, don't use Mail::Query::SPF. It's obsolete, unsupported and suffers from bugs. If you're going to use a Perl based solution, use Mail::SPF (SpamAssassin supports both).

Pre-queue filtering has advantages and disadvantages:

http://www.postfix.org/SMTPD_PROXY_README.html#pros_cons

With a policy server, like pypolicyd-spf, you can use the Postfix policy interface to reject mail during the SMTP session without having to accept the cons of pre-queue filtering. Additionally, pypolicyd-spf will write SPF-Received: headers in the message which a post-queue spamassassin will use for it's mail filtering rules.

If you have sufficient resources it pre-queue filtering may be the way to go, for most it's too risky.

hi

> don't use Mail::Query::SPF. It's obsolete, unsupported and suffers from bugs.
> If you're going to use a Perl based solution, use Mail::SPF (SpamAssassin supports both).

ok, confused now. there's also apparently Mail::SPF::Query.

checking,

module_info Mail::SPF
 Name: Mail::SPF
 Version: v2.007
 Directory: /usr/lib/perl5/vendor_perl/5.12.3
 File: /usr/lib/perl5/vendor_perl/5.12.3/Mail/SPF.pm
 Core module: no

 module_info Mail::SPF::Query
  Can't create Module::Info object for module 'Mail::SPF::Query' at /usr/bin/module_info line 96.
 module_info Mail::Query
  Can't create Module::Info object for module 'Mail::Query' at /usr/bin/module_info line 96.
 module_info Mail::Query::SPF
  Can't create Module::Info object for module 'Mail::Query::SPF' at /usr/bin/module_info line 96.

completely unknowingly, I've got the one you suggest. Thanks for the mention, in any case.

> Pre-queue filtering has advantages and disadvantages:
> http://www.postfix.org/SMTPD_PROXY_README.html#pros_cons
> With a policy server, like pypolicyd-spf, you can use the Postfix policy interface to reject mail during the SMTP
> session without having to accept the cons of pre-queue filtering.

sure, aware of that. and quite clear in a completely either-or scenario. in this mixed-case of "going to be running SA pre-queue *anyway* ...", just the question of "which SPF-checker" lingers for me.

> Additionally, pypolicyd-spf will write SPF-Received: headers in the message which a post-queue
> spamassassin will use for it's mail filtering rules.

as would/could a pre-queue instance of SA, right? meaning, it (Mail::SPF-based SPF checks) could also be configured to do some lightweight checks pre-queue, score ~ 0 but write those same headers, and pass on to heavier, additional checks & scoring at a post-queue SA instance. yes?

> If you have sufficient resources it pre-queue filtering may be the way to go, for most it's too risky.

yep. getting a quantitative handle on "sufficient" and "risky" is the challenge. time/experience will tell, but would *like* to make some knowledgeable choices in the design/deploy stage. my goal is to get as much blocked/dropped/reject as early as possible, balanced against not having my system drop to its knees when someone send me "3 emails" ...

thanks for the comments.

DChil