Server running RHEL 3, PLESK 7.5, qmail

The server is hosting several domains and IP addresses all through a single ethernet interface.

Server is closed to relaying. People reporting my server as an abuser are giving me email headers like this:

My interpretation of this is that people are connecting anonymously through one of my IPs, their email is being transferred internally on my server, then sent from my main IP.

What can I do to stop this please?

well clearly your server is *NOT* closed to relaying otherwise thus wouldn't be happening would it? try scanning yourself at http://www.abuse.net/relay.html and see what they say you are vulnerable to. they'll also tell you how to fix it for your MTA. obviosuly we can't tell you exactly what to change on your MTA as you've not provided your config for us to check.

Thanks for your feedback. On my server PLESK controls qmail, and from PLESK I have specified that it should be closed to relaying. I've also checked the rcpthosts file [which I believe is managed through the PLESK interface], and it contains only the domains that are hosted on the server.

Please tell me what else you need to know about my config.

well i have no experience of plesk whatsoever, so i could only look over the actual real qmail config files.

From what I have read, the config files seem to be the same as for standard qmail, but on a different path.

Given that I know there is a rcpthosts file, is there a setting somewhere that would override that? Where would that setting *normally* be stored please?

First off, let me say I'm a newbie when it comes to Linux. So I'm learning from my mistakes.

I disabled mail on every domain, and kept checking maillog file but qmail was still sending out loads of spam.

Then I stopped Apache, hoping that maybe there was a PHP script injection going on, and checked maillog again. Still there was spam going out.

Then I stopped qmail itself. The maillog entries stopped.

Then I ran ps aux and saw lots of qmail entries.

Knowing that my server is being used to send phishing emails from email address service@ppl.com I then ran ps aux | grep ppl.com

There were lots of entries, which have gardually died over time. They are of the form:

Due to my lack of knowledge, that's about as far as my diagnosis can get. How can I find out how these qmail-remote processes belonging to user qmailr are being started?

So "securitytest%abuse.net" seems to have got past the rcpthosts file? What should my next steps be please?

have you got the percenthack options disabled? I assume it would be appending your local domain to what is initially percieved to be a local user name, which could then be spun round and rewritten.

There is no file called percenthack on my system.

Now I have learned how to telnet onto port 25 and type in SMTP commands.

The sender "Security%abuse.net" is accepted, then the DATA command then some text and a '.' [period]. I get the SMTP response

250 ok 119xxxxx qp 12112

I quickly dived into the tail of the maillog file and saw that a message from spamtest@mydomain.com qp 12112 had been tried but delivery was deferred because the remote_host_could_not_complete_sender_verify_callout

Using the message id in the log message I then checked the recipient address which was "Security%abuse.net@host.mydomain.com"

So clearly my server is handling mail for badly formed email addresses that it shouldn't.

HOWEVER, my problem is the other away around. The above is deferred email is a sender in mydomain.com, but somehow an:

SMTP MAIL FROM:somebody@NOTmydomain.com command is getting injected into my mail queues, getting around my rcpthosts file, and is being sent from my server.

If I:

ps aux | grep qmail-remote I'm seeing lots of lines of mail being sent from email address "Service@ppl.com" such as:

Right now, qmail is handling just emails from service@ppl.com, no other addresses, but I also see entries where the sender field is blank, it doesn't contain any email addresses at all.

ok, so it looks like this could be percenthack related, and oddly i only found out that it existed the other day... so someone sent you an email to "Security%abuse.net" this contained no FQDN so qmail expanded it to "Security%abuse.net@your.domain.com" qmail then applies the percenthack "feature" to convert that to "Security@abuse.net" and off it goes.

Regarding the email to "security%abuse.net" that I built in a telnet session, described above, the qmail-send program has now sent a fail message to the server admin email address.

So the email address with the % sign in, is having the domain added to the end, and then the message is being rejected.

This doesn't explain then how MAIL TO:<somebody@not_in_my_rcpthosts_file.com> is getting past my rcpthosts file. I'm beginning to think that there must be some rogue script on the server that is bypassing the rcpthosts file, or that a genuine email address has been hijacked on the client side and is being used to piggy back sending these phishing emails.

Any advice of how to look for rogue scripts please?

It is very unlikely for qmail to be setup as open relay, since its default configuration is not suppose to be so. Can you check your mail log, not just one or two lines, is best to show more, say last 10 or 20 lines. It will be easier for us to understand the situation.

If you are using qmail-smtpd, you should check your qmail-smtpd startup script? If you are using qpsmptd, then you need to be careful to your plug-in configuration. If you are using other SMTP program, you will need to provide that information as well.

From the simulation of SMTP handshaking via telnet, it is possible, the party that spam email is one of your valid user. Which is why, those email able to get through.

I now have the situation under control.

I have used qmail-remove to remove any spamming/phishing email, or 'bouncing' messages from my mailer daemon. Doing this, I reduced the size of the mail queue from 3500 to 14!
I've added 'bad' email sending addresses [ ppl.com boa.com ] to the badmailfrom file.
I've changed the DNS A record for every mail.<domainX>.com on the server to be a single IP.
For all other IPs that the server uses I've firewalled port 25 [SMTP]

The combination of all of these things has the situaton under control. However, I still haven't found the root cause.