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

Getting rid of spoofed NDR's in Exchange 2007

It appears that there is a lot spam being spoofed with our domain.  Our SMTP queues continually fill up with undeliverable replies.  If you look at any one of these messages, the recipient is always listed as some random email address that is not part of our organization or email domain scope. We are running Exchange 2007, and also Groupshield 7.0 for Exchange.  I can create a content filter rule in Groupshield to blocks all messages that start with "Undeliverable", but then we lose legitimate NDR's.  I have tried to create a transport rule in Exchange 2007, but it doesn't appear to be working.  What I have done is create a transport rule that says:

When a message is sent to users OUTSIDE the organization (because the recipient is listed as an outside email address)
AND the subject line contains "Undeliverable:*"
Silently drop the message

So, I would assume that this transport rule would delete all messages that have outside recipients and have Undeliverable as the start of the subject line.  However, we still receive TONS of these spoofed NDR's.  The recipient email address is blank "<>" on all of these NDR's.  Does anyone know how I can limit these NDR's but still allow legit NDR's through?
0
Jake Pratt
Asked:
Jake Pratt
  • 4
  • 4
  • 4
2 Solutions
 
LeeDerbyshireCommented:
Sadly, there is no way to accept only good NDRs.  Your server doesn't know the difference.  If you added an SPF record to your public DNS, you might reduce it by a small amount, but not enough people are using SPF to make much of a difference.  The only mitigating aspect to these things is that they tend to come in spells, and you'll hopefully find that they will dry up soon.
0
 
Jake PrattAuthor Commented:
Thanks for your response.  Relaying is not enabled on my server.  I have double checked all of my permissions, and even tried to send relay messages via telnet.  I get the 550 5.7.1 Unable to relay message.  The problem here is that someone is spoofing my domain.  They are probably not inside my organization.  What is happening is someone is sending spam spoofed as someone@mydomain.com, when it becomes undeliverable, the NDR's are getting sent back to the server for "mydomain.com", which is my email server.  So I'm getting pounded with these NDR's.  It doesn't necessarily mean that someone is sending them from inside, or relaying them off my server.

I've read something about creating an SPF record in my DNS, so that any email coming from "mydomain.com" must match the IP address of my server in the SPF record.  Although, from what I hear, not all servers require SPF authentication, so it's not a complete fix.

Isn't there a transport rule that will help with this?  It seems like the one I created should work.
0
Transaction-level recovery for Oracle database

Veeam Explore for Oracle delivers low RTOs and RPOs with agentless transaction log backup and transaction-level recovery of Oracle databases. You can restore the database to a precise point in time, even to a specific transaction.

 
LeeDerbyshireCommented:
The recipient of the NDR is internal, so I don't think it will match your transport rule.  We all have the same problem from time to time.  AFAIK, no-one has an answer yet.  If the NDRs are sitting in your queue, you might try to find a product that supports BATV.  If they are getting into mailboxes, then even that won't help.
0
 
Jake PrattAuthor Commented:
Thanks for your comments.  What you're saying makes sense, but I want to make sure I'm understanding something correctly: the recipient.  So, you're saying that the recipient is internal, right?  I'm just wondering why the queue says otherwise.  I may be misunderstanding how to read the queue, but I'm going to give you a specific example.  I'm looking at one message in my queue right now that has this listed:

From Address: <>
Status: Ready
Message Source Name: DSN
Recipients: info@ralled.com

The recipient listed here has nothing to do with our organization.  Every recipient on these NDR's is different, and they all are completely different from our domain.  So, just to make sure I understand:  you're telling me that even though the recipient in the queue is listed as "info@ralled.com", that the real recipient is the spoofed address, ie "spammer@mydomain.com", right?  If that's the case, then I can totally see why the server can't distinguish between good and bad NDR's.  But if that's the case, then I'm still not sure why the recipient is listed as an outside address.

So, if there's nothing I can do to split up good and bad NDR's, is there a way to designate that my queue only hold NDR's for like 5 or 10 minutes before dumping them?  Thanks again for your help.
0
 
Exchange_GeekCommented:
"So, if there's nothing I can do to split up good and bad NDR's, is there a way to designate that my queue only hold NDR's for like 5 or 10 minutes before dumping them?"

