On Tue, Oct 29, 2024 at 01:35:54PM +0000, Ken Gillett via Postfix-users wrote:
> I have found why:-
>
> user@mydomain works
> user@myhostname fails
>
> The first is listed in virtual_users, but the latter is not.
Indeed users listed in virtual(5) get a free ride regardless of address
class. So you can choose to list the second address form also, and
work around the problem.
> However I am still puzzled that after the latter is not found in
> virtual_users, the address checking continues to check in passwd (or
> OD):-
Checking the address-class-specific tables is expected when there's no
matching entry in virtual(5), canonical(5) or other possible sources
of address rewrites..
> smtpd: send attr table = unix:passwd.byname
> smtpd: send attr flags = 524352
> smtpd: send attr key = ken
> smtpd: private/proxymap socket: wanted attribute: status
> smtpd: input attribute name: status
> smtpd: input attribute value: 0
> smtpd: private/proxymap socket: wanted attribute: value
> smtpd: input attribute name: value
> smtpd: input attribute value: ken:********:501:20:Ken
> Gillett:/Users/ken:/bin/bash
> smtpd: private/proxymap socket: wanted attribute: (list terminator)
> smtpd: input attribute name: (end)
> smtpd: dict_proxy_lookup: table=unix:passwd.byname flags=lock|utf8_request
> key=ken -> status=0 result=ken:********:501:20:Ken
> Gillett:/Users/ken:/bin/bash
> smtpd: maps_find: local_recipient_maps:
> proxy:unix:passwd.byname(0,lock|fold_fix|utf8_request): ken =
> ken:********:501:20:Ken Gillett:/Users/ken:/bin/bash
In Postfi 2.5.5 from postfix.org, "mail_addr_find" will call "maps_find"
first with the full address (including the domain), then (for local
domains) if the prior lookup got no result, with just the localpart, and
finally if the prior lookup got no result, the "@domain" catchall:
https://github.com/vdukhovni/postfix/blob/9eba2938490d35ce6268b519e4588f101abd7fe1/postfix/src/global/mail_addr_find.c#L114-L156
So the lookup should have stopped here, after finding a match for the
localpart.
> smtpd: send attr request = lookup
> smtpd: send attr table = unix:passwd.byname
> smtpd: send attr flags = 524352
> smtpd: send attr key = @macserve.home
> smtpd: private/proxymap socket: wanted attribute: status
> smtpd: input attribute name: status
> smtpd: input attribute value: 1
> smtpd: private/proxymap socket: wanted attribute: value
> smtpd: input attribute name: value
> smtpd: input attribute value: (end)
> smtpd: private/proxymap socket: wanted attribute: (list terminator)
> smtpd: input attribute name: (end)
> smtpd: dict_proxy_lookup: table=unix:passwd.byname flags=lock|utf8_request
> key=@macserve.home <mailto:key=@macserve.home> -> status=1 result=
> smtpd: maps_find: local_recipient_maps: @macserve.home: not found
> smtpd: mail_addr_find: k...@macserve.home <mailto:k...@macserve.home> -> (not
> found)
This second lookup is unexpected, and clobbers the prior result.
> smtpd: NOQUEUE: reject: RCPT from macpro.home[10.33.33.26]: 550 5.1.1
> <k...@macserve.home <mailto:k...@macserve.home>>: Recipient address rejected:
> User unknown in local recipient table; from=<> to=<k...@macserve.home
> <mailto:k...@macserve.home>> proto=ESMTP helo=<macserve.home>
> smtpd: > macpro.home[10.33.33.26]: 550 5.1.1 <k...@macserve.home
> <mailto:k...@macserve.home>>: Recipient address rejected: User unknown in
> local recipient table
>
> and despite clearly finding the user (me) it then proceeds to think it's "not
> found".
>
> How can I fix that?
You can't, except (see above) by adding entries to virtual(5).
Apple's source code (for MacOS) Postfix 2.5.5 appears essencially the
same as upstream:
https://github.com/apple-oss-distributions/postfix/blob/postfix-197.7/postfix/src/global/mail_version.h#L24
https://github.com/apple-oss-distributions/postfix/blob/postfix-197.7/postfix/src/global/mail_addr_find.c#L123-L156
I haven't found Apple source code for a server-specific Postfix.
It appears, at first blush, that either the Apple server product or its
compiler modified Postfix to produce binaries that behave in ways not
intended by the upstream Postfix C-source, since the localpart lookup
success should short-circuit the "@domain" lookup and its failure.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
