------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1297 Phil Pennock <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Phil Pennock <[email protected]> 2012-09-17 18:43:17 --- Okay, the git migration seems to be missing tags for some of the older commits, including 4.60; we have 4.61 (and the release before 4.60, 4.54). So we're looking for a point between "4 Oct 2005" and "4 Apr 2006" as the start-point for any changes, so anything changed before 2005-10-04 is safe and only the later changes are candidate culprits. The first relevant file (and the only one I checked yesterday) is match.c. Commit 95d1f782e772c5dd39d718409edabe1eca92690d is safe. % git diff 95d1f782e772c5dd39d718409edabe1eca92690d HEAD match.c | less Assuming that a given lookup test returns the same error code, there are no additional ways out of this code. (There are, unfortunately, FILE* leaks, but code executing this should not be in a long-lived process, since Exim forks for new connections, etc). The code path is that verify_check_this_host() calls match_check_list, passing check_host() as the callback function, the one whose return value matters for returning out of the code I was looking at above. So it looks as though the change comes with commit 1688f43b. That was part of release 4.61. ChangeLog items: PH/23 When a malformed item such as 1.2.3/24 appears in a host list, it can never match. The debug and -bh output now contains an explicit error message indicating a malformed IPv4 address or mask. PH/24 An host item such as 1.2.3.4/abc was being treated as the IP address 1.2.3.4 without a mask. Now it is not recognized as an IP address, and PH/23 above applies. The comment added: /* The pattern is not an IP address. A common error that people make is to omit one component of an IPv4 address, either by accident, or believing that, for example, 1.2.3/24 is the same as 1.2.3.0/24, or 1.2.3 is the same as 1.2.3.0, which it isn't. (Those applications that do accept 1.2.3 as an IP address interpret it as 1.2.0.3 because the final component becomes 16-bit - this is an ancient specification.) To aid in debugging these cases, we give a specific error if the pattern contains only digits and dots or contains a slash preceded only by digits and dots (a slash at the start indicates a file name and of course slashes may be present in lookups, but not preceded only by digits and dots). */ This predates my involvement as a maintainer of Exim, but appears to suggest that the entries were not matching what you thought they were, and the silence was encouraging people in this belief. So yes, it's a change in behaviour; you can get back almost the same behaviour by using +ignore_unknown as an entry in the hostlist just before the file reference. Fixing the entries as you have done gives the correct behaviour both before and after this change. !hosts = : +relay_hosts : \ ${if exists {/etc/greylistd/whitelist-hosts}\ {+ignore_unknown : /etc/greylistd/whitelist-hosts}{}} -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
