Setting up imapd can be really frustrating. Actually, I take that back;
setting up secure imapd is the frustrating bit. This is mostly
due to the apparent lack of any customer-service talent from the folks who produce
imapd. Reading the documentation is akin to an experience with a lurking singular,
sinister attitude of mind. For example, here is a quote from imapd/docs/SSLBUILD:
"We can NOT provide you with support in building/installing OpenSSL, or in obtaining certificates. If you need help in doing this, try the contacts mentioned in the OpenSSL README."
Never mind the vagueness with "the contacts" or the lack of said references in the OpenSSL README. Or the clever use of all-caps with the element of the negative. Most of what they implement, they implement well. But where it doesn't work on the client end, or where it relies on outside sources (i.e., the "not us" syndrome), they deflect, deny, and blame others for not following the "official IMAP standards". Given that type of tone, I have to agree with Alan Cox who said it best regarding a similar issue with the same mindset:
"Take TCP for example. The TCP protocol is specified in a series of documents. If you make a formally correct implementation of the base TCP RFC you won't even make connections. Much of the flow control behaviour, the queueing and the detail is learned only by being directly part of the TCP implementing community. You can read all the scientific papers you like, it will not make you a good TCP implementor."
In other words, program to make your stuff work; don't just program by the book and blame others for not trying.
Historically, bad attitudes are associated with blaming, not fixing. Every discipline has elements of this to one degree or another. The key to surviving in a world where bad attitude is marketed as a customer-service template is simple: Understand that, when bad attitude is officially recognized and approved of by the Powers That Be, it's not "bad" anymore. In fact, it's a tremendous self-motivator towards group productivity and as a result frequently left alone by management. Without official endorsement, it lives only where dissenting sentiments can thrive at most companies or departments: underground. The kiss of death for bad attitude -- and therein lies the solution -- is to enact any attempt to domesticate it with rules or policies. Just the barest hint of management interference or regulation can splinter a cohesive "bad attitude" group culture. Which requires a somewhat unique balancing technique of management-endorsement along with the regulation of -- and not the restriction of -- said attitudes.
With that said, we must also be realistic. Where they lack in customer-service savvy, they make up for in functionality. So, when in Rome...
Modify directory permissions:
# chmod 1777 /var/spool/mail
Update /etc/services with:
imaps 993/tcp
pop3s 995/tcp
Update/etc/inetd.conf with:
pop3s stream tcp nowait.100 root /usr/sbin/ipop3d ipop3d
imaps stream tcp nowait.100 root /usr/sbin/imapd imapd
Clean up the imap source directory, if this is not your first build:
$ make clean
no-threads prevents building in support for multithreaded apps.
In the case of Apache, this actually increases performance, since Apache 1.3
does not use threads anyway. This prevents the overhead (memory and/or time)
relating to these locking mechanisms from happening and thus being wasted. -DSSL_FORBID_ENULL
prevents null encryptions. -fPIC is not needed unless you are planning
on using mod_ssl as a Dynamic Shared Object (DSO), which we aren't.
$ cd openssl-0.9.x
$ ./config no-threads -DSSL_FORBID_ENULL
$ make
$ make test
$ make install
$ cd ..
Edit imapd's Makefile to remark out the EXTRADRIVERS=mbox
line. This will speed up some of your mailbox requests, unless you depend on
this feature (see docs/CONFIG if you want the full details on why).
If you have problems with Nescape or Microsoft e-mail clients, you might examine
the BRAIN_DAMAGE setting options in src/imapd/Makefile and determine
if they're relevant to your situation.
$ cd imapd-src
$ make slx SSLTYPE=unix
$ cp c-client/c-client.a /usr/local/lib/libc-client.a
$ cp c-client/rfc822.h c-client/mail.h c-client/linkage.h /usr/local/include
$ cp imapd/imapd /usr/sbin
$ cp ipopd/ipop3d /usr/sbin
$ cd ..
For this bit, let's assume your domain is fluffygerbils.com, and your webserver is prefixed with "www". It will save you a lot of headache to not name your files "server.key" and so forth, as six months down the road you may not recall whether "server" refers to a purchased certificate, a self-created one, a self-created certificate authority, etc. So, let's name all our keys with the prefix "www.fluffygerbils.com" and add on the necessary suffixes. Here's a quick cheat sheet if you're not familiar with keys yet:
File in
/usr/local/ssl/certs/ |
chmod | Description |
www.fluffygerbils.com.key |
0400 | Your RSA Private Key. Should be 1024 bits in length. No one should have access to this file other than yourself. RSA is a public-key encryption technology developed by RSA Data Security, Inc. The acronym stands for Rivest, Shamir, and Adelman, the inventors of the technique. The RSA algorithm is based on the fact that there is no efficient way to factor very large numbers. Deducing an RSA key, therefore, requires an extraordinary amount of computer processing power and time. |
www.fluffygerbils.com.pem |
0400 | Your PEM (Privacy Enhanced Mail) Private Key. This is a copy of your RSA Private Key, but saved in a different format. |
www.fluffygerbils.com.csr |
0400 | Your CSR (Certificate Signing Request) file. This is what you need to submit to request your official SSL certificate. Once you have your official SSL certificate, you can archive this file. |
www.fluffygerbils.com.crt |
0444 | Your CRT (CeRTificate) Public Key. This is what you get from a Certificate Authority - your "SSL Certificate" - without this, you can't do web SSL. |
imapd.pem |
0444 | Your PEM (Privacy Enhanced Mail) Public Key. This is actually just a copy of your PEM Private Key and your CRT Public Key concatenated into a single file. Without this, you can't do SSL e-mail. |
ipop3d.pem |
Symlink | This should be a soft link to imapd.pem, or a copy of the same file. |
Definition of "Certificate Authority" |
N/A |
This is either an official organization, like VeriSign, or a fake organization that you create yourself. Yes, it seems silly to create a request to submit to yourself to be approved by yourself to send back a certificate to yourself. But, it has to be done unless you submit to a real organization. What's the difference? Web browsers and e-mail clients typically already know about official certificate authorities, whereas they don't know who you are. It's part security-related, part money-making. Take your pick. If you are primarily supporting non-tech-savvy folks, pay the money and go for the official certificate authority bit and save yourself having to answer lots of questions and touch each computer to install your own certificate authority file. There really is no difference in the security provided. If you want to be your own "fake" Certificate Authority, see http://www.modssl.org/docs/2.8/ssl_faq.html#ToC29.
|
5.1 Generate your RSA Private Key. Select five random files to feed the random number seeder.
# openssl genrsa -des3 -rand file1:file2:...:file5 -out www.fluffygerbils.com.key 1024
This command will generate 1024 bit RSA Private Key and stores it in the file
www.fluffygerbils.com.key. It will ask you for a pass phrase: use
something secure and remember it. Your certificate will be useless without
the key. Make sure you BACK UP your key to someplace secure and make a note
of the pass phrase.
5.2 Generate your PEM Private Key. Essentially, the same file as your RSA Private Key, but saved in a different format.
# openssl rsa -outform PEM -in www.fluffygerbils.com.key -out www.fluffygerbils.com.pem
5.3 Generate your PEM Public Key. For this to work, you need to have either purchased or signed your own CRT certificate.
# cd /usr/local/ssl/certs
# cat www.fluffygerbils.com.pem www.fluffygerbils.com.crt >imapd.pem
# ln -s /usr/local/ssl/certs/imapd.pem ipop3d.pem
5.4 Delete <-> unnecessary files and keep <+> others:
<+> hostname.key
<-> hostname.pem
<-> hostname.csr
<+> hostname.crt
<+> imapd.pem
<+> ipop3d.pem
Generating your Certificate Signing Request (CSR):
$ openssl req -new -key www.fluffygerbils.com.key -out www.fluffygerbils.com.csr
This command will prompt you for the X.509 attributes of your certificate.
Remember to give the name www.fluffygerbils.com when prompted for `Common Name
(eg, YOUR name)'. Do not enter your personal name here. We are requesting a
certificate for a webserver, so the Common Name has to match the FQDN of your
website (a requirement of the browsers).