Postfix root aliases not working

Hi Linoders,

I'm fighting with Postix and I don't want let it win… :lol:

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: [email protected]

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, [email protected].

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=<[email protected] exemple>
Apr 23 15:05:23 exemple postfix/qmgr[6685]: 000636445: from=<[email protected]>, 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=<[email protected] 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></[email protected]></[email protected]></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

Well, all I do is drop a .forward file containing my email address into root's home directory.

Thanks for your feedback. I've tried without big success. I keep on receiving same kind of error messages.

GooleApps receive it from root account.

Delivery to the following recipient failed permanently:

     [email protected]

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

/etc/aliases only applies to mail that reaches the local delivery agent. Since you are relaying all your mail to google, those mails never get seen by the LDA.

You might be able to find what you want in here:

http://www.postfix.org/ADDRESSREWRITINGREADME.html

It is my understanding that mail that is generated on the server and addressed simply to "root" (not "[email protected]") will be delivered locally. Delivering a local message to "root" is different than dispatching an email to [email protected].

@sleddog:

It is my understanding that mail that is generated on the server and addressed simply to "root" (not "[email protected]") will be delivered locally. Delivering a local message to "root" is different than dispatching an email to [email protected].

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 "[email protected]" 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 "[email protected]$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 "[email protected]".

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 "[email protected]$myorigin" to "[email protected]$myhostname". See also the "delivering some users locally" section in the STANDARDCONFIGURATIONREADME document.

Thanks for the feedbacks.

This is why I receive an email at [email protected]

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 "[email protected]" and it is delivered locally. By "locally" I mean it is delivered to root's mail without invoking an SMTP process:

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=<[email protected]>
Apr 23 14:18:53 sun postfix/qmgr[16298]: 9854CE10072: from=<[email protected]>, size=321, nrcpt=1 (queue active)
Apr 23 14:18:53 sun postfix/local[15529]: 9854CE10072: to=<[email protected]>, 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></[email protected]></[email protected]></root> 

If I send a command-line message to "[email protected]" then Postfix relays the message to my ISP's mailserver, which attempts to deliver it to mydomain.ca (where it bounces, as [email protected] is not a valid address).

I see. so the durty fix is the create a [email protected], 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?

(when I say create [email protected] mean a root email account at GoogleApps level)

@jollyjumper:

I see. so the durty fix is the create a [email protected], 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.,

[[email protected]] 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:

[[email protected]] 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:

[[email protected] ~] echo [email protected] > .forward

Now, local mail destined for "root" will be sent by Postfix to [email protected].

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 [email protected]

This works for me… :)

Fantastic Sledog. What a complete description, very clear, thanks for your time.

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:

[[email protected]] 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.

Yes, there should be just just one reverse DNS – to your FQDN.

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.

Thanks

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:

http://www.dnsqueries.com/en/dns_traversal.php

Hi Sleddog,

So rDNS work fine!

But… I still have the same error :cry:

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 <[email protected]> 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: <[email protected]>
Date: Tue, 27 Apr 2010 01:02:01 +0200 (CEST)

/bin/sh: root: not found</logname=root></path=></home=></shell=></[email protected]>

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.

I got it!

Again thanks for all your time and knowledge sharing. I give you 5 stars + bonus *@

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct