0

I am in-charge of a dedicated server with Plesk Control Panel installed on a Windows Server 2008 Web Edition.

The issue that I am having is related with the emails setup on the same server using Plesk (It uses MailEnable though in the background). For the last one week, some of our clients are getting a lot of 'Delivery Failure' emails from 'Delivery Subsystem'. These are all fake emails as our clients have not sent those emails to receive a bounce back. But somehow they are there in the outgoing SMTP queue of our server.

The real issue is that I am unable to solve this issue since I belong to a programming background and not very expert in the server domain but have been given this work by my client.

I checked to verify that we don't have un-authenticated localhost relay capabilities enabled for MailEnable. But we do have options 'Allow relay for privileged addresses' and 'Allow relay for authenticated senders' checked there. The only privileged IP there is 127.0.0.1. The guys at Codero suggest us to disabled the relay option for 127.0.0.1. It does make sense but then it means that we have to change the scripts of more than 50 websites setup on our server which doesn't sound really feasible at this time.

Where are these coming from and how do I stop them?

EDIT: Let's take an example which will make the things absolutely clear.

We have a domain called myabc.com which is one of the 50 domains hosted at our dedicated server. Just a few days back I was reported by the owner of this domain that he was receiving 100's of failed delivery mails on one of his email accounts, say myemail@myabc.com. I checked his inbox and found it to be correct.

Then as part of my troubleshooting, I went to see the outgoing queue of the SMTP at our server & was surprised to find 16000 emails held in a queue. I cleared it though. I checked a few of the emails & found that all of them are sent through random email id's that are not even configured on our server for myabc.com. But not all are random, there are those id's as well which are configured on our server and hence, our client is receiving bounce back emails on those id's (I checked myself the other email id's on myabc.com and found that they are also receiving the bounce back emails).

However whatever emails I checked there, I found that the only domain targeted for this is myabc.com. I didn't find any email targeted from an email id on any other domain on our server. However I can't be 100% sure about it as it is difficult to check all 16000 emails. But also no other client has reported it till date (And I hope no-one else does in future). So I assume that since the emails are in SMTP outgoing queue on our server, so somehow they are being sent through our server only. As I said, I am a programmer and so finding it hard to troubleshoot. Please pardon me if something doesn't make any sense.

HopelessN00b
  • 54,273

3 Answers3

2

First, you should NEVER have an unauthenticated relay server connected to Internet. It'll be exploited in 15 minutes flat.

In order to make it simpler to setup a secure system, you should configure you mail server to only relay mail if any of the following condition is true:

  • The sender IP address is localhost (127.0.01)
  • The sender is authenticated.

In MailEnabled, this is done through the "relay" tab of the SMTP connector (see this for a more detailed help).

Stephane
  • 6,482
2

If I understand your question correctly, you've been joe-jobbed; that is, someone else on the internet has sent out a large number of spam emails with sender addresses in your clients' domains, and you're getting the bounces from non-existent recipients (this is also known as "backscatter").

If this is so, then let us leave aside the pros and cons of unauthenticated localhost-only relaying, since that has nothing to do with preventing backscatter.

The sad truth is that there's nothing you can do to cut out backscatter completely. It's caused by a combination of email being unauthenticated as regards sender (so you can't stop people sending email as your clients) and certain mail servers that I won't name not generating "5xx user unknown" failures at delivery time, but instead accepting undeliverable emails then generating new messages to tell the "sender" about the failure.

But you can minimise backscatter. One way is to take advantage of SPF, Sender Policy Framework (aka Sender-Permitted-From). This is a method of using the DNS to tell the internet which servers are allowed to send email claiming to be from your client's domains.

Of course, you can only advertise this information; others have to configure their mail servers to use it. But a fairly large percentage do, and since spammers are rational beings (well, sort of), they would prefer to send mail that will be accepted by 100% of recipients, not just 60% (say). So: just as a car alarm doesn't make your car impossible to steal, only harder to steal than the car next to it so the thief moves on, so SPF tends to make spammers prefer other domains than your clients' for their joe-jobbing.

At the risk of self-promotion, the canonical SF answer on setting up SPF is What are SPF records, and how do I configure them? ; it includes a pointer to the main internet site on SPF.

MadHatter
  • 81,580
0

I know of no hosting environment that allowed unauthenticated relaying (at least not for long...). As Stephane mentioned this is a security issue waiting to be exploited. Once you are known as a spam relay all of your mail will be blacklisted. How do you know one of your hosted domains is not already compromised? What appears to be backscatter could in fact be legitimate bounce messages since your relay is open.

Jim B
  • 24,276