There isn't any transport rule that would help you get rid of this problem.
What i would suggest is to open a case with PSS Team and let them assist you towards driving for resolution.

If they would not be able to help - you can definitely get your money back :)
0
 
LeeDerbyshireCommented:
These are outgoing NDRs, then.  Maybe I misunderstood, but I assumed you were asking about incoming NDRs.  We all get both, of course, but you should see NDRs in 3 places:

1. In users mailboxes.
2. Queued for local delivery (badly addressed incoming NDRs).
3. Queued for outgoing delivery (badly addressed outgoing NDRs).

You can get rid of 3 by turning off NDRs at the server (although it's said to be inconsiderate); you can get rid of 2 by turning on recipient filtering (although this is said to expose you to NDR attacks); but 1 is a big problem.
0
 
Exchange_GeekCommented:
I am currently testing this on my lab server

Is it possible to attach the entire message header, I am currently doing the very same test and I would require certain info from the message header of the NDR being sent.

You may change the IP address and confidential information in the header.

Thanks.
0
 
Jake PrattAuthor Commented:
Thanks for all your help, guys.

"You can get rid of 3 by turning off NDRs at the server (although it's said to be inconsiderate); you can get rid of 2 by turning on recipient filtering (although this is said to expose you to NDR attacks); but 1 is a big problem."

We are not getting any delivered to mailbox (at least not too many).  The big problem is either incoming or outgoing. But I'm really not sure which we're dealing with.  I would assume it's outgoing.

"Is it possible to attach the entire message header, I am currently doing the very same test and I would require certain info from the message header of the NDR being sent."

I can't seem to get the header info for any of these messages.  Since they're not getting delivered to a mailbox, I can't access the header via a client.  And when I look at an NDR that DID get delivered to a mailbox, viewing the header is not an option for that message.  If you know a way to get that header, let me know.  Here is all the info on one particular message in the queue, though.  This is taken from the queue viewer.  I changed my server name to <local server name>.  And even though it's not listed here, the error code these NDR's are getting is 4.5.0, but I'm sure that's no surprise.

Identity: <local server name>\98695\241245
Subject: Undeliverable: Your credit score
Internet Message ID: <00feeb23-7ea8-4e71-ba89-727630fb8b19>
From Address: <>
Status: Ready
Size (KB): 5
Message Source Name: DSN
Source IP: 255.255.255.255
SCL: -1
Date Received: 11/12/2008 9:44:10 AM
Expiration Time: 11/14/2008 9:44:10 AM
Last Error:
Queue ID: <local server name>\98695
Recipients:  guy@awards.com (definitely outside our organization)

Thanks again for all of your help guys.
0
 
Exchange_GeekCommented:
Ok I was able to perform quite a bit of experiment in my lab. I will tel you what i did and the results.

I have an E2k3 - RGC - E2k7SP1 box.
Opened relay on E2k3 box and started sending spams to outside world (since E2k7SP1 isn't connected to internet - messages would stay in queue).

Now, on E2k7SP1 box create a transport rule.
Go to Organization - Hub - Transport Rule - New rule (Name it) -
"when the From address contains specific words" (click on link - type on next window <>)
silently drop message.

Enable rule and check your queues emptying out.

Oh I also deleted the above rule and later created a new one (for testing purpose)
Go to Organization - Hub - Transport Rule - New rule (Name it) -
 "when the From address contains specific words" (click on link - type on next window <>)
redirect to specific address (test@mydomain.com)

Enable rule and check all those messages getting redirected to my test mailbox.
 

0
 
LeeDerbyshireCommented:
To stop all outgoing NDRs for badly addressed incoming mail, you need to go to Org Configuration/Hub Transport/Remote Domains, and look at the properties of the Default Entry.  On the second tab, which has a strange, possibly badly coded, title, you can turn off NDRs.  But - it's not usually considered a good thing, since external senders won't know that they've incorrectly addressed their mail.  Most people just ignore what's lying in the queues.
0
 
Jake PrattAuthor Commented:
Thanks for all your help guys.  Too bad I could never completely solve this.  I do appreciate the help, though.
0

Featured Post

Prep for the ITIL® Foundation Certification Exam

December’s Course of the Month is now available! Enroll to learn ITIL® Foundation best practices for delivering IT services effectively and efficiently.

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