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
  • 53,385
  • 32
  • 133
  • 208
Sumit Mehta
  • 1
  • 3
  • Are these bounces from emails that were sent from your server? Or are you getting bounces from messages you never sent? – MadHatter Jun 11 '13 at 15:05
  • Hi MadHatter. Yes we are getting bounces for messages that we never sent. – Sumit Mehta Jun 12 '13 at 04:36
  • From your edit: **either** you're allowing these emails to be placed on your server via SMTP (open SMTP relay, see other answers, fix it) **or** your server has some other way for people to inject email (web script, etc.). Take **one** of these emails. Look at the times and dates, the `Received-From:` headers, etc. Cross-correlate with logs (eg web, mail servers). Find out whether it was created locally (web script, etc.) or remotely (open SMTP relay). Then either close the relay, or disable the script. Or do what they suggested, require local auth for SMTP, and edit your legit scripts. – MadHatter Jun 12 '13 at 08:26
  • [Administration panels are off topic](http://serverfault.com/help/on-topic). [Even the presence of an administration panel on a system,](http://meta.serverfault.com/q/6538/118258) because they [take over the systems in strange and non-standard ways, making it difficult or even impossible for actual system administrators to manage the servers normally](http://meta.serverfault.com/a/3924/118258), and tend to indicate low-quality questions from *users* with insufficient knowledge for this site. – HopelessN00b Feb 25 '15 at 08:40

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,382
  • 3
  • 25
  • 47
  • Thanks for the answers. I just crossed check and found that we have only two options enabled: 'Allow relay for authenticated senders' and 'Allow relay for privileged IP ranges'. However, I still remember exactly that on many classic ASP websites, the contact us forms are just passed port 25 on localhost and the emails are dispatched. I am wondering how can this be possible if 'Allow relay for local sender addresses' is not checked? Thanks. – Sumit Mehta Jun 11 '13 at 17:00
  • @SumitMehta OBVIOUS, or? Because 127.0.x.x is likely in the priviledged IP range. – TomTom Jun 12 '13 at 07:03
  • Yes it is there in the privileged IP range. I encountered one more fact that this issue is only prevalent on one of the 50 domains and not every domain. – Sumit Mehta Jun 12 '13 at 07:30
  • If you're sure that you mail server is configured to prevent unauthenticated external relaying, then it can mean two things: the problem is in your software stack (typically, a badly written or configured form mailer) or a weak password somewhere. You should look at the SMTP logs to find out exactly where these emails comes from – Stephane Jun 12 '13 at 08:41
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.

Community
  • 1
MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • Thanks for updating me on SPF. I have one more concern. Let's suppose that the spammer puts email id's that are configured on our server but he must be dispatching those emails through some other servers i.e. he only has sender's email-id to be of a domain configured on our server. It should not be held in the SMTP queue of our server. I have seen upto 16000 emails in our SMTP outgoing queue so it makes me think that the mails are actually being sent using our server somehow. Please correct me if I am wrong. – Sumit Mehta Jun 12 '13 at 07:36
  • You said those 16000 emails were bounces awaiting delivery *to* your clients from mail you had not sent. If those 16000 emails are mails *from* soneone at your clients' domains, to third-party recipients, waiting for delivery off-server, then your assurances above (in comments) are **wrong**, and my answer is irrelevant. Please, clarify this situation! An **example** of one of the emails, making it clear which domains are your and which are not, would be helpful. – MadHatter Jun 12 '13 at 07:42
  • I have updated the question with an example to make things clear. Please check the updated question above. – Sumit Mehta Jun 12 '13 at 08:22
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
  • 23,938
  • 4
  • 35
  • 58