Accessing your email

Overview of the mail service

We recommend you read email using 'mutt'. Requests to have other email clients installed may be granted. Pine will not be installed due to a long history of security problems.

You should not have to do anything to send or receive mail on Once your account has been activated, our mailer software will accept all email for your username. The files created in your home directory should ensure that when you send mail using mutt, it will use the correct from name and address.

procmail is a mail pre-processor. It is capable of doing complex analysis of mail messages and performing various filtering operations that aid in managing mailing lists and fighting any spam that may slip through the system counter measures.

Mail is stored in the 'Maildir' format.

If you wish, you may use fetchmail to retrieve mail from other sites, and read it on our systems. You may place an email address in ~/.qmail-default if you wish your mail to be forwarded elsewhere.

Dovecot, the imap service, has been installed and is currently available for use in pre-auth mode via an SSH tunnel.

If none of this made sense to you do not worry. You do not need to understand it to read and send email.

Greylisting and greyfiltering is in effect as an anti-spam measure, and bmf and dspam have been installed from ports.

Reading and responding to email

Please see My first mutt for a new user introduction to mutt.

Dovecot imap in SSH pre-auth tunnel mode

Dovecot imap is available in SSH pre-auth tunnel mode. A configuration example for mutt is displayed below: (Tools like isync or offlineimap have handy features for offline imap folders).

set imap_idle=yes	# Keep imap connection open when idle
set folder=imap://	# Set this before using + to point
					# to mail folders.
set spoolfile=+incoming/
set mail_check=60	# Check all folders for new mail every N seconds. Don't
			# reduce this value. 
set timeout=10		# Scan current folder for new mail every N seconds. 
set tunnel="ssh -q MAIL='maildir:~/Maildir/' /usr/local/libexec/dovecot/imap" 

Use SSH multi-plexing to speed up mailbox access by logging into miracle (with ControlMaster auto) before starting mutt.

