------- 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 <pdp@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #3 from Phil Pennock <pdp@???> 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
