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
