fallback_transport is ignored because src/local/{dotforward,mailbox}.c will get an error from mypwnam_err for unknown users. postfix interprets this as an transient error and puts the message to the deferred queue. For unknown users a return value of 0 seems to be expected. This used to work for us.
Error message from /var/log/maillog: Jan 17 09:57:34 mailbox postfix/local[27760]: warning: error looking up passwd info for anote: Result too large
I'm not sure at the moment, but looking into the code of src/global/mypwd.c, it seems the error message "Result too large" is an error returned from getpwnam_r(3), see man errno(2) code 34. Perhaps you could also do a "postmap -q ..." lookup for the user "anote" to verify if the same error is returned. Since there was no change in the related files between 2.4.0 and 2.4.4 it would be from interest what was the last working postfix version and where are the transports for the users defined, additional some details (uid) of the user "anote"
anote is not a user: getent passwd anote; echo $? 2 Our nsswitch.conf: passwd: files cache [success=return] ldap The following small test program (copy/pasted from https://bugzilla.redhat.com/show_bug.cgi?id=988068) shows that the error actually seems to somewhere in getpwnam_r or library routines supporting it. According to the documentation getpwnam_r should return 0 and set the result pointer to NULL when the user does not exist. cat >getpwnamtst.c <<EOF #include <sys/types.h> #include <pwd.h> #include <stdio.h> int main(int argc, char* argv[]) { struct passwd pwd; char buf[4096]; int err; struct passwd *res; err = getpwnam_r(argv[1], &pwd, buf, 4096, &res); printf("<%s> err: <%d>\n", argv[1], err); return 0; } EOF cc -o getpwnamtst getpwnamtst.c getpwnamtst anote ./getpwnam anote <anote> err: <34> But sometimes I get: ./getpwnam anote <anote> err: <0> So getpwnam sometimes returns fail and sometimes success for the same (non existant) user? The pr should probably get reassigned to basesystem. Matthias
reset Assignee
I'm pretty sure that this is a duplicate of 248932, which is fixed. Feel free to reopen if you can still reproduce this bug on a current release. *** This bug has been marked as a duplicate of bug 248932 ***