Philip Hazel wrote:
> On Thu, 5 Oct 2006, Eli wrote:
>
>
>>I dunno - my personal opinion is that I'd prefer to have add_header function
>>*just* like message did *IF* the point to using add_header is to ultimately
>>abolish the use of "warn message = ...". However, if the actual intended
>>use of add_header is to allow the unconditional addition of a header to a
>>message, then perhaps calling "warn message = ..." depreciated behaviour
>>should be revoked, and both methods kept for the future.
>>
>>Comments?
>
>
> 0. "add_header" was never meant as an exact drop-in for "message".
>
> 1. The use of "message" in "warn" is anomalous (I should have thought
> about this more deeply when I overloaded its meaning). In all other
> cases, "message" is used when access is denied. It seems best to keep it
> for that function.
100% it even has the correct name ;-)
>
> 2. When it was adapted for "warn", "message" was assuming that it was
> kind of like a pseudo- or soft deny, with the value being used only when
> all the conditions were true. When I implemented add_header, which of
> course applies to verbs other than "warn", I thought it simpler to make
> it work like "set" and other modifiers (which have grown in number -
> originally there was only "endpass", IIRC) and make it work "in line".
>
Clear.
> 3. I don't think there is anything you could do with "message" that you
> can't do with "add_header", is there? If you want it only to happen when
> all the conditions are true, as "message" did, you just put it at the
> end.
>
Other than 'speak' to the connected peer MTA if/as/when an acl is a
rejection-class verb? Probably.
> 4. The manual contains this:
>
> ---------------------------------------------------------------------
> The add_header modifier acts immediately it is encountered during the
> processing of an ACL. Notice the difference between these two cases:
>
> accept add_header = ADDED: some text
> <some condition>
>
> accept <some condition>
> add_header = ADDED: some text
>
> In the first case, the header line is always added, whether or not the
> condition is true. In the second case, the header line is added only if
> the condition is true. Multiple occurrences of add_header may occur in
> the same ACL statement. All those that are encountered before a
> condition fails are honoured.
> ---------------------------------------------------------------------
>
> I hoped that that would make it clear how it works.
>
> 5. I think it's confusing to keep both methods indefinitely.
>
>
If you *must* trash one, trash add_header, then.
message can be used to add a header.
add_header, OTOH, doesn't (shouldn't) work as well for specifying what is to be
sent to the connected client during smtp (OR in a later bounce).
Separating the two - i.e. *preventing* 'message' from being used for headers *at
all* seems the more consistent approach. i.e - it speaks over the smtp port, not
into the message & header file.
While we are at it - for (Exim 8.X?) - can 'warn' (a psychologically 'loaded'
word if ever was, and too rarely actually doing anything 'warning' in nature) be
renamed or aliased to one of:
- flag
- check
- mark
- score
- note
- test
- tally
i.e. a scorekeeper or accounting-class verb.
Much like the real-world, an accountant may detect and onpass information that
causes Management to change course, but cannot directly change the firm's course
of action himself.
Best,
Bill
