Vale SORBS, we’ll hardly miss ye…

SORBS is on death’s door.

I can’t say I’m unhappy to see this or i’ll miss it when it’s gone. An arbitrary definition of “spam” is not so good; providing almost no information to administrators and end users is just plain poor and demanding a “donation” for removal is just plain bovine excrement.

Something I learned from my formative years as a neophyte mail admin-in-training on news.admin.net-abuse.email was that if you wanted to run a blacklist and be taken seriously, you need a fair deal of transparency (ie provide info on why/how a server got listed and a means to resolve the issue) and fairly sane and personable demeanour, and a clear and stricly enforced policy on listing.

Unfortunately SORBS failed all of these in my experience.

One of my old jobs was to handle abuse@ at a Large Australian Hosting Provider (now part of MelbourneIT) along with my regular systems admin / support duties.

Alas, as unfortunately happens in large network / hosting ops, a customer spews some junk. We found and terminated the perp, but not before getting blacklisted.

A quick check of the major lists found the evidence / reason for listing and after informing them that we’d resolved the issue removal was quite swift.

But not SORBS. After jumping through a couple of hoops to find out how / when the servers got listed, no evidence for it’s addition was found aside a single “Recieved:” email header – which is easily forged (and at the time quite popular with spammers to confuse less experienced users/admins)

Our request for more information was met with little more than “I have proof, but I’m not sharing any more” and removal was met with “Donate to the fund supporting Mr Anti-Spammer, who’s being sued for defamation by WeSpamYou Pty. Ltd and I’ll remove it” (names spared to protect the innocent).

W.T.F? Of course the answer was “no” (with the backing of management) especially after I pointed out the case had been settled, in the anti-spammer’s favour. This was changed to a “donate to $charity” after I reminded Mr/Ms Sullivan of that fact.

It still didn’t act as a deterrent (even Legal pointing out that it’s potentially extortion didn’t work!) so I just gave up and stopped bothering with him. You know what they say about arguing with an idiot – they bring you to their level and beat you with experience.

Henceforth, I’ve been advising mail administrators not to use SORBS zones. Customers getting bounces mentioning SORBS got a boilerplate response outlining the situation and why using opaque and arbitrary lists are a Bad Thing (worded appropriately for on-forwarding to ISPs as applicable). I don’t recall ever getting one complaint, as most of the major ISPs here didn’t use it to block mail anyway and smaller players generally got the message once made aware.

There are far better alternatives that don’t generate so many false positives, catch more genuine spam and don’t shake down mail admins / abuse guys for removal. I personally use zen.spamhaus.org for my DNS blacklist needs and it’s never let me down in over 6 years (tied into a multitude of Postfix and Exim installs for small and large mail providers alike)

Mike’s Mailer Cookbook: SMTP auth, SASL and MySQL

I’m putting this up here as both a reminder to myself and just in case it’s useful to others.

I serve my IMAP user credentials (Courier in my case) from a MySQL backend and know from experience that my users find it very convenient to use the same set of credentials when sending mail with SMTP AUTH.

Now I can extract details and add them to /etc/saslauthdb2 et. al but a) it’s a little too fiddly especially when you’ve got all the security bells and whistles turned on and b) it seems like needless replication, and I’m big fan of KISS theory in systems admin.

So why not use the Cyrus-SASL SQL plugin:

  • Install the SQL plugin – “yum install cyrus-sasl-sql”
  • (For postfix) Create an “smtpd.conf” file in /usr/lib(64)/sasl2″ containing something similar to the following:

pwcheck_method: auxprop
auxprop_plugin: sql
mech_list: cram-md5 digest-md5
sql_engine: mysql
sql_hostnames: <my-db-server>
sql_user: <my-user-with-select-grant>
sql_passwd: <my-sql-password>
sql_database: <my-db-with-imap-creds?
sql_select: SELECT clear FROM passwd WHERE id = ‘%u@%r’ AND active = 1

  • Enable SMTP AUTH in  your config (Read The Fine Material for that)
  • Give it a test run with your MUA of choice.

I personally only offer CRAM/DIGEST (not plaintext LOGIN/PLAIN) because I’m paranoid – you mileage my vary; I also use the stock standard SQL schema that courier-authlib prefers and use user@domain (“%u” – user, “%r” SASL realm, commonly your domain) for virtual login names – adjust the sql_select statement above to suit your environment, and switch “clear” for “crypt” if you want to offer PLAIN / LOGIN instead.

I’ve been using this for what feels like forever but it’s cheap and has served me well; I’m always open to improvements though.