I recently came across a server where email sent (i.e. RCPT TO) from remote to ‘root@domain’ for any valid domain on the server would be accepted by postfix and forwarded to a remote address unless the domain explicitly had a root@ account defined. Long story short, the server was converted from qmail to Postfix and Plesk’s installer merged the old /var/qmail/alias/ alias files into the custom Plesk version of the Postfix aliases database. Additionally, Plesk stupidly sets up several aliases for all domains that deliver to local accounts, including root@, postmaster@ and mailer-daemon@. Read on to learn how to alter or remove those.
So here is a server forwarding email for a local account to a remote address. I thought that was kind of odd since I didn’t see any reason for that to be occurring. Postfix was set up with a default /etc/aliases file that has this:
# # Aliases in this file will NOT be expanded in the header from # Mail, but WILL be visible over networks or from /bin/mail. # # >>>>>>>>>> The program "newaliases" must be run after # >> NOTE >> this file is updated for any changes to # >>>>>>>>>> show through to sendmail. # # Basic system aliases -- these MUST be present. mailer-daemon: postmaster postmaster: root
Normally that would cause Postfix to allow an incoming email destined for just ‘root’ to be attempted, however, when you try to send such a message, it fails upon completion of the SMTP conversation because root typically has no mail directory for Postfix to actually delivery the message into:
telnet DOMAIN 25 Connected to DOMAIN. Escape character is '^]'. 220 DOMAIN ESMTP Postfix ehlo dude 250-PIPELINING 250-ETRN 250-STARTTLS 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from: <user@domain> 250 2.1.0 Ok rcpt to: root 250 2.1.5 Ok data 354 End data with . Subject: blah test . 550 5.7.1 Command rejected quit 221 2.0.0 Bye
The corresponding log entry in /usr/local/psa/var/log/maillog is:
Nov 7 11:56:27 /usr/lib64/plesk-9.0/psa-pc-remote[2465]: Incorrect recipient mailname : root Nov 7 11:56:27 /usr/lib64/plesk-9.0/psa-pc-remote[2465]: Message aborted.
So anyway, on this particular server, I found that the message was being accepted and then attempted for forwarding to a remote address. I thought that was fairly odd since I didn’t see anything connecting the two together until I saw this in the /etc/postfix/main.cf file:
alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases
The only file I could find in /var/spool/postfix/plesk/ that started with aliases was aliases.db. There is a command to convert it back to the original text format:
root@server:/var/spool/postfix/plesk# postmap -s aliases > aliases
So having run that, I found the cause of the server accepting email to root@<domain>:
_plesk_bounce_domain1.com "|/usr/lib64/plesk-9.0/bouncemessage This\\\ address\\\ no\\\ longer\\\ accepts\\\ mail." _plesk_bounce_domain1.com "|/usr/lib64/plesk-9.0/bouncemessage This\\\ address\\\ no\\\ longer\\\ accepts\\\ mail." postmaster support@remote_domain.com root support@remote_domain.com _plesk_bounce_domain3.com "|/usr/lib64/plesk-9.0/bouncemessage This\\\ address\\\ no\\\ longer\\\ accepts\\\ mail." _plesk_bounce_domain4.com "|/usr/lib64/plesk-9.0/bouncemessage This\\\ address\\\ no\\\ longer\\\ accepts\\\ mail." mailer-daemon support@remote_domain.com
The ones that start with _plesk… seem innocuous enough; those are just Plesk’s settings for domains where the setup is to accept a message and then bounce it back if the address doesn’t exist. Where did the others come from though? Turns out this server began life with Plesk having been installed with the qmail mail server instead of Postfix, and was later converted to Postfix. In qmail, there is traditionally an ~alias (most often /var/qmail/alias/) directory that holds .qmail forwarding files for local accounts you want to forward elsewhere. On this particular server, there was a /var/qmail/alias/.qmail-root, .qmail-postmaster and .qmail-mailer-daemon set to forward all three local addresses to a remote domain the server owner used for support requests. When the Plesk installer was used to convert the server from qmail to Postfix, it added the forwarding set up in those files to the alias database.
Why was the server also accepting email for root@ on any valid domain on the server? Turns out Plesk sets that up by default to forward to root@localhost.localdomain if there is not an explicitly defined root@ account on the domain in question. So no root = accept mail for root and send it to the local user account, and in this case the local user account forwarded elsewhere. You can see this setup via:
postmap -s /var/spool/postfix/plesk/virtual | grep root
After that qmail to postfix conversion was done, there was no way to know these aliases/forwards were there other than the steps we’ve gone through in this article, since there is no web interface to the contents of that alias database. The solution to get the server to stop forwarding root mail was to remove those lines from the aliases file, then run the following to recreate the aliases.db from your newly edited aliases file:
root@server:/var/spool/postfix/plesk# postmap hash:aliases postfix reload
What lead to this exercise to begin with? A moronic ‘security’ company called Trustkeeper considering the presence of an email account named root as being a ‘security’ risk. Their explanation of why it’s a risk was:
By confirming that “root@domain” and/or “postmaster@domain” are valid addresses is saying that any Spammers issuing mail using MAIL FROM:<> (hiding source address) have the ability to eat up the bandwidth with an overabundance of unsolicited messages.
Umm, no shit, you mean if a spammer knows an account exists, they can send it email and waste bandwidth? Their logic for calling this a security issues makes no sense whatsoever because nearly any ecommerce or business domain has a sales@ and support@ email address, so with that being the case, basically any business operating online has an inherent security risk (according to them) from having an email account that nearly any customer would expect to exist that they can spam. Fucking stupid.