Wandering Thoughts archives


An open letter to free webmail providers

Dear free webmail providers: I have a simple request for you that will help the spam problem. Please stop allowing people to send out mail through your systems from IP addresses that are well known as heavy spam sources, especially of things such as advance fee fraud.

I got yet another '419' advance fee fraud spam today, sent through a free webmail provider. Selected headers are:

Received: from dbmail-mx1.orcon.net.nz ([]) [...]
Received: from webmail.orcon.net.nz ([])
   by dbmail-mx1.orcon.net.nz (8.13.2/8.13.2/Debian-1) [...]
From:   Ed Bahir <edbahir@orcon.net.nz>
Subject: Your Kind Attention Required Please!

The IP address is in the CBL, in the SBL, in SORBS, in Spews, in the AHBL, indeed it's somewhat hard to find a DNSbl that it's not in. One its two SBL listings is from January 2004, more than a year old by now.

Yet orcon.net.nz didn't bother to do anything, and blithely let this spammers send his email out. As a result, I (and likely a bunch of other people) got spammed. Also as a result, orcon.net.nz will not be able to send us any email any time soon.

Orcon.net.nz is far from alone in behaving with such little regard for other people. Major webmail providers also blithely allow CBL and SBL listed IP addresses to send out email through them, to the extent that I've made our antispam system do the checks for them. (Amazingly, all of it is advance fee fraud spam. Who would have thought?)

It's really past time that this stopped. That it doesn't stop makes me feel rather angry, and also feel that free webmail providers don't actually give much of a rat's ass about spam (whatever their public statements).

Dear free webmail software authors:

A lot of people just installed your webmail software without thinking about it. Maybe they haven't gotten '419' spam from free webmail providers themselves and can be excused for not thinking about it, but frankly I can't imagine that you have that excuse.

So please make your webmail software default to refusing to send out mail from IP addresses on the CBL and the SBL at least. You can do it with one DNS query to the XBL, so it's real easy. You can make it only a default, so someone who wants to can turn it off. But that way, at least your software would put some obstacles in the way of '419' spammers by default.

spam/WebmailBadSources written at 16:14:18; Add Comment

An unchanging system should be stable

One of my principles of system administration is an unchanging system should be stable. Stable means more than 'doesn't crash', it means 'doesn't need to be fiddled with all the time'; no hand-holding, no cleaning up afterwards. It means a system that can be left to run quietly in the corner.

This does mean that you have to make it so that ordinary things can't cause the system to explode. The two big ones are making sure that system logs don't get too big and that temporary directories like /tmp and /usr/tmp get cleaned out regularly. (Fortunately modern systems mostly do this for you.)

After I've done this, I've found that things that keep demanding my attention are usually symptoms of some deeper issue that I need to deal with:

  • I've failed to automate a necessary procedure
  • I need to fix or work around some piece of buggy software
  • there's a dying or broken piece of hardware somewhere
  • the systems are underconfigured or overloaded

There is a rare and unfortunate final case:

  • a vendor's stuck me with braindead software that demands I interact with it by hand.

And really, if the systems aren't overloaded, the users aren't asking for changes, and there's no buggy software or broken hardware, why should a system need attention? Everything left looks a lot like monkey make-work, whether self-inflicted or forced on you by vendors.

Sidebar: What about security?

New security issues are changes, and all changes require you to do things.

I feel that things that look for local security problems should only alert you if there is something you need to deal with, such as a reliable sign of a breakin.

(Keeping logs of other information is okay, but looking at them is usually just boredom inducing monkey-work; what are you going to do with the information, and is it actually productive?)

sysadmin/GettingStableSystems written at 03:20:47; Add Comment

By day for June 2005: 11 12 14 16 17 18 20 21 22 23 24 26 27 28 29; after June.

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.