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 --- [email protected] PGP-Key:29E99DD6 +49 151 2300 9283 computing @ chaos claudius -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
