2

I have a CentOS 6.5 server running Postfix 2.6x (the default distribution) with five public IPv4 IPs bound to it. Each IP has DNS and rDNS set separately. Each uses a different hostname at a different domain. I have five Postfix instances, one bound to each IP, like this example:

  • 192.168.34.104 red.example.com /etc/postfix
  • 192.168.36.48 green.example.net /etc/postfix-green
  • 192.168.36.49 pink.example.org /etc/postfix-pink
  • 192.168.36.50 orange.example.info /etc/postfix-orange
  • 192.168.36.51 blue.example.us /etc/postfix-blue

I've tested each IP by telneting to port 25. Postfix answers and banners properly with the correct hostname. Email is received on all of these instances with no problems and is routed to the correct place. This setup, minus the final instance, has existed for a couple of years and works.

I never bothered to set up outbound email to go through any but the main instance, however; there was no need. Now I need to send email from blue.example.us that actually leaves from that interface and IP, such that the Received headers show blue.example.us as the sending mailhost, so that SPF and DKIM validate, etc etc.

The email that will be sent from blue.example.com is a feedback loop sent by a single shell account on the server (account5), an account that is dedicated to sending this email. The account receives the feedback loop emails from servers on other networks, saves the bodies of those emails, and then generates a new outbound email header, appends the saved body, and sends the email. It's sending by piping each email to sendmail -oi -t. We're doing it this way to mask the identities of the initial servers. The procmail script that processes these emails works correctly.

However, I cannot configure this account to send email through the proper Postfix instance/IP/interface. The exact same account and script sends email through the main Postfix instance /etc/postfix without any issues. When I change MAIL_CONFIG to point to /etc/postfix-blue in either .bash_profile or the Procmail script that handles this email, though, I get this error:

sendmail: fatal: User account5(###) is not allowed to submit mail

I've read the manuals on Postfix.org, searched Google, and tried the suggestions in three previous answers here on ServerFault.com:

Postfix - specify interface to deliver outbound mail on

Postfix user is not allowed to submit mail

Postfix rejects php mails

I have been careful to stop and restart Postfix after each configuration change, and tested the results. Nothing has worked. The main postfix instance happily accepts outbound email from account5. The postfix-blue instance continues to reject email from account5 with the sendmail error above.

As tempting as it is to blame machine hostility, I know that I must be missing something or doing something wrong. Does anybody have any suggestions as to what it might be? Please feel free to ask for further information about my setup if you need it.

=-=-=-=-=-=-=-=-=-=

At the request of the responder, here are main.cf and master.cf for a) the main postfix instance ("red.example.com") and b) the FBL instance ("blue.example.us")

[NOTE: All parameters not specified below were left at the default Postfix 2.6 settings]

MAIN:

master.cf

smtp      inet  n       -       n       -       -       smtpd

main.cf

myhostname = red.example.com
mydomain = example.com
inet_interfaces = $myhostname, localhost
inet_protocols = all
lmtp_host_lookup = native
smtp_host_lookup = native
ignore_mx_lookup_error = yes
mydestination = $myhostname, localhost.$mydomain, localhost
local_recipient_maps =
mynetworks = 192.168.34.104/32
relay_domains = example.com,
            example.info,
            example.net,
            example.org,
            example.us
relayhost = [192.168.34.102] # Separate physical server, main mailserver.
relay_recipient_maps = hash:/etc/postfix/relay_recipients
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
smtpd_banner = $myhostname ESMTP $mail_name
multi_instance_wrapper = ${command_directory}/postmulti -p --
multi_instance_enable = yes
multi_instance_directories = /etc/postfix-green /etc/postfix-pink /etc/postfix-orange /etc/postfix-blue

FBL:

master.cf

184.173.119.103:25      inet  n       -       n       -       -       smtpd

main.cf

myhostname = blue.example.us
mydomain = blue.example.us <= Deliberately set to subdomain only.
myorigin = $mydomain
inet_interfaces = $myhostname
lmtp_host_lookup = native
smtp_host_lookup = native
ignore_mx_lookup_error = yes
mydestination = $myhostname
local_recipient_maps  = unix:passwd.byname $alias_maps $virtual_alias_maps
mynetworks = 192.168.36.51/32, 192.168.35.20/31 <= Second IP is backup MX servers
relay_domains = $mydestination
recipient_canonical_maps = hash:/etc/postfix-blue/canonical
virtual_alias_maps = hash:/etc/postfix-fbl/virtual
alias_maps = hash:/etc/aliases, hash:/etc/postfix-blue/canonical
alias_maps = hash:/etc/aliases, hash:/etc/postfix-blue/canonical
mailbox_command = /usr/bin/procmail -a "$EXTENSION" DEFAULT=$HOME/Mail/ MAILDIR=$HOME/Mail
smtpd_banner = $myhostname ESMTP $mail_name
authorized_submit_users = 
multi_instance_name = postfix-blue
multi_instance_enable = yes

