On 02/02/2013 15:22, Simon Hobson wrote:
I had another thought on this - seems a cleaner way to do it, though I suspect it would be even harder to do.If we tracked the queue_id, and once we've said "yes" to any recipient for that queue_if, then we won't say "no" to any further recipients for that message (at least for the quota module). Still update the quota tracking (so the sender will now be over quota), but allow the message through to all recipients. So we'll either accept all recipients, or none*. So the logic for quotas would be : IFthe sender within quota limit then update tracking add this queue_id to tracking permit elifwe already accepted a recipient for this message queue_id update tracking permit else defer * Potentially, we could reject some recipients, but then the user falls below quota and we then accept one - we then accept all the remaining recipients. And a further thought on deferring updates until the DATA phase. This would give more accurate tracking in that there may be other reasons the message receipt is cancelled - it may fail AV/Spam tests for example. Thus if the message gets cancelled, we don't get a call during DATA phase and so don't add the cancelled recipient count to the quota tracking. Similar considerations might apply to the accounting module - though it's not one I use.
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?
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?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
