unsigned long geek = random();

In the first part of this short series, I detailed the reasoning behind my need for a new mail server. In this second part, I’m going to detail my mail architecture as well as the software choices I made and why.

All mail for my various domains is delivered to the primary MX, which is a hosted server sitting in the US running Debian GNU/Linux (unfortunately my hosting provider doesn’t support NetBSD). It runs postfix and makes use of a variety of checks within postfix itself as well as postgrey for greylisting. I use a fairly conservative list of RBLs and, in conjunction with greylisting, they stop most spam from being accepted. Why postfix? Well, I stopped using sendmail over ten years ago, and although I’ve had good results with Exim in the past, these days I’m just most comfortable with postfix and it suits my needs perfectly.

The RBLs I use:

• zen.spamhaus.org
• cbl.abuseat.org
• list.dsbl.org

Once mail has been received by my primary MX, it is delivered to local mailboxes, one per user. None of the users read their mail from the US server, however. All the mail is downloaded to the local mail server via SSL-secured POP3 and accessed here, either locally or via IMAP. The local mail server is a Sun Ultra 2 running NetBSD/sparc64 3.1_STABLE.

Software I’m using on the local mail server:

• postfix
• dovecot for IMAP (over SSL) access. There are a number of IMAP/POP3 servers available, but I chose Dovecot because of its clean design, good security record and flexible support for mail storage, amongst other things.
• amavisd-new with spamassasin (with razor and Bayesian filtering enabled) and clamav for content filtering
• getmail to download mail from the US server
• mailgraph for simple reporting

All of the above are available in pkgsrc. As I have already done any RBL-based checks on the MX, I don’t do any of them locally.

I’ve been using basically the same approach for my personal mail for over twelve years - a curses-based client (currently mutt), mail storage in mbox format and reading my mail on the mail server itself, logged in via ssh. As can well be imagined, it’s starting to get a little long in the tooth:

• The mbox format has a number of limitations (locking, performance, etc), although it is convenient to have a mail folder housed in a single file. Using mbox format also prevents me from using a client that doesn’t support it.
• I have no convenient external access to my mail - if I’m not with a laptop, trying to read mail via an ssh connection from a mobile phone is rather uncomfortable.

To finally move into the 21st century, over the past few weeks I’ve put in place a new Sun Ultra 2 mail server, running NetBSD/sparc64. Over the next few days I’ll be discussing the configuration of the new server, focusing in particular on some of the challenges faced when using a slightly, er, unusual platform.

As part of my mail server rebuild (to be discussed in a future series of posts), I’ve been upgrading some of my mail system configuration files. One of them is fetchmail.conf, the configuration file for fetchmail, which I use to fetch mail from my mail server. It required a few changes after the upgrade to version 6.3.8 and a few changes in my environment.

A snippet from my updated configuration file:

        username user1 with password "pass1" is user1 here ssl fetchall
                sslfingerprint "BA:34:74:B6:7F:EF:A7:88:7C:7A:D1:8B:79:C5:10:D9"
                sslcertpath /etc/openssl/certs
                smtphost mail.relay.co.za
        username user2 with password "pass2" is user2 here ssl fetchall
                sslfingerprint "BA:34:74:B6:7F:EF:A7:88:7C:7A:D1:8B:79:C5:10:D9"
                sslcertpath /etc/openssl/certs
                smtphost mail.relay.co.za

Now, why on earth does one have to specify an SSL fingerprint, certificate path and mail server for each user? Wouldn’t it make more sense to have a global default and individual overrides where necessary? Chalk this up as another reason why I should move to getmail. Yes, I know I could add the functionality myself, but I really do need to move away from using an abomination before God to fetch my mail.

Note to self: this is the second “sucks” post in two days. Must remember to be more positive.

… when you’re on the receiving end of it


776354139 2946 Tue May 8 07:06:14 mj@turner.org.za
(host mail.netbsd.org[204.152.190.11] said: 450 : Recipient address rejected: Greylisting in action, please try later (in reply to RCPT TO command))
port-sparc64@netbsd.org

But seriously, although there are some valid criticisms of greylisting, it’s very effective at reducing spam, albeit at the cost of mail server and network resources. I just wish more mailing lists would make use of it - most of the spam I get these days is from lists that don’t have adequate anti-spam measures in place (Debian, FreeBSD and OpenBSD lists I’m looking to you!).

In the week I got a vodafone Mobile Connect 3G card courtesy of our IT department, who will be paying for the subscription and first 500MiB of traffic. My notebook currently runs Debian GNU/Linux 3.1 with kernel 2.6.13 and I had no difficulty getting the card working. It was simply a matter of making sure my kernel had support for the Option USB card (I have the Option 3G Quadlite card), inserting the card and configuring my PPP connection.

Some useful links:

• vodafone 3G on Linux, which includes Alan Barrett’s info on getting it working under NetBSD.
• MyADSL Linux 3G HOWTO.

I was browsing the MyBroadband forums this evening when I spotted this thread. Since the new Telkom tariffs came into effect at the beginning of November, it seems that ISPs reselling Telkom ADSL accounts have resorted to more frequent connection resets in order to ensure that subscribers don’t exceed their monthly traffic limits. Prior to 1 November, all ISPs reset connections every 24 hours (according to Telkom, in order to update RADIUS accounting, amongst other things).

From my understanding, this increase in reset frequence has been brought about by two things:

• Telkom now charges ISPs for actual ADSL traffic instead of for individual 3GiB accounts, as they did the past
• RADIUS traffic accounting is only updated at connection reset

In order to prevent situations where subscribers are able to download large amounts during the time between their penultimate and final connection resets before they reach their traffic limit, some ISPs are resorting to resetting connections every two hours. Yes, every two hours.

It seems as if the ADSL “broadband” market in South Africa is becoming more of a laughing stock by the month, primarily as a result of Telkom’s monopolistic practices.

I’ve been using ZoneEdit to provide DNS for some of my domains for a while now and I’ve been fairly happy with them. I haven’t had any outages and they’ve been pretty good at responding to my queries. The best thing: their service is free for the first five domains you host with them.

One thing that’s very nifty is that they support dynamic DNS, which is ideal for people who have a dynamic IP at home (like me). There are other free dynamic DNS providers, but they typically require you to register a hostname within one of their existing domains, which is not what I wanted. Others, who allow you to register any domain and update hosts within it dynamically, typically charge. ZoneEdit allow you to register any domain and update it using a dynamic DNS client, which is what I’ve done.

I have a slightly complicated setup because I have ZoneEdit’s servers listed as authoritative, but I update their servers via zone transfers rather than by using their web interface (ie I have a “phantom primary”). To allow me to support dynamic DNS for my home IP, I’ve created a subdomain which I’ve delegated to ZoneEdit and update using ddclient. Works rather well.