** Additional Information after testing Masegaloeh's latest suggestion **

I just tried adding "account5" to authorized_submit_users, and setting MAIL_CONFIG in .bash_profile for the "account5" shell account, with "export MAIL_CONFIG" also set. Procmail no longer complains; it thinks that it is properly generating and sending the FBL. However, maillog reports the following:

May 29 14:47:42 newton postfix-blue/qmgr[3522]: 5BC773E612F: from=<fbl@blue.example.us>, size=1106, nrcpt=1 (queue active)
May 29 14:47:42 newton postfix-blue/qmgr[3522]: warning: connect to transport private/smtp: Connection refused
May 29 14:47:42 newton postfix-blue/error[3766]: 5BC773E612F: to=<fbl-test@example.com>, relay=none, delay=0.01, delays=0/0/0/0, dsn=4.3.0, status=deferred (mail transport unavailable)

Do I need to add something to a transport configuration file, perhaps?

  • These secondary postfix instances, are they using different main.cf|master.cf configurations? Can you post the first one and the blue one? – NickW May 28 '14 at 15:59
  • Yes, definitely. That's why I mentioned the separate postfix directories, and that I'd checked by telneting to the IPs. I'll happily provide the files you ask about, but this comment window does not appear to have space. It's limited to about 500 characters. How should I do this? – Catherine Jefferson May 28 '14 at 16:43
  • @CatherineJefferson, you can edit your post and add the config there. By the way, did you mean account5 is sending via submission instead doing smtp transaction? – masegaloeh May 28 '14 at 17:10
  • It's sending by piping each email to "sendmail -oi -t". I'll edit the original post. – Catherine Jefferson May 28 '14 at 17:46
1

When you send email via local submission a.k.a sendmail it will use default instance e.g. red.example.com. This behavior was explained in postfix official documentation.

One Postfix instance is special: this is the instance whose configuration directory is the default one compiled into the Postfix utilities. The location of the default configuration directory is typically /etc/postfix, and can be queried via the "postconf -d config_directory" command. We call the instance with this configuration directory the "default instance".

The default instance is responsible for local mail submission. The setgid postdrop(1) utility is used by the sendmail(1) local submission program to spool messages into the maildrop sub-directory of the queue directory of the default instance.

Even in the rare case when "sendmail -C" is used to submit local mail into a non-default Postfix instance, for security reasons, postdrop(1) will consult the default main.cf file to check the validity of the requested non-default configuration directory.

So, while in most other respects, all instances are equal, the default instance is "more equal than others". You may choose to create additional instances, but you must have at least the default instance, with its configuration directory in the default compiled-in location.

Some suggestions:

  1. Based on above snippet, you could try to use sendmail -C to specify the instance to submit email. Or
  2. The other workaround is swap the the instance, e.g. red.example.com become blue.example.us and vice versa.

Edit based on comments below

sendmail: fatal: User account5(###) is not allowed to submit mail

The error above caused by authorized_submit_users parameter is blank (postfix-blue instance). The effect is nobody could execute sendmail via postfix-blue instance. Adding account5 to that parameter should solves the problem.

Another error

warning: connect to transport private/smtp: Connection refused

was caused by missing smtp transport in master.cf. Make sure this line present in master.cf

smtp      unix  -       -       n       -       -       smtp

and add -o smtp_bind_address=192.168.36.51 at the end of the line so email will send through address 192.168.36.51.

  • Unfortunately "sendmail -C" does not work -- I get the same error as with changing the MAIL_CONFIG directory. (I'd tried that, but didn't mention it earlier.) Swapping the instances would definitely not work; I don't want to mix the feedback loop with the rest of my mail streams. Is there a setting in the default main.cf file that would add the other config directory to the "allowed" list? – Catherine Jefferson May 29 '14 at 1:05
  • What do you mean allowed list? – masegaloeh May 29 '14 at 3:16
  • @masegaloeh she means this: serverfault.com/questions/574911/postfix-rejects-php-mails – NickW May 29 '14 at 8:29
  • @NickW if that is the case then OP can modify authorized_submit_users become account5 – masegaloeh May 29 '14 at 9:24
  • She's saying she's done that.. at least as far as I understand. – NickW May 29 '14 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.