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!).

Spanning Sync is finally out of beta and release 1.0 is available. They’ve adopted both an annual ($25) and once-off pricing model ($65).

In the few days I’ve been using it, I’ve been very impressed with the product. If you’re still fighting with synchronising calendars between devices, sharing calendars with others, etc. give it a try – the combination of Spanning Sync and Google Calendar seems to be a winner.

Over the years I’ve tried various approaches to try and synchronise calendars between the various electronic devices I use – laptop, home workstation, mobile phone and PDA. None of the approaches have been ideal because they’ve either required me to use applications I don’t want to (Outlook, for example) or they’ve required me to change the way I work.

The ideal solution would be for me to be able to maintain my appointments and tasks in whichever calendar is easiest to use at the time – typically my mobile phone’s calendar when I’m in meetings, Google Calendar when I’m at my desk and have access to the web and iCal when I’m at home. Anything I maintain in one calendar must be visible in the others.

Yesterday I finally got around to giving the combination of Google Calendar, iCal and Spanning Sync a try. My impressions so far? Definitely favourable. I’ve setup calendars in Google Calendar to match my iCal configuration, but I’ve also had to create iCal calendars for each of the public calendars I access in Google (see the screenshot below). Once that’s done, it’s a matter of synchronising Google Calendar and iCal using Spanning Sync and iCal and my mobile phone using iSync. Heck, if a Unix geek can do it, anyone can

Next step is to setup a calendar to share with my family so that we’re all aware of family events, school activities, etc. After that I’ll have to get them to actually use it…

It amazes me when I come across people who blindly block all traffic from bogons, but who don’t update their bogon lists at regular intervals.

My mail server currently sits in the 70.* block, which ARIN only released for use in January 2004. Of course, there are people with out of date bogon filters who still block traffic from my mail server over two years later (this is easy to spot as I can connect to them from a variety of other addresses, just not my mail server). I don’t see this often, but it’s enought to be mildly annoying. It really isn’t that difficult to update bogon filters automatically. I promise.

Just to follow up on last week’s post about the demise of BidPay – it seems that Jonathan’s experiences with Auctionchex have been favourable.

To quote:

[It] looks like auctionchex may be a good way to go for overseas payments:
(1) it is cheap – they make their money off the exchange rate differential (not through an extra $5+ like bidpay did), in fact they
only charged an extra R10.00 to post my cheque within the states.
(2) you don’t even need a credit card – you pay them by transferring into their FNB account.
(3) they have the appearance of being one of the smaller guys – which makes them easier to contact should there be problems.

Certainly sounds good to me.