** Updated on 11/12/04 5:19 P.M. CST (GMT -6)
The original post is further down – this is the update.
I’m sorry. Where’s the duct tape? Because I need to seal a few outbound ports and keep from hurting myself :^)
Here’s the skinny: Almost all of our clients are running Trend Micro’s C/S/M for SMB for their Anti-Spam solution – however this one client is a non-profit and already had Symantec Corporate A/V, so they went with SpamCatcher that they were able to get from TechSoup. Well, SpamCatcher works a little differently than Trend’s Anti-Spam. SpamCatcher doesn’t integrate directly with Exchange – instead, when it is running on the Exchange server, it has to be configured to listen on port 25, then Exchange is reconfigured to listen on port 26. As a result, SpamCatcher receives the emails on 25, then delivers them to Exchange on 26. SO – since this is an SBS, SpamCatcher & Exchange are running on the same box, so Exchange is receiving its emails from it’s own IP. Since Exchange on SBS is configured by default to allow itself to relay, this in effect opened this Exchange server up as an Open Relay – even though it was otherwise properly configured.
This also means that this IS NOT an issue with njabl.org – it was a uncommon configuration on this one server. My bad :^( Go ahead and whip me, beat me, and send me to my room without supper . . .
SO – the moral of the story is that if you’re running any sort of Anti-Spam / Anti-Virus / Anti-whatever that works similarly (actually receiving your email, then resending to Exchange on a different port), then you are most likely going to be an Open Relay.
The other moral of the story is to remember to think THEN blog . . . :^)
** End update – original post follows:
I received an email today from a client where they forwarded an NDR that they received. The NDR indicated that their message had been blocked because they were blacklisted. The specific blacklist indicated was njabl.org. I went to the njabl.org site and performed a search on the client’s (static) IP, and sure enough – a result was returned. In addition, the result included a message header from an automated open relay test njabl.org performed on the client’s server. And there, right in front of my eyes was a message header that clearly showed that this client’s SBS had received the email and relayed it. Remember – in a default configuration, Exchange on SBS 2003 is NOT an open relay. That’s about when panic started to set in . . .
So I remote’d in to the client’s SBS and verified the relay settings for their Default SMTP Virtual Server – and everything was set how it should be – it was restricted to allow relaying only from the following list, which inluded the IPs of the SBS (internal, loopback & external). The option ‘Allow all computers which successfully authenticate to relay, regardless the list above’ was unchecked, and the Users / Groups permissions was configured only to allow Authenticated Users to submit.
Hmmm. Next step was to take a look at my Message Tracking Center. Sure enough, Exchange shows where it received the message and submitted it back to njabl.org. What the #&%@ ?!?
I was getting ready to dig through my Exchange logs, when I took another look at the message header that njabl.org had displayed when I searched their database – and there it was, in plain sight. The section of the header that showed where my SBS received their test message read:
Received: from rt.njabl.org ([192.168.16.2]) by with Microsoft SMTPSVC(6.0.3790.0);
Ok, remember where I said above that there were three IPs in the Allow list in the Default SMTP Virtual Server relay settings – the internal IP, loopback IP & external IP? This is a default configuration, and perfectly normal and secure (usually). Take a look at that header line again – does the IP for rt.njabl.org look familiar? Yep – that’s the default internal IP for an SBS – and by default, our Exchange is configured to allow relaying via that IP. So this client’s SBS relayed njabl.org’s test message, not because it was an Open Relay, but because it just so happened that their server used to send the test message is publicly advertising a private IP that happens to be allowed.
I emailed njabl.org about this, and requested that they reconfigure their sending server to advertise a public IP, as they will be getting false positives from our SBS boxes in a default configuration.
So – my recommendation for the time being is to do a search on njabl.org to verify that your SBS servers are not wrongly listed as Open Relays, and to edit your Default SMTP Virtual Server relay settings by removing the IPs from the allow list. Under normal conditions, this will not affect your performance / functionality at all, but will protect you from being wrongly listed as an Open Relay by njabl.org if they don’t change their current procedures.