Author: W B Hacker Date: To: exim users Subject: Re: [exim] Best way to pass information between message and its'
bounce
jori.hamalainen@??? wrote: > Hi all,
>
> when messages come in I set certain acl_m_* -variables at ACL to
> message.
>
> Now if next hop is permamently denying the relay, so I get bounce
> message written by template.
>
> My experiment shows me that I cannot access original message acl_m_
> -variables. I'd like to use those in generation of bounce message.
> Naturally I acknowledge that I can access original message's headers.
> But transferring variable data through headers (headers_add in
> ACL&router and headers_remove in transports) seems to be non-optimal,
> and I am not quite sure if I use headers_add in router to add header,
> if I can refer to it at bounce template.
>
> --
>
> Also can I set variables in routers? My skill of RTM does not help me
> on that. Naturally variables are called _ACL_m which hints where to
> set those. What if I want to generate counter for example how many
> times message is tried to be routed or set variable for next router
> in line? Or something similar.
>
> --
>
> Third, can there be global exim variables with access from /proc or
> by signal? Those could be used for easier SNMP monitoring instead of
> crude parsing log by intervals. For example $stats_exim_deny,
> $stats_exim_accept, $stats_exim_transport etc... So counter for every
> ACL 'verb' (accept, log, deny, drop,...) and also for transport (how
> many gone out successfull or how many delayed, bounced etc) and
> perhaps something how many msgs we have in queue (this last one might
> be a bit trickier as listening daemon does not list the queue?).
>
> Have I missed some obvious FAQ answers on my questions?
'Sort of'.
All of the above are covered in the docs.
>
> Best regards, Jori
Basics:
- an acl_m variable is stored with the message in the fs, and 'lives'
through the router/transport completion. Once the only/last copy of
message has been transported, acl_m's are deleted, and can no longer be
accessed. The acl_m variables do NOT travel onward with the message body
or headers.
- Unless stripped, X (or other) headers remain with the message, even
into POP/IMAP mailstore and on to the user's MUA and their local store,
e.g. potentially available 'from somewhere' many years after delivery.
As you can create very simple X-headers with numeric, binary, or encoded
information, they need not be significantly heavier to handle than acl_m
variables.
- router/transports access acl_m variables as 'read-only' and have to
share one native general-pupose writable variable and a couple of
bespoke ones (helo_data for example) that.conversely, may not be
avaialable to be READ - at least not at all points you might wish to do so.
OTOH, there is no limit on what you can store and/or read-back with an
SQL INSERT, an invoked script, or by writing/reading or just 'touching'
a file. You'll just have to write that part yourself.
- Something similar applies w/r global variables.
As Exim normally spawns a child process for each connection, changes are
not readily shareable across multiple such instances.
While you can use SQL INSET/UPDATE or SELECT's, write-to/read-from a
file, execute a script or binary (sky is the limit, there), the
asynchronous nature of the potentially 'many' child processes means they
will generally be in different stages, so you don't have full control
over / predictability of - if/as/when shared information will be
in-place or actioned.
That said, it is common to use flat-files or CDB/BDB/DB or SQL to hold
information written by Exim or other processes, such as white/grey/black
lists. The information will at least be actioned on the next 'new' run
of a child process with no restart of the parent Exim daemon required.
'where there's a will, there's a way'. Usually many ways.
