On Wed, Jun 08, 2011 at 02:18:41PM -0400, Ricardo Signes wrote:
> My first moronic attempt to fix this was to move some of the logging to the
> policy service, and to communicate the record id via the added header to the
> logging transport, so it could update the record with the spam check score. I
> had forgotten that the policy service was being queried once *per recipient*,
> which the obvious problem that each message was logged multiple times. I
> didn't want to try coordinating based on instance id (incrementing the
> recipient count each time, etc.) -- and anyway, there is another problem: the
> mail might pass all the recipient restrictions and then fail during DATA.
It is easy to determine which policy service requests are for additional
recipients of the same message.
> My current thinking is this:
>
> 1. a fast, idempotent policy service will check usage at rcpt time so that
> we can avoid accepting DATA if the user is over quota; it will signal
> acceptance with "OK"
>
> 2. an end_of_data_restriction will log the recipient count, size, etc; it
> will signal acceptance by PREPENDing the record identifier
>
> 3. the logging transport will still exist, and will do the content checks
> and update the record with the spam score
Sounds sensible.
--
Viktor.
