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

Exchange 2010: Several DnsConnectorDelivery's In The Queue Viewer That Looks Like Spam

I found the following article that deals with a similar issue that I'm seeing, but I'm still wondering if someone is somehow able to send out spam through our MSExchange 2010 Server.


The reference says, "the default behavior for Exchange is to accept inbound mail completely and then checks the recipients. If there is no recipient on Exchange, an NDR will be sent back to the sender which in many cases of spam is faked or originated from all over the Internet. This is what I suspect happens to your server."

Also, I've suspended some of the connectors and then noticed that the messages don't get delivered; for example, I sent a message from my Gmail account and I noticed that the Gmail DnsConnectorDelivery popped up, so I suspended it to see what would happen. When suspended the messages from the Gmail domain don't get delivered until I resume the DnsConnectorDelivery (btw, the connectors that I suspect are Spam I have suspended and are setting in a suspended state now). FYI, we are running the Anti-Spam features and in Recipient Filtering we have selected, "Block messages sent to recipients that do not exist in the Directory."

Other factors are that our Default Receive Connector's Network Settings are set to the following:

Use These local IP Addresses To Receive Email:
(All Available IPv6) Port 25
(All Available IPv4) Port 25

Receive Mail From Remote Servers That Have These IP Addresses:
Start Address ::
End Address ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
Start Address
End Address

And under Permissions all check boxes are selected.

Can I limit the addresses or permissions without breaking what's working? I'm not sure of the changes that need to happen if any.
  • 4
  • 3
5 Solutions
Mmh, I guess a question with differnt aspects.

Firt at all...
an NDR is sent, when "Block messages sent to recipients that do not exist in the Directory."
is disabled. Otherwise Exchnage refuses the connection. That means as far the sender sends the SMTP recipient information, exchnages cuts off the connection. The sending server will produce a message... Server don't like user....".

If you have a lot of messages looking like spam, you may investigate the source and target of such mails. The one option is, that your server really produces NDRs and tries to send them out. This may happen, if a sender uses differnt e-mail addresses as target, where only one or a few are valid.
The other option is (should not happen with your settings), if somebody sends spam with your e-mail domain as sender. If the NDR comes back, you have something like a loop.

Having multiple connections to the outside world in general is nothing unusual, if one internal sender sends e-mail to a lot of recipients, you get a lot of connections in the queue.

If you have outgoing targets, which are suspicious, you may investigate the mail in the queue to see, what you can find inside. Sending mails to a bunch of users with at least one valid adress is a way, to knock out the setting you made to avoid it.

Maybe it is an idea to work with IP  block list providers like spamcop or spamhaus, this can catch such mails before they reach the queue. The effect is the same. If a sender IP is blacklisted, the exchange just cuts the connection.
CreatedAuthor Commented:
When I view the messages in the General tab from the Queue Viewer they all have the following:

From Address: <>
Message Source Name: DSN
Source IP
SCL: -1
Recipients: newsletter@123newsletter.com

Note: the recipient in this case is not real and is being used as an example. However the recipients that I'm seeing are real email addresses and are not destined for anyone in our domain. They very much look like spam type addresses.
Looks like a Reverse NDR attack.

You can put a stop to it by enabling Recipient Validation - use this command:
Set-RecipientFilterConfig -RecipientValidationEnabled $true

(ref: http://technet.microsoft.com/en-us/library/aa998613.aspx)

If that doesn't work (and it should have worked) here is one guy's very creative alternative fix:
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Recepient filter is set as I can understand...

And is is a classic NDR

The point with such mails is, that either somebody send you mails with a couple of recipients, where at least one of them is valid. This way they either find more valid addresses (everything what doesn't come back), or it is just a trick to try to pass the limitations.

The solution is to keep out such mail at all.
Kaffient postet one method - a smarthost -, this moves the filtering task to a provider - I usually to prefer to use blacklist databases. At leset they filter out nearly 99%

You can try it...
Just add to your IP Block List providers (Exchange Antispam)
bl.spamcop.net, sbl.spamhaus.org, xbl.spamhaus.org, sbl-xbl.spamhaus.org
one or all of them....
CreatedAuthor Commented:
Thanks for the replys. So it does look like I've got a Reverse NDR Attack of some sort on my hands, I'm thinking it's looking more like Directory Harvesting after looking into it further.

Yes the Recipient Filtering is already set to True as mentioned it was turned on by selecting the check box "Block messages sent to recipients that do not exist in the Directory."

Also, we have been using Spamhaus as one of the IP Block List Providers. Maybe it's not enough, I don't know, so I'm going to add some of the others and see if that helps.

I have also seen that disabling NDRs might help with this issue, but then legitimate senders will not see bounced messages if they wrongly type in an email address. Any other suggestions on how to deal with these issues?
> I have also seen that disabling NDRs might...
yes you are right, if affect also legitimated NDRs....

You will never be able to filter all of such tries, but if you can limit it to a normal amount of false NDRs your exchange can live with this in my mind. Exchnage will throw them out after a while.

Otherwise you have to invest in additional spam filter technology and as more close you want to reach the 100%, as more expensive it will be.
CreatedAuthor Commented:
I now have a better understanding of what might be going on with the Exchange Queue and can see that its some sort of reverse NDR attack and can look into to taking appropriate actions. However, I'm still not sure or confident that my email server is not being used somehow to send out spam. Hopefully any attempts die before going out. How can I be sure that I'm not somehow relaying spam?
You can use these tools...

But I'm quite sure, if you server would be open, your server will have thousands of such messages. And it would be blacklisted. Make also the blacklist test on this site....

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

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