>Bear in mind that if you implement immediate header mangling you may
>also break existing configurations which rely on header changes not
>being effectively immediately
True. I believe the change would still be a good thing to have though, as
it would make more sense when reading over config data just like you posted.
It would (to someone who has no prior knowledge of how Exim works) seem that
what *should* happen in your checks is if there's no ID, insert one - the
test later on that re-checks if there was no ID originally looks as if it's
out of place since you'd kinda think that since an ID was generated, the
latter test would not be executed (even though it is).
This would seem to note that if headers are reworked, not only would
documentation need to be extensively redone, but maybe we would need
additional def: checks that could be run for two different cases. One type
of def: could check the original headers, and another type of def: could
check headers created by exim. To keep portability, the standard def: could
be made to check original headers, and then another def: type could be made
to check other headers.
Eli.
-----Original Message-----
From: exim-users-admin@??? [
mailto:exim-users-admin@exim.org] On Behalf
Of David Woodhouse
Sent: Thursday, January 15, 2004 6:46 AM
To: exim-users@???
Cc: Nigel Metheringham
Subject: RE: [Exim] Removing headers in ACLs
On Thu, 2004-01-15 at 00:49 +0000, Philip Hazel wrote:
> On Wed, 14 Jan 2004, Nigel Metheringham wrote:
>
> > 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 :-
>
> Thanks for highlighting another perhaps non-obvious feature. Or perhaps
> "feature".
Bear in mind that if you implement immediate header mangling you may
also break existing configurations which rely on header changes not
being effectively immediately, such as...
warn condition = ${if !def:h_Message-ID: {1}}
message = Message-ID: <E$message_id@$primary_hostname>
< ... other checks ... >
accept hosts = +relay_hosts
< ... more stringent tests, including ... >
deny condition = ${if !def:h_Message-ID: {1}}
message = RFC2822 says you SHOULD have a Message-ID.\n\
Most messages without it are spam, so your mail has been
rejected.
Not that this means I think you shouldn't _do_ it -- just that it's
something that needs documenting clearly in the release notes.
--
dwmw2
--
## 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]
