• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3648
  • Last Modified:

Exchange 2010 Standard spam in queue viewer

Hi Folks,

Saw something in the Exchange 2010 queue that concerns me.  At any given time I see ten to twenty of these messages in retry.  I know these are failures scheduled for retry but are there routed messages getting through as well.  Is it just backscatter spam?   I turned the firewall log on for Server 2008R2 in the hopes of seeing something.  Letting it collect for a couple of hours.

The From field is blank  <> and the source ip is
 (broadcast on the Lan)

Is the source ip correct?  Is this backscatter spam or do I possibly have a spam bot on a client somewhere on the lan broadcasting on port 25?  My mx record points to postini then to my site and my firewall locks down inbound smtp to only postini's range(s).  OWA was opened recently on the firewalls wan interface for a few iphones.  There is no Edge Transport Server.  


Identity: msx\178807\676450
Subject: Undeliverable: Max-Gentleman  Enlargement*Pills
Internet Message ID: <f5b9da66-ee93-4440-83cb-abc13549e426@xxxxxxxxxx.com>
From Address: <>
Status: Ready
Size (KB): 8
Message Source Name: DSN
Source IP:
SCL: -1
Date Received: 4/6/2012 2:38:24 PM
Expiration Time: 4/8/2012 2:38:24 PM
Last Error: 451 Try again later
Queue ID: msx\178807
Recipients:  +._-epnp@imee.net
  • 3
  • 2
1 Solution
Alan HardistyCo-OwnerCommented:
This is Backscatter spam - you either need to install the Exchange 2010 Anti-Spam Tools and make sure you enable Recipient Filtering:



Install 3rd party Anti-Spam Software, such as Vamsoft ORF and make sure you have Recipient Filtering enabled as a minimum (which will stop this spam from forcing your server to send NDR's back to spammers and it will keep you off www.backscatterer.org).

rjearley1966Author Commented:
Thanks Alan.  

Couple of follow up questions.  Also as it is the wknd going to leave this open for awhile.  Why is the source ip showing broadcast?  Broadcast packets are not permitted in through perimeter firewall.  Why doesn't the source ip show the nat translated address of the firewall wan to lan interfaces?

What about this from Msft?

It isn't a best practice to run anti-spam functionality on the Hub Transport server. We recommend that you run anti-spam features on the Edge Transport server at the perimeter of your organization. Only run anti-spam features on the Hub Transport server if you haven't deployed an Edge Transport server.
Alan HardistyCo-OwnerCommented:
The source is your server and the <> shows this and the broadcast address is what is always shown in an NDR email.

The reason for the generation of the NDR emails is as follows:

A spammer forges an email and claims it comes from someone (probably harvested from the web) and sends it to a random Invalid Recipient on your server.  Your Server accepts the email (rather than rejecting the Recipient as Invalid) and then processes it further.  Your server then determines that the Recipient doesn't exist and because it has accepted the email, it is now required by RFC standards to send back an NDR email to the Sender (who is forged).  In some case the Sender address will be valid and the emails will leave your server and in other cases, they are invalid and will sit on your server until your server gives up trying to send it.

If one or more of the emails being sent to your server is sent from an address that has been harvested from a Honeypot list (a list of emails that have never been advertised and only setup to trap spam), then when your server sends an NDR back to that address, it will get immediately blacklisted on Backscatterer.org and you can check on www.mxtoolbox.com/blacklists.aspx.

The Microsoft comment is true and perfectly good avice IF you have installed an Edge Transport Server.  This would be the first point of entry into your organisation for emails, so Anti-Spam measures should be installed / configured there.  If of course you don't have an Edge Transport Server, you can't and thus have to configure Anti-Spam on the Hub Transport Server instead.  I don't have a Hub Transport any more (I used to), so my Anti-Spam software is running on my Hub Transport Server.

If you implement Anti-Spam software on your server, and at least include Recipient Filtering, then when an email destined to an Invalid Recipient is received, your server will check to see if the Recipient Exists and if not, immediately reject the email.  This then forces the Sending Server to generate the NDR message, not your server and thus you won't get Blacklisted on Backscatterer.org as a result.

Hope that all makes sense.

rjearley1966Author Commented:
Alan thanks I get it; :-) I am looking for an explanation for source ip thank you.  If you read my original question in total you will see the term backscatter;  CNE here I want to understand  the braodcast address :-)  Is this just a MSFT snafu?

Sembee you still around?
Alan HardistyCo-OwnerCommented:
Sembee hasn't posted since December 2010 on EE.

The Address is the standard IP Address listed in all NDR messages - I can't explain why it is this IP address and not another, but that is what is seen in all NDR messages.

I know you mentioned Backscatter in your question - I am confirming that this is Backscatter.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now