On Sat, 13 Oct 2007, Tony Earnshaw wrote:
> Tobias J. Kreidl skrev, on 13-10-2007 09:31: > >> I'm wondering about the view of having policyd deal with initial >> conenctions up-front, so that things get rejected before they've even had >> much processing via postfix. My question is, how does the efficiency of >> policyd compare with the efficiency of postfix internals? Does >> postfix do a "better" job of rejecting than policyd? As one experiment, I >> have created a configuration with policyd way up front: >> >> etc. etc. ... > > To my mind it should come last in smtpd_recipient_restrictions. What's > the point of greylisting stuff that Postfix would reject anyway? > > -Tonni > > -- > Tony Earnshaw > Email: tonni at hetnet dot nl > In this case, I'm not really wanting to do any greylisting at all, as at our institution, we want to receive evrything legitimate and would rather post-process the email, if needed, than cut it off. Many of our users are subscribed to various listservs, mailing lists, and who knows what all else out there, and we've run into problems in the past by trying to be overly selective. As to preventing as much "know" spam as possible, that's in part the job of RBLs and spamhaus handle. Really, at this point, we see policyd as primary playing a multiple server role for what "anvil" does already in postfix. However, the great thing here is the ability to share the information among all the participating mail gateway machines instead of having each one track this sort of thing alone (anvils's big limitation). I know others have more specific constraints, such as limiting the number of messages per recipient, the total volume of email, etc., but that's not the case here. Also, why accept mail that's being used to mailbomb a user who is real and normally would accept any "reasonable" email from the outside world, if they didn't know better? Policyd can catch these before posftfix takes on the message and figures out how to process it completely. I guess it's partly also a question in our case of trapping email before we decide to process it via amavisd; why burdon amavisd, if the message is going to be rejected anyway? (Yes, you could argue that applying the other smtpd_recipient_restrictions first could deal with this, as well.) I'm still curious about the actual efficiency of what some of these overlapping services are in policyd vs. postfix. The crux of the discussion in my mind is which utility is more efficient at specific jobs? BTW, thanks a lot, Cami, for putting policyd together. We're handling about 200k messages a day through policyd and with using it pretty strictly right now as a rate-limiter, the DB is only a little over 1 MB! We may expand the role of policyd in which cas it will, of course grow quite a bit. Depending on various factors, we may choose to use a diffetn DB instance in that case and leave the current one as is, since it's working so efficiently. The overhead on the mail gateways as well s the MySQL server is almost unnoticed. I did have one quick question; instead of a stop/start to re-read the policyd.conf settings, it'd be useful to be able to "kill -HUP" the daemon, instead. Any chance of building that in at some point? I know it stos and starts up quickly, but why not make it "HUPable," unless there's a specific reason not to? --Tobias ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ policyd-users mailing list policyd-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/policyd-users
