>You do need to watch this since routers are a per recipient item, and
>acls may also be per recipient items, so the header set you are carrying
>will also become per-recipient before it ever gets to the transports.
>This could make life very interesting indeed :-
Hm, right. I forgot about that part. So then I guess what could be
considered is that a message initially starts off with a "master" set of
headers. If any headers are changed in any way during an ACL section which
is per recipient (such as the RCPT ACL), then the master copy of headers
would be copied to that individual recipient and modifications would happen
for only that recipients set of headers. If you then do header
modifications during an ACL section which is global (such as the DATA ACL),
then they would be applied to the global set of headers AND to each
recipients set of headers.
This way, if no headers are customized for a particular recipient, then we
don't need to waste memory storing a set of headers for every recipient (bad
if there's like 1000 recipients and the message has like 800k of headers!).
Or, maybe as even more of a memory saver - just have one master set of
headers, and we would queue all header changes rather than apply any
immediately. Then, when its time to save the actual message to disk, the
original headers are intact, followed by a list of various changes per
recipient and globally.
Although I see one concern with saving only header changes per recipient,
and that is that we might lose some consistency if we do inline processing
unless we make sure to not *just* queue changes, but to also have it appear
to be applied - this way if a header removal is done, then a header addition
which depends on the header removal to have been done before, it appears to
have been done, even though its just a queue of changes. This would add
some overhead I would assume to every header change during an ACL (since it
would need to apply all changes temporarily, then execute the next header
change, etc...).
So starting with a master set, headers are changed during RCPT time, so the
changes are queued onto a recipient specific list. More headers are changed
further on at RCPT time, so we apply the list of changes queued up, so that
if there were any previous header removals, they appear to have been done
already. Then any changes made during DATA time would also queue the
changes (as to why, read on!) but they would be a master queue of changes
(since the changes aren't recipient specific). Finally when the message is
to be saved, we save the master set, then we save all recipient specific
changes, then we save the master set of changes. When the message is to be
finally delivered, the recipient specific changes are applied, then the
master set of changes applied afterwards.
The reason you'd want to have a queue of changes is because if we want them
to be done inline (in order of occurance), the recipient specific changes
happen before the global changes (I don't think there are any recipient
specific ACLs that happen after DATA, are there?). If we change the master
set directly at DATA time, then certain headers that were initially present
during RCPT time that may have affected header changes might not be the same
after DATA time, so we would want to apply recipient changes first - but
since we don't do final delivery before DATA time, we can't apply
per-recipient changes at that time, so we'd need to queue all changes to be
done at final delivery time.
Maybe during recipient specific ACLs, not only queueing the changes could be
done, but we'd make a copy of the master headers and apply the changes to
that set (as well as queue the changes in a separate list). Then when the
recipient specific ACL is complete, we just wipe the copy of modified
headers (now useless) and keep the queue.
Any comments?
Eli.
-----Original Message-----
From: exim-users-admin@??? [
mailto:exim-users-admin@exim.org] On Behalf
Of Nigel Metheringham
Sent: Wednesday, January 14, 2004 11:09 AM
To: exim-users@???
Subject: RE: [Exim] Removing headers in ACLs
On Wed, 2004-01-14 at 15:58, Eli wrote:
> If a re-implementation of how headers are added and removed is going to be
> done, I'd actually opt in for the ability to have them done inline, rather
> than remove first, then add. It would not only remove the burden of
> remembering all transactions and then processing them later (since you
just
> process as you walk the ACL statements and do them as you see them), but
it
> would make more sense when people are reading the config file. Also, it
> would give better control, IE I could add a header unconditionally, then,
> later on in the ACL (or in another ACL) I could have a condition which may
> remove that header. If removes THEN adds were the way it was done (like
> routers/transports), then I would never be able to do that, and you would
> probably get a lot of people asking why.
You do need to watch this since routers are a per recipient item, and
acls may also be per recipient items, so the header set you are carrying
will also become per-recipient before it ever gets to the transports.
This could make life very interesting indeed :-
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
--
## List details at
http://www.exim.org/mailman/listinfo/exim-users Exim
details at
http://www.exim.org/ ##
---
[This E-mail scanned for viruses]
---
[This E-mail scanned for viruses]
