• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

E-mail Accounts: Outbound Spam

E

Eric Pretorious

Regular Pleskian
E-mail Accounts: Stopping Outbound Spam

WARNING: Some names have been changed to protect the privacy of the individuals involved

During the installation and configuration of Plesk 11.x, we had created an e-mail account for testing purposes ([email protected]). It seems that someone recently discovered the account and guessed the password and then began relaying an enormous amount of UCE/Spam using the account. When we discovered this, we immediately deleted the account (Domains -> Example.com -> Mail -> Remove) but - more than 60 hours later - the account still appears to be very active:
Code: 
Aug  6 20:27:28 www postfix/qmgr[29665]: EF1331C9498: from=<[email protected]>, size=557, nrcpt=5 (queue active)
Aug  6 20:27:28 www postfix/qmgr[29665]: E2AA22417E7: from=<[email protected]>, size=552, nrcpt=5 (queue active)
Aug  6 20:27:28 www postfix/qmgr[29665]: EC2DE1C92B6: from=<[email protected]>, size=778, nrcpt=5 (queue active)
Aug  6 20:27:28 www postfix/qmgr[29665]: E36E61E0446: from=<[email protected]>, size=556, nrcpt=5 (queue active)
Aug  6 20:27:28 www postfix/qmgr[29665]: E69E31C928F: from=<[email protected]>, size=558, nrcpt=5 (queue active)
Aug  6 20:27:28 www postfix/qmgr[29665]: EC9151E18CE: from=<[email protected]>, size=767, nrcpt=5 (queue active)
Aug  6 20:27:28 www postfix/qmgr[29665]: E5DE01E18B2: from=<[email protected]>, size=754, nrcpt=5 (queue active)
Aug  6 20:27:28 www postfix/qmgr[29665]: EC7F71E1EC9: from=<[email protected]>, size=554, nrcpt=5 (queue active)
Aug  6 20:27:28 www postfix/qmgr[29665]: E63021E1468: from=<[email protected]>, size=759, nrcpt=5 (queue active)

Looking more closely at message ID E63021E1468:
Code: 
...<SNIP>...
Aug  6 19:17:29 www postfix/error[9897]: E63021E1468: to=<[email protected]>, relay=none, delay=409051, delays=409051/0/0/0.02, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mx2.comcast.net[2001:558:fe2d:70::22]:25: Network is unreachable)
Aug  6 19:18:02 www postfix/smtp[10023]: E63021E1468: to=<[email protected]>, relay=cluster3.eu.messagelabs.com[194.106.220.51]:25, delay=409084, delays=409051/31/1.6/0, dsn=4.0.0, status=deferred (host cluster3.eu.messagelabs.com[194.106.220.51] refused to talk to me: 501 Connection rejected by policy [7.7] 9206, please visit www.messagelabs.com/support for more details about this error message.)
Aug  6 20:27:29 www postfix/error[18017]: E63021E1468: to=<[email protected]>, relay=none, delay=413251, delays=413251/0.01/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mx2.comcast.net[2001:558:fe2d:70::22]:25: Network is unreachable)
Aug  6 20:28:04 www postfix/smtp[17857]: E63021E1468: to=<[email protected]>, relay=none, delay=413286, delays=413251/34/1.4/0, dsn=4.4.1, status=deferred (connect to cluster3.eu.messagelabs.com[194.106.220.51]:25: Connection refused)
Aug  6 21:38:01 www postfix/error[24861]: E63021E1468: to=<[email protected]>, relay=none, delay=417483, delays=417483/0.01/0/0.01, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mx1.comcast.net[2001:558:fe14:70::22]:25: Network is unreachable)
Aug  6 21:38:20 www postfix/smtp[24899]: E63021E1468: to=<[email protected]>, relay=cluster3.eu.messagelabs.com[85.158.139.3]:25, delay=417502, delays=417483/18/1.2/0, dsn=4.0.0, status=deferred (host cluster3.eu.messagelabs.com[85.158.139.3] refused to talk to me: 501 Connection rejected by policy [7.7] 9011, please visit www.messagelabs.com/support for more details about this error message.)
...<SNIP>...

  1. Why is Postfix still accepting e-mail for this account? How can we permanently disable this account?
  2. There don't appear to be any entries in /usr/local/psa/var/log/maillog that give us a clue about the source IP address of these messages. How can we determine the source of these messages?
 
