UCE: Fighting Junk/UCE/Spam

If you haven’t noticed yet, we're really seeing an increase in the volume of junk-mail/uce/spam as of late. As far as tools go, the obvious one is Microsoft's IMF for Exchange 2003 SP2. It's a good tool (not to mention free), and I've personally worked with organizations as large as 3,000 mailboxes that use the IMF (and hey, Microsoft uses it internally for about some 70,000+ mailboxes, so it must work).

That said, I have to say that I'm a huge fan of the Barracuda spam firewall appliance. Now, I know that some people - including Andy, have experienced real problems with support. While I can't say I've run into the issue, I am aware of it. In my experience, it's a great tool - mostly because it "just works", but also because I have something to go back to and show clients when they talk about spam and the volume of junk mail that they receive. I also am a big fan of the Bayesian filter because it too, just works.

The recent increase of junk has caused us to receive more UCE-support requests, for which we go though and review the junk on a weekly basis depending on our client contracts, in order to build-up the Bayesian database for the Barracuda appliances. So far we’re keeping up; but the increase is notable.

UCE: Part 5 – SORBS blocking issue finally resolved

I just wanted to let everyone know that the SORBS DUHL inappropriate blocking of a customer static IP address has finally been resolved. I won't rehash all of this again, expect to link up my last post on the subject and provide a few suggestions.

It seems like the key to working with SORBS is to just accept the fact that they are virtually non-responsive. Know going in that it's going to take 1 to 2 months to resolve, then find a work-around, implement it, and hope.

The three big things NOT to do are:
1) Don't re-submit for delisting - even if the only response they provided was automated and promised you a quick turn-around.
2) Don't try calling or emailing anyone directly. Even if you find a contact, no one else I talked to could actually engage them.
3) Most importantly, if you're going to complain publicly, do it as anonymously as possible. Meaning, don't provide the domain name in question in the complaint. Just follow these three simple rules, and eventually you'll get delisted.... Hopefully... Maybe... Fun times.

UCE: Part 4 – SORBS blocking issues resolved? Nope.

As you might recall from previous posts, SORBS had incorrectly categorized a few of our customer’s static IP addresses as dynamic. This blocking was based on the response that SORBS received when doing a reverse DNS on the IP… the gist of it was that the IP didn’t look static enough for them. After contacting SORBS, and then engaging the ISP, the initial expectation set by SORBS was that they would respond in 2-15 days (who here thinks 2-15 days is in any way appropriate? ).

Having waited 30-days... yes, an entire month... SORBS did finally respond via their DUHL robot, which indicated that one of the IP’s had been “submitted for delisting from the DUHL”. A human response would be just been better… but okay, at least the issue was resolved.

Or so I though. That was 1 week ago.

After checking on and off for the past week, it seems that the IP address that had supposedly been submitted for delisting is still being blocked for the same reasons as before. Oh, and if I re-submit before the delisting, my request gets shuffled back to the bottom of the stack. How’s that for vindictive? No way to call, no way to engage anybody… just submit your requests and hope that your email stops getting blocked.

It seems like lots of people are having the same problems… SORBS even has an entry on Wikipedia, and be sure to check here as well… finally, do a search on SORBS. Plenty of bad press.

Make me wonder what the process looks like if someone is actually sending UCE/spam.

Fun times.

UCE: Part 3 – SORBS issues are on-going

Having previously posted concerning this and related topics, I just wanted to provide an update and let you know that the issue with the incorrect classification of IP ranges for a particular ISP by SORBS is ongoing. SORBS has yet to turnaround our request, and it has extended beyond what they consider a “reasonable” 2-15 day turnaround.

This has been a particularly difficult issue to get any traction on, as it’s next to impossible to engage SORBS, either directly or though the ISP (which has been very cooperative).

For each affected customer, we’ve started forwarding email traffic through the ISP’s SMTP servers, and this has proved to be a an effective workaround.

If and when something changes, I’ll post with the details.

UCE: Part 2 - SORBS Blocking Continued

We've had another customer report the same SORBS incorrect block/IP-classification issue as the one I posted about last week (different IP range). So as a continuation of the previous post, I'll add that the ISP submitted a request to SORBS for removal over a week ago, however SORBS has yet review the issue. While we're still within what SORBS considers to be a "reasonable" response time (2-15 days), it's definitely not meeting the customer's expectations.

This is becoming a frustrating process to navigate, as there’s no one at SORBS to contact (compare this to AOL’s process for resolving spam/uce issues). Secondly, their blocking process casts a wide-net (perhaps inappropriately so), and the removal process is primarily automated, resulting in IPs being rejected without human review. This puts the responsibility back on the user to prove to SORBS that they are making legitimate requests.

So while we continue to try to resolve the issue with SORBS, were left with two work-around options.

1) Work with the ISP to change the PTR record to point to the domain name, instead of the IP address (dsl-xxx-xxx-xxx-xxx.isp.com).

2) Forward email though the ISP's SMTP server

The ISP isn't confident that option 1 will resolve the issue, and since we need to expedite the resolution of this issue, we'll be going with option 2 - forwarding email from the Exchange server to the ISP's SMTP server for mail delivery, instead of using DNS to route for delivery.

What makes this such a problem is that none of the customers experiencing this issue are doing anything wrong… SORBS simply doesn’t like the way the PTR records shows up when doing a reverse DNS lookup on the domain. Unfortunately, there's not much that can be done expect to work-around the issue right now, and to wait on SORBS to respond to the request.

