March 4th: We are finished a major mail system overhaul. It is a massive
improvement over the previous system. It opens up a huge number
of options for us, and fixes some old issues. See the end for
list of why these changes are significant.
Coming soon: it is becoming clear that we need to run a SMTP
server on an alternate port (for all those clients with ISPs that
block connections to outside SMTP servers).
We will try to get this configured soon.
Major Issue: Eudora 6 and SSL (TLS actually)
Some e-mail clients (e.g. Eudora 6) are capable
of detecting that the new POP server can support SSL (via TLS). Eudora's
default setting is to use SSL when it is available, so it tries to do
that. Unfortunately it doesn't like the SSL certificate being used
and promptly halts with an ugly "SSL Negotiation Failed: Certificate
Error..." message. We do not believe this can be properly solved in a
virtual hosting environment.
The simplest fix is to turn off SSL :-(.
In Eudora 6 this is done from the Tools -> Options menu, clicking on the
'checking mail' icon and change "secure sockets when receiving" to
"Never" from its default "if available" setting.
If you'd rather have SSL working, then you'll need to go a few steps
further. This works on Eudora 6 and 5.1 (and maybe other versions?).
First, you need to have "secure sockets when receiving" (described above)
set to either "if available" or "start TLS", and you must let the system
try to connect and fail due to the unrecognized certificate. Once
that is done, you can tell Eudora to trust that certificate:
tools -> options
click on "checking mail"
click on "Last SSL Info"
click on "certificate information manager" (at the bottom)
click "Add To Trusted" (you're welcome to go into "View
certificate details" before doing this)
click Done and/or Ok as appropriate to get back
Eudora and IMAP. For some reason SSL and IMAP don't seem to
mix. The only fix seems to be setting "secure sockets when receiving" to
Other Issues (less commonly encountered).
Mailbox size limits. We used to purge old/stale mail in big
active mailboxes. We had no choice because the load
caused by cycling large mailboxes would bring
a webserver to it's knees. With this update, we no longer
scan purge old/stale mail from big mailboxes, which means that
some people are hitting the 50 megabyte mailbox limit! The immediate
fix is to turn down (or off) the leave-mail-on-server settings
for the e-mail client.
The new software limits the number
of simultaneous pop connections from one IP address. Currently
the limit is eight. (It was four). This can be a
problem for systems that poll the POP accounts and dump the mail
into other systems. At this point the fix is to breakup your list of
accounts and schedule it as smaller runs. (We are of the opinion
that any reasonable software would do that for you automatically
Yahoo: Some folks were using yahoo mail and having yahoo connect to
their pop account and retrieve their recent unread messages.
Unfortunately, the new POP server doesn't support the "last" command,
and we don't expect to replace that functionality. There are lots of
alternatives: The yahoo system can grab all your mail for you, or
you can have your mail forwarded to yahoo, or you can use one of our
webmail systems... http://yourdomain/cgi-bin/sm is a new and quite
nice system (squirrel mail).
There is a POP extension for sending mail. One or two clients were using
this. It was never officially supported, and no longer works. Sorry. Talk
to us! We will help you work around this.
Scripts on the webservers. If you have installed
scripts which parse mail spool files directly, this update will almost
certainly break them, as we are changing from mbox type spool files to
maildir spool files. That is a significant change in metaphors. Instead
of having one file that contains all your messages, all new messages
will be in one of two directories (new or cur). If your mailbox is
"firstname.lastname@example.org" then, then the files would be in
/example.vmail/spool/test/new or /example.vmail/spool/test/cur .
Benefits of This Change:
The main change is the way that mail is stored for retrieval. It has
changed from an "mbox" format to a "maildir" format. This is
significant because individual messages can be accessed much more
quickly and changes to the files do not require rewriting the
"whole spoolfile". The immediate result is a significant performance
Other benefits that we can get from this new system:
- we can now reasonably offer an IMAP service.
- we have put up a "real" webmail package
(http://yourdomain/cgi-bin/sm/) to take advantage of IMAP.
- SSL (or TLS) connections for mail. But if you've read the
Eudora notes above, you know this sword has two edges.
- POP-before-SMTP reliability improvements.
The new mail server software also implements pop-before-smtp
directly, which solves some reliablity issues with the old system,
where an extra daemon had to parse the logs and copy info
into the relaying database.
- The new mailserver software is being actively maintained and
should be more secure.
- Scalability. Maildir is "network safe", which means that we
can take the task of inbound mail handling away from the webservers
and deliver the mail over a network file system. If the spam and
virus epidemics continue, we will need this option soon.
- Spam filter training. With IMAP, one of the problems with trying
to train bayesian filters is easily solved. The problem was how do
you teach the filter what it's mistakes were?
- The ability to provide POP/IMAP service without requiring
a dedicated IP address.