rjearley1966
asked on
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 255.255.255.255
(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.
Thanks,
Rich
Identity: msx\178807\676450
Subject: Undeliverable: Max-Gentleman Enlargement*Pills
Internet Message ID: <f5b9da66-ee93-4440-83cb-a
From Address: <>
Status: Ready
Size (KB): 8
Message Source Name: DSN
Source IP: 255.255.255.255
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
queues.png
message-tracking-example.txt
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 255.255.255.255
(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.
Thanks,
Rich
Identity: msx\178807\676450
Subject: Undeliverable: Max-Gentleman Enlargement*Pills
Internet Message ID: <f5b9da66-ee93-4440-83cb-a
From Address: <>
Status: Ready
Size (KB): 8
Message Source Name: DSN
Source IP: 255.255.255.255
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
queues.png
message-tracking-example.txt
ASKER
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?
Important:
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.
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?
Important:
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.
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.
Alan
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.
Alan
ASKER
Alan thanks I get it; :-) I am looking for an explanation for source ip 255.255.255.255 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?
Sembee you still around?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
http://technet.microsoft.com/en-us/library/bb201691.aspx
or
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).
Alan