If anyone has some config examples for other MTA’s, or knows if postfix will support TXT lookups, please let me know. Otherwise, I’ll write something up later myself.

The oil industry seem to be particularly bad, and having two marketing companies using our service and a chain of casinos also make for fun times when using various filters.

A couple of months ago I implemented some tighter spam controls. Basically, enforcing the RFCs a bit more tightly because we know spammers take short-cuts. Most of these controls are still in place, but I’ve had to exempt several of our customers due to complaints that email wasn’t getting through. It seems it’s not just spammers that take short-cuts - there are a lot of amateur mail admins out there, and we’re not just talking cowboys who’ve thrown an M$ Exchange server in without taking it out of its cellophane. We’re talking BIG companies (lots in the oil industry), technical companies, all sorts.

You’d think being strict with enforcing RFCs would be reasonably safe, but I’ve lost count of the number of mailservers that don’t have a postmaster address set up, that send from invalid addresses, don’t have reverse IP resolution set up etc. etc. etc. These are really good ways to catch out spammers at smtp time, but from time to time it catches a real email and I’m tired of explaining to customers that it’s the other guy’s mailserver that’s broken.

Many email RFCs have been broken, bent and ignored for so long that suddenly enforcing them breaks things.

Rejecting mail at SMTP time is the “right” way to do things. It reduces bandwidth, memory, cpu and disk usage and eliminates backscatter. In a large ISP the two main costs are power and bandwidth, and so there are real cost savings to be made by enforcing RFCs at SMTP time. It’s even good for the environment. By ruthlessly checking for a postmaster address I know that while I sit at my keyboard here, I’m doing my bit for the polar ice caps.

By fortunate coincidence, the most problematic of our clients *only* receive email from UK companies + a couple of known addresses that we can whitelist individually. So, if we could whitelist *everything* from the UK as well, we’d be pretty sure of not missing and valuable emails.

I’ve taken an old script of Dan Shearer’s (thanks Dan) for grabbing the IP ranges from RIPE, APNIC, AFRINIC, ARIN & LACNIC, updated it and hacked it around so it spits out zone files suitable for use with rbldnsd. If anyone else wants to make use of it, feel free. http://georbl.info/

The Scottish Open Source Awards opened today, 1st August 2007 at 9AM, for nominations and entries. The awards are open to business, government, education, not-for-profit, charities and students, who contribute to or use Open Source Software or services.

Press Release

Scottish Open Source Awards website.

rejected RCPT <joe@bloggs.com>: Previous (cached) callout verification failure

There are two solutions.

The first is to turn off callout caching using the no_cache option in exim.conf. eg:

verify = recipient/callout=no_cache

or you can flush the callout cache. Simply -HUPing or restarting exim won’t do. You need to delete the cache manually:

cd /var/spool/exim/db
mv callout callout.deleted  # or just delete it

Debian 4.0 (Etch) became the stable version of Debian yesterday. If you’ve been using Etch prior to this, you will need to add security updates to your sources.list:

#
#  /etc/apt/sources.list
#

#
# etch
#
deb     http://ftp.uk.debian.org/debian/     etch main contrib non-free
deb-src http://ftp.uk.debian.org/debian/     etch main contrib non-free

#
#  Security updates
#
deb     http://security.debian.org/ etch/updates  main contrib non-free
deb-src http://security.debian.org/ etch/updates  main contrib non-free

Running apt-get update you may run into these errors:

W: Conflicting distribution: http://security.debian.org stable/updates Release
     (expected stable but got etch)
W: You may want to run apt-get update to correct these problems

Check your sources.list file again, and explicity use “etch” instead of stable as on some mirrors they don’t seem to be the same thing, yet. Then re-run apt-get update.

Welcome to Debian 4.0!

What’s New
Release Notes
Upgrading from Sarge to Etch

The legal stuff:
http://www.dti.gov.uk/files/file35992.pdf

http://www.dti.gov.uk/innovation/sustainability/weee/page30269.html

Now our penguins are safe.

Anyone looking for amusement should head to their nearest computer shop and ask if they’ve “registered for WEEE”. Photos of the resultant facial expressions should be sent to me. Prizes awarded.

I’d write more on this, but so many have already.

If you’re attached to your Freeserve/Wanadoo/Orange account, but are sick of having your emails bounced, I suggest reading Andrew West’s Gmail workaround for Orange/Freeserve/Wanadoo customers with email problems.

If a spammer fakes an email address on someone else’s domain, some incorrectly configured mailservers receiving the spam will bounce the message back to the (apparent) sender. Meaning whichever poor schmuck has had their domain faked will get a huge pile of bounce messages. Thousands. Some misguided email administrators will even ban email from the domain and/or mailserver that appears to send the message.

Despite the abundance of information available on backscatter spam, there are still loads of mail servers that will happily bounce mail in this manner. Exim, Postfix and Sendmail, configured correctly, are all capable of dealing with this problem. If you’re looking for a reason to avoid using qmail, backscatter spam would be a good place to start.

The only time a mailserver should reject a message is at SMTP time. ie. when it is still connected to the sending machine. Once a mailserver has accepted an email for delivery it has made a commitment to deliver the email. Therefore a mailserver should never accept email that it isn’t able to deliver. Bounce messages should only be sent to local clients to indicate that their message did not get through.

I was very amused to find from my Google Webmaster Tools that I currently rank number 3 when searching for “alcohol unpacking software”. I suppose it’s only fair really - alcohol and computers make up such a large part of my life.

echo 1 > /proc/sys/net/ipv4/ip_forward

Ever wondered what all that stuff in /proc/sys/net actually does? Ok, a lot of it is pretty logical, but sometimes it’s nice to actually know with a bit more certainty. Today I broke something on a server because I assumed, instead of looking it up. Oops.

There’s a lot of documentation in the kernel sources which is surprisingly accessible to the non kernel hackers among us. First, get yourself a copy of the kernel source if you don’t have one. Take a look in /usr/src. If you don’t see a directory called something like linux-2.6.18, you probably don’t have the kernel source available. If you’re on a debian, ubuntu or other apt-based distro, you can apt-get the source for your kernel:

cd /usr/src
apt-get source linux-image-2.6.18-3-k7

Once your kernel source has downloaded and unpacked, cd into the source directory. You’ll find a directory called Documentation, and inside that a subdirectory called networking. The document we’re looking for in this case is ip-sysctl.txt. Open it in your favorite text editor.

  
/proc/sys/net/ipv4/* Variables:

ip_forward - BOOLEAN
        0 - disabled (default)
        not 0 - enabled

        Forward Packets between interfaces.

        This variable is special, its change resets all configuration
        parameters to their default state (RFC1122 for hosts, RFC1812
        for routers)

  

Have a browse around - there’s quite a bit of other doco. There’s an index file, 00-INDEX that lists what’s what.