Tales of a Fourth Grade Nothing

As an aide-memoire, here is a quick way to prevent fetchmail from logging Server certificate verification error: certificate not trusted messages.

1. Create a certificates directory
   mkdir -p /usr/local/etc/fetchmail/certs
2. Change to a temporary directory
   cd $TMPDIR
3. Get the certificate from your POP3 server
   echo | openssl s_client -connect <pop server>:993 -showcerts > info
   where <pop server> is your mail server
4. Extract the security certificate
   sed -n "/^--*BEGIN/,/^--*END/{p;/^--*END/q;};d" info > /usr/local/etc/fetchmail/certs/<pop server>.pem
5. Find the certificating authority
   grep issuer= /tmp/info
6. Get the appropriate root certificate, for example:
   wget http://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem
7. Move the root certificate into place
   mv GeoTrust_Global_CA.pem /usr/local/etc/fetchmail/certs
8. Create hashed symlinks
   c_rehash /usr/local/etc/fetchmail/certs
9. Append the following to the fetchmail configuration file
   sslcertck sslcertpath /usr/local/etc/fetchmail/certs
10. Restart the fetchmail daemon

And, obviously, check the logs to confirm the validity of the change and send a few test mails from a remote server to check that everything is working as expected...

Slightly against my better judgement, I've decided to follow the path of least resistance by ditching my current email solution and give Outlook Web Access a whirl. My initial feelings are:

• it isn't nearly as horrible as I'd expected; certainly nothing like as bad as Outlook 2003
• the lack of proper regexps and booleans makes writing mail filters a total chore
• quoting is completely and utterly broken in a way that defies belief
• the shortcuts are horrible and I reserve the right to switch back to a console-driven client

It has also made me realise just how short of resources my desktop system is. It's been prone to bouts of swapping for a while, but in the last few days the problem has gone from acute to chronic: grindingly slow interactive response punctuated by periods of catatonia when it starts to thrash. Time, I think, to swap it for one of the no-longer-used and better specified application analyst machines from a few desks down.

After having spent a while setting up Postfix on my NetBSD box, I decided, somewhat perversely, to move my mail services over to Debian on my slug.

The process of configuring the slug was generally pretty straight forward. All I did was install Postfix with apt-get, copy across the configuration files from my BSD box, modify main.cf to correct the locations of the various binaries — all extra packages installed on NetBSD go into the /usr/pkg directory — and tweak the start up scripts.

The only problem I experienced was, as always, with SMTP auth to my ISP's mail server. I checked the log and found that postfix was complaining about SASL: "warning: SASL authentication failure: No worthy mechs found" It transpired that the problem was due to a missing package: libsasl2-modules is required when using SMTP auth with Postfix but isn't included in the standard bundle of dependencies. All I had to do was install the missing module and, presto chango, my mail server was peachy-kean and willing to handshake with my ISP.

Ever wanted to get postfix authentication working under NetBSD? Well, it's not actually all that difficult. Here's a quick guide to doing it from scratch:

1. Install pkgsrc
Download the tarball from the NetBSD web site. Bootstrap the installation as follows:

cd /usr/pkgsrc/bootstrap; ./bootstrap
cd /etc
ln -s ../usr/pkg/etc/mk.conf .

2. Set Postfix Options
Edit /etc/mk.conf to add the option "PKG_OPTIONS.postfix+=sasl"

3. Build and Install Postfix
Build and install the package in the normal way:

cd /usr/pkgsrc/mail/postfix
make install

4. Build and Install cy2-plain
Build and install the auth package in the usual way (you might need other packages if you want to use something other than plaintext authentication):

cd /usr/pkgsrc/security/cy2-plain
make install

5. Setup the Configuration Files
Set up the postfix configuration files by doing the following:

cd /etc/postfix
mv main.cf main.orig
mv master.cf master.orig
ln -s ../../usr/pkg/etc/postfix/main.cf .
ln -s ../../usr/pkg/etc/postfix/master.cf .

6. Edit main.cf
Change the main.cf configuration file. It should contain something like the following (where "mail.isp" is the name of your ISP's SMTP relay host):

# Directory settings
command_directory = /usr/pkg/sbin
config_directory = /usr/pkg/etc/postfix
daemon_directory = /usr/pkg/libexec/postfix
queue_directory = /var/spool/postfix
sample_directory = /usr/pkg/share/examples/postfix
newaliases_path = /usr/pkg/bin/newaliases
sendmail_path = /usr/pkg/sbin/sendmail
mailq_path = /usr/pkg/bin/mailq

# User settings
mail_owner = postfix
setgid_group = maildrop

# Local settings
myorigin = $myhostname
mydestination = $myhostname localhost localhost.$mydomain
mynetwork_style = host
relay_domains =
relayhost = [mail.isp]
notify_classes = resource, software

# SASL settings
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/usr/pkg/etc/postfix/sasl_passwd
smtp_sasl_security_options =

7. Setup the SASL Password File
Create the password file as follows:

touch /usr/pkg/etc/postfix/sasl_passwd
chmod 0600 /usr/pkg/etc/postfix/sasl_passwd

Then add the lines:

[mail.isp] username:password

Replacing "[mail.isp]" with the name of your SMTP relay host. Create the password hash with:

postmap hash:/usr/pkg/etc/postfix/sasl_passwd

8. Configure the Startup Scripts
Add the following to /etc/rc.conf.d/postfix:

required_files='/usr/pkg/etc/postfix/main.cf'
start_cmd='/usr/pkg/sbin/postfix start'
stop_cmd='/usr/pkg/sbin/postfix stop'
reload_cmd='/usr/pkg/sbin/postfix reload'

9. Start Postfix
Start the daemons by hand:

/usr/pkg/sbin/postfix start

10. Test the Configuration
Try sending a message to a user on the local machine. If this works, try sending a message a remote user. Examine the mail log and confirm that the relayhost has accepted the message — the smtp server should report something like "status=sent (250 OK id=XXX)" if the message has been accepted.

The trick to setting up SMTP client authentication with sendmail seems to be the following:

1. mkdir -m 700 /etc/mail/auth
2. vi /etc/mail/auth/client-info
3. Dump the following into the file: 'AuthInfo:smtphost.isp "U:localuser" "I:remoteuser" "P:smtppassword" "R:smtphost.isp" "M:DIGEST-MD5 CRAM-MD5 LOGIN PLAIN"' with the various bits and pieces tuned to reflect your setup.
4. cd /etc/mail/auth; makemap hash client-info < client-info
5. vi /etc/mail/sendmail.mc
6. Add 'FEATURE(`authinfo',`hash /etc/mail/auth/client-info')'
7. m4 sendmail.mc > sendmail.cf
8. kill -HUP `cat /var/run/sendmail.pid`

Easy when you know how...

Discovered how to mark messages as read using procmail and maildir today. Turns out the trick involves renaming the mail after it's been delivered, thus:

MAILDIR=$HOME/Maildir :0 c $MAILDIR/ :0 ai * LASTFOLDER ?? ()\/[^/]+^^ | mv $LASTFOLDER $MAILDIR/cur/$MATCH:2,S

Way more complicated than using formail to add a "Status: RO" as used to be the way of things with mbox.