On 10/27/2011 8:54 PM, Fred Kilbourn wrote:
> * Should be able to calculate the true message size, not simply trust any
> size headers sent.

True message size can only be determined after the DATA phase of the
conversation has ended.

> * Should handle multi-recipient messages somewhat gracefully.  Optimally,
> I'd like to be able to deliver to everyone except for those over quota, and
> then reject with a "5.2.2   Mailbox full".  My thought is, I'd still get the
> message to the intended recipients by re-injecting the message somehow,
> minus those recipients that are over quota.  Also, I'd indicate in the
> rejection message that "only x, y, z.... users didn't receive the message"
> for the benefit of legitimate senders.

The only time you can reject individual recipients is during the
RCPT stage, before you've seen the DATA.

> From what I've read, the three ways to implement such a system would be
> either as an smtp policy server, a before-queue milter, or a before-queue
> content filter.

Yes.

> 
> Finally, my questions are these:
> 
> 1:  Is there some package out there I may have missed that does this nicely?
> 
> 2:  Are these the only three candidate methods within postfix for
> implementing such a system?  Have I missed anything?  Does someone have a
> suggested alternative?

A simpler alternative is a check_recipient_access table that rejects
mail when the client is already over quota.  You could query an SQL
table, or use a TCP table to talk to a daemon, or have an external
program build a hash table.

This would likely reduce your bounces to only a handful, rather than
thousands.

> 3:  Of these candidate methods, which has the best potential performance,
> are there any with limitations that will preclude me from implementing the
> features I've mentioned?  (I know I could read more on this one, but I'm
> looking for a small shortcut here please).

Don't get caught up in premature optimization.  That said, a policy
service lets postfix do most of the work, and would have the least
overhead.  Milter and proxy add more overhead, but offer more control.

At any rate, overall performance depends on a lot of things besides
the interface you use.


  -- Noel Jones

Reply via email to