Linux

Postfix: How to identify a PHP script sending spam

Your domain is hosted on a Linux server using Postfix to send emails and is blacklisted for spam?

You probably have a malicious script sending a large number of emails directly from the server … well, you get the enemy at home!

If your outgoing mail daemon (ie the software used to send emails) is Postfix, you can identify the source of spam in just a few simple steps.

The resolution of the problem can be just as easy, although in most cases needs further investigation.

It is in fact necessary to prevent the situation from happening again, as if someone was able to load a script on your server, you may have some security flaw.

The first thing to do is log on to your mail server with a user with administrative rights (sudo) and be sure that the php.ini file of your domain (and/or the global server) contains the following line:

mail.add_x_header = On

without which what we will do next will not produce any useful result.

Once checked this, you will need to inspect the mail queue with the command:

mailq

In the first column you will see the unique ID of each outgoing email, for example:

DA5E8647235C 369763 Wed Mar 29 16:30:19 someotheruser@someotherdomain.com
 (connect to somedomain.com[123.123.123.123]:25: Connection refused)
 someuser@somedomain.com

Once identified one of these emails that is obviously spam, we are going to examine its details with the command:

postcat -q <ID>

and we search for a line starting with “X-PHP-Originating-Script” (present thanks to the php.ini line mentioned above).

For example, using grep to avoid having to manually scroll through the email content:

postcat -q DA5E8647235C | grep X-PHP-Originating-Script

we could get an output like this:

X-PHP-Originating-Script: 45:badmailer.php

The number 45 is the UID, which is the Linux user ID that ran the script, while badmailer.php is the script that is sending spam emails.

At this point you’ll just have to locate badmailer.php file, delete it or clean it up, and above all to understand how it was uploaded to your server and executed from there.

If your header does not contain the X-PHP-Originating-Script row, most likely your mail account has been hacked, and is used to “legitimately” send spam from your server. In this case, identified a spam outbound email, you should launch the following command to see which account was used for authentication:

postcat -q DA5E8647235C | grep sasl_username

You’ll get an output like this:

named_attribute: sasl_username=info@nullalo.com

In the example, you must immediately change info@nullalo.com account’s password with a stronger one (long, with special, uppercase and lowercase characters).

Another thing you can do to contain the damage is flush your outgoing mail queue with the following command:

postsuper -d ALL

If, however, important emails are also queued in addition to spam emails, you’ll have to delete the unwanted emails individually with the command:

postsuper -d <ID>

So, in the example we will launch the following command:

postsuper -d DA5E8647235C

That’s it … if you run into trouble, just add a comment to this article and we’ll try to help you!

Previous post

Windows Update stuck while searching: how to fix

Next post

Chrome: How to install self-signed SSL certificates

Fulvio Sicurezza

Fulvio Sicurezza

5 Comments

  1. Lorenzo
    Wednesday July 12th, 2017 at 01:25 PM — Reply

    Ciao!
    Il tuo articolo è utilissimo per tutti coloro che hanno questo problema visto che è la risoluzione definitiva.

    Nel mio caso però nelle email di spam che vengono inviate non c’è nessuna riga “X-PHP-Originating-Script”, nonostante l’header appare completo.
    Come si può capire cosa le sta generando? Grazie.

    • Fulvio Sicurezza
      Wednesday July 12th, 2017 at 06:10 PM — Reply

      Ciao Lorenzo,

      se la riga “X-PHP-Originating-Script” manca, molto probabilmente lo spam ha origine da un account di posta elettronica che è stato “bucato”, e che quindi invia posta dal tuo server in maniera “legittima”.
      In questo caso ti consiglio di esaminare bene l’header per risalire al mittente dell’email e cambiare tempestivamente la password di quell’account, utilizzandone magari una più complessa.
      Ad ogni modo, ho aggiornato l’articolo con quanto sopra accennato, facci sapere!

  2. Friday September 8th, 2017 at 10:37 PM — Reply

    how to increase security in postfix for spam ?

  3. Rick
    Saturday July 28th, 2018 at 04:53 PM — Reply

    Thank you for this great article

  4. Dan
    Saturday November 10th, 2018 at 09:50 AM — Reply

    One thing I’ve learned the hard way – if you’re using PHP Mailer, or any other library for sending emails from your server, be sure to change the script’s default path and directory names to a string consisting of random characters.

    For example, if the directory name is phpmailer, rename it, so it’s 7PSBYyAFFD.

    The path to the script becoms:
    public_html/mysite/7PSBYyAFFD/PHPMailerAutoLoad.php

    If you do this, you also need to change your PHP code which calls the mailer, so that it uses the new directory name.

    Of course, this won’t help much, if there are other problems with your site – backdoors, compromised email accounts, or other security holes.

Leave a reply

Your email address will not be published. Required fields are marked *