------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=614
Summary: Inconsistency in how deny message bubbles up from sub-
ACL
Product: Exim
Version: 4.68
Platform: x86
OS/Version: Linux
Status: NEW
Severity: bug
Priority: low
Component: ACLs
AssignedTo: ph10@hermes.cam.ac.uk
ReportedBy: aprl@math.arizona.edu
CC: exim-dev@exim.org
If a parent ACL denies based on a call to a sub-ACL, and if the sub-ACL sets a
'message', then the parent ACL will sometimes use (i.e., return) that message,
and will sometimes write that message to the log, but the behavior is
inconsistent. (Examples below.) It seems to depend on whether the parent ACL
calls an additional sub-ACL beyond the sub-ACL that set the message, and/or on
whether the parent ACL already had a 'message' set prior to calling the
sub-ACL. These subtle dependencies might be illuminated by the examples below.
Here's a (somewhat minimalized and therefore strange-looking) example to show
this behavior:
my_delay_acl:
accept
delay = 8s
my_spamcheck_acl:
deny
message = Sub-ACL message.
accept
acl_smtp_data:
deny
!acl = my_spamcheck_acl
acl = my_delay_acl
accept
Here acl_smtp_data will deny with "550 Administrative prohibition" and will log
"... rejected after DATA" with no message appended. This brings up two
concerns:
(1) Should the 'message' from the sub-ACL have bubbled up to become the
return message? (I would say 'yes'.)
(2) Should the log line be consistent with what was returned to the calling
host? (I would say 'yes'.)
Now simplify acl_smtp_data to:
acl_smtp_data:
deny
!acl = my_spamcheck_acl
delay = 8s
accept
I simply inlined the innocuous code from my_delay_acl to the place it is called
--- this shouldn't affect anything, right? But now acl_smtp_data will deny with
"550 Sub-ACL message." and will log "... rejected after DATA: Sub-ACL message."
Notice that:
(1) Unlike before, now the last 'message' set by a sub-ACL bubbled up and
became the return message. (I would say this is desirable.)
(2) The message in the log line is consistent with the message returned to
the calling host. (I would also say this is desirable.)
Now change acl_smtp_data to introduce a parent message:
acl_smtp_data:
deny
message = Parent message.
!acl = my_spamcheck_acl
delay = 8s
accept
Now acl_smtp_data will deny with "550 Parent message." yet will log "...
rejected after DATA: Sub-ACL message."
Notice that:
(1) Presence of a pre-existing parent message prevented the sub-ACL from
overriding the message. (I would not have expected this behavior.)
(2) Yet the sub-ACL was nonetheless able to override the log message. In
particular, the log message is inconsistent with the message returned to the
calling host. (I find this undesirable.)
Now change acl_smtp_data to have a parent message but also call an additional
innocuous sub-ACL:
acl_smtp_data:
deny
message = Parent message.
!acl = my_spamcheck_acl
acl = my_delay_acl
accept
Now acl_smtp_data will deny with "550 Parent message" and will log "...
rejected after DATA: Parent message."
Notice that:
(1) Presence of the parent message and an additional sub-ACL prevented the
first sub-ACL from overriding the message. (I find this undesirable.)
(2) Whereas previously the sub-ACL could nonetheless override the log
message, by now calling an additional innocuous sub-ACL, the log message is no
longer overridden. (At least the log message is consistent with the returned
message. Consistency is good.)
My feeling is that the current way Exim handles 'message' and overrides by
sub-ACLs is confusing and downright unpredictable (and as far as I can tell,
undocumented). To make things predictable and useful, I would suggest things to
always be handled as follows:
(0) Context-handling for 'message = blabla' should essentially behave like
'set acl_m1 = blabla'
(1) That is, the most-recently set 'message', whether in a sub-ACL or parent
ACL, is the one that will be used.
(2) If it remains unset, then a default message will be used in its stead.
(3) Whatever message ends up getting used, it should be used both for the
message returned to the server and for the message put in the log line.
(4) In particular, pre-existence of a message prior to calling a sub-ACL
doesn't affect whether the sub-ACL can override the message. And calling
additional sub-ACLs that don't set a message also will have no effect on
whether a prior-called sub-ACL can override the message.
In this approach, something like
message = Default parent ACL message that can be overridden.
!acl = my_spamcheck_acl
acl = my_delay_acl
will cause the sub-ACL message to be returned and logged, whereas in
!acl = my_spamcheck_acl
acl = my_delay_acl
message = Forced parent ACL message.
the forced parent message will be returned and logged.
In short, this proposed approach gives the administrator configuring Exim a lot
of flexibility to achieve various types of desirable behaviors.
--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=614
Summary: Inconsistency in how deny message bubbles up from sub-
ACL
Product: Exim
Version: 4.68
Platform: x86
OS/Version: Linux
Status: NEW
Severity: bug
Priority: low
Component: ACLs
AssignedTo: ph10@hermes.cam.ac.uk
ReportedBy: aprl@math.arizona.edu
CC: exim-dev@exim.org
If a parent ACL denies based on a call to a sub-ACL, and if the sub-ACL sets a
'message', then the parent ACL will sometimes use (i.e., return) that message,
and will sometimes write that message to the log, but the behavior is
inconsistent. (Examples below.) It seems to depend on whether the parent ACL
calls an additional sub-ACL beyond the sub-ACL that set the message, and/or on
whether the parent ACL already had a 'message' set prior to calling the
sub-ACL. These subtle dependencies might be illuminated by the examples below.
Here's a (somewhat minimalized and therefore strange-looking) example to show
this behavior:
my_delay_acl:
accept
delay = 8s
my_spamcheck_acl:
deny
message = Sub-ACL message.
accept
acl_smtp_data:
deny
!acl = my_spamcheck_acl
acl = my_delay_acl
accept
Here acl_smtp_data will deny with "550 Administrative prohibition" and will log
"... rejected after DATA" with no message appended. This brings up two
concerns:
(1) Should the 'message' from the sub-ACL have bubbled up to become the
return message? (I would say 'yes'.)
(2) Should the log line be consistent with what was returned to the calling
host? (I would say 'yes'.)
Now simplify acl_smtp_data to:
acl_smtp_data:
deny
!acl = my_spamcheck_acl
delay = 8s
accept
I simply inlined the innocuous code from my_delay_acl to the place it is called
--- this shouldn't affect anything, right? But now acl_smtp_data will deny with
"550 Sub-ACL message." and will log "... rejected after DATA: Sub-ACL message."
Notice that:
(1) Unlike before, now the last 'message' set by a sub-ACL bubbled up and
became the return message. (I would say this is desirable.)
(2) The message in the log line is consistent with the message returned to
the calling host. (I would also say this is desirable.)
Now change acl_smtp_data to introduce a parent message:
acl_smtp_data:
deny
message = Parent message.
!acl = my_spamcheck_acl
delay = 8s
accept
Now acl_smtp_data will deny with "550 Parent message." yet will log "...
rejected after DATA: Sub-ACL message."
Notice that:
(1) Presence of a pre-existing parent message prevented the sub-ACL from
overriding the message. (I would not have expected this behavior.)
(2) Yet the sub-ACL was nonetheless able to override the log message. In
particular, the log message is inconsistent with the message returned to the
calling host. (I find this undesirable.)
Now change acl_smtp_data to have a parent message but also call an additional
innocuous sub-ACL:
acl_smtp_data:
deny
message = Parent message.
!acl = my_spamcheck_acl
acl = my_delay_acl
accept
Now acl_smtp_data will deny with "550 Parent message" and will log "...
rejected after DATA: Parent message."
Notice that:
(1) Presence of the parent message and an additional sub-ACL prevented the
first sub-ACL from overriding the message. (I find this undesirable.)
(2) Whereas previously the sub-ACL could nonetheless override the log
message, by now calling an additional innocuous sub-ACL, the log message is no
longer overridden. (At least the log message is consistent with the returned
message. Consistency is good.)
My feeling is that the current way Exim handles 'message' and overrides by
sub-ACLs is confusing and downright unpredictable (and as far as I can tell,
undocumented). To make things predictable and useful, I would suggest things to
always be handled as follows:
(0) Context-handling for 'message = blabla' should essentially behave like
'set acl_m1 = blabla'
(1) That is, the most-recently set 'message', whether in a sub-ACL or parent
ACL, is the one that will be used.
(2) If it remains unset, then a default message will be used in its stead.
(3) Whatever message ends up getting used, it should be used both for the
message returned to the server and for the message put in the log line.
(4) In particular, pre-existence of a message prior to calling a sub-ACL
doesn't affect whether the sub-ACL can override the message. And calling
additional sub-ACLs that don't set a message also will have no effect on
whether a prior-called sub-ACL can override the message.
In this approach, something like
message = Default parent ACL message that can be overridden.
!acl = my_spamcheck_acl
acl = my_delay_acl
will cause the sub-ACL message to be returned and logged, whereas in
!acl = my_spamcheck_acl
acl = my_delay_acl
message = Forced parent ACL message.
the forced parent message will be returned and logged.
In short, this proposed approach gives the administrator configuring Exim a lot
of flexibility to achieve various types of desirable behaviors.
--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##