>>>>> "Kelley" == Kelley Reynolds <schnozzy@???> writes:
>> ACLs are processed in sequential order. Some ACL condition clauses
>> overwrite the "message" field that's used when the ACL triggers a
>> rejection, and some don't. This is why your results are
>> inconsistent; to get consistency, put your clauses in the
>> logically correct order.
Actually that explanation was too simplistic. There are in fact
_two_ "message" fields (the one used by message=, which is returned
to the client, and the one used by log_message=, which is logged
and defaults to the message= value if not explicitly set). Many of
the ACL clauses set the log_message= field without touching the
message= field, so in those cases what you see in the log doesn't
match what the client sees (which you'll probably have to use exim -bh
to find out).
Kelley> A Ha! This explains it. Perhaps I am misreading 38.11 in the
Kelley> documentation but
Kelley> ..
Kelley> If message is used on a statement that verifies an address,
verify = reverse_host_lookup doesn't verify an "address" in that
context, the docs are referring to an email address not an IP.
reverse_host_lookup actually only sets the log_message= field as
far as I can tell from the code.
Kelley> This makes it seem that if I specify message in the ACL, it
Kelley> overrides any message set by verification (and indeed, the
Kelley> documentation makes it seem like only address verification
Kelley> does this as opposed to all verify calls). I don't read
Kelley> anywhere that message has to be *after* the verify call since
Kelley> verify overwrites the message value. I'm just trying to help
Kelley> clarify the documentation so this doesn't catch anybody else.
Kelley> The sequential processing makes perfect sense, just doesn't
Kelley> read that way in the docs.
Another caveat is that the message= or log_message= text isn't expanded
until after the condition processing is done. I think that's a mistake,
frankly.
--
Andrew, Supernews
http://www.supernews.com
