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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
