------- 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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [email protected] 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/ ##
