[arch-general] Postfix delivery problem
Dear list,
We have a mail server with postfix and dovecot where we have mail
addresses with local unix accounts (authenticated by pam) and without
unix accounts (dovecot passwd-file authentication). The problem only
affects those non-unix account mail addresses. (There are also
completely virtual email addresses with different domains, also managed
by dovecot, but still working fine, for simplicity ignored here; sorry
the config is really complicated).
All non-unix-account addresses are listed in a postfix table,
configured in main.cf by:
mailbox_transport_maps = hash:/etc/postfix/mailbox_transport_maps
looking like this:
user1 dovecot
user2 dovecot
All this was working fine, before yesterdays (rather big)
system-upgrade.
Now we get the following error in the mail logs:
On Fri, Dec 23, 2016 at 03:18:13AM +0100, G. Schlisio wrote:
It seems like postfix/local is ignoring the mailbox_transport_maps option and trying to deliver itself instead of passing to dovecot, thus finding no entry in the system passwd. After full upgrade config files were merged (no changes in mail config) and a reboot was done. The list of upgraded packages is shown at http://termbin.com/k5ql . As downgrading postfix, dovecot and icu (linking) did not resolve this issue, we are very confused.
I don't have any specific advice for you about mailbox_transport_maps, but I'm on postfix-3.1.3-2 and using an aliases file to route addresses that do not map to local accounts to addresses that do have local accounts, and that still seems to work (I just tested it to be sure). Also your log statements end at the .forward lookup, which is supposed to happen before mailbox_transport_maps, so I think the .forward "couldn't find user" line is a red herring and any mailbox_transport_maps processing would happen after that. From the postconf(5) man page: -- The precedence of local(8) delivery features from high to low is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, mailbox_command_maps, mailbox_command, home_mailbox, mail_spool_direc‐ tory, fallback_transport_maps, fallback_transport and luser_relay. -- Maybe you could share the full verbose output of a single invocation of local? The fact that you rolled back to a previous postfix (that presumably worked) and are still having the issue seems fishy to me, and kinda implies that the likely culprit here is that something in your configuration merge messed up your config files. If you saved your old config files, I'd do a diff and see what's different. Maybe something is overwriting the mailbox_command_maps value after you've set it, or maybe there's a parse error somewhere that's preventing postfix from ever reaching where you set mailbox_command maps. You might also reach out to the postfix mailing lists for help, as you'll likely get better debugging tips for scenarios like this than from a distribution-specific list. Cheers, Jeremy
You might also reach out to the postfix mailing lists for help, as you'll likely get better debugging tips for scenarios like this than from a distribution-specific list.
hi jeremy, thank you for your ideas, i took it to the postfix mailing lists now, but progress there is slow as well. the problem seem to hide very well. link to thread included for future reference [0]. have a nice christmas everyone georg [0] https://marc.info/?l=postfix-users&m=148248292712509&w=2
i took it to the postfix mailing lists now
hi all, there is a workaround in place for now, which is disabling .fordward completely by setting an empty forward_path. the cause of the problem seems to be a non-POSIX behaviour of glibcs getpwnam_r() function. a more lengthy discussion can be found here [0]. i am not aware of any changes to glibc (2.24-2 from core installed here since august), but maybe someone has a hint what caused this behaviour to change? now that a workaround is in place this becomes less urgent though, still it would be nice to understand what actually happened. regards georg [0] http://postfix.1071664.n5.nabble.com/user-lookup-error-td52867.html
participants (2)
-
G. Schlisio
-
Jeremy Brown