Status:

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 "never".

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 "test@example.com" 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 increase.

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.