6.0.0-beta1
7/10/25

[#4904] A Postfix policy daemon to manage white/blacklisting
Summary A Postfix policy daemon to manage white/blacklisting
Queue Ingo
Queue Version HEAD
Type Enhancement
State Resolved
Priority 1. Low
Owners chuck (at) horde (dot) org
Requester robb (at) wtg (dot) cw (dot) com
Created 01/16/2007 (6750 days ago)
Due
Updated 08/14/2007 (6540 days ago)
Assigned
Resolved 08/14/2007 (6540 days ago)
Milestone
Patch No

History
08/14/2007 06:59:21 PM Chuck Hagenbuch Comment #11
Assigned to Chuck Hagenbuch
State ⇒ Resolved
Reply to this comment
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.
08/14/2007 09:43:59 AM robb (at) wtg (dot) cw (dot) com Comment #10 Reply to this comment
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.


08/13/2007 02:19:42 PM Chuck Hagenbuch Comment #9 Reply to this comment
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.
08/13/2007 08:33:05 AM robb (at) wtg (dot) cw (dot) com Comment #8 Reply to this comment
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.
08/12/2007 06:21:21 PM Chuck Hagenbuch Comment #7 Reply to this comment
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.
08/12/2007 06:19:38 PM Chuck Hagenbuch Comment #6
New Attachment: ingo-postfix-policyd Download
Reply to this comment
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.
01/17/2007 11:29:20 AM robb (at) wtg (dot) cw (dot) com Comment #5 Reply to this comment
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.
01/17/2007 10:17:29 AM Jan Schneider Comment #4 Reply to this comment
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.
01/17/2007 09:47:16 AM robb (at) wtg (dot) cw (dot) com Comment #3 Reply to this comment
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)
01/16/2007 07:42:20 PM Chuck Hagenbuch Comment #2
State ⇒ Feedback
Reply to this comment
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.
01/16/2007 05:04:09 PM robb (at) wtg (dot) cw (dot) com Comment #1
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ A Postfix policy daemon to manage white/blacklisting
Queue ⇒ Ingo
State ⇒ New
Reply to this comment
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

Saved Queries