On Tue, 26 Aug 2003, David Woodhouse wrote:
> OK; I was just thinking that Exim already _has_ a lot of the apparatus
> I'd require for this -- keeping a database and expiring stuff from it
> periodically etc. Would it really be that much extra code to use those
> same functions for Message-ID caching?
Yes. A new hints data type (and maybe file) would have to be invented,
requiring updates to exim_dumpdb, exim_tidydb, exim_fixdb as well as to
Exim itself. Then there is the problem of message ids. If a message
comes in without a message id, Exim will invent one. It will be
different each time. That will defeat the idea.
> That wouldn't be ideal -- I don't want to use it only for SpamAssassin,
> but also for temporary callout failures... if we get a temporary failure
> on callout, defer once and accept the mail only if they retry, etc.
That is getting even more complicated.
If you really want this, and can stand the cost, you could program it
all yourself in a separate command which is called via ${run or ${perl.
> Am I permitted to use the Exim db functions from local_scan()?
They are not defined in the API, so if you use them, the interface is
not guaranteed to be stable.
> Incidentally, how _does_ Exim expire stuff from its hints databases,
> such as negative callout records for addresses that a spammer
> _attempted_ to use many years ago?
All entries are timestamped. exim_tidydb flushes them. If you aren't
running exim_tidydb periodically via cron, your hints files will
gradually grow.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
