E-mail Accounts: Outbound Spam

[Eric Pretorious]

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:

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:

...<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?

 

[Eric Pretorious]

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:

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]

...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

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...

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

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

[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)?

 

[Eric Pretorious]

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

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:

[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!

 

[Eric Pretorious]

This is pretty clearly a bug in Plesk 11.x:

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...

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

[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)?

How/Where can I file a bug report?

 

[Eric Pretorious]

This is pretty clearly a bug in Plesk 11.x... How/Where can I file a bug report?

A little help here?

 

[IgorG]

A little help here?

Is this problem reproducible in Plesk 12?

 

[Eric Pretorious]

Is this problem reproducible in Plesk 12?

I have no idea, Igor. We're using PP 11.0.9 (Update #62) on CentOS 6.5 (x86_64).

 

[IgorG]

I have no idea, Igor. We're using PP 11.0.9 (Update #62) on CentOS 6.5 (x86_64).

What are the reasons for using this very old Plesk version?