LinuxHostingSupport

If you feel emails are saturated in the Plesk Qmail mail queue, there is a possibility that your Plesk server is been used for sending spam emails.

On a Plesk server relaying is not allowed by default so following are the ways spamming is mostly done. They are explained below point wise.

1) Using CGI by a user
2) PHP scripts. Also refer the article to locate the directories of the PHP scripts that are sending emails.
3) By a compromised email account

First, lets look at the the mail queue

# /var/qmail/bin/qmail-qstat
messages in queue: 22507
messages in queue but not yet preprocessed: 0

As you can see above, there are a large amount of emails in the mail queue. The source of these emails could either be a PHP/CGI script OR an authorized email account on the server.

Let’s start with reading the message headers with ‘qmail-qread’

# /var/qmail/bin/qmail-qread
5 Nov 2012 11:50:17 GMT #768752 1231 
remote user1@domain1.com
remote user2@domain1.com
remote user1@domain2.com

This will list the sender and recipient of all the emails in the mail queue.

In the above example #768752 is the message ID, now find out the location of this email to read the complete header

# find /var/qmail/queue/mess/ -name 768752
/var/qmail/queue/mess/0/768752

Above is the complete path to the mail file, now open the file and look for the “Received” line.

# cat /var/qmail/queue/mess/0/768752 | more

The “Received” line indicates from where the message was received OR invoked.

1) If the message is sent via CGI by a user, it will display the UID of the user as below:

Received: (qmail 26193 invoked by uid 10001); 5 Nov 2012 11:50:17

Now, search the UID 10001 in the passwd file to find the domain name

# grep 10001 /etc/passwd

This will display the domain name the UID 10001 belongs to.

2) The “Received” line indicates the UID of user Apache (i.e. 48)  if email is sent via a PHP script

Received: (qmail 26193 invoked by uid 48); 5 Nov 2012 11:50:17 +000

In such a case, you have to monitor the PHP scripts in real-time i.e. scripts that are running when emails are been sent.

Execute the below command as it is when the mail queue is growing rapidly

# lsof +r 1 -p `ps axww | grep httpd | grep -v grep | \
awk ' { if(!str) { str=$1 } else { str=str","$1}}END{print str}'` \
| grep vhosts | grep php

The above command won’t display the location of the php scripts, so please refer the article to locate the folders of the PHP scripts that are sending emails.

3) Many a time email accounts are compromised and used for sending bulk/spam emails from other locations. In such a case, “Received” line contains “invoked from network”

Received: (qmail 26193 invoked from network); 5 Nov 2012 11:50:17

Refer the article to find the compromised email accounts on a Plesk server.

Screen is used to run interactive programs in the backgroud while we can logout from the server. We can also re-attach to the existing screen session to check the progress of the running programs.

Sometimes, server admin need to run commands under a different user so they “su” to another user and use screen.

root@server [~]# su - user1
user1@server [~]# screen
Cannot open your terminal '/dev/pts/0' - please check.

As you can see, after changing the identity to ‘user1’, you cannot run screen and instead it exits with the error message

Cannot open your terminal '/dev/pts/0' - please check.

This indicates that the ‘user1’ don’t have access to the /dev/pts/0 file.

This is because the terminal is owned by the user (root) who opens the session so even if you su to another user (user1), the terminal will still be owned by the original user (root) hence the error.

Here are the permission and ownership of the terminal:

# ls -la /dev/pts/0
crw--w----  1 root tty 136, 0 Oct 28 04:34 /dev/pts/0

As you can see the ‘user1’ have no permission to read and write to the file. The file is only readable by root and writable by root and tty group.

There are 4 different solutions as stated below out of which 1st and 2nd are not recommended. They are a security risk and only recommended if you want to perform a very small tasks.

With the first 2 solutions, you may end up giving unprivileged access to a privileged login if you don’t revert the changes.

1) Set read/write permissions for ‘all’ on the terminal device in question which is /dev/pts/0 in our case. This way you can su to any user and run a screen session under his session.

# chmod a+rw /dev/pts/0

2) Set read permission to ‘tty’ group and then add the user ( in our case ‘user1’ ) to the ‘tty’ group in /etc/group file.

# chmod g+r /dev/pts/0

Open /etc/group file and search for tty:x:5: , at the end of the line add the username so he will be a part of the ‘tty’ group

tty:x:5:user1

Make sure you remove the user from the tty group once you complete your task.

3) This is the safest solution and is recommended. Set a strong password for user1, SSH directly with the user and run the screen session under it.

4) This is an alternate solution for the 3rd method.

a) Start a screen session as root
b) change to user1 with su command
c) execute your scripts/command
d) detach (don't terminate) from the screen using Ctrl a+d