On 02/05/2013 04:57 PM, Simon Hobson wrote:
Nigel Kukard wrote:Sorry, just to understand this a bit better, you're deferring not rejecting?Yes. It's just that each "reject" is counted as an error by Postfix and it eventually drops the connection.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 ?The message size is increased at end-of-data stage, at that time we have a list of recipients which afaik is what we multiple the size by and bump up the counter.That's what I thought - I'd noticed in the logs that tracking updates for message count all come before updates for message size. How hard would it be to do the same with message count ? It would solve my problem - though I guess others may disagree. It would still leave the situation where more than one message is being received concurrently, and part way through the tracking value is updated such that further recipients are deferred. But at least one message would be handled, and the tracking value wouldn't be incorrectly increased for any failed messages.
I think why its like it is is so we don't have to receive an entire message before denying it for a recipient limit threshold. In the RCPT stage we can reject single recipients, but at DATA we reject all of them.
As for changing it, or maybe adding another type of limit to cater for updates after end of data would be the best, if there is enough demand it shouldn't be a problem.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