Last edited:
FWIW: I don't recall if the [email protected] account was created as an alias or a full-featured e-mail account but, after reviewing the Postfix log file (i.e., /usr/local/psa/var/log/maillog), I'm fairly sure that this is an error in the way that Plesk manages the e-mail tables because of the way that Postfix is delivering the rejection notices (DSN, NDR, etc) to my personal account:
Code: 
Aug  7 00:17:41 www postfix/pipe[6491]: 6EED21C458B: to=<[email protected]>, orig_to=<[email protected]>, relay=plesk_virtual, delay=0.5, delays=0.14/0.01/0/0.35, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Aug  7 00:18:05 www postfix/pipe[6491]: DE9D91C458B: to=<[email protected]>, orig_to=<[email protected]>, relay=plesk_virtual, delay=0.1, delays=0.01/0/0/0.1, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Reminder: Some names have been changed to protect the privacy of the individuals involved
 
Eric Pretorious said:
...It seems that someone recently discovered the account and guessed the password and then began relaying an enormous amount of UCE/Spam using the account. When we discovered this, we immediately deleted the account (Domains -> Example.com -> Mail -> Remove) but - more than 60 hours later - the account still appears to be very active
Click to expand...

Reminder: Some names have been changed to protect the privacy of the individuals involved

The first place I checked was the PSA database. I found the mail table and verified that the account in question does not exist in the MySQL table. So then I checked the Postfix configuration files (i.e., /etc/postfix/main.cf & /etc/postfix/master.cf) looking for MySQL-related configuration statements but there don't appear to be any. So then I realized that, maybe, Plesk generates Berkley DB files or Trivial DB files...
Code: 
[root@www postfix]# file /var/spool/postfix/plesk/*
/var/spool/postfix/plesk/aliases.db:            Berkeley DB (Hash, version 9, native byte-order)
/var/spool/postfix/plesk/blacklists.db:         Berkeley DB (Hash, version 9, native byte-order)
/var/spool/postfix/plesk/non_auth.re:           ASCII text
/var/spool/postfix/plesk/no_relay.re:           ASCII text
/var/spool/postfix/plesk/passwd.db:             SQLite 3.x database
/var/spool/postfix/plesk/passwd_db_key:         data
/var/spool/postfix/plesk/poplock.db:            Berkeley DB (Hash, version 9, native byte-order)
/var/spool/postfix/plesk/sdd_transport_maps.db: Berkeley DB (Hash, version 9, native byte-order)
/var/spool/postfix/plesk/transport.db:          Berkeley DB (Hash, version 9, native byte-order)
/var/spool/postfix/plesk/virtual.db:            Berkeley DB (Hash, version 9, native byte-order)
/var/spool/postfix/plesk/virtual_domains.db:    Berkeley DB (Hash, version 9, native byte-order)
/var/spool/postfix/plesk/vmailbox.db:           Berkeley DB (Hash, version 9, native byte-order)

So I just kept digging. I checked the Postfix master file (i.e., /etc/postfix/master.cf) and found that - IIUC - Postfix is configured to verify senders using the database /var/spool/postfix/plesk/passwd.db:
Code: 
...<SNIP>... 
plesk_saslauthd unix y y n - 1 plesk_saslauthd status=5 listen=6 dbpath=/var/spool/postfix/plesk/passwd.db
...<SNIP>...

A quick search for 'Postifix saslauthd' lead me to the KB Article #113866 which, in turn, demonstrated how to query the user database (i.e., /var/spool/postfix/plesk/passwd.db) so I found that the account in question is still present in the database and is still active:
Code: 
[root@www postfix]# /usr/local/psa/admin/bin/mail_auth_view
Authentication database contents:
+--------------------------------------+-----+--------------------------------------+
|             address                  |flags|               password               |
+--------------------------------------+-----+--------------------------------------+
| ...<SNIP>...                         |     |                                      |
|                  [email protected]    |     |                           *********  |
| ...<SNIP>...                         |     |                                      |
+--------------------------------------+-----+--------------------------------------+
Flags
	A - account disabled
	D - domain disabled
	E - password encrypted

How can I rebuild the passwd.db file (so that it contains the information stored in the MySQL tables)?
 
Last edited:
Eric Pretorious said:
How can I rebuild the passwd.db file (so that it contains the information stored in the MySQL tables)?
Click to expand...

Reminder: Some names have been changed to protect the privacy of the individuals involved.

