Zied Fakhfakh <[email protected]> wrote: > Only the Error message received at the client side (Zimbra webmail actually) > does not reflect the data I filled in, is it expected ?
How on earth should I know - I don't know what you "filled in" or where, or what your system configuration is, or what error message you got, or ... Ideally you'd specify : What you did configuration wise What you did to test it What you expected to happen/get What actually happened/you got But throwing a few guesses in ... If you configured a policy to rate limit a client, and then you tried sending messages above that rate, then I'd expect the client to give you an error message. That error message is client specific, and may or may not include any detail of what the mail server said to it - unfortunately quite a few give no more detail than "it didn't work" ! The message may well be sent to some of the recipients - that is defined by your mail server config. For example, before I got all this sorted out, I had Postfix set to allow up to 50 recipients per message, but only 3 errors before it aborted reception. Because of the way Policyd does rate limiting, it would count the accepted recipients as delivered and update the counters accordingly - but postfix would terminate it after 3 fails from Policyd. The result was that a customer we had that used us for a relay for mailshots would get permanently stuck - each delivery attempt would use up the few recipients allowed before hitting the limit, but then get rejected and stuck back in the queue. There was never any time for enough quota to develop to allow sending of a single 50 recipient message and so nothing went through. I had to relax the error limit (up to 50). That way, the initial recipients would get accepted - and if the quota was hit then the rest of them would get rejected, leading to the message getting out to a few recipients at a time at the allowed rate. It would go out to all recipients eventually. I have put in a feature request for recipients to be updated after message delivery (like message size is done). That would mean the customer going over-quota, but then being blocked completely for a short time until the counters bled down. In your case, using a mail client rather than a server, if (say) the user sent a message to 20 recipients when there was only 10 recipients worth of quota available - the client would get an error, but 10 of the recipients would get the message. If the user then resends the message, it may go to those who previously got it, but unless the quota has reset enough, it may well still fail again and some recipients will not get it. If the client is deterministic in the order of recipients then it will always be the same ones that do get the message (those at the start of the list) and don't get the message (those at the end of the list). _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
