Applicable to:
- Plesk for Linux
Symptoms
- Plesk Obsidian running on a Linux-based operating system
- Postfix accepts emails sent to mailboxes that do not exist for the domain in the Plesk GUI and forwards them to the Plesk admin mailbox
- The emails appear to be regular spam and result in entries that are similar to the following within the
/var/log/maillog:
Click to expandCONFIG_TEXT: Aug 20 08:32:44 server postfix/smtpd[1216681]: B479747251: client=unknown[203.0.113.2]
Aug 20 08:32:45 server psa-pc-remote[1923586]: B479747251: from=<random@spam.domain> to=<postmaster@example.org>
Aug 20 08:32:47 server postfix/cleanup[1213413]: B479747251: message-id=<a6d186a95dad7ea7842ab318ec6d272d1b414a94@spam.domain>
Aug 20 08:32:51 server psa-pc-remote[1923586]: B479747251: py-limit-out: stderr: INFO:__main__:No SMTP AUTH and not running in sendmail context (incoming or unrestricted outgoing mail). SKIP message.
Aug 20 08:32:51 server psa-pc-remote[1923586]: B479747251: py-limit-out: stderr: SKIP
Aug 20 08:32:53 server psa-pc-remote[1923586]: B479747251: spf: stderr: PASS
Aug 20 08:32:53 server psa-pc-remote[1923586]: B479747251: check-quota: stderr: SKIP
Aug 20 08:32:53 server postfix/qmgr[4119497]: B479747251: from=<random@spam.domain>, size=100187, nrcpt=1 (queue active)
Aug 20 08:32:53 server postfix/local[1228398]: B479747251: to=<postmaster@localhost.localdomain>, orig_to=<postmaster@example.org>, relay=local, delay=9.6, delays=9.6/0.01/0/0, dsn=2.0.0, status=sent (forwarded as 4D4A347253)
Aug 20 08:32:53 server postfix/qmgr[4119497]: B479747251: removed
...
Aug 20 08:32:53 server postfix/cleanup[1210532]: 4D4A347253: message-id=<a6d186a95dad7ea7842ab318ec6d272d1b414a94@random@spam.domain>
Aug 20 08:32:53 server postfix/local[1228398]: B479747251: to=<postmaster@localhost.localdomain>, orig_to=<postmaster@example.org>, relay=local, delay=9.6, delays=9.6/0.01/0/0, dsn=2.0.0, status=sent (forwarded as 4D4A347253)
Aug 20 08:32:53 server postfix/qmgr[4119497]: 4D4A347253: from=<random@spam.domain>, size=100675, nrcpt=1 (queue active)
Aug 20 08:32:53 server postfix/smtp[1228399]: 4D4A347253: to=<root@server.example.com>, orig_to=<postmaster@example.org>, relay=none, delay=0.01, delays=0/0.01/0/0, dsn=5.4.6, status=bounced (mail for server.example.com loops back to myself)
Aug 20 08:32:53 server postfix/bounce[1228400]: 4D4A347253: sender non-delivery notification: 5163147254
Aug 20 08:32:53 server postfix/qmgr[4119497]: 4D4A347253: removed -
When the mail service is enabled for a domain (i.e. example.org), the following email accounts are set up in Postfix by default:
CONFIG_TEXT: postmap -s /var/spool/postfix/plesk/virtual | grep @example.org
An email message sent to one of those default mailboxes (for example root@example.org) gets forwarded to root@localhost.localdomain and subsequently ends up in the mailbox of the email address that is set under the Plesk Administrator's Profile (pleskadmin@example.com for the purpose of this article)
anonymous@example.org anonymous@localhost.localdomain
drweb@example.org drweb@localhost.localdomain
kluser@example.org kluser@localhost.localdomain
postmaster@example.org postmaster@localhost.localdomain
root@example.org root@localhost.localdomain
mailer-daemon@example.org mailer-daemon@localhost.localdomain
Cause
By default, all emails sent to the default mailboxes go to root@localhost.localdomain, due to which they are forwarded to the designated Plesk Administrator email address pleskadmin@example.com:
CONFIG_TEXT: postmap -s /var/spool/postfix/plesk/aliases
drweb pleskadmin@example.com
kluser pleskadmin@example.com
postmaster pleskadmin@example.com
root pleskadmin@example.com
anonymous pleskadmin@example.com
drweb-daemon pleskadmin@example.com
mailer-daemon pleskadmin@example.com
mailman pleskadmin@example.com
These default mailboxes are present in all Postfix and Sendmail configurations as demanded by the RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES protocol. They serve as a way for security companies to contact the server administrator in case of legal claims, abuse reports, malicious content reports, etc.
If you'd like to adjust Plesk postfix aliases via Plesk GUI, consider voting for the following feature request: Add an option to disable reserved mailnames like root, postmaster, anonymous for domains – Your Ideas for Plesk.
The current behavior of default mailboxes will be reviewed as a product improvement #PPPM-14506. It will be addressed in future versions of Plesk and you may track the progress in the Change Log for Plesk Obsidian.
Resolution
Until the bug tied to this behavior is resolved, you may execute one of the following workarounds:
To make all emails sent to @localhost.localdomain default mailboxes stop getting delivered to your Plesk Administrator mailbox (pleskadmin@example.com in the example), you should do the following:
-
Log into the server via SSH
-
Open the
/etc/aliasesfile for editing with your favorite command-line text editor -
For example, in order to make emails delivered to the account root@localhost.localdomain get deleted instead of being delivered to pleskadmin@example.com, add the following line into the
/etc/aliasesfile:CONFIG_TEXT: root: /dev/null
- Save the changes and close the file
-
Apply the new settings via this command::
# postalias /etc/aliases
-
Verify that the setting is applied by running this command:
# postmap -s /etc/aliases | grep root
- Restart postfix
# systemctl restart postfix
Note: This will not affect any manually created mailbox with name root@domainname.com, but if such a mailbox does not exist, then the message intended for it will be deleted instead of being delivered to the Plesk Administrator email address (pleskadmin@example.com in this example).
These changes will make all emails intended for the root@ mailboxes for domains go to /dev/null (which means nowhere essentially) instead of the Administrator mailbox (pleskadmin@example.com in this example)
To make all emails sent to @localhost.localdomain default mailboxes get delivered to another specifically designated mailbox instead, you should do the following:
-
Log into the server via SSH
-
Open the
/etc/aliasesfile for editing with your favorite command-line text editor -
For example, in order to make emails delivered to the account root@localhost.localdomain get delivered to john.doe@example.com instead of pleskadmin@example.com, add the following line into the
/etc/aliasesfile:CONFIG_TEXT: root: john.doe@example.com
- Save the changes and close the file
-
Apply the new settings via this command:
# postalias /etc/aliases
-
Verify that the setting is applied by running this command:
# postmap -s /etc/aliases | grep root
- Restart postfix
# systemctl restart postfix
Note: This will not affect any manually created mailbox with name root@domainname.com, but if such a mailbox does not exist, then the message intended for it will be deleted instead of being delivered to the Plesk Administrator email address (pleskadmin@example.com in this example).
These changes will make all emails intended for the default root@ mailboxes of domains go to john.doe@example.com instead of the Administrator mailbox (pleskadmin@example.com in this example)
If you instead want to receive these emails, but filter and reject the ones containing spam, you can do so by installing the Plesk Email Security extension and tweaking the spam score for incoming emails, as explained in the following article:
What is the recommended initial setup after installing the Plesk Email Security extension?
Comments
6 comments
Seems to be no valid reason for Plesk to be creating these other than postmaster and even then you could argue it should be created so a customer would see there is a postmaster mailbox and forward it or check it for email as they see fit.
Recently, it seems that "the bad guys" are now exploiting these alias domain names, and this has become a liability / vulnerability. I am now getting bombarded with junk sent to drweb, root, and anonymous. Thank you for offering this solution, but perhaps these aliases need to be eliminated. I am concerned that adding the line "root: /dev/null " could prevent something important from being sent. What was it originally intended for?
I agree with Franck Palaia. This is an non-sense that this behavior is expected by design. If domain's owner want to receive mails on postmaster or root, it must be his choice.
I agree with thecomments. To summarize my point of view:
1) There are apparently idiots who have recently been using this behavior to spam.
2) This behavior by design seems to date from another time and has been largely abandoned since (because of spam precisely).
3) Creating a postmaster mailbox or other should be a choice of the domain user or their provider, not be a default behavior of the server that shows spammers a target on their backs to all hosted domains.
4) This default setting is all the more strange since we have had some Plesk servers for more than 10 years (under CentOS 6 (!), Debian 10, Almalinux 8 and 9) under Qmail AND Postfix and that this behavior has only been observed on an Almalinux9/postfix server and does not seem to concern Almalinux8/Postif.
I'm afraid that this is not just happening on AlmaLinux. I do have an AlmaLinux server where this is happening, but one of my servers that is also getting this kind of nuisance "attack" is still running CentOS Linux 7.9.2009, but it has the TuxCare end-of-life extension installed (with the monthly subscription). I am in the process of migrating it and a number of servers to AlmaLinux. Another work-around, that may only work until "the bad guys" try a new subject line, is to set up filters that delete mail sent with the subject lines "miss you..." and "Your bonus". I have only noticed those two (so far...).
I am now noticing these messages coming in to individual accounts on some subscriptions, not just the Plesk aliases, but from many, many e-mail addresses..
Just to add a confirmation here that the "miss you..." mails are an annoying new wave of spam to the aliases :-( However, it seems that most of them are originating from the same source so that IP banning the source may help to mitigate it temporarily. We also found that changing SPF handling from "hard fail" to "soft fail" decreased the number of this type of spam that comes through.
Please sign in to leave a comment.