Harrowing (but Successful) False-Positive

[lawless]

I've just spent about three weeks finding the solution to an aggravating problem with SpamCop false-positives. I'm sharing the solution here to help others. If you're abruptly getting lots of false-positives, see the instructions below on how to check for a likely cause.

I had always believed that SC traces e-mail as far back as possible using "Received:" headers, and then uses that farthest-back point for reporting the miscreant. This is essentially true, but over the years SC has become much less trusting of intermediate relays--apparently with good cause. Lately, with the explosion of spam, SC is seeing spam coming from a variety of ostensibly respectable sources.

So I was quite surprised when suddenly ALL my e-mail from valid correspondents started getting tagged as spam. As it turns out, my web and e-mail hosting provider Tierra.NET has inbound mail relays that can be abused by spammers for sending outbound spam. Tierra is otherwise a great provider, but they appear to be idiots when it comes to spam control and prevention and relay management. They have web-host customers on their inbound mail-relay servers. Spammers sign-up for web-hosting accounts and then use 'perl' and PHP scripts to blast out huge volumes of spam. These get reported and the relays get block-listed. Then valid-source e-mail inbound to innocent bystanders gets marked as spam by SC.

I figured all that I needed to do was change to another host provider who runs clean relays. A nice idea in theory--fuggedaboutit in practice. I tried iPowerWeb first. Their misconfigured 'qmail' relays produce SC-unparsable "Received:" lines, so after about two days my own reports got their relays SC block-listed. Then I tried ValueWeb. They're somewhat better, but they use the same bank of several dozen relays for inbound-forwarding and outbound mail. These relays get SC reports and are susceptible to sudden-total-false-positive syndrome. Their flat-out refusal to correct the problem and the very slow relays they operate convinced me to take the money-back guarantee.

In the end, they all pretty much suck on the SC front. Tierra is the best host provider in my opinion, so I kept them. I wasn't ready to try out a fourth provider.

Finally I found the solution. An outfit in Toronto, EasyDNS.COM, runs a squeaky-clean mail relay (aka MX). I registered the .NET variation of my .COM domain at my old provider and renamed my hosting account to .NET. At the same time I subscribed to EasyDNS and transferred my .COM DNS and e-mail forwarding to them. Then I established a mail-forwarding map with their web control-panel to forward most of my e-mail through SC and some of it directly to my newly named .NET hosting "shadow" account.

If you choose to do this, here are some pit-falls:

1) Don't register your "shadow" domain at EasyDNS. If you do EasyDNS, creates a "parking" entry on their DNS servers that will prevent your "visible" domain from forwarding e-mail directly to your "shadow" domain. This happened to me. It required a manual configuration change by EasyDNS personnel to delete the "parking" DNS and mail-map entries (they are very competent). It's better to avoid this hassle.

2) EasyDNS's relay will reject your e-mail for a few minutes to a few hours when you switch your MX to them. You should edit your MX entries to make their server your secondary MX until their systems recognize your visible domain. This can be checked by configuring an alternate e-mail client personality that references their MX in the outbound SMTP field. Then send yourself an email periodically until they stop bouncing. Note that the EasyDNS relay will never accept e-mail to any destination other than your own account.

3) Watch out for the timing and dependencies of all the steps. It takes about 24-hours for a redirected 'whois' to take effect. I got away with little trouble because I had my .COM at ValueWeb by the time I decided to go with EasyDNS. The .NET register and rename was done on my old account while it was inactive. I haven't thought-through how to pull this off without the third provider.

4) Network Solutions' advanced-DNS sucks! If you are using this facility, transfer any domains you have registered with them to Tierra's DomainDicover before you proceed. When you redirect your 'whois' from (for example) ValueWeb to EasyDNS, Network Solutions deletes your DNS entry from their servers immediately. As a result your domain will be in "does not exist" limbo for twelve to eighteen hours.

So that's my advice for anyone who hates SC false-positives and doesn't want to spend weeks digging around for a solution. If you want to check how good or bad your provider is, do this:

1) Run 'nslookup -type=MX yourdomain.com'. This can be done in a "command prompt" window on Windows NT, 2000 & XP. Here's a web-page that does the same thing for those who are afraid of a DOS prompt: http://www.zoneedit.com/lookup.html.

2) Enter the raw IP for each of the MXs listed in SC's block-list checker at http://mailsc.spamcop.net/bl.shtml. If any of the relays have recent reports or recent "spam trap" activity, you are at risk. If one is block-listed, you are already screwed. Older report samples are shown at the bottom of the page. If any occurred within the last month or two, you should ask your ISP to explain it. If you get a brain-dead answer, start worrying.

Finally I should mention that another approach exists for the hard-headed and technically astute. You can setup your own MX while making sure that it's not an open relay. This is not for the faint-of-heart. Don't try it unless you know what you are doing or are willing to spend a few days beating your head against the wall learning. Mine is still sore.

[lawless]

I forgot to mention another significant issue.

As soon as I discovered that Tierra has mail relays that get block-listed by SpamCop, I immediately setup my own outbound mail relay. I don't want spam-tainted relays at the web-hoster causing my e-mail to get blocked on its way past mail relays that subscribe to the SpamCop BL. If you have a static IP address and a Linux or UNIX system, setting up an outbound mail relay is relatively easy. Just make sure your inbound SMTP port is blocked by your router. Having a static IP is mainly about not inheriting an address recently used by a spammer via DHCP.

I'm reasonably sure that none of 'sendmail', 'postfix' or 'qmail' run on Windows platforms, so you're stuck with Exchange if you want to relay from a Windows system. Don't ask me for help on that one.

Since I had no success finding a web-host provider with clean relays, finding one with clean outbound relays is probably a near impossibility. EasyDNS doesn't allow outbound relaying. Good luck finding one if you're not prepared to setup your own.

Configuring a clean two-way relay, as I finally did, is more difficult than setting up a outbound-only relay. It requires an "access" DB to permit the local systems to send mail out and "virtual domain" and "virtual user" tables to translate and forward inbound e-mail for just your domain while preventing abuse by spammers. I created a minimal 'sendmail' configuration that does this, and will share it with anyone who wants help. It's just a few lines, but it took a day to work it all out.