Nigel Kukard wrote: >You're very right in your analysis, the delegation protocol doesn't >really give us enough information to only count successful deliveries. > >The mail counter is increased during the RCPT stage, so if 100 >recipients are received, and the 99th one fails in such a way that >Postfix terminates delivery the counter is already increased. > >Deferring the counter update to the DATA stage may not be sufficient >either, what happens if 100 connections are made for 100 recipients >each, the counters are deferred to DATA and all are updated at the same >time. > >I'm not sure if one can get around this. What about changing the >destination concurrency limit?
We don't (in the general case) have control over the servers sending mails through us - this is a setup specifically for customers to send/receive thei mail. Deferring the counter updates would work for me, though I can see how it might not work for others. With my setup, the theoretical maximum "overshoot" would 450 recipients - 9 connections*, 50 recipients per message. The result would be that the customer would be massively over-limit and their mail would pause for a while. * 3 servers at the moment, each with asmtpd_client_connection_count_limit of 3 As it is, if I increase the limits sufficiently then mail will flow - but they are a bit higher than I'd prefer. Both in terms of the message rate, and the allowable errors before Postfix drops the connection. The only other way round it I can see would be to have high/low marks - so when the high mark is reached then deliver stops altogether, and doesn't restart until the low mark is reached. The effect would be that mail would come in in spurts. I guess that would need extra fields in the tables, and extra logic - beyond my coding abilities I think (but I'll have a quick look at the code and see).
smime 19.p7s
Description: mailforge
_______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
