On 12/23/2016 04:29 PM, John Fawcett wrote: > On 12/23/2016 03:56 PM, G. Schlisio wrote: >>> It was worth checking the obvious to exclude it. >>> >>> I suspect that one of the system libraries used by the .forward >>> mechanism has been impacted by your upgrade. >>> >>> If you don't need to use .forward files you might try setting >>> >>> forward_path = >>> >>> in main.cf and restart postfix. If that solves it, then there is >>> something wrong outside postfix. >>> >>> John >> YAY, that fixed it. sendmail -bv reports delivery to dovecot. >> >> what was the exact error then and how can i avoid this in the future? >> just point me to the topics to read, so i dont eat more of your time >> helping other people with mailing problems or preparing christmas or >> whatever. your fast and precise help is very much appreciated! >> >> best regards >> georg > I'm glad it worked. It's a workaround rather than a solution. For people > that need .forward files, it won't work at all. > > There is a priority that local follows, you can read it here: > > http://www.postfix.org/postconf.5.html#mailbox_transport_maps > > My guess was that there was a lookup failure happening in the .forward > routines so you never got to the mailbox_transport_maps. By setting > forward_path to empty then you are skipping the .forward routines > altogether. > > The real problem is happening in the glibc routine getpwnam_r > > http://man7.org/linux/man-pages/man3/getpwnam_r.3.html > > For users not found in the passwd file postfix expects that this > function should return 0, but it is returning an error code. I think the > confusion arises because the original POSIX specification did not > specifically define all the return values that could be acceptable for > not found. It would be interesting to see if something in your upgrade > has changed the way this function is working. > > 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
