Postfix root aliases not working
I'm fighting with Postix and I don't want let it win…
I've installed Postfix and made it work with my GoogeApps account. Just work fine, I can send emails. Excepted for when it comes to root to forward its emails to my GA email account, which is what I need.
I've read many posts about it, but still I can't find my mistake.
Any fresh eyes to look at my below config and advice me?
So, I set up the aliases file:
# /etc/aliases
MAILER-DAEMON: postmaster
postmaster: root
root: myUser@exemple.com
I've also tried:
root: myLocaluserAccount
mailer-daemon: postmaster
postmaster: root
I then did the usual newaliases command and reloaded Postfix.
None work. Root don't use the email aliase I provide him.
So I've cheched if the aliase for root is well registered:
# postmap -q root hash:/etc/aliases
and it's fine, gives me my correct email,
Sending an email to root for test, I get the following:
# echo test | /usr/sbin/sendmail -f anmailaddress root
# tail /var/log/mail.log
Apr 23 15:04:38 exemple postfix/master[3766]: reload -- version 2.6.5, configuration /etc/postfix
Apr 23 15:05:23 exemple postfix/pickup[6686]: 000636445: uid=1000 from= <autre>Apr 23 15:05:23 exemple postfix/cleanup[6690]: 000636445: message-id=<20100423130523.000636445@ exemple>
Apr 23 15:05:23 exemple postfix/qmgr[6685]: 000636445: from=<anmailaddress@exemple.com>, size=278, nrcpt=1 (queue active)
Apr 23 15:05:23 exemple postfix/tlsmgr[6693]: warning: request to update table btree:/var/run/smtpd_tls_session_cache in non-postfix directory /var/run
Apr 23 15:05:23 exemple postfix/tlsmgr[6693]: warning: redirecting the request to postfix-owned data_directory /var/lib/postfix
Apr 23 15:05:23 exemple postfix/tlsmgr[6693]: warning: request to update table btree:/var/run/smtp_tls_session_cache in non-postfix directory /var/run
Apr 23 15:05:23 exemple postfix/tlsmgr[6693]: warning: redirecting the request to postfix-owned data_directory /var/lib/postfix
Apr 23 15:05:25 exemple postfix/smtp[6692]: 000636445: to=<root@ exemple.com="">, orig_to=<root>, relay=smtp.gmail.com[209.85.229.109]:587, delay=2.1, delays=0.02/0.03/0.87/1.2, dsn=2.0.0, status=sent (250 2.0.0 OK 1272027925 r29sm285659wbv.3)
Apr 23 15:05:25 exemple postfix/qmgr[6685]: 000636445: removed</root></root@></anmailaddress@exemple.com></autre>
Looking at how home_mail box is configure I get:
# sudo postconf | grep -E 'spool|mailbox'
home_mailbox =
mail_spool_directory = /var/mail
mailbox_command =
mailbox_command_maps =
mailbox_delivery_lock = fcntl, dotlock
mailbox_size_limit = 0
mailbox_transport =
mailbox_transport_maps =
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps
queue_directory = /var/spool/postfix
strict_mailbox_ownership = yes
unknown_virtual_mailbox_reject_code = 550
virtual_mailbox_base =
virtual_mailbox_domains = $virtual_mailbox_maps
virtual_mailbox_limit = 51200000
virtual_mailbox_lock = fcntl, dotlock
virtual_mailbox_maps =
My postfix main.cf seems to be set correctly, but… :
# /etc/postfix/main.ch
smtpd_banner = ' '
biff = no
append_dot_mydomain = no
readme_directory = no
# TLS parameters
## TLS Settings
#
# For Google Apps
smtp_tls_CAfile = /etc/postfix/certif/cacert.pem
smtp_tls_cert_file = /etc/postfix/certif/Google-Mail-humanoise-cert.pem
smtp_tls_key_file = /etc/postfix/certif/Google-Mail-humanoise-key.pem
smtp_tls_session_cache_database = btree:/var/run/smtp_tls_session_cache
smtp_use_tls = yes
smtpd_tls_CAfile = /etc/postfix/certif/cacert.pem
smtpd_tls_cert_file = /etc/postfix/certif/Google-Mail-exemple-cert.pem
smtpd_tls_key_file = /etc/postfix/certif/Google-Mail-exemple-key.pem
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:/var/run/smtpd_tls_session_cache
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
## SASL Settings
# This is going in to THIS server
smtpd_sasl_auth_enable = no
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtpd_sasl_local_domain = $myhostname
smtp_sasl_security_options = noanonymous
#smtp_sasl_security_options =
smtp_sasl_tls_security_options = noanonymous
smtpd_sasl_application_name = smtpd
#Forward all mail to the mail server that is responsible for the "example.com" domain.
relayhost = [smtp.gmail.com]:587
transport_maps = hash:/etc/postfix/transport
myhostname = exemple
mydomain = exemple.com
myorigin = /etc/mailname
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, $mydomain, localhost.$mydomain,www.$mydomain, ssl.$mydomain, localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 109.74.204.98
mailbox_size_limit = 0
recipient_delimiter = +
inet_protocols = all
html_directory = no
notify_classes = resource, software, protocol
soft_bounce = no
inet_interfaces = loopback-only
Any ideas, what I I'm missing?
Thanks for your input
16 Replies
GooleApps receive it from root account.
Delivery to the following recipient failed permanently:
root@exemple.com
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 i57si1895232wej.17 (state 14).
----- Original message -----
the message
You might be able to find what you want in here:
@sleddog:
It is my understanding that mail that is generated on the server and addressed simply to "root" (not "
root@domain.com ") will be delivered locally. Delivering a local message to "root" is different than dispatching an email toroot@domain.com .
I think postfix appends the domain before it does anything else. From the Address Rewriting doc I referenced above:
> Rewrite addresses to standard form
Before the cleanup(8) daemon runs an address through any address mapping lookup table, it first rewrites the address to the standard "
user@fully.qualified.domain " form, by sending the address to the trivial-rewrite(8) daemon. The purpose of rewriting to standard form is to reduce the number of entries needed in lookup tables.The Postfix trivial-rewrite(8) daemon implements the following hard-coded address manipulations:
(snip)
Rewrite "user" to "user@$myorigin"
This feature is controlled by the boolean appendatmyorigin parameter (default: yes). You should never turn off this feature, because a lot of Postfix components expect that all addresses have the form "user@domain".
If your machine is not the main machine for $myorigin and you wish to have some users delivered locally without going via that main machine, make an entry in the virtual alias table that redirects "user@$myorigin" to "user@$myhostname". See also the "delivering some users locally" section in the STANDARDCONFIGURATIONREADME document.
This is why I receive an email at
Looking at the doc you point me out I'm not clear about what would be the way to send an other user. Thus at this stage the mail goes to ***root***@exemple.com and I would need myuser@exemple.com. Therefore virtual email domain or canonical wouldn't help. Am I right? If so, what else could it be tried?
@Stever:
I think postfix appends the domain before it does anything else.
This is true. But I think what what happens after that will depend on the server's hostname, the Postfix myhostname setting, and probably the content of /etc/hosts.
For example I have a local dev box…
hostname: sun.mydomain.ca
Postfix config:
myhostname = sun.mydomain.ca
relayhost = [smtp.myISP.com]
/etc/hosts:
192.168.0.10 sun.mydomain.ca sun
If I send a command-line message to "root" it is expanded to "
Apr 23 14:18:53 sun postfix/pickup[15495]: 9854CE10072: uid=0 from= <root>Apr 23 14:18:53 sun postfix/cleanup[15527]: 9854CE10072: message-id=<20100423164853.9854CE10072@sun.mydomain.ca>
Apr 23 14:18:53 sun postfix/qmgr[16298]: 9854CE10072: from=<root@sun.mydomain.ca>, size=321, nrcpt=1 (queue active)
Apr 23 14:18:53 sun postfix/local[15529]: 9854CE10072: to=<root@sun.mydomain.ca>, orig_to=<root>, relay=local, delay=0.05, delays=0.03/0.01/0/0.02, dsn=2.0.0, status=sent (delivered to maildir)
Apr 23 14:18:53 sun postfix/qmgr[16298]: 9854CE10072: removed</root></root@sun.mydomain.ca></root@sun.mydomain.ca></root>
If I send a command-line message to "
So what you suggest is it to created a Virtual email host exemple.com?
@jollyjumper:
I see. so the durty fix is the create a
root@exemple.com , but this is what I wanted to avoid, because spam and the potential risk…So what you suggest is it to created a Virtual email host exemple.com?
No. I apologize if I've confused things. Here's what I suggest you do:
First, undo any changes to /etc/alias and run newaliases, so it is back to the default. Then…
1. Assign your Linode a unique, fully-qualified domain name (FQDN).
For example, if your domain is "example.com", you might use "server1.example.com" as your FQDN. It must be unique, not used anywhere else.
2. Setup DNS for your FQDN.
In the Linode DNS Manager (or wherever you manage DNS for your domain) create an A record for server1.example.com.
Give it an appropriate amount of time to take effect then check it with a DNS lookup, e.g.,
[me@server1] host server1.example.com
…Should return your Linode's IP.
3. Setup reverse DNS for your Linode's IP.
You do this in the Linode Manager ("Network" tab).
Give it an appropriate amount of time to take effect then check it. e.g., if your Linode IP is 192.168.1.1:
[me@server1] host 192.168.1.1
…Should return your FQDN (server1.example.com).
4. Set your hostname in Postfix.
Edit /etc/postfix/main.cf and find the "myhostname" setting. Set it to:
myhostname = server1.example.com
Restart Postfix.
5. Create a .forward file that redirects root's email to someone else. For example, as root make sure you're in root's home directory (/root) and do:
[root@server1 ~] echo
Now, local mail destined for "root" will be sent by Postfix to
When Gmail receives the message it will do a DNS lookup on the sending mailserver – server1.example.com -- and find a good A record. It might do a reverse DNS lookup on the IP -- and find that it reverse-resolves correctly to server1.example.com.
Then -- provided the message doesn't trigger some other spam-filter -- Gmail will accept the message and deliver it to
This works for me…
When you say:
> 3. Setup reverse DNS for your Linode's IP.
You do this in the Linode Manager ("Network" tab).
Give it an appropriate amount of time to take effect then check it. e.g., if your Linode IP is 192.168.1.1:
[me@server1] host 192.168.1.1
…Should return your FQDN (server1.example.com)
does it mean Linode manager can only have one rDNS per IP?
host email.exemple.com now send me myLinodeIP, perfect.
So at this stage I'm only waiting for host myLinodeIP to send me the new rDNS, still sending the old linode rDNS.
All mail sent from your Linode server is identified by your FQDN -- server1.example.com
You might host 20 different domains on your Linode, but still all mail is identified as coming from your FQDN - server1.example.com.
So you ensure that reverse DNS for server1.example.com is set to your Linode's IP.
Learning thanks to your DNS expertise, just discoverd there are only 13 root servers worlwide.
> The domain name system is a distributed database that translates names into ip addresses. When an update occours, it is possible to have non syncronized records across the internet. This tool shows you all the process of name resolving, starting from root server
If you want to try:
So rDNS work fine!
But… I still have the same error
So I've started investigated differently. Maybe you have an idea?
To summurise:
The email sending the error says /bin/sh: root: not found:
Subject: Cron <root@exemple> root clamscan -R /var/www
Content-Type: text/plain; charset=ANSI_X3.4-1968
X-Cron-Env: <shell= bin="" sh="">
X-Cron-Env: <home= root="">
X-Cron-Env: <path= usr="" bin:="" bin="">
X-Cron-Env: <logname=root>
Message-Id: <20100426230201.939EA6446@server.exemple.com>
Date: Tue, 27 Apr 2010 01:02:01 +0200 (CEST)
/bin/sh: root: not found</logname=root></path=></home=></shell=></root@exemple>
So I went to see if the symlink to what root shell points is correct and then check valide login shells:
#cat /etc/passwd | grep $USER
root:x:0:0:root:/root:/bin/bash
#cat /etc/shells
# /etc/shells: valid login shells
/bin/csh
/bin/sh
/usr/bin/es
/usr/bin/ksh
/bin/ksh
/usr/bin/rc
/usr/bin/tcsh
/bin/tcsh
/usr/bin/esh
/bin/dash
/bin/bash
/bin/rbash
That seems to be ok, but just to be sure:
# ls -l /bin/*sh
-rwxr-xr-x 1 root root 875596 Sep 14 2009 /bin/bash
-rwxr-xr-x 1 root root 92132 Sep 21 2009 /bin/dash
lrwxrwxrwx 1 root root 4 Oct 30 18:57 /bin/rbash -> bash
lrwxrwxrwx 1 root root 4 Oct 30 18:57 /bin/sh -> dash
Let's now see Cron
#crontab -e
02 1 * * * root clamscan -R /var/www
02 2 * * * root clamscan -R /srv/www/
I don't see anything really wrong but maybe you do…
thanks
> /bin/sh:
- this is the originator of the message; a shell that was called through the literal name /bin/sh command tells you that
> root:
this command
> not found
doesn't exist in $PATH.
> 02 1 * * * root clamscan -R /var/www
The "username" field exists only in the systemwide crontab (/etc/crontab, /etc/cron.d/*), and this is most probably user's personal crontab, that always executes as him. Thus, cron interprets the word "root" as the first word of command line.
If clamscan needs to be ran as root, move the lines to /etc/crontab.
If he can run as the user that you're currently operating as, remove "root " from the lines.
Again thanks for all your time and knowledge sharing. I give you 5 stars + bonus *@