Re: [arch-general] Postfix delivery problem

2016-12-23 Thread G. Schlisio
> 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


Re: [arch-general] Postfix delivery problem

2016-12-23 Thread G. Schlisio
> 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=148248292712509=2


Re: [arch-general] Postfix delivery problem

2016-12-22 Thread Jeremy Brown
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