The Dovecot documentation is horribly lacking. Dovecot appears to only display mail folders starting with a dot, so you may need to link incoming to .incoming, sent to .sent, etc. Also, dots in filenames (e.g. "list.openbsd-sc" is treated as a folder, so mutt will display a directory called list with the openbsd-sc mail folder inside.

imaps with certificate authentication is still planned, but not high up on the priority list.

Troubleshooting missing email

As stated in our UCE policy, a small number of RBLs are used to prevent spammers and spammer friendly sites from delivering mail here. Any connection which has a source IP that is listed in one of the RBLs is dropped, and the email address in the ReturnPath header will get notified of the delivery failure by the MTA which attempted mail delivery.

Consequently, valid mail from any of your friends who may be using a spammer friendly site will actually get told if their attempts to send mail to you was rejected. Valid mail will not simply vanish without a trace.

If you feel you are missing email due to RBLs, check the RBL logs at or /var/www/users/stats/rejected-email to see if the site you are expecting mail from was rejected. Also, check your ~/Maildir/.procmail.log to see if the mail was delivered to a different folder than then one you expected.

RBL checking is done on a per machine basis, and cannot be done on a per user basis. The possibility of tagging based on RBL lookups have been considered and may be implemented when I have spare cash to actually pay for the extra IP traffic involved in receiving full spam messages instead of just rejecting mail based on source IP.

Privacy & Encryption

Our authentication requirements will protect the contents of the mail as it travels from to your workstation. However, this is slightly pointless as the message has just crossed the Internet in plain text.

To protect the contents of your messages, you need to rely on a higher layer than mail protocols. has GNU Privacy Guard installed and highly recommend that you start using it. However, there are certain things you need to realise before you do so.

By using GnuPG as installed on, you are making the following assumptions:

  1. You assume the staff has not trojaned sshd, gnupg or the system kernel to get your GnuPG passphrase.
  2. You assume the staff has not, either through incompetence or neglect, allowed attackers to compromise the system.

You need to decide for yourself if these assumptions are safe for you to make. If they are, you should be able to go ahead and make use of GnuPG. If not, you may want to create a GnuPG key pair that you use exclusively for mail sent and recieved through That way, if your assumed web of trust fails, your GnuPG key may have been commpromised, but your original GnuPG key is still good.

You may want to leave out the greeting when gpg starts and the version in clear-text signatures. We use encrypted swap memory so you can safely ignore the "secure memory" warning. You may supress all of these by editing your ~/.gnupg/options and adding:


An alternative to placing encryption keys on miracle would be to use imap and read/decrypt mail locally on your client.

Using virtual mail hosts

Suppose you have registered and arranged to use miracle as MX for this domain. You will recieve all mail for this domain to your miracle account, unless you state otherwise.

To maquerade outgoing mail, add the following to your .profile
MAILNAME='Your Full Name'

These variables can also be set in ~/.ssh/environment if you want your real userid and name on CVS commit messages.

Mutt configuration notes

The system-wide mutt configuration is in /etc/mutt/Muttrc. User specific options go in ~/.muttrc which can also be used to override system-wide options. Users are encouraged to study the system-wide file and consult muttrc(5) for the exact meaning of options.

Procmail configuration notes

The system-wide configuration is placed in /etc/procmailrc. If you want to create your own ~/.procmailrc you should copy this file and add your own options. ~/.procmailrc cannot be a symlink.

The order of rules is important, and generally, only the first match is used. The following entry filters dublets before you ever see them, and stores the msgid of the previous 8192 messages in msgid.cache. This should probably be one of your first rules.

:0 Wh: msgid.lock
| formail -D 8192 msgid.cache

This entry kills HTML email:

* Content-type: text/html

Use Sender, List-Id or something similar from the header to match mailing list mail. Avoid trying to match on To, Cc or Bcc. If you postfix the folder with a slash, procmail will write the mail to a Maildir.

* List-Id: <secprog\.list-id\.securityfocus\.com>

* Sender: owner-source-changes@openbsd\.org

Notes on creating mailinglists

Some brief notes, stolen from

A user of types:

$ ezmlm-make ~/SOS ~/.qmail-sos userid-jokes

and instantly has a functioning mailing list (seemingly for distribution of jokes),, with all relevant information stored in a new ~/SOS directory. This location can be anywhere the user has write access.

The listname you specify must contain your userid. If you want to create a list which does not contain your userid, contact staff. If hosts an MX for you, you may create lists on this domain at will by replacing with your domain name in the ezmlm-make command.

ezmlm sets up joe-sos-subscribe and joe-sos-unsubscribe for automatic processing of subscription and unsubscription requests. Any message to joe-sos-subscribe will work; The list admin doesn't have to explain any tricky command formats. ezmlm will send back instructions if a subscriber sends a message to joe-sos-request or joe-sos-help.

ezmlm automatically archives new messages. Messages are labelled with sequence numbers; a subscriber can fetch message 123 by sending mail to joe-sos-get.123. The archive format supports fast message retrieval even when there are thousands of messages.

ezmlm takes advantage of qmail's VERPs to reliably determine the recipient address and message number for every incoming bounce message. It waits ten days and then sends the subscriber a list of message numbers that bounced. If that warning bounces, ezmlm sends a probe; if the probe bounces, ezmlm automatically removes the subscriber from the mailing list.

ezmlm is easy for users to control. The user can edit ~/SOS/text/* to change any of the administrative messages sent to subscribers. He can remove ~/SOS/public (removing this file is strongly recommended) and ~/SOS/archived to disable automatic subscription and archiving. He can put his own (any) email address into ~/SOS/editor to set up a moderated mailing list. He can edit ~/SOS/{headeradd,headerremove} to control outgoing headers.

To view who is subscribed to your list, type:

$ ezmlm-list ~/SOS

Vacation messages

You may use the vacation(1) program to mail out vacation notices when you go away for longer periods of time. The program will not spam posters to mailinglists, and it will only mail out one notification per vacation.

The vacation program expects ~/.vacation.msg containing your with SMTP headers. You can use this template:

From: Full Name <>
Subject: Away until Date/Month
Precedence: bulk

This is an autogenerated message. Feel free to send more mail; you will
only receive this message once.

I am away on vacation, returning x/y. For queries related to FOO, contact
FOO Master at

Full Name

When you have created the message, insert the following near the top of your ~/.procmailrc, replacing userid with your system login.

| /usr/bin/vacation userid

When you return from vacation, prefix those two lines with # and delete ~/.vacation.db so that vacation will send out notices next time you go on vacation. Go through your mail, and delete most of it because there is just too much of it to read anyway.

Help! It appears I'm not getting any mail!

This is what you do if you think you're not getting mail to your miracle account.

Sign into two sesions, one running mutt, the other running tail -f ~/Maildir/.procmail.log. From mutt, send a message to your local email address. An entry should appear immediately in your .procmail.log showing the message as received and telling you where it was stored. You should be able to find the message in your inbox in mutt. If so, local mail works.

While keeping the .procmail.log open, send mail to your miracle account from somewhere else. Remember: If you never sent mail to miracle from that place before, the outbound mailserver will be subject to greyfiltering so an actual delivery make not take place for 30 minutes or more. You might want to ask a friend who sends you mail all the time to send you a test mail, as to avoid the greylisting delay on unknown systems. Again, you should see an entry in .procmail.log within a few minutes, and if so, remote mail works also.

Maybe your actual email address doesn't end in '', which means you have mail hosted here or somewhere else. Check that the domain MX records are correct with:

$ host -t MX mail is handled by 50

If your mail isn't handled by miracle, you need to make sure your external MX host works.

If you need any help finding the cause of your mail issues, talk to Daddy Chief.