2

In postfix I'm trying to setup a catch-all address for unknown local accounts. Any mail that can be delivered to a local user should be delivered to their local mailbox (and respect any aliases in /etc/aliases, both for local aliases as well as aliases that forward mail to the outside). Any mail for a user that does not exist in /etc/aliases or /etc/passwd should be redirected to root. For root I've setup an alias in /etc/aliases to redirect to a separate mail address admin@companydomain.com (not on the local server).

To achive this I've set in main.cf:

luser_relay = root
local_recipient_maps =

Other settings I have tried for luser_relay are:

admin@companydomain.com
root@localhost
root@localhost.localdomain
root@--server hostname--
root@$local
--other user with no alias--
--other user with no alias--@localhost
--other user with no alias--@localhost.localdomain
--other user with no alias--@--server hostname--
--other user with no alias--@$local

But I keep getting a user lookup error (when sending a mail to a non-existing test user with mail -s test test):

Jan  4 14:08:03 test postfix/pickup[28595]: A4E3382454: uid=--uid-- from=<--local user-->
Jan  4 14:08:03 test postfix/cleanup[29192]: A4E3382454: message-id=<20150104140803.A4E3382454@--server hostname-->
Jan  4 14:08:03 test postfix/qmgr[28596]: A4E3382454: from=<--local user--@--server hostname-->, size=456, nrcpt=1 (queue active)
Jan  4 14:08:03 test postfix/local[29194]: warning: error looking up passwd info for test: No such file or directory
Jan  4 14:08:03 test postfix/local[29194]: A4E3382454: to=<test@--server hostname-->, orig_to=<test>, relay=local, delay=0.02, delays=0.01/0/0/0, dsn=4.0.0, status=deferred (user lookup error)

If there's a solution in which the catch-all address is set admin@companydomain.com that's fine, but I'd prefer it to be redirected to root and honor /etc/aliaseses so that when I need to change admin@companydomain.com I only have to do it in /etc/aliases and not also in another postfix configuration file.

My postfix version is 2.10.1 (CentOS 7) and besides the above luser_relay and local_recipient_maps I've added a recipient_bcc_maps and transport_maps.

Perhaps my transport map interferes with luser_relay?

/.*@localhost(\.localdomain)?$/  local:
/.*@--the server's hostname--/   local:
/.*@--company domain--           relay:
/.*/                             discard:

The purpose of the transport map is to deliver any local mail, allow mail to be sent to the company domain, but discard any other mails. The recipient_bcc_maps is setup to bcc all mails discarded in the transport map to a debug address. Also the alias for root in /etc/aliases falls in the --other domain to not discard--. Since this concerns a development server I want any local mail to be delivered as such, and also deliver any mail addressed to the company domain, but prevent any other mail from being sent to the outside world.

The output of postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
html_directory = no
inet_interfaces = localhost
inet_protocols = all
local_recipient_maps =
luser_relay = root
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost.$mydomain, localhost
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
transport_maps = pcre:/etc/postfix/transport
unknown_local_recipient_reject_code = 550

Anybody who can spot the error in my configuration?

Thank you!

masegaloeh
  • 18,236
  • 10
  • 57
  • 106
SunMar
  • 71
  • 1
  • 6
  • Also I'm trying to reproduce your postfix setup (and its problem) to my VM. It fails or I can't reproduce error message *error looking up passwd info for test: No such file or directory*. The message goes forwarded smoothly – masegaloeh Jan 05 '15 at 07:32
  • Mails sent to root are succesfully delivered to the outside aliases setup in /etc/aliases, so there seems to be no issue there. Weird that you can't reproduce it. Also when I remove the weird part of the configuration (by commenting out the recipient_bcc_maps and transport_maps from main.cf and removing the alias in /etc/aliases to revert it back to its default configuration) I still get the user lookup error with "No such file or directory". So it doesn't look like that part of my configuration is causing the problem. – SunMar Jan 06 '15 at 01:09
  • Looks like your problem related when *postfix can't find user*. [This thread on postfix mailing list](http://postfix.1071664.n5.nabble.com/user-lookup-error-td52867.html) suggest that the problem likely from the OS itself. Did you have any other user authentication method beside the `/etc/passwd` file? – masegaloeh Jan 06 '15 at 08:09
  • No, I don't use LDAP or some database backend. Only local users in `/etc/passwd`. I tried `sendmail -bv test` and it returns `Mail Delivery Status Report will be mailed to .` which is correct. So it seems the `mail` command is using a different route than `sendmail`. – SunMar Jan 06 '15 at 13:56
  • try to debug postfix with the step http://www.postfix.org/DEBUG_README.html#debug_peer – masegaloeh Jan 06 '15 at 14:01
  • Hmm, increasing verbosity in the logs (by using debug_peer_level and adding -v -v in master.cf) does not really give more information to go on. Just did `sendmail -bv test` with another user and then it suddenly said it delivered to that user, so I think `sendmail` ends up telling where the delivery failed mail is sent to, not the actual mail going out. When doing `sendmail -bv test` I still see the same error in maillog. I'm going to look into the debugging options more see if there's anything useful there. Thank you for the suggestions so far! – SunMar Jan 06 '15 at 14:35

1 Answers1

4

It took a long while but I've finally been able to find out the issue. It's in the NSS configuration /etc/nsswitch.conf. My Rackspace Cloud Server had the yum package sssd-client installed by default, and /etc/nsswitch.conf has default entries for passwd and other files to use sss.

Basically if you have the default /etc/nsswitch.conf and install the sssd-client package the No such file or directory issue will occur on CentOS 7. That's because it tries to look for /var/lib/sss/mc/passwd (eventually figured this out with the help of an strace which was also a big hassle to get working properly). But that file does not exist when you haven't setup sssd. I've tested this by downloading the CentOS 7 DVD from the CentOS website and installing a minimal installation in a VM. Next I added luser_relay to the Postfix configuration which worked fine, then all I did was install sssd-client and it "magically" stopped working.

Fix 1: Remove sss from /etc/nsswitch.conf.

You'll see a line like:

passwd: files sss

Change that to:

passwd: files

By default sss is also enabled for shadow, group, services and netgroup, you should remove it for those as well to prevent issues there when libnss tries to access them.

Fix 2: Remove the sssd-client package.

Removing the sssd-client package also fixes the issue, I guess because without a client libnss ignores the sss directive in /etc/nsswitch.conf. If you don't need it you might as well remove it with yum remove sssd-client.

SunMar
  • 71
  • 1
  • 6