UCE: SORBS is incorrectly identifying static IP addresses as dynamic

I recently had a customer submit a ticket indicating that they were unable to send email to a particular domain and that they were receiving an NDR. After asking them to send me a copy of the NDR, I started by checking DNSstuff to verify that the customer’s IP hadn’t been added to any block lists. With the exception of SORBS they hadn’t been added to any other lists. This fact was my first indication that the issue was probably not a spam/uce/virus issue on an internal host.

Having then received the forwarded NDR, it confirmed that SORBS had indeed added them to their block list.

Your host xxx.xxx.xxx.xxx was found in the DNS Blacklist at dnsbl.sorbs.net

After doing a lookup of the IP address in the SORBS database, I noted the following error:

Dynamic/Generic IP/rDNS address, use your ISPs mail server or get rDNS set to indicate static assignment

Just to get some further confirmation, I checked IP addresses in the range near the affected IP, and the entire range was actually block listed, with SORBS noting that the range was a dynamic range. Next, I confirmed that there wasn’t anything out of the ordinary going on in terms of hosts on the customer network sending out uce/spam/junk, and then proceeded to request that SORBS remove the blocked IP.

While waiting for a response for SORBS, I used nslookup to check out the rDNS information for this domain.

nslookup
set type=ptr
xxx.xxx.xxx.xxx

The nslookup results indicated that rDNS was setup properly, with the PTR pointing to “dsl-xxx-xxx-xxx-xxx.domain.com” (where xxx-xxx-xxx-xxx = the customer’s IP address).

The first response I received from SORBS support indicated that my delisting request was “rejected”, stating that the IP address in question was “dynamic”, and provided three options as far as a path-forward.

1) Send your email through your ISP's mail servers, as suggested in various places at our website.

2) Have your DNS data modified so that the listed IP address has a clearly non-dynamic rDNS. We suggest that you include the keyword "static" on this name, to avoid future listings. Also, insure that the TTL is set to no less than 43200 seconds (we recommend 86400).

3) Ask your ISP to get in touch with SORBS with the list of dynamic and static IP allocations within its network, so that our DUHL list can be updated. Note that many large ISPs do this periodically to reduce the inconvenience to its users. In this case, the communication must come from a RIR contact for the affected IP space.

The IP address is a static address - both our records, and the billing information confirms this, further it has been static for a number of years. Since option 1 wasn’t going to meet the customer’s needs, and since the ISP would need to handle making any changes to PTR records, we had to bring in the ISP on option three to request delisting on our behalf. We reported the issue to our ISP customer support, as well as to our ISP’s abuse address (e.g. abuse@yourispdomin.com).

SORBS specifically wants PRT's to identify addresses as static, and points to an RFC draft on suggested generic naming schemes as the source of this requirement, such that a PTR of "dsl-xxx-xxx-xxx-xxx.yourispdomain.com" might be considered to be dynamic, while a PTR of "dsl-xxx-xxx-xxx-xxx.static.yourispdomain.com" would fit the model that they want.

The ISP's Abuse Team was the first to respond, and indicated that SORBS is infamous for blocking based on PTR’s not looking static enough. They then submitted a request with SORBS on the customer’s behalf to prompt delisting.

As soon as I confirm that this issue is resolved, I will follow-up with a post.

Exchange, UCE: How to handle NDRs (Non-Delivery Reports)

A discussion that keeps coming up concerns how we should be handling NDRs for our customer installations. It seems that even with the higher-end anti-spam appliances, the “recommended” configuration is to generate bounced messages – even when the incoming mail is scored as decisively spam/uce.

So the question becomes, should we even generate NDRs at all?

Between the fact that incoming spam will invariably have a forged “From:” address, and that some organizations are recommending that we disable all NDRs – why even bother with the NDR?

It certainly doesn’t take too many complaints from your customer’s ISP or the re-addition of their IP/domain name to RBLs to cause your customer have serious misgivings about your service.

That leaves you with disabling NDRs across the board.

The first place to consider disabling NDRs is at the perimeter. So if you have a perimeter antispam appliance, consider not generating NDRs there. If your perimeter happens to be your Exchange server itself, you might want to consider disabling NDRs in Exchange 2000 and 2003 , (see this link for Exchange 5.5).

Mail: Mail delayed when sending to Aol.com

We had a new customer contact us recently concerning issues with outgoing mail. Not too surprisingly, we found that their mail server (running Exchange 5.5) was being used as a relay. After cleaning that up, and submitting removal requests to RBLs, we received a follow-up call that they couldn’t send messages to AOL.com.

Apparently, whatever processes that AOL uses to detect and block IP addresses that are generating spam/uce traffic, doesn’t include an automated request for removal process.

So the first thing I did was a whois on aol.com, and found the technical contact phone number, and gave them a call. Thankfully it’s a support number for Sys/Mail admins to call when dealing with mail issues and aol.com. After holding for a reasonable amount of time (10 – 15 minutes), the person I spoke with was able to help address the issue.

They asked me for the static IP of the mail server in question, and then had me submit an email from a mailbox on my customer’s server to the address “ipconfirm@mailtest.mx.aol.com”, which automatically responded with my customer’s static IP to confirm. After that, they just looked-up the IP address, and confirmed my suspicions that the IP was automatically blocked during the spam-incident.