Fri, 10 Apr 2026 11:23:03 +0000 https://bugs.horde.org/ticket/4904 A Postfix policy daemon to manage white/blacklisting Postfix can consult an external policy daemon to decide whether to white/blacklist email. A daemon which could answer Postfix with an OK or REJECT based on a users black or white lists in ingo would be a very useful addition to horde. It would allow email to be rejected before it is accepted from a remote smtp server (if you accept email you really should deliver). Or alternatively mail could be accept from a source even if it is listed in for example an rbl (false positives do happen). More information on Postfix policy daemons can be found here: http://www.postfix.org/SMTPD_POLICY_README.html Tue, 16 Jan 2007 17:04:09 +0000 https://bugs.horde.org/ticket/4904#t28535 In my opinion a daemon is a bit outside the scope of a web application. I could certainly see interoperating with one, or having one as an affiliated project, but then you need to decide what backend this is for, too. For instance, I doubt it'd make sense to do this with sieve, since sieve should be tied into the MDA anyway. Same, perhaps, for spamassassin. That leaves procmail, maildrop, and imap... I'm just not sure where it fits. Tue, 16 Jan 2007 19:42:20 +0000 https://bugs.horde.org/ticket/4904#t28558 I understand your reservations. My main reasoning behind this is to avoid accepting email you are not going to deliver, call me a zealot but I think this is bad. The daemon should be fairly simple to write, could probably be writen to run from php on the command line and should share a bit of code with Ingo. Reading directly from the horde_prefs table seems to make the most sense. I worry that anything outside of the Horde project would not necessarily be well maintained and would have to duplicate code to de-serialize Horde's preferences. The next best alternative to this I can see is it being posible for Ingo to write it's black/whitelist out to a external database table without serialization. This could be good in that other external apps might be able to refer to this table for the information they require. I'm willing to put a bounty of $100 on either of these two solutions (not both :o) Wed, 17 Jan 2007 09:47:16 +0000 https://bugs.horde.org/ticket/4904#t28591 > The next best alternative to this I can see is it being posible for > Ingo to write it's black/whitelist out to a external database table > without serialization. This could be good in that other external apps > might be able to refer to this table for the information they require. This is already possible with the HEAD code. Wed, 17 Jan 2007 10:17:29 +0000 https://bugs.horde.org/ticket/4904#t28594 >> The next best alternative to this I can see is it being posible for >> Ingo to write it's black/whitelist out to a external database table >> without serialization. This could be good in that other external apps >> might be able to refer to this table for the information they require. > > This is already possible with the HEAD code. ok, I may look into hacking something up for personal use with this. Folder rules would need (at least for me) to remain backended into maildrop, I'm not sure if this is an issue (with the code in head). The bounty remains $100 for a suitable postfix policy daemon. I'd rather it were at least within ingo/scripts, but will be happy to discuss other avenues. Wed, 17 Jan 2007 11:29:20 +0000 https://bugs.horde.org/ticket/4904#t28601 I decided to take a look at this as I might be able to use it myself. Please give this a look, and if that bounty is still good, I'll be happy to look at any tweaks, etc. Note that if your Horde users are different from "username", where their recipient email address is username@domain, there is a hook that will be called to determine the Horde user to look at whitelist/blacklist rules for: _ingo_hook_smtpd_access_policy_username. This hook should be defined in ingo/config/hooks.php, in a file otherwise just like horde/config/hooks.php. Sun, 12 Aug 2007 18:19:38 +0000 https://bugs.horde.org/ticket/4904#t35913 I forgot to specify that this file does indeed live in ingo/scripts. I took a shot at the usage instructions in the file header, but I didn't have a chance to test it yet, so if you do try it and have any tweaks to them, please let me know. Sun, 12 Aug 2007 18:21:21 +0000 https://bugs.horde.org/ticket/4904#t35916 I can't find the script in current cvs head ingo/scripts. I've solved the problem another way. Using amavis pre-queue and allowing sam to control black/whitelisting. I still feel this is a useful thing for horde to be able to do and will assist in testing. The bounty is good, email me directly and I will make payment. Mon, 13 Aug 2007 08:33:05 +0000 https://bugs.horde.org/ticket/4904#t35945 > I can't find the script in current cvs head ingo/scripts. I attached it to this ticket for testing/feedback before committing it. It doesn't require any changes to HEAD ingo. > I've solved the problem another way. Using amavis pre-queue and > allowing sam to control black/whitelisting. I still feel this is a > useful thing for horde to be able to do and will assist in testing. Cool, thanks. Mon, 13 Aug 2007 14:19:42 +0000 https://bugs.horde.org/ticket/4904#t35954 works as described. Needed a bit of tweaking to run on my system: here: > * policy unix - n n - - spawn > * user=nobody argv=/path/to/horde/ingo/scripts/ingo-postfix-policyd user=apache was required to get read access to horde configs > $pos = strpos($user, '@'); > if ($pos !== false) { > $user = substr($user, 0, $pos); > } this probably needs to be configurable (command line arg?), username for us is same as email address. Tue, 14 Aug 2007 09:43:59 +0000 https://bugs.horde.org/ticket/4904#t35968 Thanks for the feedback! I've committed the script now to HEAD, and it'll be in the next Ingo 1.2 release (probably RC1, but possibly ALPHA-2). I changed the default username from nobody to www-data, and added a note about that user needing to be able to access Horde configs, logfiles, etc. As to the email address/user problem, I went with bare username by default because, well, it matched my system. But I know this is going to vary for people, which is why I included the hook. If most people's systems use the full email address, I'm happy to make that the default. Thanks again. Tue, 14 Aug 2007 18:59:21 +0000 https://bugs.horde.org/ticket/4904#t35971