jesse at kci
Apr 22, 2011, 3:07 PM
Post #1 of 2
dbmail-postfix-policyd - postfix policy server to check quotas [was [Dbmail-dev] delivery/recipient lookups]
Here's an initial go at this if anyone wants to start playing with it.
I tested this version with dbmail 1.2 on postgres, and dbmail 2.2 on
mysql, with good initial results. Again, it's a postfix policy server
that checks dbmail quotas, so mail that would go over quota can be
rejected in smtp, rather than creating a bounce message.
I want to emphasize, this is not production ready (though I'm testing
it on our production system while monitoring it). It could use some
improvement in the logging to track more verbosely what it's doing, but
more of an issue for production is handling what happens if the script
dies - either need a watcher/restart script (maybe part of the init
script?) or write some restart routines to handle that instead of
die()ing. There's no init script yet, either (maybe could just add it
as one more optional service in the dbmail init script?)
If anyone wants to try this out, I'd be glad to hear of your results
and any problems. It should default to just allowing mail if it
"doesn't work", I doubt there'll be any problem with blocking mail. I
haven't added user@ and @domain catch-alls yet, and there may be some
cases that don't work if say postfix delivers to plain usernames without
the @domain part (though probably not a common setup).
Run "perldoc dbmail-postfix-policyd" for a man page with info on how
to set it up (pretty simple). I had to install libconfig-inifiles-perl
(debian package) on one server to run it; the other was good to go.
Hollar if you need help with any other dependencies (dbi, etc.).
On Mon, 2011-04-11 at 22:54 +0200, Paul J Stevens wrote:
> On 04/11/2011 07:14 PM, Jesse Norell wrote:
> > Hello,
> > Some time ago I started on a postfix policy server to do dbmail quota
> > lookups, and I'm now getting back to finishing that. I'll try to make
> > it support most (all?) dbmail versions, but those differ some in how the
> > aliases/users lookups were done. If anyone wants to review this logic
> > and provide feedback I'd appreciate it.
> > It seems I need to be able to identify when *all* recipients are
> > handled by dbmail, and all of them would go over quota (and subsequently
> > bounced) if the message were to be allowed - if either of those aren't
> > known/true, we'll just allow the message.
> Sounds about right.
> > dbmail 1.2:
> > - single per-user quota across all mailboxes
> > - current usage calculated from summing all message (status < 2) sizes
> > - all addresses have to be in aliases table
> > - look up all deliver_to's for a given alias:
> > - if it's numeric, it's a userid, and should check quota/usage
> > - if it's non-numeric, it's either:
> > - a forwarding address; recursively lookup in aliases table,
> > and if not found, allow the message
> > - a ! or | command, allow the message
> > dbmail 2.0:
> > - single per-user quota across all folders
> > - current usage from dbmail_users.curmail_size
> > - recipient lookup same as 1.2 above ?????
> In 2.0 the lmtp support was added, iirc. This brought the DSN code which
> allowed better back-propagation of delivery results esp with regard to
> multiple recipients.
> > dbmail 2.2:
> > - single per-user quota across all folders (same as 2.0)
> > - current usage from dbmail_users.curmail_size (same as 2.0)
> > - recipients no longer need to be in aliases table ???
> correct. Delivery rules were cleaned up extensively, and should deal
> with your case correctly: only if *all* recipients fail a hard bounce is
> generated. Otherwise soft-bounces or retries are triggered, depending on
> the conditions (perm-fail or temp-fail).
> > - if recipient isn't in aliases table, but a matching username exists,
> > just use that single user's quota settings
> username is treated as the primary alias.
> > - if recipient is in aliases table, recursively follow by owner_id
> > (numeric) and userid (non-numeric), or treat as a command
> > (non-numeric) as appropriate
> > - usermap is strictly for pop/imap, not delivery
> > In checking dbmail 3.0 schema, it looks like there are still no
> > per-mailbox quotas, so it would be identical to 2.2?
> Correct. Lately thunderbird has stopped treating dbmail as a server with
> QUOTA capability it seems. Not sure why, haven't investigated. But
> you're right: only per-user quota (single quota-root "/").
Kentec Communications, Inc.
jesse [at] kci