The problem appears to be that when it fails to find anything for k...@macserve.home, postfix splits the address into ken and @macserve.home (after getting that from mydestination).
It then runs ken against unix:passwd.byname and gets a result:- > dict_proxy_lookup: table=unix:passwd.byname flags=lock|utf8_request key=ken > -> status=0 result=ken:********:xxx:xx:Ken Gillett:/Users/ken:/bin/bash > maps_find: local_recipient_maps: > proxy:unix:passwd.byname(0,lock|fold_fix|utf8_request): ken = > ken:********:xxx:xx:Ken Gillett:/Users/ken:/bin/bash However, not content with that, it then continues to try the same thing with @macserve.home:- > dict_proxy_lookup: table=unix:passwd.byname flags=lock|utf8_request > key=@macserve.home <mailto:key=@macserve.home> -> status=1 result= > maps_find: local_recipient_maps: @macserve.home: not found which unsurprisingly is not found. The final result is then issued as a fail:- > mail_addr_find: k...@macserve.home <mailto:k...@macserve.home> -> (not found) > 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> > > 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 So I'm wondering why it even tries to find @macserve.home when it has already found the actual user, ken (i.e. me). Surely having established the existence of the user, should it not exit the checking process and simply continue to receive and process the mail message? It occurs to me that if ken@home were not being found in virtual_users, it would also fail. In fact, I cannot see how it could accept anything that isn't specifically listed in virtual_users since @whatever will never match anything in unix:passwd.byname and if that second check is what becomes the overall result, nothing with an @ and anything following will pass. In which case, every user has to be in virtual_users and there'd be no point even trying to check against unix:passwd.byname. This doesn't seem right. Ken G i l l e t t _/_/_/_/_/_/_/_/ > >> On Tue 29 Oct 2024, at 01:04, Wietse Venema via Postfix-users >> <postfix-users@postfix.org <mailto:postfix-users@postfix.org>> wrote: >> >> There is a way to make the Postfix SMTP daemon more chatty in the >> logfile, but that works only if you can update and verify the right >> configuration files. Which you haven't, going by your reports sofar. >> >> /path/to/postconf debug_peer_list=ip-of-telnet-client >> /path/to/postconf debug_peer_level=2 >> /path/to/postfix reload >> >> where ip-of-telnet-client is the IP address of the client >> that you use to send the commands with telnet. >> >>> e.g. reveal what it thinks is the domain, what it thinks is the >>> user to be validated. Is there anything like that? Currently all >>> I know is that one doesn't work, without any indication of what >>> is being done internally and hence resulting in the failure. Is >>> there anything really useful like that? >> >> The debug logging will show the working of the guts, but it will >> take someone like Viktor or me to make sense of the gibberish. > > _______________________________________________ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
