Re: [exim] autoreply vacation complexity troubles

Top Page
Delete this message
Reply to this message
Author: Kjetil Torgrim Homme
Date:  
To: Daniel Tiefnig
CC: exim-users
Subject: Re: [exim] autoreply vacation complexity troubles
On Tue, 2007-05-08 at 11:02 +0200, Daniel Tiefnig wrote:
> Wolfgang Hennerbichler wrote:
> > VERY cool approach to save ldap ressources!
>
> Since exim-4.50 (or so) this shouldn't make a difference, as lookups
> (read: more than one lookup) are cached, or does it? I'm using a macro
> to do the same lookup for routing information over and over again, and
> it takes the result out of its cache.


I think it's been that way forever, so that's not the motivation for it.
the reason for this technique is to use a single lookup to get *all*
information, rather than separate queries for spam threshold, vacation
message etc. etc.

> Regarding the autoreply, maybe you also want to use your spamscanner to
> decide whether to send reply messages or not. We do, and the "condition"
> snippet looks something like this:


in fact my snippet did this, too, although it checked our spam header
rather than the ACL value directly. we do it that way since we handle
the sending of vacation messages on the backend server (ie. where Cyrus
runs) to get a single "once" database for the user. the "once" database
makes sure a single recipient isn't getting multiple vacation messages.
we have multiple Exim frontends doing the scanning, and want to avoid
sharing state among them, so it can't be stored there.


while I'm at it, perhaps I should mention a trick we do with the naming
of the once database (I think I've mentioned it before):

vacation_message:
  driver = autoreply
  once_repeat = 7d
  once = /somewhere/tripnote/TRIPNOTE_USER=\
             ${md5:TRIPNOTE_SUBJECT TRIPNOTE_BODY}.db
  ...


TRIPNOTE_* are macros which expand to the hopefully self-explanatory
values. the filenames become something like
"kjetilho=a934fcc3144f081ffd9f0dd1930410d5.db", and the nice thing is
that if the user changes the text in any way, the once database is
essentially reset so that recipients will get the new message even if
they got already a different message a couple of days ago.

we periodically run a job which deletes db-files which haven't been
modified in seven days.
--
Kjetil T.