| 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 (6751 days ago) |
| Due | |
| Updated | 08/14/2007 (6541 days ago) |
| Assigned | |
| Resolved | 08/14/2007 (6541 days ago) |
| Milestone | |
| Patch | No |
Assigned to Chuck Hagenbuch
State ⇒ Resolved
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.
here:
* user=nobody argv=/path/to/horde/ingo/scripts/ingo-postfix-policyd
if ($pos !== false) {
$user = substr($user, 0, $pos);
}
for us is same as email address.
it. It doesn't require any changes to HEAD ingo.
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.
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.
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.
New Attachment: ingo-postfix-policyd
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.
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.
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.
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.
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)
State ⇒ Feedback
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.
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ A Postfix policy daemon to manage white/blacklisting
Queue ⇒ Ingo
State ⇒ New
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