Nigel Kukard wrote: >Pretty tough one this. We can't really accept all recipients if one has >been accepted, what would happen if there are 1M of them?
Then Postfix would reject the message when it reached smtpd_recipient_limit which I have set at 50. Though not having tested it, I assume it will start to reject recipients, and then close the connection when it reaches the error limit. In that case, it won't reach the DATA phase, as the message won't be processed and we don't (incorrectly) increment the quota tracking. Of course, if you do set the recipient limit very high, then the user could go well over quota and then be blocked from sending any more mail for a while. That isn't all that different from what happens now - you can set a quota of (say) 600/hr whch is 10/minute, but they can send at a very high rate until they reach 600 and only then will they be throttled. >Wouldn't something like per-message instead of per-recipient counting be >more beneficial in your usage case? this is a counter which is updated >in the EOD state similar to the message size counter? Well I suppose it would be an interesting thing to consider, but from the customer's POV it makes things complicated. There are two things to think about here. One reason for restricting message rate is to control load on the servers - if the user spits a several meg message out to 3k recipients then that creates quite a spike of load on the server, and it impacts on handling mail for other users (it's worse on my old system which uses after-queue scanning as all these messages go in the queue and delay scanning of others). But it's easier to explain "x messages / hour" than "x messages, after allowing for how your software splits them, per hour". Some of the software we know customer's use will actually send out one message per recipient - thousands of them ! Some bulks up the recipient list. BTW - how is the message size quota handled ? That can't be known reliably until end of data so presumably the recipient list must be getting held for that ? _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
