Now I feel like doing something about Exim's header handling! (See
http://www.exim.org/bugzilla/show_bug.cgi?id=354 or Exim 4 WishList item 333)
Some questions to discuss:
How much can be done without breaking backwards compatibility? I'm primarily
thinking about what is visible when. How many configurations would break if
headers_remove removed headers previously added by headers_add?
Can some things be done before completely revamping the header handling, i.e.
which wishes are actually blocked by, or could even be included in, the
aforementioned bug 354?
The somewhat peculiar system filter mechanism, which its whole set of
configuration options, could be deprecated and replaced with something else.
What's special with the system filter is that it's run once per message,
whereas routers are run once per recipient. I think adding recipients from
ACLs has been suggested at some time. Another idea was a kind of routers that
only run once per message. What else is needed to get the same features as is
possible with system filters?
Let's see if I've understood what happens to headers throughout the course of
a delivery...
First, header lines can be added (but not removed) in ACLs (the add_header
modifier or the message modifier in a warn statement). Headers lines added in
the MAIL, RCPT and PREDATA ACLs are accumulated and duplicates are removed.
They are then added to the message and become visible during the DATA and
MIME ACLs. Header lines added in the DATA and MIME ACLs are accumulated in
the same way, duplicates are removed and finally the result is added to the
message.
Then the local_scan() function is called. It can do whatever it wants.
If the message is accepted it is written to the spool in its current state.
Then it can be delivered.
In every delivery attempt, the system filter is run first. It can add and
remove header lines, and all such changes happen immediately. The altered
header is saved to the -H spool file, so if delivery fails and the filter
doesn't use the first_delivery condition, the same header fields will be
added on the next attempt.
Then all the recipient addresses are routed. Every router can add and remove
header lines for the recipient in question, but the message is not actually
modified and thus the new header lines do not become visible; instead the
additions and removals are accumulated in a data structure associated with
each address. They are not written to disk, so on a second attempt all these
header modifications are rolled back.
When all addresses have been routed and assigned transports, they are batched
together subject to batch_max, extra headers etc. The transports write the
message copies to their destinations, omitting the header fields that have
been set to be removed and appending any extra header lines. Expansion
variables still reflect the way the message looked after passing the system
filter.
To add to this we have address rewriting and possibly other things I have
forgotten. What *have* I forgotten?
--
Magnus Holmgren holmgren@???
(No Cc of list mail needed, thanks)
