On 12/23/2016 05:29 PM, John Fawcett wrote: > On 12/23/2016 03:34 PM, Dominic Raferd wrote: >> On 23/12/2016 14:27, John Fawcett wrote: >>> On 12/23/2016 03:13 PM, Dominic Raferd wrote: >>>> Obviously I am being thick but can someone explain why this does not >>>> work as I would expect. Basically email addresses are not matching >>>> against domain names in a hashed database: >>>> >>>> $ postconf|grep "^parent_domain_matches_subdomains.*smtpd_access_maps" >>>>> /dev/null && echo "domain.tld should match as the domain part of an >>>> email address" >>>> domain.tld should match as the domain part of an email address >>>> $ # Do a lookup against a full mail address >>>> $ echo j...@mydomain.org REJECT >/tmp/test; postmap /tmp/test >>>> $ postmap -q j...@mydomain.org /tmp/test >/dev/null && echo Success || >>>> echo Failure >>>> Success >>>> $ # Do a lookup against a domain address >>>> $ echo mydomain.org REJECT >/tmp/test; postmap /tmp/test >>>> $ postmap -q j...@mydomain.org /tmp/test >/dev/null && echo Success || >>>> echo Failure >>>> Failure >>> postmap only tests the specific key you are querying. If you want to >>> check if the domain will match you should query for that. >>> >>> postmap -q mydomain.org /tmp/test >>> >>> Where postfix needs to check for multiple keys in the access map it will >>> make multiple lookups. That functionality is not in postmap. >>> >>> John >>> >> Thanks John I hadn't realised that. I understand now. It does make >> postmap -q rather less useful though. > To be fair maps are general features used from various places within > postfix. Each place a map is used can have multiple lookups taking place > depending on the context. I think it would be a big job (and perhaps > even an impossible one) to replicate that logic into postmap. > > John > Georg
Replying to my own post: on re-reading the specification, it looks clear "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set /*result/ to /pwd/. If no matching password record was found, these functions return 0 and store NULL in /*result/. In case of error, an error number is returned, and NULL is stored in /*result/. " So it's the various implementations that may be deviating from this: "Experiments on various UNIX-like systems show that lots of different values occur in this situation: 0, ENOENT, EBADF, ESRCH, EWOULDBLOCK, EPERM and probably others." In the case reported it is returning EINVAL (invalid argument). What version of glibc are you using? John
