Marco Giunta <giu...@sissa.it> wrote: > For example: I have a quota of 100mails /hour, I want to send a single mail > to 60 recipients but I misspell the 59th address and my Postix SMTP reject > the message. Even if my message was rejected from server, Policyd update my > quota to 59/100. Then I fix wrong address, I resend the mail but now after 41 > recipients Policyd reject my email, because I reach the quota of 100mails > /hour, even if smtp server didn't send ANY emails. > > Is there something wrong with my configuration or is the intended behaviour ??
It's intended behaviour, but I believe it is not "correct" and I believe there is a feature request in somewhere for the quota update to be done (by config option) at end-of-data so in your case it would either update with 60 when the message is accepted, or update with nothing at all as the message was rejected. I hit this too. My mail server is set to max recipients/message 50, and to reject messages after 3 errors (toss out any buggy clients or spammers taking shortcuts with the protocols). What I found was that one customer was (with out permission) sending out large mailshots and once the quota was reached the following happened : - Client attempts to send mail to 50 recipients, some get accepted, then the rest get rejected. Once 3 recipients are rejected, the connection is closed. - Since the client server has a load of these messages, it *will* retry at least one delivery before the quota has bled down to allow another 47 recipients through. - Client then starts over, after a few recipients it gets failures, after 3 of those the connection gets dropped. - The server looks incredibly busy, the client appears to be sending huge volumes of mail, but in fact nothing at all is getting through ! But because policyd counts the recipients it didn't reject, it keeps the quota topped up all the time. The workaround for me was to remove the error count limitation, but that still leaves a problem when the quota is rate limiting this sort of traffic. Instead of failing, the behaviour is now "get a few recipients through, the rest get rejected". As a result, instead of processing a moderate number of messages to 50 recipients each, you end up processing a large number to a small number (possibly as few as 1) of recipients each. For a large mailshot, that can be the different between a modest system load, and things grinding to a halt as Amavis grinds through them all. The end result is that you can't reasonably to rate limit large volumes of recipients without significant tradeoffs. For me it was computationally cheaper to allow a higher quota level. IIRC I think I experimented with the quota levels. By manually upping the limit it was possible to let a chunk of traffic through. Once that upper limit is reached, then manually lower the limit which blocks all traffic for that user until the tracking value has bled down. Rinse and repeat. IIRC it worked very well, but meant watching the logs and manually changing values - and it's more or less what would happen with quotas applied at end-of-data time. Sadly I don't have the skills needed to add this feature or I'd have done it. _______________________________________________ Users mailing list Users@lists.policyd.org http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
