Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I administer a Windows Server 2003 with Exchange 2003 as well as GFI installed. I am watching the GFI dashboard and every third email is spam. Not only that it goes to a non existent address then the Postmaster@ourdomain.com sends out an NDR to the sender.

Should I be worried about this? I know it is directory harvesting but we have directory harvesting turned on in GFI and I do see it is working but obviously doesn't work for emails that don't exist. My issue is I would turn off NDR but then people who legitimately mistype and email address to our domain will never know their email did not get to the recipient.

What do others do to combat spam?

Is 3 times the amount of spam to ham normal?

We filter out 90% of the spam but some does get into the users inbox.

Thanks for the suggestions and advice!

share|improve this question

4 Answers 4

up vote 4 down vote accepted

Welcome to the internet my friend, would you like some spam? :)

In my experience 3:1 (or higher) Spam:Ham ratio isn't unusual -- My company gets on the order of 3.75:1 & my personal box is around 2:1. If you want email you just have to cope with the fact that you will get a bunch of spam along with it.

Definitely don't disable NDRs 5xx permanent failure messages -- It is expected and proper that your server return these, and as you said people who legitimately mistype an address need to be told they made a typo (the number of angry users from turning off NDRs is in my experience far greater than the benefit of disabling them as a spam-fighting measure. (ETA: If your system is sending out an email of its own you don't need to do that: The sending SMTP server should notify the sender)


Re: other ways to fight the flood (in the order I apply them):

  1. DNS Block lists (see spamhaus.org)
    1. My own blocklist (to which I add IP ranges that are particularly bad)
      This is a firewall rule in my case: If I think you're that terrible you're not even going to talk to my SMTP server.
  2. spam-filtering software (which you're already doing)
    You can layer a few different filtering technologies here if you really want to.
  3. AV software (not strictly an anti-spam measure, but it catches some spam-with-trojan mails)

You can also consider greylisting but I've found that to be of limited value personally (and it annoys me in general: It creates double the traffic/workload for legit emails).

share|improve this answer
    
Excellent stuff thanks! +1 We use Symantec Corp for AV works well and is great to manage. Excellent you have confirmed my thoughts on spam. –  Campo May 12 '10 at 18:22
    
Also of note, if your server is originating actual bounce messages (sending an email rather than just telling the other side "5xx Go Away") you may actually be relaying the spam -- Triple check that you're not an open relay & that none of your client systems are compromised & spewing junk :) –  voretaq7 May 12 '10 at 18:26
    
Any advice/programs I can use to accomplish this? This is the side of spam I am a little n00bish on. I know how to get the server setup. I don't believe we are an open relay. I do restrict which IP's can send mail from this server. –  Campo May 12 '10 at 18:51
1  
abuse.net/relay.html is a good relay-checker. For checking your client systems a good AV/Trojan checker & the MS Malicious Software Removal Tool are good starting points (assuming it's a Windows environment). –  voretaq7 May 12 '10 at 18:57
    
Good stuff thanks! –  Campo May 12 '10 at 20:13

I had the same problem with the NDR issues. What I did to resolve the issue was to set up greylisting using JEPS

share|improve this answer
    
I like the idea of greylisting. only concern is websites that require an email confirmation for an account. How do you tackle this issue with Greylisting? –  Campo May 12 '10 at 19:36
    
Greylisting doesn't stop legitimate email from being delivered, it simply stops email that doesn't have an email server behind it that respects the "I'm busy try back later" response. Spammers simply can't afford to try every single email twice, especilly when they are trying the random name approach. an email confirmation mail would have a legitimate email server behind it that will simply requeue the email for delivery. –  Jim B May 12 '10 at 19:42
    
Greylisting can be a particular nuisance with websites that require an account to be created and the email address confirmed before they can be used. If the sending MTA of the site is poorly configured, greylisting may delay the initial email containing the signup confirmation link, thus introducing a waiting period even though the actual website may have attempted to send out the email confirmation code immediately. from: en.wikipedia.org/wiki/Greylisting –  Campo May 12 '10 at 20:14
    
@Campo Welcome to wkikipedia as a source of technical information "If the sending MTA of the site is poorly configured... thus introducing a waiting period " - being the key phrase, I would suspect that as popular as greylisting is most sites have already run into this problem and resolved it. Regardless other than trying to point out that web admins are somehow dumber than other admins ANY misconfigured MTA would cause issues so I'm not sure why they would pick on webadmins. Email is not IM so if a website is assumming immediate email delivery- well there is an old saying about ass-u-me –  Jim B May 12 '10 at 20:43
    
HEHE gotcha! Thanks –  Campo May 12 '10 at 20:58

3:1 spam:ham ratio sounds about right. There is a ridiculous amount of spam out there.

I've never used GFI before. We run a dual-spam filtering system, first level is Postini which then sends mail to our servers. Second level is Spamassassin/Amavis running locally, before forwarding it to our exchange server, which doesn't have anything running. That seems to catch the stuff that Postini lets through. About 1 spam every few days gets through and false positives seem low.

If you are only catching 90% of spam that is a horrible catch rate. I'll give the GFI product the benefit of the doubt and say that something is misconfigured. Make sure you have gone through the settings to ensure everything is done right. You should have at least one RBL enabled - I recommend spamcop.

I would disable NDR for non-existing accounts. You are right, that if someone mistypes an address that it won't bounce. However, the many, many spam messages that are sent from 'fake' from addresses to invalid accounts creates a condition where your server is basically spamming other mail servers with its NDR. NDR should be disabled in most situations.

share|improve this answer
    
Interesting. I have updated some of the filter and will continue to do so. If I do not get results I will look into a system similar to the one you described –  Campo May 12 '10 at 18:49
  • NDR for non-existing accounts is non-standard. Most systems just swallow it ;) You dont want to help people identify which accounts exist.
  • Yes, most email you get is spam. 3:1 is actually pretty good. Some accounts go up to 90% spam, very little ham. You have to live with it. Be happy, you are acutally not really on teh bad end.
share|improve this answer
4  
While originating a new message is non-standard, the 5xx-series "permanent failure" message is RFC compliant and expected. Please don't break the internet by silently swallowing emails to nonexistent users without telling the sender -- Sometimes it's a Real Person(tm) on the other end and they need to know they mistyped an address :-) –  voretaq7 May 12 '10 at 18:22
    
@voretaq7 Agreed :) –  Campo May 12 '10 at 18:50
    
...until someone comes along and berates you for emitting "backscatter". –  David Mackintosh May 13 '10 at 3:11
    
Yes, that is the issue. Sending an NDR allows me to use you to spam a third person ;) –  TomTom May 13 '10 at 5:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.