Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am running Exchange on an installation of SBS 2003 and I have recently run into a problem where random spam queues began showing up in my SMTP queues. I was first alerted to it because my antivirus software was telling me my server was infected, but luckily I think it's just because the spam contains malicious attachments. One weird thing is that all of the messages in the queue appear to be from 'postmaster@mydomain.com' to address on the spammer domain. Does this mean that they are trying to get me to email them sensitive information from my server? At any rate, I need to figure out how to secure my server so that the only people who can send email from my server are authenticated domain users. Does anyone know the best way to lock this down so that only domain accounts can send email, and no one else? Users need to be able to send mail both in and out of the office. Remote email is done through Remote Web Workplace and ActiveSync to smartphones. I am using the Microsoft-Server-ActiveSync web application in my default web site in IIS 6, in case that is providing any security holes for spammers to get through.

Any help is greatly appreciated.

share|improve this question

3 Answers 3

up vote 3 down vote accepted

It sounds like backscatter (NDR spam) to me, rather than your server being an open relay. Exchange Server 2003 by default is not an open relay. You can check whether or not your Exchange server is an open relay by using any number of online tests. You can help prevent backscatter spam in a few ways:

  1. Disable NDR's on your Exchange server.

  2. Filter email sent to recipients that don't exist in AD.

EDIT

After reading the other answers and reading the comments to my answer, here's an updated answer:

  1. Filter email sent to recipients that don't exist in AD. This is probably the more preferred method to deal with backscatter at your Exchange server.

  2. Disable NDR's on your Exchange server. This is the least preferred method and was probably not the best suggestion on my part. While it does deal with the problem, it may not be completely in the spirit of RFC 5321 (although it probably is acceptable based on the verbage of RFC 5321 section 6.2).

share|improve this answer
    
Strictly speaking disabling NDRs are not "by RFC" –  Vick Vega Sep 21 '11 at 1:09
    
RFC 5321 section 6.2 seems to be saying that this is an acceptable practice, albeit probably frowned upon. I realize that this setting in Exchange 2003 is all or nothing, but it is a method for combating NDR spam. –  joeqwerty Sep 21 '11 at 1:18
    
The requirement for NDRs can be severely limited by not accepting email from the Internet unless you are willing and able to deliver it. The can reduce local back scatter to near 0. It can't fix open relay back scatter, but there aren't many of them left. –  BillThor Sep 21 '11 at 1:26
    
Thanks, I've turned on the recipient filter and will monitor it over the next few days to make sure the queues clear up. –  Mike C Sep 22 '11 at 0:31
    
Glad to help... –  joeqwerty Sep 22 '11 at 0:53

There is a Microsoft KB article that describes this perfectly. It's even an SBS based article:

http://support.microsoft.com/kb/886208

The basic answer is you're suffering from a backscatter problem. The solution is to turn on recipient filtering as detailed in the MS KB article.

That's a short-term solution. The problem with recipient filtering is that it leaves you vulnerable to a directory harvest attack. If you want to really secure your server, you shouldn't accept SMTP connections directly. The best thing to do is use a service like Postini or MXLogic and only accept SMTP connections from those systems.

share|improve this answer

Perhaps you should take a look at This article which will explain the purpose of the postmaster@mydomain.com.

Nonetheless, it may help to run the MS Exchange Best Practices Analyzer and the MX Toolbox SuperTool to ensure your server is secure and set up to best practice standards.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.