I knew that if I just kept digging, I'd find the answer so I began looking at the contents of the Plesk administrative directory (i.e., /usr/local/psa/admin/bin/) and that's where I found the solution:
Code: 
[root@www bin]# ./mailmng --help-commands
Mailmng commands:
...<SNIP>...
--remove-mailbox            removes a mailbox for a given mailname.
...<SNIP>...

[root@www bin]# ./mailmng --remove-mailname -h
remove a mailname
Usage: --remove-mailname --domain-name=<domain_name> --mailname=<mail_name>
Allowed options to remove a mailname:
  --domain-name arg     domain name (mandatory)
  --mailname arg        mailname (mandatory)

[root@www bin]# ./mailmng --remove-mailname --domain-name=example.com --mailname=info

[root@www bin]# ./mail_auth_view | grep [email protected]

[root@www log]# grep info\@example\.com maillog | tail
Aug  7 21:27:44 www postfix/qmgr[20147]: 9B1231C9255: from=<[email protected]>, size=538, nrcpt=5 (queue active)
Aug  7 21:27:44 www postfix/qmgr[20147]: 99A011C84A2: from=<[email protected]>, size=765, nrcpt=5 (queue active)
Aug  7 21:27:44 www postfix/qmgr[20147]: 9749A1C8CCF: from=<[email protected]>, size=769, nrcpt=5 (queue active)
Aug  7 21:27:44 www postfix/qmgr[20147]: 9764A1C950D: from=<[email protected]>, size=566, nrcpt=5 (queue active)
Aug  7 21:27:44 www postfix/qmgr[20147]: 938ED1C9103: from=<[email protected]>, size=758, nrcpt=5 (queue active)
Aug  7 21:27:44 www postfix/qmgr[20147]: 98A2A1D1E12: from=<[email protected]>, size=753, nrcpt=5 (queue active)
Aug  7 21:27:44 www postfix/qmgr[20147]: 9DA081C8FF7: from=<[email protected]>, size=788, nrcpt=5 (queue active)
Aug  7 21:27:44 www postfix/qmgr[20147]: 92E7A1E06BF: from=<[email protected]>, size=753, nrcpt=5 (queue active)
Aug  7 21:28:56 www plesk_saslauthd[8099]: No such user '[email protected]' in mail authorization database
Aug  7 21:28:56 www plesk_saslauthd[8099]: failed mail authenticatication attempt for user '[email protected]' (password len=9)

[root@www log]# date
Thu Aug  7 21:30:18 UTC 2014

Problem solved! :)
 
Last edited:
This is pretty clearly a bug in Plesk 11.x:

Eric Pretorious said:
During the installation and configuration of Plesk 11.x, we had created an e-mail account for testing purposes ([email protected]). It seems that someone recently discovered the account and guessed the password and then began relaying an enormous amount of UCE/Spam using the account. When we discovered this, we immediately deleted the account (Domains -> Example.com -> Mail -> Remove) but - more than 60 hours later - the account still appears to be very active...
Click to expand...

Eric Pretorious said:
...KB Article #113866 which, in turn, demonstrated how to query the user database (i.e., /var/spool/postfix/plesk/passwd.db) so I found that the account in question is still present in the database and is still active:
Code: 
[root@www postfix]# /usr/local/psa/admin/bin/mail_auth_view
Authentication database contents:
+--------------------------------------+-----+--------------------------------------+
|             address                  |flags|               password               |
+--------------------------------------+-----+--------------------------------------+
| ...<SNIP>...                         |     |                                      |
|                  [email protected]    |     |                           *********  |
| ...<SNIP>...                         |     |                                      |
+--------------------------------------+-----+--------------------------------------+

How can I rebuild the passwd.db file (so that it contains the information stored in the MySQL tables)?
Click to expand...

How/Where can I file a bug report?
 
Last edited:
You must log in or register to reply here.

Similar threads

Erwin Fiten
Question Spam sent from my server by other hosts ???
Replies
4
Views
532
Bitpalast
Bitpalast
mapodec
Resolved Emails sent from Plesk accounts are not delivering only to Google Workspace
Replies
2
Views
652
mapodec
mapodec
W
Issue Mail forwarded on the server in the target mailbox is delivered to the SPAM folder
Replies
0
Views
472
W4ru
W
andreios
Question Bounced mail from Clamav
Replies
2
Views
885
andreios
andreios
G
Issue [email protected] keeps sending e-mail notification even if i've edited panel.ini file.
Replies
2
Views
1K
IT Ufficio Key-One
I
Back
Top