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 yep. > > 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 "/"). -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
