Re: [exim] recording delivery in DB

Thank you Phil, for taking the time to show the implications of either
way.

> On 2010-09-18 at 18:15 +0200, Axel Rau wrote:
>>
>> Am 18.09.2010 um 17:01 schrieb Dave Evans:
>>
>>> Better than patching deliver.c? Personally I reckon that parsing
>>> the main log
>>> would be the much better option, unless you have some requirement
>>> for the
>>> updates to be synchronous with respect to delivery.
>> No, that's no requirement.
>> My rationale was:
>> - having one more process in the chain is one more point which may
>> fail,
>
> See, the question is not "is there an extra step?" but "what happens
> when it fails?". Ie, what is the coupling involved in the extra step?


Unfortunately I did not give enough details. I try it now:

1. The IMAP server (used for user mail delivery and submission) stores
email in a DB (see aox.org).
2. On the same mailhost are in- and outbound SMTP-relays (exim), which
store and retrieve reputation data in another DB on the same backend.
exim bases its decisions about accept/defer/deny on data stored in the
DB.
3. The DB backend (it's not mySQL) is vital for all 3 email server
functions. It lives on the same physical host.
4. There is a backup mailhost whose DBs form a replication cluster
with the 1st one.
5. Logs from the whole network have a medium- to long-term storage on
a central loghost in a DB.
6. Short term log storage is local to servers in the file system.

Taking all this in account, I still would prefer a solution in
deliver.c, if it could be fed to mainstream code base at some time in
the future.

Axel
---
axel.rau@??? PGP-Key:29E99DD6 +49 151 2300 9283 computing @
chaos claudius