My users are not receiving legitimate NDRs (For example foramis-spelt email address) For external addresses. Internal to Internal is fine. External emails receive an NDR if they try to email the company to an email that does not exist. We are getting a lot of fake NDRs though. (One user reported 50 for the same address in an hour) What is the best way to reverse this, so we do get the real NDRs, but not the spam ones? I have tried to adjust the Anti-spam settings on the Edge transport, but to no avail.

Monica, This is a new way of spam where spammers use an existing adres to send mail from bij spoofing the adres and sending bunch of mail to other mailservers. In most times this users don't exist so you get the NDR because your mailserver is responsible for your domain. They call this technique backscatteron the page of Spamlinks.net you can find some information about it. At this moment there is not really a solution for it, you could create a SPF record for your domain in the external DNS server but if you search on the internet it will reduce the NDR's a little. Regards, Johan

Well... there are a couple of things potentially going on. First you are relying on the outside email administrators setting their severs to NDR messages properly. Some security people feel it's better to accept email to bad addresses, and to silently delete them to prevent directory harvest attacks. Frankly I think this is a worthless security effort as it doesn't really stop spammers, and only hurts real users. So if you have a remote domain where you think that the email messages aren't being NDR'ed properly, then contact postmaster@ to see if you can talk to a person to confirm or deny their settings. As for the fake NDR's, what the other person posted is true, but more often than not I find that those messages are legitimate NDR's being generated from virus infected emails. Meaning the virus takes over a computer and turns it into a zombie. That zombie computer starts spewing out emails to various TO addresses with faked FROM addresses. The servers the zombie sends the mail toare accepting the email and then NDR'ing them because the TO: address is incorrect. When those messages get NDR'ed the remote servers have nothing to go on other than the FROM address. This is part of the reason why I tell most customers to configure Exchange to check the TO address before accepting the email, so that they NDR the email to the host trying to deliver it (again some security folk hate this setting as they feel it is a security violation which IMHO is completely wrong). How can you protect yourself? You need some sort of anti-spam/anti-virus software that will hopefully pick up on messages coming in as containing a bad payload and wack them. This fixes the majority of those types of messages. However there are some systems out there that will still generate NDR's to emails your users didn't send, and those will get back to your users. So part of the issue is user education. I hope some of this help.

Thanks. I knewthe fake ones were spam. I have logged a call with our firewall contractors to try to decrease the fake NDRs again (We have an external company for firewalls) I was just hoping to have a second level to stop them. However if that will stop the real ones, it's better to leave it alone. The not getting genuine NDRs is definitely on my end though. I have tested serveral domains. Some I know have NDRs as I received them from the old email system. (We changed from Notes to Exchange 2007, late last year.) Any ideas on that at least? Thanks

Well, you would need to track the messages you are sending using the message tracking option in the Exchange Management Console Toolbox. You want to track one of the messages you sent to the remote domain that you know you should get an NDR for. What you want to see is the EventID of Send and the Source as SMTP. Then in the ServerHostname field you should see the remote server name that your system handed the email to. If you handed them the email, but never got an NDR back, then I would contact those email admins (usually postmaster@domainname.com) and ask them if they NDR'ed the message. 9/10 if you are nice and explain yourself with the details of the individual message you are tracking the remote administrators will help you out (assuming they monitor the email address you are using). If they confirm they NDR'ed the email, ask them which hose they delivered the NDR to. You may find your "firewall" is intercepting and dropping NDRs or something like that. Good luck!

I did trace the path before posting here.(Yes thereis an SMTP event listed, so it does leave the company.) What I can't explain is that if I send an emailan incorrectaddress in Exchange there is no NDR. When I send it from our old email system, which was notes, there is an NDR. The incorrect address is exactly the same, the sender is the same. The domain I am sending it to is the same. The only thing that is different is that I'm using Exchange. I thought maybe this would have to do with the in-built spam filters in Exchange 2007, but that's just a guess as I can't find any references to this issue.

I can definitely understand how these situations can be very frustrating to troubleshoot, but then again if were easy we wouldn't have IT jobs. The first thing I do is when I have concerns about Exchange doing something with the email is I take Exchange out of the picture. Meaning I use another email tool to connect directly to the remote server to see what sort of behavior I am getting. I use the tool POSTIE from www.infradig.com to remotely connect to destination email servers (rather than trying to remember the old SMTP verbs for a direct TELNET session). If you could try using a tool like POSTIE, it will tell you if the email was accepted or if it was rejected. If it is accepted, then its up to the remote system to NDR it, which they may and which Exchange (or some Exchange integrated application) may be tossing. If it rejects the email at the command prompt, that means Exchange should be NDR'ing the email to you. Another thing to try in tandem is to turn up the NDR message diagnostics under the Message Transport aspect of your Hub Transport server(s). Good luck!