Linode Forum
https://forum.linode.com/

Postfixroot aliases not working
https://forum.linode.com/viewtopic.php?f=11&t=5496		 Page 1 of 2
Author:  jollyjumper [ Fri Apr 23, 2010 9:58 am ]
Post subject:  Postfixroot 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:
Code:
# /etc/aliases
MAILER-DAEMON: postmaster
postmaster: root
root: myUser@exemple.com

I've also tried:
Code:
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, myUser@exemple.com.

Sending an email to root for test, I get the following:
Code:
# 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


Looking at how home_mail box is configure I get:
Code:
# 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... :
Code:
# /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
Author:  sleddog [ Fri Apr 23, 2010 10:04 am ]
Post subject: 
Well, all I do is drop a .forward file containing my email address into root's home directory.
Author:  jollyjumper [ Fri Apr 23, 2010 11:57 am ]
Post subject: 
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.
Code:
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
Author:  Stever [ Fri Apr 23, 2010 12:23 pm ]
Post subject: 
/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/ADDRESS_REWRITING_README.html
Author:  sleddog [ Fri Apr 23, 2010 12:32 pm ]
Post subject: 
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 to root@domain.com.
Author:  Stever [ Fri Apr 23, 2010 12:45 pm ]
Post subject: 
sleddog wrote:
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 to root@domain.com.


I think postfix appends the domain before it does anything else. From the Address Rewriting doc I referenced above:

Quote:
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 append_at_myorigin 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 STANDARD_CONFIGURATION_README document.
Author:  jollyjumper [ Fri Apr 23, 2010 1:12 pm ]
Post subject: 
Thanks for the feedbacks.
This is why I receive an email at root@exemple.com

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?
Author:  sleddog [ Fri Apr 23, 2010 1:21 pm ]
Post subject: 
Stever wrote:
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 "root@sun.mydomain.ca" and it is delivered locally. By "locally" I mean it is delivered to root's mail without invoking an SMTP process:

Code:
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


If I send a command-line message to "root@mydomain.ca" then Postfix relays the message to my ISP's mailserver, which attempts to deliver it to mydomain.ca (where it bounces, as root@mydomain.ca is not a valid address).
Author:  jollyjumper [ Fri Apr 23, 2010 1:49 pm ]
Post subject: 
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?
Author:  jollyjumper [ Fri Apr 23, 2010 1:52 pm ]
Post subject: 
(when I say create root@exemple.comI mean a root email account at GoogleApps level)
Author:  sleddog [ Fri Apr 23, 2010 4:13 pm ]
Post subject: 
jollyjumper wrote:
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 myName@gmail.com > .forward

Now, local mail destined for "root" will be sent by Postfix to myName@gmail.com.

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 myName@gmail.com

This works for me... :)
Author:  jollyjumper [ Fri Apr 23, 2010 8:05 pm ]
Post subject: 
Fantastic Sledog. What a complete description, very clear, thanks for your time.
When you say:
Quote:
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.
Author:  sleddog [ Fri Apr 23, 2010 8:17 pm ]
Post subject: 
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.
Author:  jollyjumper [ Fri Apr 23, 2010 9:00 pm ]
Post subject: 
Thanks

Learning thanks to your DNS expertise, just discoverd there are only 13 root servers worlwide.

Quote:
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
Author:  jollyjumper [ Tue Apr 27, 2010 6:04 am ]
Post subject: 
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:
Code:
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

So I went to see if the symlink to what root shell points is correct and then check valide login shells:
Code:
#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:
Code:
# 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
Code:
#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
Page 1 of 2 All times are UTC-04:00
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/