mirror of
https://github.com/uw-imap/imap.git
synced 2024-11-16 10:28:23 +01:00
4227 lines
152 KiB
HTML
4227 lines
152 KiB
HTML
|
<!--
|
||
|
* ========================================================================
|
||
|
* Copyright 1988-2007 University of Washington
|
||
|
*
|
||
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
||
|
* you may not use this file except in compliance with the License.
|
||
|
* You may obtain a copy of the License at
|
||
|
*
|
||
|
* http://www.apache.org/licenses/LICENSE-2.0
|
||
|
*
|
||
|
*
|
||
|
* ========================================================================
|
||
|
*
|
||
|
-->
|
||
|
|
||
|
<!--chtml set title="IMAP Toolkit Frequently Asked Questions"-->
|
||
|
<!--chtml include "//imap/incs/top.inc"-->
|
||
|
|
||
|
<h2>Table of Contents</h2>
|
||
|
|
||
|
<ul>
|
||
|
<li>
|
||
|
<a href="#general">1. General/Software Feature Questions</a>
|
||
|
|
||
|
<ul>
|
||
|
<li><a href="#1.1">1.1 Can I set up a POP or IMAP server on
|
||
|
UNIX/Linux/OSF/etc.?</a></li>
|
||
|
|
||
|
<li><a href="#1.2">1.2 I am currently using qpopper as my POP3 server
|
||
|
on UNIX. Do I need to replace it with ipop3d in order to run
|
||
|
imapd?</a></li>
|
||
|
|
||
|
<li><a href="#1.3">1.3 Can I set up a POP or IMAP server on Windows
|
||
|
XP, 2000, NT, Me, 98, or 95?</a></li>
|
||
|
|
||
|
<li><a href="#1.4">1.4 Can I set up a POP or IMAP server on Windows
|
||
|
3.1 or DOS?</a></li>
|
||
|
|
||
|
<li><a href="#1.5">1.5 Can I set up a POP or IMAP server on
|
||
|
Macintosh?</a></li>
|
||
|
|
||
|
<li><a href="#1.6">1.6 Can I set up a POP or IMAP server on
|
||
|
VAX/VMS?</a></li>
|
||
|
|
||
|
<li><a href="#1.7">1.7 Can I set up a POP or IMAP server on
|
||
|
TOPS-20?</a></li>
|
||
|
|
||
|
<li><a href="#1.8">1.8 Are hierarchical mailboxes supported?</a></li>
|
||
|
|
||
|
<li><a href="#1.9">1.9 Are "dual-use" mailboxes supported?</a></li>
|
||
|
|
||
|
<li><a href="#1.10">1.10 Can I have a mailbox that has both messages
|
||
|
and sub-mailboxes?</a></li>
|
||
|
|
||
|
<li><a href="#1.11">1.11 What is the difference between "mailbox" and
|
||
|
"folder"?</a></li>
|
||
|
|
||
|
<li><a href="#1.12">1.12 What is the status of
|
||
|
internationalization?</a></li>
|
||
|
|
||
|
<li><a href="#1.13">1.13 Can I use SSL?</a></li>
|
||
|
|
||
|
<li><a href="#1.14">1.14 Can I use TLS and the STARTTLS
|
||
|
facility?</a></li>
|
||
|
|
||
|
<li><a href="#1.15">1.15 Can I use CRAM-MD5 authentication?</a></li>
|
||
|
|
||
|
<li><a href="#1.16">1.16 Can I use APOP authentication?</a></li>
|
||
|
|
||
|
<li><a href="#1.17">1.17 Can I use Kerberos V5?</a></li>
|
||
|
|
||
|
<li><a href="#1.18">1.18 Can I use PAM for plaintext
|
||
|
passwords?</a></li>
|
||
|
|
||
|
<li><a href="#1.19">1.19 Can I use Kerberos 5 for plaintext
|
||
|
passwords?</a></li>
|
||
|
|
||
|
<li><a href="#1.20">1.20 Can I use AFS for plaintext
|
||
|
passwords?</a></li>
|
||
|
|
||
|
<li><a href="#1.21">1.21 Can I use DCE for plaintext
|
||
|
passwords?</a></li>
|
||
|
|
||
|
<li><a href="#1.22">1.22 Can I use the CRAM-MD5 database for
|
||
|
plaintext passwords?</a></li>
|
||
|
|
||
|
<li><a href="#1.23">1.23 Can I disable plaintext passwords?</a></li>
|
||
|
|
||
|
<li><a href="#1.24">1.24 Can I disable plaintext passwords on
|
||
|
unencrypted sessions, but allow them on encrypted sessions?</a></li>
|
||
|
|
||
|
<li><a href="#1.25">1.25 Can I use virtual hosts?</a></li>
|
||
|
|
||
|
<li><a href="#1.26">1.26 Can I use RPOP authentication?</a></li>
|
||
|
|
||
|
<li><a href="#1.27">1.27 Can I use Kerberos V4?</a></li>
|
||
|
|
||
|
<li><a href="#1.28">1.28 Is there support for S/Key or OTP?</a></li>
|
||
|
|
||
|
<li><a href="#1.29">1.29 Is there support for NTLM or SPA?</a></li>
|
||
|
|
||
|
<li><a href="#1.30">1.30 Is there support for mh?</a></li>
|
||
|
|
||
|
<li><a href="#1.31">1.31 Is there support for qmail and the maildir
|
||
|
format?</a></li>
|
||
|
|
||
|
<li><a href="#1.32">1.32 Is there support for the Cyrus mailbox
|
||
|
format?</a></li>
|
||
|
|
||
|
<li><a href="#1.33">1.33 Is this software Y2K compliant?</a></li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#requirements">2. What Do I Need to Build This Software?</a>
|
||
|
|
||
|
<ul>
|
||
|
<li><a href="#2.1">2.1 What do I need to build this software with SSL
|
||
|
on UNIX?</a></li>
|
||
|
|
||
|
<li><a href="#2.2">2.2 What do I need to build this software with
|
||
|
Kerberos V on UNIX?</a></li>
|
||
|
|
||
|
<li><a href="#2.3">2.3 What do I need to use a C++ compiler with this
|
||
|
software to build my own application?</a></li>
|
||
|
|
||
|
<li><a href="#2.4">2.4 What do I need to build this software on
|
||
|
Windows?</a></li>
|
||
|
|
||
|
<li><a href="#2.5">2.5 What do I need to build this software on
|
||
|
DOS?</a></li>
|
||
|
|
||
|
<li><a href="#2.6">2.6 Can't I use Borland C to build this software
|
||
|
on the PC?</a></li>
|
||
|
|
||
|
<li><a href="#2.7">2.7 What do I need to build this software on the
|
||
|
Mac?</a></li>
|
||
|
|
||
|
<li><a href="#2.8">2.8 What do I need to build this software on
|
||
|
VMS?</a></li>
|
||
|
|
||
|
<li><a href="#2.9">2.9 What do I need to build this software on
|
||
|
TOPS-20?</a></li>
|
||
|
|
||
|
<li><a href="#2.10">2.10 What do I need to build this software on
|
||
|
Amiga or OS/2?</a></li>
|
||
|
|
||
|
<li><a href="#2.11">2.11 What do I need to build this software on
|
||
|
Windows CE?</a></li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#build">3. Build and Configuration Questions</a>
|
||
|
|
||
|
<ul>
|
||
|
<li><a href="#3.1">3.1 How do I configure the IMAP and POP servers on
|
||
|
UNIX?</a></li>
|
||
|
|
||
|
<li><a href="#3.2">3.2 I built and installed the servers according to
|
||
|
the BUILD instructions. It can't be that easy. Don't I need to write
|
||
|
a config file?</a></li>
|
||
|
|
||
|
<li><a href="#3.3">3.3 How do I make the IMAP and POP servers look
|
||
|
for INBOX at some place other than the mail spool directory?</a></li>
|
||
|
|
||
|
<li><a href="#3.4">3.4 How do I make the IMAP server look for
|
||
|
secondary folders at some place other than the user's home
|
||
|
directory?</a></li>
|
||
|
|
||
|
<li><a href="#3.5">3.5 How do I configure SSL?</a></li>
|
||
|
|
||
|
<li><a href="#3.6">3.6 How do I configure TLS and the STARTTLS
|
||
|
facility?</a></li>
|
||
|
|
||
|
<li><a href="#3.7">3.7 How do I build/install OpenSSL and
|
||
|
obtain/create certificates for use with SSL?</a></li>
|
||
|
|
||
|
<li><a href="#3.8">3.8 How do I configure CRAM-MD5
|
||
|
authentication?</a></li>
|
||
|
|
||
|
<li><a href="#3.9">3.9 How do I configure APOP
|
||
|
authentication?</a></li>
|
||
|
|
||
|
<li><a href="#3.10">3.10 How do I configure Kerberos V5?</a></li>
|
||
|
|
||
|
<li><a href="#3.11">3.11 How do I configure PAM for plaintext
|
||
|
passwords?</a></li>
|
||
|
|
||
|
<li><a href="#3.12">3.12 It looks like all I have to do to make the
|
||
|
server use Kerberos is to build with PAM on my Linux system, and set
|
||
|
it up in PAM for Kerberos passwords. Right?</a></li>
|
||
|
|
||
|
<li><a href="#3.13">3.13 How do I configure Kerberos 5 for plaintext
|
||
|
passwords?</a></li>
|
||
|
|
||
|
<li><a href="#3.14">3.14 How do I configure AFS for plaintext
|
||
|
passwords?</a></li>
|
||
|
|
||
|
<li><a href="#3.15">3.15 How do I configure DCE for plaintext
|
||
|
passwords?</a></li>
|
||
|
|
||
|
<li><a href="#3.16">3.16 How do I configure the CRAM-MD5 database for
|
||
|
plaintext passwords?</a></li>
|
||
|
|
||
|
<li><a href="#3.17">3.17 How do I disable plaintext
|
||
|
passwords?</a></li>
|
||
|
|
||
|
<li><a href="#3.18">3.18 How do I disable plaintext passwords on
|
||
|
unencrypted sessions, but allow them in SSL or TLS sessions?</a></li>
|
||
|
|
||
|
<li><a href="#3.19">3.19 How do I configure virtual hosts?</a></li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#3.20">3.20 Why do I get compiler warning messages such
|
||
|
as:
|
||
|
|
||
|
<ul>
|
||
|
<li>passing arg 3 of `scandir' from incompatible pointer
|
||
|
type</li>
|
||
|
|
||
|
<li>Pointers are not assignment-compatible.</li>
|
||
|
|
||
|
<li>Argument #4 is not the correct type.</li>
|
||
|
</ul>during the build?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#3.21">3.21 Why do I get compiler warning messages such
|
||
|
as
|
||
|
|
||
|
<ul>
|
||
|
<li>Operation between types "void(*)(int)" and "void*" is not
|
||
|
allowed.</li>
|
||
|
|
||
|
<li>Function argument assignment between types "void*" and
|
||
|
"void(*)(int)" is not allowed.</li>
|
||
|
|
||
|
<li>Pointers are not assignment-compatible.</li>
|
||
|
|
||
|
<li>Argument #5 is not the correct type.</li>
|
||
|
</ul>during the build?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#3.22">3.22 Why do I get linker warning messages such
|
||
|
as:
|
||
|
|
||
|
<ul>
|
||
|
<li>mtest.c:515: the `gets' function is dangerous and should not
|
||
|
be used.</li>
|
||
|
</ul>during the build? Isn't this a security bug?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#3.23">3.23 Why do I get linker warning messages such
|
||
|
as:</a>
|
||
|
|
||
|
<ul>
|
||
|
<li>auth_ssl.c:92: the `tmpnam' function is dangerous and should
|
||
|
not be used.</li>
|
||
|
</ul>during the build? Isn't this a security bug?
|
||
|
</li>
|
||
|
|
||
|
<li><a href="#3.24">3.24 OK, suppose I see a warning message about a
|
||
|
function being "dangerous and should not be used" for something other
|
||
|
than this gets() or tmpnam() call?</a></li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#operation">4. Operational Questions</a>
|
||
|
|
||
|
<ul>
|
||
|
<li><a href="#4.1">4.1 How can I enable anonymous IMAP
|
||
|
logins?</a></li>
|
||
|
|
||
|
<li><a href="#4.2">4.2 How do I set up an alert message that each
|
||
|
IMAP user will see?</a></li>
|
||
|
|
||
|
<li><a href="#4.3">4.3 How does the c-client library choose which of
|
||
|
its several mechanisms to use to establish an IMAP connection to the
|
||
|
server? I noticed that it can connect on port 143, port 993, via rsh,
|
||
|
and via ssh.</a></li>
|
||
|
|
||
|
<li><a href="#4.4">4.4 I am using a TLS-capable IMAP server, so I
|
||
|
don't need to use /ssl to get encryption. However, I want to be
|
||
|
certain that my session is TLS encrypted before I send my password.
|
||
|
How to I do this?</a></li>
|
||
|
|
||
|
<li><a href="#4.5">4.5 How do I use one of the alternative formats
|
||
|
described in the formats.txt document? In particular, I hear that mbx
|
||
|
format will give me better performance and allow shared
|
||
|
access.</a></li>
|
||
|
|
||
|
<li><a href="#4.6">4.6 How do I set up shared mailboxes?</a></li>
|
||
|
|
||
|
<li><a href="#4.7">4.7 How can I make the server syslogs go to
|
||
|
someplace other than the mail syslog?</a></li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#security">5. Security Questions</a>
|
||
|
|
||
|
<ul>
|
||
|
<li><a href="#5.1">5.1 I see that the IMAP server allows access to
|
||
|
arbitary files on the system, including /etc/passwd! How do I disable
|
||
|
this?</a></li>
|
||
|
|
||
|
<li><a href="#5.2">5.2 I've heard that IMAP servers are insecure. Is
|
||
|
this true?</a></li>
|
||
|
|
||
|
<li><a href="#5.3">5.3 How do I know that I have the most secure
|
||
|
version of the server?</a></li>
|
||
|
|
||
|
<li><a href="#5.4">5.4 I see all these strcpy() and sprintf() calls,
|
||
|
those are unsafe, aren't they?</a></li>
|
||
|
|
||
|
<li><a href="#5.5">5.5 Those /tmp lock files are protected 666, is
|
||
|
that really right?</a></li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#strange">6. <i>Why Did You Do This Strange Thing?</i>
|
||
|
Questions</a>
|
||
|
|
||
|
<ul>
|
||
|
<li><a href="#6.1">6.1 Why don't you use GNU autoconfig / automake /
|
||
|
autoblurdybloop?</a></li>
|
||
|
|
||
|
<li><a href="#6.2">6.2 Why do you insist upon a build with -g?
|
||
|
Doesn't it waste disk and memory space?</a></li>
|
||
|
|
||
|
<li><a href="#6.3">6.3 Why don't you make c-client a shared
|
||
|
library?</a></li>
|
||
|
|
||
|
<li><a href="#6.4">6.4 Why don't you use iconv() for
|
||
|
internationalization support?</a></li>
|
||
|
|
||
|
<li><a href="#6.5">6.5 Why is the IMAP server connected to the home
|
||
|
directory by default?</a></li>
|
||
|
|
||
|
<li><a href="#6.6">6.6 I have a Windows system. Why isn't the server
|
||
|
plug and play for me?</a></li>
|
||
|
|
||
|
<li><a href="#6.7">6.7 I looked at the UNIX SSL code and saw that you
|
||
|
have the SSL data payload size set to 8192 bytes. SSL allows 16K; why
|
||
|
aren't you using the full size?</a></li>
|
||
|
|
||
|
<li><a href="#6.8">6.8 Why is an mh format INBOX called #mhinbox
|
||
|
instead of just INBOX?</a></li>
|
||
|
|
||
|
<li><a href="#6.9">6.9 Why don't you support the maildir
|
||
|
format?</a></li>
|
||
|
|
||
|
<li><a href="#6.10">6.10 Why don't you support the Cyrus
|
||
|
format?</a></li>
|
||
|
|
||
|
<li><a href="#6.11">6.11 Why is it creating extra forks on my SVR4
|
||
|
system?</a></li>
|
||
|
|
||
|
<li><a href="#6.12">6.12 Why are you so fussy about the date/time
|
||
|
format in the internal <code>"From "</code> line in traditional
|
||
|
UNIX mailbox files? My other mail program just considers every line
|
||
|
that starts with <code>"From "</code> to be the start of the
|
||
|
message.</a></li>
|
||
|
|
||
|
<li><a href="#6.13">6.13 Why is traditional UNIX format the default
|
||
|
format?</a></li>
|
||
|
|
||
|
<li><a href="#6.14">6.14 Why do you write this "DON'T DELETE THIS
|
||
|
MESSAGE -- FOLDER INTERNAL DATA" message at the start of traditional
|
||
|
UNIX and MMDF format mailboxes?</a></li>
|
||
|
|
||
|
<li><a href="#6.15">6.15 Why don't you stash the mailbox metadata in
|
||
|
the first real message of the mailbox instead of writing this fake
|
||
|
FOLDER INTERNAL DATA message?</a></li>
|
||
|
|
||
|
<li><a href="#6.16">6.16 Why aren't "dual-use" mailboxes the
|
||
|
default?</a></li>
|
||
|
|
||
|
<li><a href="#6.17">6.17 Why do you use ucbcc to build on
|
||
|
Solaris?</a></li>
|
||
|
|
||
|
<li><a href="#6.18">6.18 Why should I care about some old system with
|
||
|
BSD libraries? cc is the right thing on my Solaris system!</a></li>
|
||
|
|
||
|
<li><a href="#6.19">6.19 Why do you insist upon writing .lock files
|
||
|
in the spool directory?</a></li>
|
||
|
|
||
|
<li><a href="#6.20">6.20 Why should I care about compatibility with
|
||
|
the past?</a></li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#problems">7. Problems and Annoyances</a>
|
||
|
|
||
|
<ul>
|
||
|
<li><a href="#7.1">7.1 Help! My INBOX is empty! What happened to my
|
||
|
messages?</a></li>
|
||
|
|
||
|
<li><a href="#7.2">7.2 Help! All my messages in a non-INBOX mailbox
|
||
|
have been concatenated into one message which claims to be from me
|
||
|
and has a subject of the file name of the mailbox! What's going
|
||
|
on?</a></li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.3">7.3 Why do I get the message:
|
||
|
|
||
|
<ul>
|
||
|
<li>CREATE failed: Can't create mailbox node xxxxxxxxx: File
|
||
|
exists</li>
|
||
|
</ul>and how do I fix it?</a>
|
||
|
</li>
|
||
|
|
||
|
<li><a href="#7.4">7.4 Why can't I log in to the server? The user
|
||
|
name and password are right!</a></li>
|
||
|
|
||
|
<li><a href="#7.5">7.5 Help! My load average is soaring and I see
|
||
|
hundreds of POP and IMAP servers, many logged in as the same
|
||
|
user!</a></li>
|
||
|
|
||
|
<li><a href="#7.6">7.6 Why does mail disappear even though I set
|
||
|
"keep mail on server"?</a></li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.7">7.7 Why do I get the message
|
||
|
|
||
|
<ul>
|
||
|
<li>Moved ##### bytes of new mail to /home/user/mbox from
|
||
|
/var/spool/mail/user</li>
|
||
|
</ul>and why did this happen?</a>
|
||
|
</li>
|
||
|
|
||
|
<li><a href="#7.8">7.8 Why isn't it showing the local host name as a
|
||
|
fully-qualified domain name?</a></li>
|
||
|
|
||
|
<li><a href="#7.9">7.9 Why is the local host name in the
|
||
|
From/Sender/Message-ID headers of outgoing mail not coming out as a
|
||
|
fully-qualified domain name?</a></li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.10">7.10 What does the message:
|
||
|
|
||
|
<ul>
|
||
|
<li>Mailbox vulnerable - directory /var/spool/mail must have 1777
|
||
|
protection</li>
|
||
|
</ul>mean? How can I fix this?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.11">7.11 What does the message:
|
||
|
|
||
|
<ul>
|
||
|
<li>Mailbox is open by another process, access is readonly</li>
|
||
|
</ul>mean? How do I fix this?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.12">7.12 What does the message:
|
||
|
|
||
|
<ul>
|
||
|
<li>Can't get write access to mailbox, access is readonly</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li><a href="#7.13">7.13 I set my POP3 client to "delete messages
|
||
|
from server" but they never get deleted. What is wrong?</a></li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.14">7.14 What do messages such as:
|
||
|
|
||
|
<ul>
|
||
|
<li>Message ... UID ... already has UID ...</li>
|
||
|
|
||
|
<li>Message ... UID ... less than ...</li>
|
||
|
|
||
|
<li>Message ... UID ... greater than last ...</li>
|
||
|
|
||
|
<li>Invalid UID ... in message ..., rebuilding UIDs</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.15">7.15 What do the error messages:
|
||
|
|
||
|
<ul>
|
||
|
<li>Unable to read internal header at ...</li>
|
||
|
|
||
|
<li>Unable to find CRLF at ...</li>
|
||
|
|
||
|
<li>Unable to parse internal header at ...</li>
|
||
|
|
||
|
<li>Unable to parse message date at ...</li>
|
||
|
|
||
|
<li>Unable to parse message flags at ...</li>
|
||
|
|
||
|
<li>Unable to parse message UID at ...</li>
|
||
|
|
||
|
<li>Unable to parse message size at ...</li>
|
||
|
|
||
|
<li>Last message (at ... ) runs past end of file ...</li>
|
||
|
</ul>mean? I am using mbx format.</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.16">7.16 What do the syslog messages:
|
||
|
|
||
|
<ul>
|
||
|
<li>imap/tcp server failing (looping)</li>
|
||
|
|
||
|
<li>pop3/tcp server failing (looping)</li>
|
||
|
</ul>mean? When it happens, the listed service shuts down. How can
|
||
|
I fix this?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.17">7.17 What does the syslog message:
|
||
|
|
||
|
<ul>
|
||
|
<li>Mailbox lock file /tmp/.600.1df3 open failure: Permission
|
||
|
denied</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.18">7.18 What do the syslog messages:
|
||
|
|
||
|
<ul>
|
||
|
<li>Command stream end of file, while reading line user=...
|
||
|
host=...</li>
|
||
|
|
||
|
<li>Command stream end of file, while reading char user=...
|
||
|
host=...</li>
|
||
|
|
||
|
<li>Command stream end of file, while writing text user=...
|
||
|
host=...</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.19">7.19 Why did my POP or IMAP session suddenly
|
||
|
disconnect? The syslog has the message:
|
||
|
|
||
|
<ul>
|
||
|
<li>Killed (lost mailbox lock) user=... host=...</li>
|
||
|
</ul></a>
|
||
|
</li>
|
||
|
|
||
|
<li><a href="#7.20">7.20 Why does my IMAP client show all the files
|
||
|
on the system, recursively from the UNIX root directory?</a></li>
|
||
|
|
||
|
<li><a href="#7.21">7.21 Why does my IMAP client show all of my
|
||
|
files, recursively from my UNIX home directory?</a></li>
|
||
|
|
||
|
<li><a href="#7.22">7.22 Why does my IMAP client show that I have
|
||
|
mailboxes named "#mhinbox", "#mh", "#shared", "#ftp", "#news", and
|
||
|
"#public"?</a></li>
|
||
|
|
||
|
<li><a href="#7.23">7.23 Why does my IMAP client show all my files in
|
||
|
my home directory?</a></li>
|
||
|
|
||
|
<li><a href="#7.24">7.24 Why is there a long delay before I get
|
||
|
connected to the IMAP or POP server, no matter what client I
|
||
|
use?</a></li>
|
||
|
|
||
|
<li><a href="#7.25">7.25 Why is there a long delay in Pine or any
|
||
|
other c-client based application call before I get connected to the
|
||
|
IMAP server? The hang seems to be in the c-client mail_open() call. I
|
||
|
don't have this problem with any other IMAP client. There is no delay
|
||
|
connecting to a POP3 or NNTP server with mail_open().</a></li>
|
||
|
|
||
|
<li><a href="#7.26">7.26 Why does a message sometimes get split into
|
||
|
two or more messages on my SUN system?</a></li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.27">7.27 Why did my POP or IMAP session suddenly
|
||
|
disconnect? The syslog has the message:
|
||
|
|
||
|
<ul>
|
||
|
<li>Autologout user=<...my user name...> host=<...my
|
||
|
imap server...></li>
|
||
|
</ul></a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.28">7.28 What does the UNIX error message:
|
||
|
|
||
|
<ul>
|
||
|
<li>TLS/SSL failure: myserver: SSL negotiation failed</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.29">7.29 What does the PC error message:
|
||
|
|
||
|
<ul>
|
||
|
<li>TLS/SSL failure: myserver: Unexpected TCP input
|
||
|
disconnect</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.30">7.30 What does the error message:
|
||
|
|
||
|
<ul>
|
||
|
<li>TLS/SSL failure: myserver: Server name does not match
|
||
|
certificate</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.31">7.31 What does the UNIX error message:
|
||
|
|
||
|
<ul>
|
||
|
<li>TLS/SSL failure: myserver: self-signed certificate</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.32">7.32 What does the PC error message
|
||
|
|
||
|
<ul>
|
||
|
<li>TLS/SSL failure: myserver: Self-signed certificate or
|
||
|
untrusted authority</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.33">7.33 What does the UNIX error message:
|
||
|
|
||
|
<ul>
|
||
|
<li>TLS/SSL failure: myserver: unable to get local issuer
|
||
|
certificate</li>
|
||
|
</ul>mean?</a>
|
||
|
</li>
|
||
|
|
||
|
<li><a href="#7.34">7.34 Why does reading certain messages hang when
|
||
|
using Netscape? It works fine with Pine!</a></li>
|
||
|
|
||
|
<li><a href="#7.35">7.35 Why does Netscape say that there's a problem
|
||
|
with the IMAP server and that I should "Contact your mail server
|
||
|
administrator."?</a></li>
|
||
|
|
||
|
<li><a href="#7.36">7.36 Why is one user creating huge numbers of
|
||
|
IMAP or POP server sessions?</a></li>
|
||
|
|
||
|
<li><a href="#7.37">7.37 Why don't I get any new mail notifications
|
||
|
from Outlook Express or Outlook after a while?</a></li>
|
||
|
|
||
|
<li><a href="#7.38">7.38 Why don't I get any new mail notifications
|
||
|
from Entourage?</a></li>
|
||
|
|
||
|
<li><a href="#7.39">7.39 Why doesn't Entourage work at all?</a></li>
|
||
|
|
||
|
<li><a href="#7.40">7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE)
|
||
|
work at all?</a></li>
|
||
|
|
||
|
<li><a href="#7.41">7.41 Why can't I connect via SSL to Eudora? It
|
||
|
says the connection has been broken, and in the server syslogs I see
|
||
|
"Command stream end of file".</a></li>
|
||
|
|
||
|
<li><a href="#7.42">7.42 Sheesh. Aren't there <i>any</i> good IMAP
|
||
|
clients out there?</a></li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.43">7.43 But wait! PC Pine (or other PC program build
|
||
|
with c-client) crashes with the message
|
||
|
|
||
|
<ul>
|
||
|
<li>incomplete SecBuffer exceeds maximum buffer size</li>
|
||
|
</ul>when I use SSL connections. This is a bug in c-client, right?</a>
|
||
|
</li>
|
||
|
|
||
|
<li><a href="#7.44">7.44 My qpopper users keep on getting the DON'T
|
||
|
DELETE THIS MESSAGE -- FOLDER INTERNAL DATA if they also use Pine or
|
||
|
IMAP. How can I fix this?</a></li>
|
||
|
|
||
|
<li><a href="#7.45">7.45 Help! I installed the servers but I can't
|
||
|
connect to them from my client!</a></li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.46">7.46 Why do I get the message
|
||
|
|
||
|
<ul>
|
||
|
<li>Can not authenticate to SMTP server: 421 SMTP connection went
|
||
|
away!</li>
|
||
|
</ul>and why did this happen? There was also something about
|
||
|
|
||
|
<ul>
|
||
|
<li>SECURITY PROBLEM: insecure server advertised AUTH=PLAIN</li>
|
||
|
</ul></a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.47">7.47 Why do I get the message
|
||
|
|
||
|
<ul>
|
||
|
<li>SMTP Authentication cancelled</li>
|
||
|
</ul>and why did this happen? There was also something about
|
||
|
|
||
|
<ul>
|
||
|
<li>SECURITY PROBLEM: insecure server advertised AUTH=PLAIN</li>
|
||
|
</ul></a>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#7.48">7.48 Why do I get the message
|
||
|
|
||
|
<ul>
|
||
|
<li>Invalid base64 string</li>
|
||
|
</ul>when I try to authenticate to a Cyrus server?
|
||
|
</li></a>
|
||
|
</ul>
|
||
|
</li>
|
||
|
|
||
|
<li>
|
||
|
<a href="#additional">8. Where to Go For Additional Information</a>
|
||
|
|
||
|
<ul>
|
||
|
<li><a href="#8.1">8.1 Where can I go to ask questions?</a></li>
|
||
|
|
||
|
<li><a href="#8.2">8.2 I have some ideas for enhancements to IMAP.
|
||
|
Where should I go?</a></li>
|
||
|
|
||
|
<li><a href="#8.3">8.3 Where can I read more about IMAP and other
|
||
|
email protocols?</a></li>
|
||
|
|
||
|
<li><a href="#8.4">8.4 Where can I find out more about setting up and
|
||
|
administering an IMAP server?</a></li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
</ul><!--=======START BODY-->
|
||
|
<hr>
|
||
|
|
||
|
<h2><a name="general">1. General/Software Feature Questions</a></h2>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.1"><strong>1.1 Can I set up a POP or IMAP server on
|
||
|
UNIX/Linux/OSF/etc.?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. Refer to the UNIX specific notes in files CONFIG and BUILD.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.2"><strong>1.2 I am currently using qpopper as my POP3 server on
|
||
|
UNIX. Do I need to replace it with ipop3d in order to run
|
||
|
imapd?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Not necessarily.
|
||
|
|
||
|
<p>Although ipop3d interoperates with imapd better than qpopper, imapd
|
||
|
and qpopper will work together. The few qpopper/imapd interoperability
|
||
|
issues mostly affect users who use both IMAP and POP3 clients; those
|
||
|
users would probably be better served if their POP3 server is
|
||
|
ipop3d.</p>
|
||
|
|
||
|
<p>If you are happy with qpopper and just want to add imapd, you should
|
||
|
do that, and defer a decision on changing qpopper to ipop3d. That way,
|
||
|
you can get comfortable with imapd's performance, without changing
|
||
|
anything for your qpopper users.</p>
|
||
|
|
||
|
<p>Many sites have subsequently decided to change from qpopper to
|
||
|
ipop3d in order to get better POP3/IMAP interoperability. If you need
|
||
|
to do this, you'll know. There also seems to be a way to make qpopper
|
||
|
work better with imapd; see the answer to the <a href="#7.44">My
|
||
|
qpopper users keep on getting the DON'T DELETE THIS MESSAGE -- FOLDER
|
||
|
INTERNAL DATA if they also use Pine or IMAP. How can I fix this?</a>
|
||
|
question.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.3"><strong>1.3 Can I set up a POP or IMAP server on Windows XP,
|
||
|
2000, NT, Me, 98, or 95?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Yes. Refer to the NT specific notes in files CONFIG and BUILD. Also,
|
||
|
for DOS-based versions of Windows (Windows Me, 98, and 95) you *must*
|
||
|
set up CRAM-MD5 authentication, as described in md5.txt.
|
||
|
|
||
|
<p>There is no file access control on Windows 9x or Me, so you probably
|
||
|
will have to do modifications to env_unix.c to prevent people from
|
||
|
hacking others' mail.</p>
|
||
|
|
||
|
<p>Note, however, that the server is not plug and play the way it is
|
||
|
for UNIX.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.4"><strong>1.4 Can I set up a POP or IMAP server on Windows 3.1 or
|
||
|
DOS?</strong></a><br>
|
||
|
<a name="1.5"><strong>1.5 Can I set up a POP or IMAP server on
|
||
|
Macintosh?</strong></a><br>
|
||
|
<a name="1.6"><strong>1.6 Can I set up a POP or IMAP server on
|
||
|
VAX/VMS?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes, it's just a small matter of programming.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.7"><strong>1.7 Can I set up a POP or IMAP server on
|
||
|
TOPS-20?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
You have a TOPS-20 system? Cool.
|
||
|
|
||
|
<p>If IMAP2 (RFC 1176) is good enough for you, you can use MAPSER which
|
||
|
is about the ultimate gonzo pure TOPS-20 extended addressing assembly
|
||
|
language program. Unfortunately, IMAP2 is barely good enough for Pine
|
||
|
these days, and most other IMAP clients won't work with IMAP2 at all.
|
||
|
Maybe someone will hack MAPSER to do IMAP4rev1 some day.</p>
|
||
|
|
||
|
<p>We don't know if anyone wrote a POP3 server for TOPS-20. There
|
||
|
definitely was a POP2 server once upon a time.</p>
|
||
|
|
||
|
<p>Or you can port the POP and IMAP server from this IMAP toolkit to
|
||
|
it. All that you need for a first stab is to port the MTX driver.
|
||
|
That'll probably be just a couple of hours of hacking.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.8"><strong>1.8 Are hierarchical mailboxes
|
||
|
supported?</strong></a><br>
|
||
|
<a name="1.9"><strong>1.9 Are "dual-use" mailboxes
|
||
|
supported?</strong></a><br>
|
||
|
<a name="1.10"><strong>1.10 Can I have a mailbox that has both messages and
|
||
|
sub-mailboxes?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Yes. However, there is one important caveat.
|
||
|
|
||
|
<p>Some mailbox formats, including the default which is the traditional
|
||
|
UNIX mailbox format, are stored as a single file containing all the
|
||
|
messages. UNIX does not permit a name in the filesystem to be both a
|
||
|
file and a directory; consequently you can not have a sub-mailbox
|
||
|
within a mailbox that is in one of these formats.</p>
|
||
|
|
||
|
<p>This is not a limitation of the software; this is a limitation of
|
||
|
UNIX. For example, there are mailbox formats in which the name is a
|
||
|
directory and each message is a file within that directory; these
|
||
|
formats support sub-mailboxes within such mailboxes. However, for
|
||
|
technical reasons, the "flat file" formats are generally preferred
|
||
|
since they perform better. Read imap-2007/docs/formats.txt for more
|
||
|
information on this topic.</p>
|
||
|
|
||
|
<p>It is always permissible to create a directory that is not a
|
||
|
mailbox, and have sub-mailboxes under it. The easiest way to create a
|
||
|
directory is to create a new mailbox inside a directory that doesn't
|
||
|
already exist. For example, if you create "Mail/testbox" on UNIX, the
|
||
|
directory "Mail/" will automatically be created and then the mailbox
|
||
|
"testbox" will be created as a sub-mailbox of "Mail/".</p>
|
||
|
|
||
|
<p>It is also possible to create the name "Mail/" directly. Check the
|
||
|
documentation for your client software to see how to do this with that
|
||
|
software.</p>
|
||
|
|
||
|
<p>Of course, on Windows systems you would use "\" instead of "/".</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.11"><strong>1.11 What is the difference between "mailbox" and
|
||
|
"folder"?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
The term "mailbox" is IMAP-speak for what a lot of software calls a
|
||
|
"folder" or a "mail folder". However, "folder" is often used in other
|
||
|
contexts to refer to a directory, for example, in the graphic user
|
||
|
interface on both Windows and Macintosh.
|
||
|
|
||
|
<p>A "mailbox" is specifically defined as a named object that contains
|
||
|
messages. It is not required to be capable of containing other types of
|
||
|
objects including other mailboxes; although some mailbox formats will
|
||
|
permit this.</p>
|
||
|
|
||
|
<p>In IMAP-speak, a mailbox which can not contain other mailboxes is
|
||
|
called a "no-inferiors mailbox". Similarly, a directory which can not
|
||
|
contain messages is not a mailbox and is called a "no-select name".</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.12"><strong>1.12 What is the status of
|
||
|
internationalization?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
The IMAP toolkit is partially internationalized and multilingualized.
|
||
|
|
||
|
<p>Searching is supported in the following charsets: US-ASCII, UTF-8,
|
||
|
ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6,
|
||
|
ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11,
|
||
|
ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16, KOI8-R, KOI8-U
|
||
|
(alias KOI8-RU), TIS-620, VISCII, ISO-2022-JP, ISO-2022-KR,
|
||
|
ISO-2022-CN, ISO-2022-JP-1, ISO-2022-JP-2, GB2312 (alias CN-GB),
|
||
|
CN-GB-12345, BIG5 (alias CN-BIG5), EUC-JP, EUC-KR, Shift_JIS,
|
||
|
Shift-JIS, KS_C_5601-1987, KS_C_5601-1992, WINDOWS_874, WINDOWS-1250,
|
||
|
WINDOWS-1251, WINDOWS-1252, WINDOWS-1253, WINDOWS-1254, WINDOWS-1255,
|
||
|
WINDOWS-1256, WINDOWS-1257, WINDOWS-1258.</p>
|
||
|
|
||
|
<p>All ISO-2022-?? charsets are treated identically, and support ASCII,
|
||
|
JIS Roman, hankaku katakana, ISO-8859-[1 - 10], TIS, GB 2312, JIS X
|
||
|
0208, JIS X 0212, KSC 5601, and planes 1 and 2 of CNS 11643.</p>
|
||
|
|
||
|
<p>EUC-JP includes support for JIS X 0212 and hankaku katakana.</p>
|
||
|
|
||
|
<p>c-client library support also exists to convert text in any of the
|
||
|
above charsets into Unicode, including headers with MIME
|
||
|
encoded-words.</p>
|
||
|
|
||
|
<p>There is no support for localization (e.g. non-English error
|
||
|
messages) at the present time, but such support is planned.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.13"><strong>1.13 Can I use SSL?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.5">How do I configure SSL?</a>
|
||
|
question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.14"><strong>1.14 Can I use TLS and the STARTTLS
|
||
|
facility?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.6">How do I configure TLS and
|
||
|
the STARTTLS facility?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.15"><strong>1.15 Can I use CRAM-MD5
|
||
|
authentication?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.8">How do I configure CRAM-MD5
|
||
|
authentication?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.16"><strong>1.16 Can I use APOP authentication?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Yes. See the <a href="#3.9">How do I configure APOP authentication?</a>
|
||
|
question.
|
||
|
|
||
|
<p>Note that there is no client support for APOP authentication.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.17"><strong>1.17 Can I use Kerberos V5?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.10">How do I configure
|
||
|
Kerberos V5?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.18"><strong>1.18 Can I use PAM for plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.11">How do I configure PAM for
|
||
|
plaintext passwords?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.19"><strong>1.19 Can I use Kerberos 5 for plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.13">How do I configure
|
||
|
Kerberos 5 for plaintext passwords?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.20"><strong>1.20 Can I use AFS for plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.14">How do I configure AFS for
|
||
|
plaintext passwords?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.21"><strong>1.21 Can I use DCE for plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.15">How do I configure DCE for
|
||
|
plaintext passwords?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.22"><strong>1.22 Can I use the CRAM-MD5 database for plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.16">How do I configure the
|
||
|
CRAM-MD5 database for plaintext passwords?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.23"><strong>1.23 Can I disable plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.17">How do I disable plaintext
|
||
|
passwords?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.24"><strong>1.24 Can I disable plaintext passwords on unencrypted
|
||
|
sessions, but allow them on encrypted sessions?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.18">How do I disable plaintext
|
||
|
passwords on unencrypted sessions, but allow them in SSL or TLS
|
||
|
sessions?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.25"><strong>1.25 Can I use virtual hosts?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Yes. See the answer to the <a href="#3.19">How do I configure virtual
|
||
|
hosts?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.26"><strong>1.26 Can I use RPOP authentication?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>There is no support for RPOP authentication.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.27"><strong>1.27 Can I use Kerberos V4?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Kerberos V4 is not supported. Kerberos V4 client-only contributed code
|
||
|
is available in
|
||
|
<pre>
|
||
|
<a href=
|
||
|
"ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z">ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z
|
||
|
</a>
|
||
|
</pre>This is a patchkit which must be applied to the IMAP toolkit according
|
||
|
to the instructions in the patchkit's README. We can not promise that this
|
||
|
code works.
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.28"><strong>1.28 Is there support for S/Key or
|
||
|
OTP?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>There is currently no support for S/Key or OTP. There may be an OTP
|
||
|
SASL authenticator available from third parties.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.29"><strong>1.29 Is there support for NTLM or
|
||
|
SPA?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
There is currently no support for NTLM or SPA, nor are there any plans
|
||
|
to add such support. In general, I avoid vendor-specific mechanisms. I
|
||
|
also believe that these mechanisms are being deprecated by their
|
||
|
vendor.
|
||
|
|
||
|
<p>There may be an NTLM SASL authenticator available from third
|
||
|
parties.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.30"><strong>1.30 Is there support for mh?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Yes, but only as a legacy format. Your mh format INBOX is accessed by
|
||
|
the name "#mhinbox", and all other mh format mailboxes are accessed by
|
||
|
prefixing "#mh/" to the name, e.g. "#mh/foo". The mh support uses the
|
||
|
"Path:" entry in your .mh_profile file to identify the root directory
|
||
|
of your mh format mailboxes.
|
||
|
|
||
|
<p>Non-legacy use of mh format is not encouraged. There is no support
|
||
|
for permanent flags or unique identifiers; furthermore there are known
|
||
|
severe performance problems with the mh format.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.31"><strong>1.31 Is there support for qmail and the maildir
|
||
|
format?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>There is no support for qmail or the maildir format in our
|
||
|
distribution, nor are there any plans to add such support. Maildir
|
||
|
support may be available from third parties.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.32"><strong>1.32 Is there support for the Cyrus mailbox
|
||
|
format?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>No.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="1.33"><strong>1.33 Is this software Y2K compliant?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Please read the files Y2K and calendar.txt.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><br></p>
|
||
|
|
||
|
<h2><a name="requirements">2. What Do I Need to Build This Software?</a></h2>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.1"><strong>2.1 What do I need to build this software with SSL on
|
||
|
UNIX?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>You need to build and install OpenSSL first.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.2"><strong>2.2 What do I need to build this software with Kerberos
|
||
|
V on UNIX?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>You need to build and install MIT Kerberos first.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.3"><strong>2.3 What do I need to use a C++ compiler with this
|
||
|
software to build my own application?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
If you are building an application using the c-client library, use the
|
||
|
new c-client.h file instead of including the other include files. It
|
||
|
seems that c-client.h should define away all the troublesome names that
|
||
|
conflict with C++.
|
||
|
|
||
|
<p>If you use gcc, you may need to use -fno-operator-names as well.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.4"><strong>2.4 What do I need to build this software on
|
||
|
Windows?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
You need Microsoft Visual C++ 6.0, Visual C++ .NET, or Visual C# .NET
|
||
|
(which you can buy from any computer store), along with the Microsoft
|
||
|
Platform SDK (which you can download from Microsoft's web site).
|
||
|
|
||
|
<p>You do not need to install the entire Platform SDK; it suffices to
|
||
|
install just the Core SDK and the Internet Development SDK.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.5"><strong>2.5 What do I need to build this software on
|
||
|
DOS?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>It's been several years since we last attempted to do this. At the
|
||
|
time, we used Microsoft C.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.6"><strong>2.6 Can't I use Borland C to build this software on the
|
||
|
PC?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Probably not. If you know otherwise, please let us know.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.7"><strong>2.7 What do I need to build this software on the
|
||
|
Mac?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>It has been several years since we last attempted to do this. At the
|
||
|
time, we used Symantec THINK C; but today you'll need a C compiler which
|
||
|
allows segments to be more than 32K.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.8"><strong>2.8 What do I need to build this software on
|
||
|
VMS?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>You need the VMS C compiler, and either the Multinet or Netlib
|
||
|
TCP.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.9"><strong>2.9 What do I need to build this software on
|
||
|
TOPS-20?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>You need the TOPS-20 KCC compiler.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.10"><strong>2.10 What do I need to build this software on Amiga or
|
||
|
OS/2?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>We don't know.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="2.11"><strong>2.11 What do I need to build this software on Windows
|
||
|
CE?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>This port is incomplete. Someone needs to finish it.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><br></p>
|
||
|
|
||
|
<h2><a name="build">3. Build and Configuration Questions</a></h2>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.1"><strong>3.1 How do I configure the IMAP and POP servers on
|
||
|
UNIX?</strong></a><br>
|
||
|
<a name="3.2"><strong>3.2 I built and installed the servers according to the
|
||
|
BUILD instructions. It can't be that easy. Don't I need to write a
|
||
|
config file?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
For ordinary "vanilla" UNIX systems, this software is plug and play;
|
||
|
just build it, install it, and you're done. If you have a modified
|
||
|
system, then you may want to do additional work; most of this is to a
|
||
|
single source code file (env_unix.c on UNIX systems). Read the file
|
||
|
CONFIG for more details.
|
||
|
|
||
|
<p>Yes, it's that easy. There are some additional options, such as SSL
|
||
|
or Kerberos, which require additional steps to build. See the relevant
|
||
|
questions below.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.3"><strong>3.3 How do I make the IMAP and POP servers look for
|
||
|
INBOX at some place other than the mail spool
|
||
|
directory?</strong></a><br>
|
||
|
<a name="3.4"><strong>3.4 How do I make the IMAP server look for secondary
|
||
|
folders at some place other than the user's home
|
||
|
directory?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Please read the file CONFIG for discussion of this and other
|
||
|
issues.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.5"><strong>3.5 How do I configure SSL?</strong></a><br>
|
||
|
<a name="3.6"><strong>3.6 How do I configure TLS and the STARTTLS
|
||
|
facility?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
imap-2007 supports SSL and TLS client functionality on UNIX and 32-bit
|
||
|
Windows for IMAP, POP3, SMTP, and NNTP; and SSL and TLS server
|
||
|
functionality on UNIX for IMAP and POP3.
|
||
|
|
||
|
<p>UNIX SSL build requires that a third-party software package,
|
||
|
OpenSSL, be installed on the system first. Read imap-2007/docs/SSLBUILD
|
||
|
for more information.</p>
|
||
|
|
||
|
<p>SSL is supported via undocumented Microsoft interfaces in Windows 9x
|
||
|
and NT4; and via standard interfaces in Windows 2000, Windows
|
||
|
Millenium, and Windows XP.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.7"><strong>3.7 How do I build/install OpenSSL and obtain/create
|
||
|
certificates for use with SSL?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>If you need help in doing this, try the contacts mentioned in the
|
||
|
OpenSSL README. We do not offer support for OpenSSL or certificates.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.8"><strong>3.8 How do I configure CRAM-MD5
|
||
|
authentication?</strong></a><br>
|
||
|
<a name="3.9"><strong>3.9 How do I configure APOP
|
||
|
authentication?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
CRAM-MD5 authentication is enabled in the IMAP and POP3 client code on
|
||
|
all platforms. Read md5.txt to learn how to set up CRAM-MD5 and APOP
|
||
|
authentication on UNIX and NT servers.
|
||
|
|
||
|
<p>There is no support for APOP client authentication.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.10"><strong>3.10 How do I configure Kerberos V5?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
imap-2007 supports client and server functionality on UNIX and 32-bit
|
||
|
Windows.
|
||
|
|
||
|
<p>Kerberos V5 is supported by default in Windows 2000 builds:</p>
|
||
|
<pre>
|
||
|
nmake -f makefile.w2k
|
||
|
</pre>
|
||
|
|
||
|
<p>Other builds require that a third-party Kerberos package, e.g. MIT
|
||
|
Kerberos, be installed on the system first.</p>
|
||
|
|
||
|
<p>To build with Kerberos V5 on UNIX, include EXTRAAUTHENTICATORS=gss
|
||
|
in the make command line, e.g.</p>
|
||
|
<pre>
|
||
|
make lnp EXTRAAUTHENTICATORS=gss
|
||
|
</pre>
|
||
|
|
||
|
<p>To build with Kerberos V5 on Windows 9x, Windows Millenium, and NT4,
|
||
|
use the "makefile.ntk" file instead of "makefile.nt":</p>
|
||
|
<pre>
|
||
|
|
||
|
nmake -f makefile.ntk
|
||
|
</pre>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.11"><strong>3.11 How do I configure PAM for plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
On Linux systems, use the lnp port, e.g.
|
||
|
<pre>
|
||
|
make lnp
|
||
|
|
||
|
</pre>On Solaris systems and other systems with defective PAM
|
||
|
implementations, build with PASSWDTYPE=pmb, e.g.
|
||
|
<pre>
|
||
|
make sol PASSWDTYPE=pmb
|
||
|
</pre>On all other systems, build with PASSWDTYPE=pam, e.g
|
||
|
<pre>
|
||
|
make foo PASSWDTYPE=pam
|
||
|
</pre>If you build with PASSWDTYPE=pam and authentication does not work, try
|
||
|
rebuilding (after a "make clean") with PASSWDTYPE=pmb.
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.12"><strong>3.12 It looks like all I have to do to make the server
|
||
|
use Kerberos is to build with PAM on my Linux system, and set it up in
|
||
|
PAM for Kerberos passwords. Right?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Yes and no.
|
||
|
|
||
|
<p>Doing this will make plaintext password authentication use the
|
||
|
Kerberos password instead of the /etc/passwd password.</p>
|
||
|
|
||
|
<p>However, this will NOT give you Kerberos-secure authentication. See
|
||
|
the answer to the <a href="#3.10">How do I configure Kerberos V5?</a>
|
||
|
question for how to build with Kerberos-secure authentication.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.13"><strong>3.13 How do I configure Kerberos 5 for plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Build with PASSWDTYPE=gss, e.g.
|
||
|
<pre>
|
||
|
make sol PASSWDTYPE=gss
|
||
|
</pre>However, this will NOT give you Kerberos-secure authentication. See the
|
||
|
answer to the <a href="#3.10">How do I configure Kerberos V5?</a> question
|
||
|
for how to build with Kerberos-secure authentication.
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.14"><strong>3.14 How do I configure AFS for plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Build with PASSWDTYPE=afs, e.g
|
||
|
<pre>
|
||
|
make sol PASSWDTYPE=afs
|
||
|
|
||
|
</pre>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.15"><strong>3.15 How do I configure DCE for plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Build with PASSWDTYPE=dce, e.g
|
||
|
<pre>
|
||
|
make sol PASSWDTYPE=dce
|
||
|
</pre>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.16"><strong>3.16 How do I configure the CRAM-MD5 database for
|
||
|
plaintext passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
The CRAM-MD5 password database is automatically used for plaintext
|
||
|
password if it exists.
|
||
|
|
||
|
<p>Note that this is NOT CRAM-MD5-secure authentication. You probably
|
||
|
want to consider disabling plaintext passwords for non-SSL/TLS
|
||
|
sessions. See the next two questions.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.17"><strong>3.17 How do I disable plaintext
|
||
|
passwords?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Server-level plaintext passwords can be disabled by setting
|
||
|
PASSWDTYPE=nul, e.g.
|
||
|
<pre>
|
||
|
make lnx EXTRAAUTHENTICATORS=gss PASSWDTYPE=nul
|
||
|
</pre>Note that you must have a CRAM-MD5 database installed or specify at
|
||
|
least one EXTRAAUTHENTICATOR, otherwise it will not be possible to log in to
|
||
|
the server.
|
||
|
|
||
|
<p>When plaintext passwords are disabled, the IMAP server will
|
||
|
advertise the LOGINDISABLED capability and the POP3 server will not
|
||
|
advertise the USER capability.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
|
||
|
<p><a name="3.18"><strong>3.18 How do I disable plaintext passwords on
|
||
|
unencrypted sessions, but allow them in SSL or TLS
|
||
|
sessions?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
<p>Do not set PASSWDTYPE=nul or SSLTYPE=unix. Set SSLTYPE=nopwd
|
||
|
instead, e.g.</p>
|
||
|
<pre>
|
||
|
make lnx SSLTYPE=nopwd
|
||
|
</pre>
|
||
|
|
||
|
<p>When plaintext passwords are disabled, the IMAP server will
|
||
|
advertise the LOGINDISABLED capability and the POP3 server will not
|
||
|
advertise the USER capability.</p>
|
||
|
|
||
|
<p>Plaintext passwords will always be enabled in SSL sessions; the IMAP
|
||
|
server will not advertise the LOGINDISABLED capability and the POP3
|
||
|
server will advertise the USER capability.</p>
|
||
|
|
||
|
<p>If the client does a successful start-TLS in a non-SSL session,
|
||
|
plaintext passwords will be enabled, and a new CAPABILITY or CAPA
|
||
|
command (which is required after start-TLS) will show the effect as in
|
||
|
SSL sessions.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.19"><strong>3.19 How do I configure virtual
|
||
|
hosts?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is automatic, but with certain restrictions.
|
||
|
|
||
|
<p>The most important one is that each virtual host must have its own
|
||
|
IP address; otherwise the server has no way of knowing which virtual
|
||
|
host is desired.</p>
|
||
|
|
||
|
<p>As distributed, the software uses a global password file; hence user
|
||
|
"fred" on one virtual host is "fred" on all virtual hosts. You may want
|
||
|
to modify the checkpw() routine to implement some other policy (e.g.
|
||
|
separate password files).</p>
|
||
|
|
||
|
<p>Note that the security model assumes that all users have their own
|
||
|
unique UNIX UID number. So if you use separate password files you
|
||
|
should make certain that the UID numbers do not overlap between
|
||
|
different files.</p>
|
||
|
|
||
|
<p>More advanced virtual host support may be available as patches from
|
||
|
third parties.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.20"><strong>3.20 Why do I get compiler warning messages such
|
||
|
as:</strong></a></p>
|
||
|
<pre>
|
||
|
passing arg 3 of `scandir' from incompatible pointer type
|
||
|
Pointers are not assignment-compatible.
|
||
|
Argument #4 is not the correct type.
|
||
|
|
||
|
</pre>
|
||
|
|
||
|
<p><strong>during the build?</strong></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
You can safely ignore these messages.
|
||
|
|
||
|
<p>Over the years, the prototype for scandir() has changed, and thus is
|
||
|
variant across different UNIX platforms. In particular, the definitions
|
||
|
of the third argument (type select_t) and fourth argument (type
|
||
|
compar_t) have changed over the years, the issue being whether or not
|
||
|
the arguments to the functions pointed to by these function pointers
|
||
|
are of type const or not.</p>
|
||
|
|
||
|
<p>The way that c-client calls scandir() will tend to generate these
|
||
|
compiler warnings on newer systems such as Linux; however, it will
|
||
|
still build. The problem with fixing the call is that then it won't
|
||
|
build on older systems.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.21"><strong>3.21 Why do I get compiler warning messages such
|
||
|
as</strong></a></p>
|
||
|
<pre>
|
||
|
Operation between types "void(*)(int)" and "void*" is not allowed.
|
||
|
Function argument assignment between types "void*" and "void(*)(int)" is not allowed.
|
||
|
Pointers are not assignment-compatible.
|
||
|
Argument #5 is not the correct type.
|
||
|
</pre>
|
||
|
|
||
|
<p><strong>during the build?</strong></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
You can safely ignore these messages.
|
||
|
|
||
|
<p>All known systems have no problem with casting a function pointer
|
||
|
to/from a void* pointer, certain C compilers issue a compiler
|
||
|
diagnostic because this facility is listed as a "Common extension" by
|
||
|
the C standard:</p>
|
||
|
<pre>
|
||
|
K.5.7 Function pointer casts
|
||
|
[#1] A pointer to an object or to void may be cast to a pointer
|
||
|
to a function, allowing data to be invoked as a function (6.3.4).
|
||
|
[#2] A pointer to a function may be cast to a pointer to an
|
||
|
object or to void, allowing a function to be inspected or
|
||
|
modified (for example, by a debugger) (6.3.4).
|
||
|
|
||
|
</pre>It may be just a "common extension", but this facility is relied upon
|
||
|
heavily by c-client.
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.22"><strong>3.22 Why do I get linker warning messages such
|
||
|
as:</strong></a></p>
|
||
|
<pre>
|
||
|
mtest.c:515: the `gets' function is dangerous and should not be used.
|
||
|
</pre>
|
||
|
|
||
|
<p><strong>during the build? Isn't this a security bug?</strong></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
You can safely ignore this message.
|
||
|
|
||
|
<p>Certain linkers, most notably on Linux, give this warning message.
|
||
|
It is indeed true that the traditional gets() function is not a safe
|
||
|
one.</p>
|
||
|
|
||
|
<p>However, the mtest program is only a demonstration program, a model
|
||
|
of a very basic application program using c-client. It is not something
|
||
|
that you would install, much less run in any security-sensitive
|
||
|
context.</p>
|
||
|
|
||
|
<p>mtest has numerous other shortcuts that you wouldn't want to do in a
|
||
|
real application program.</p>
|
||
|
|
||
|
<p>The only "security bug" with mtest would be if it was run by some
|
||
|
script in a security-sensitive context, but mtest isn't particularly
|
||
|
useful for such purposes. If you wanted to write a script to automate
|
||
|
some email task using c-client, you'd be better off using imapd instead
|
||
|
of mtest.</p>
|
||
|
|
||
|
<p>mtest only has two legitimate uses. It's a useful testbed for me
|
||
|
when debugging new versions of c-client, and it's useful as a model for
|
||
|
someone writing a simple c-client application to see how the various
|
||
|
calls work.</p>
|
||
|
|
||
|
<p>By the way, if you need a more advanced example of c-client
|
||
|
programming than mtest (and you probably will), I recommend that you
|
||
|
look at the source code for imapd and Pine.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.23"><strong>3.23 Why do I get linker warning messages such
|
||
|
as:</strong></a></p>
|
||
|
<pre>
|
||
|
auth_ssl.c:92: the `tmpnam' function is dangerous and should not be used.
|
||
|
</pre>
|
||
|
|
||
|
<p><strong>during the build? Isn't this a security bug?</strong></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
You can safely ignore this message.
|
||
|
|
||
|
<p>Certain linkers, most notably on Linux, give this warning message,
|
||
|
based upon two known issues with tmpnam():</p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>there can be a buffer overflow if an inadequate buffer is
|
||
|
allocated.</dd>
|
||
|
|
||
|
<dd>there can be a timing race caused by certain incautious usage of
|
||
|
the return value.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p>Neither of these issues applies in the particular use that is made
|
||
|
of tmpnam(). More importantly, the tmpnam() call is never executed on
|
||
|
Linux systems.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="3.24"><strong>3.24 OK, suppose I see a warning message about a
|
||
|
function being "dangerous and should not be used" for something other
|
||
|
than this gets() or tmpnam() call?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Please forward the details for investigation.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><br></p>
|
||
|
|
||
|
<h2><a name="operation">4. Operational Questions</a></h2>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="4.1"><strong>4.1 How can I enable anonymous IMAP
|
||
|
logins?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Create the file /etc/anonymous.newsgroups. At the present time, this
|
||
|
file should be empty. This will permit IMAP logins as anonymous as well
|
||
|
as the ANONYMOUS SASL authenticator. Anonymous users have access to
|
||
|
mailboxes in the #news., #ftp/, and #public/ namespaces only.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="4.2"><strong>4.2 How do I set up an alert message that each IMAP
|
||
|
user will see?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Create the file /etc/imapd.alert with the text of the message. This
|
||
|
text should be kept to one line if possible. Note that this will cause an
|
||
|
alert to every IMAP user every time they initiate an IMAP session, so it
|
||
|
should only be used for critical messages.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="4.3"><strong>4.3 How does the c-client library choose which of its
|
||
|
several mechanisms to use to establish an IMAP connection to the server?
|
||
|
I noticed that it can connect on port 143, port 993, via rsh, and via
|
||
|
ssh.</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
c-client chooses how to establish an IMAP connection via the following
|
||
|
rules:
|
||
|
|
||
|
<ul>
|
||
|
<li>If /ssl is specified, use an SSL connection. Fail otherwise.</li>
|
||
|
|
||
|
<li>Else if client is a UNIX system and "ssh server exec /etc/rimapd"
|
||
|
works, use that</li>
|
||
|
|
||
|
<li>Else if /tryssl is specified and an SSL connection works, use
|
||
|
that.</li>
|
||
|
|
||
|
<li>Else if client is a UNIX system and "rsh server exec /etc/rimapd"
|
||
|
works, use that.</li>
|
||
|
|
||
|
<li>Else use a non-SSL connection.</li>
|
||
|
</ul>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="4.4"><strong>4.4 I am using a TLS-capable IMAP server, so I don't
|
||
|
need to use /ssl to get encryption. However, I want to be certain that
|
||
|
my session is TLS encrypted before I send my password. How to I do
|
||
|
this?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Use the /tls option in the mailbox name. This will cause an error
|
||
|
message and the connection to fail if the server does not negotiate
|
||
|
STARTTLS.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="4.5"><strong>4.5 How do I use one of the alternative formats
|
||
|
described in the formats.txt document? In particular, I hear that mbx
|
||
|
format will give me better performance and allow shared
|
||
|
access.</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
The rumors about mbx format being preferred are true. It is faster than
|
||
|
the traditional UNIX mailbox format and permits shared access.
|
||
|
|
||
|
<p>However, and this is <em>very important</em>, note that using an
|
||
|
alternative mailbox format is an advanced facility, and only expert
|
||
|
users should undertake it. If you don't understand any of the following
|
||
|
notes, you may not be enough of an expert yet, and are probably better
|
||
|
off not going this route until you are more comfortable with your
|
||
|
understanding.</p>
|
||
|
|
||
|
<p>Some of the formats, including mbx, are only supported by the
|
||
|
software based on the c-client library, and are not recognized by other
|
||
|
mailbox programs. The "vi" editor will corrupt any mbx format mailbox
|
||
|
that it encounters.</p>
|
||
|
|
||
|
<p>Another problem is that the certain formats, including mbx, use
|
||
|
advanced file access and locking techniques that do <em>not</em> work
|
||
|
reliably with NFS. NFS is not a real filesystem. Use IMAP instead of
|
||
|
NFS for distributed access.</p>
|
||
|
|
||
|
<p>Each of the following steps are in escalating order of involvement.
|
||
|
The further you go down this list, the more deeply committed you
|
||
|
become:</p>
|
||
|
|
||
|
<ul>
|
||
|
<li>The simplest way to create a mbx-format mailbox is to prefix the
|
||
|
name with "#driver.mbx/" when creating a mailbox through c-client.
|
||
|
For example, if you create "#driver.mbx/foo", the mailbox "foo" will
|
||
|
be created in mbx format. Only use "#driver.mbx/" when creating the
|
||
|
mailbox. At all other times, just use the name ("foo" in this
|
||
|
example); the software will automatically select the driver for mbx
|
||
|
whenever that mailbox is accessed without you doing anything
|
||
|
else.</li>
|
||
|
|
||
|
<li>You can use the "mailutil copy" command to copy an existing
|
||
|
mailbox to a new mailbox in mbx format. Read the man page provided
|
||
|
with the mailutil program for details.</li>
|
||
|
|
||
|
<li>If you create an mbx-format INBOX, by creating
|
||
|
"#driver.mbx/INBOX" (note that "INBOX" must be all uppercase), then
|
||
|
subsequent access to INBOX by any c-client based application will use
|
||
|
the mbx-format INBOX. Any mail delivered to the traditional format
|
||
|
mailbox in the spool directory (e.g. /var/spool/mail/$USER) will
|
||
|
automatically be copied into the mbx-format INBOX and the spool
|
||
|
directory copy removed.</li>
|
||
|
|
||
|
<li>You can cause any newly-created mailboxes to be in mbx-format by
|
||
|
default by changing the definition of CREATEPROTO=unixproto to be
|
||
|
CREATEPROTO=mbxproto in src/osdep/unix/Makefile, then rebuilding the
|
||
|
IMAP toolkit (do a "make clean" first). Do not change EMPTYPROTO,
|
||
|
since mbx format mailboxes are never a zero-byte file. If you use
|
||
|
Pine or the imap-utils, you should probably also rebuild them with
|
||
|
the new IMAP toolkit too.</li>
|
||
|
|
||
|
<li>You can deliver directly to the mbx-format INBOX by use of the
|
||
|
tmail or dmail programs. tmail is for direct invocation from sendmail
|
||
|
(or whatever MTA program you use); dmail is for calls from procmail.
|
||
|
Both of these programs have man pages which must be read carefully
|
||
|
before making this change.</li>
|
||
|
</ul>
|
||
|
|
||
|
<p>Most other servers (e.g. Cyrus) require use of a non-standard
|
||
|
format. A full-fledged format conversion is not significantly different
|
||
|
from what you have to do with other servers. The difference, which
|
||
|
makes format conversion procedures somewhat more complicated with this
|
||
|
server, is that there is no "all or nothing" requirement with this
|
||
|
server. There are many points in between. A format conversion can be
|
||
|
anything from a single mailbox or single user, to systemwide.</p>
|
||
|
|
||
|
<p>This is good in that you can decide how far to go, or do the steps
|
||
|
incrementally as you become more comfortable with the result. On the
|
||
|
other hand, there's no "One True Way" which can be boiled down to a
|
||
|
simple set of pedagogical instructions.</p>
|
||
|
|
||
|
<p>A number of sites have done full-fledged format conversions, and are
|
||
|
reportedly quite happy with the results. Feel free to ask in the
|
||
|
comp.mail.imap newsgroup or the imap-uw mailing list for advice or
|
||
|
help.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="4.6"><strong>4.6 How do I set up shared mailboxes?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
At the simplest level, a shared mailbox is one which has UNIX file and
|
||
|
directory protections which permit multiple users to access it. What
|
||
|
this means is that your existing skills and tools to create and manage
|
||
|
shared files on your UNIX system apply to shared mailboxes; e.g.
|
||
|
<pre>
|
||
|
chmod 666 mailbox
|
||
|
</pre>
|
||
|
|
||
|
<p>You may want to consider the use of a mailbox format which permits
|
||
|
multiple simultaneous read/write sessions, such as the mbx format. The
|
||
|
traditional UNIX format only allows one read/write session to a
|
||
|
mailbox at a time.</p>
|
||
|
|
||
|
<p>An additional convenience item are three system directories, which
|
||
|
can be set up for shared namespaces. These are: #ftp, #shared, and
|
||
|
#public, and are defined by creating the associated UNIX users and home
|
||
|
directories as described below.</p>
|
||
|
|
||
|
<p>#ftp/ refers to the anonymous ftp filesystem exported by the ftp
|
||
|
server, and is equivalent to the home directory for UNIX user "ftp".
|
||
|
For example, #ftp/foo/bar refers to the file /foo/bar in the anonymous
|
||
|
FTP filesystem, or ~ftp/foo/bar for normal users. Anonymous FTP files
|
||
|
are available to anonymous IMAP logins. By default, newly-created files
|
||
|
in #ftp/ are protected 644.</p>
|
||
|
|
||
|
<p>#public/ refers to an IMAP toolkit convention called "public" files,
|
||
|
and is equivalent to the home directory for UNIX user "imappublic". For
|
||
|
example, #public/foo/bar refers to the file ~imappublic/foo/bar. Public
|
||
|
files are available to anonymous IMAP logins. By default, newly-created
|
||
|
files in #public are created with protection 0666.</p>
|
||
|
|
||
|
<p>#shared/ refers to an IMAP toolkit convention called "shared" files,
|
||
|
and is equivalent to the home directory for UNIX user "imapshared". For
|
||
|
example, #shared/foo/bar refers to the file ~imapshared/foo/bar. Shared
|
||
|
files are <em>not</em> available to anonymous IMAP logins. By default,
|
||
|
newly-created files in #shared are created with protection 0660.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="4.7"><strong>4.7 How can I make the server syslogs go to someplace
|
||
|
other than the mail syslog?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
The openlog() call that sets the syslog facility is in
|
||
|
<strong>src/osdep/unix/env_unix.c</strong> in routine
|
||
|
<strong>server_init()</strong>. You need to edit this file to change
|
||
|
the syslog facility from LOG_MAIL to the facility you want, then
|
||
|
rebuild. You also need to set up your /etc/syslog.conf properly.
|
||
|
|
||
|
<p>Refer to the man pages for syslog and syslogd for more information
|
||
|
on what the available syslog facilities are and how to configure
|
||
|
syslogs. If you still don't understand what to do, find a UNIX system
|
||
|
expert.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><br></p>
|
||
|
|
||
|
<h2><a name="security">5. Security Questions</a></h2>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="5.1"><strong>5.1 I see that the IMAP server allows access to
|
||
|
arbitary files on the system, including /etc/passwd! How do I disable
|
||
|
this?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
You should not worry about this if your IMAP users are allowed shell
|
||
|
access. The IMAP server does not permit any access that the user can
|
||
|
not have via the shell.
|
||
|
|
||
|
<p>If, and only if, you deny your IMAP users shell access, you may want
|
||
|
to consider one of three choices. Note that these choices reduce IMAP
|
||
|
functionality, and may have undesirable side effects. Each of these
|
||
|
choices involves an edit to file
|
||
|
<strong>src/osdep/unix/env_unix.c</strong></p>
|
||
|
|
||
|
<p>The first (and recommended) choice is to set
|
||
|
<strong>restrictBox</strong> as described in file CONFIG. This will
|
||
|
disable access to the filesystem root, to other users' home directory,
|
||
|
and to superior directory.</p>
|
||
|
|
||
|
<p>The second (and strongly NOT recommended) choice is to set
|
||
|
<strong>closedBox</strong> as described in file CONFIG. This puts each
|
||
|
IMAP session into a so-called "chroot jail", and thus setting this
|
||
|
option is <em>extremely</em> dangerous; it can make your system much
|
||
|
less secure and open to root compromise attacks. So do not use this
|
||
|
option unless you are <em>absolutely certain</em> that you understand
|
||
|
all the issues of a "chroot jail."</p>
|
||
|
|
||
|
<p>The third choice is to rewrite routine
|
||
|
<strong>mailboxfile()</strong> to implement whatever mapping from
|
||
|
mailbox name to filesystem name (and restrictions) that you wish. This
|
||
|
is the most general choice. As a guide, you can see at the start of
|
||
|
routine <strong>mailboxfile()</strong> what the
|
||
|
<strong>restrictBox</strong> choice does.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="5.2"><strong>5.2 I've heard that IMAP servers are insecure. Is this
|
||
|
true?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
There are no known security problems in this version of the IMAP
|
||
|
toolkit, including the IMAP and POP servers. The IMAP and POP servers
|
||
|
limit what can be done while not logged in, and as part of the login
|
||
|
process discard all privileges except those of the user.
|
||
|
|
||
|
<p>As with other software packages, there have been buffer overflow
|
||
|
vulnerabilities in past versions. All known problems of this nature are
|
||
|
fixed in this version.</p>
|
||
|
|
||
|
<p>There is every reason to believe that the bad guys are engaged in an
|
||
|
ongoing effort to find vulnerabilities in the IMAP toolkit. We look for
|
||
|
such problems, and when one is found we fix it.</p>
|
||
|
|
||
|
<p>It's unfortunate that any vulnerabilities existed in past versions,
|
||
|
and we're doing my best to keep the IMAP toolkit free of
|
||
|
vulnerabilities. No new vulnerabilities have been discovered in quite a
|
||
|
while, but efforts will not be relaxed.</p>
|
||
|
|
||
|
<p>Beware of vendors who claim that their implementations can not have
|
||
|
vulnerabilities.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="5.3"><strong>5.3 How do I know that I have the most secure version
|
||
|
of the server?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
The best way is to keep your server software up to date. The bad guys
|
||
|
are always looking for ways to crack software, and when they find one,
|
||
|
let all their friends know.
|
||
|
|
||
|
<p>Oldtimers used to refer to a concept of <em>software rot</em>: if
|
||
|
your software hasn't been updated in a while, it would "rot" -- tend to
|
||
|
acquire problems that it didn't have when it was new.</p>
|
||
|
|
||
|
<p>The latest release version of the IMAP toolkit is always available
|
||
|
at <a href=
|
||
|
"ftp://ftp.cac.washington.edu/mail/imap.tar.Z">ftp://ftp.cac.washington.edu/mail/imap.tar.Z</a></p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="5.4"><strong>5.4 I see all these strcpy() and sprintf() calls, those
|
||
|
are unsafe, aren't they?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Yes and no.
|
||
|
|
||
|
<p>It can be unsafe to do these calls if you do not know that the
|
||
|
string being written will fit in the buffer. However, they are
|
||
|
perfectly safe if you do know that.</p>
|
||
|
|
||
|
<p>Beware of programmers who advocate doing a brute-force change of all
|
||
|
instances of</p>
|
||
|
<pre>
|
||
|
strcpy (s,t);
|
||
|
</pre>to
|
||
|
<pre>
|
||
|
strncpy (s,t,n)[n] = '\0';
|
||
|
</pre>and similar measures in the name of "fixing all possible buffer
|
||
|
overflows."
|
||
|
|
||
|
<p>There are examples in which a security bug was introduced because of
|
||
|
this type of "fix", due to the programmer using the wrong value for n.
|
||
|
In one case, the programmer thought that n was larger than it actually
|
||
|
was, causing a NUL to be written out of the buffer; in another, n was
|
||
|
too small, and a security credential was truncated.</p>
|
||
|
|
||
|
<p>What is particularly ironic was that in both cases, the original
|
||
|
strcpy() was safe, because the size of the source string was known to
|
||
|
be safe.</p>
|
||
|
|
||
|
<p>With all this in mind, the software has been inspected, and it is
|
||
|
believed that all places where buffer overflows can happen have been
|
||
|
fixed. The strcpy()s that are still are in the code occur after a size
|
||
|
check was done in some other way.</p>
|
||
|
|
||
|
<p>Note that the common C idiom of</p>
|
||
|
<pre>
|
||
|
*s++ = c;
|
||
|
</pre>is just as vulnerable to buffer overflows. You can't cure buffer
|
||
|
overflows by outlawing certain functions, nor is it desirable to do so;
|
||
|
sometimes operations like strcpy() translate into fast machine instructions
|
||
|
for better performance.
|
||
|
|
||
|
<p>Nothing replaces careful study of code. That's how the bad guys find
|
||
|
bugs. Security is not accomplished by means of brute-force
|
||
|
shortcuts.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="5.5"><strong>5.5 Those /tmp lock files are protected 666, is that
|
||
|
really right?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Yes. Shared mailboxes won't work otherwise. Also, you get into
|
||
|
accidental denial of service problems with old lock files left lying
|
||
|
around; this happens fairly frequently.
|
||
|
|
||
|
<p>The deliberate mischief that can be caused by fiddling with the lock
|
||
|
files is small-scale; harassment level at most. There are many -- and
|
||
|
much more effective -- other ways of harassing another user on UNIX.
|
||
|
It's usually not difficult to determine the culprit.</p>
|
||
|
|
||
|
<p>Before worrying about deliberate mischief, worry first about things
|
||
|
happening by accident!</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><br></p>
|
||
|
|
||
|
<h2><a name="strange">6. <em>Why Did You Do This Strange Thing?</em>
|
||
|
Questions</a></h2>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.1"><strong>6.1 Why don't you use GNU autoconfig / automake /
|
||
|
autoblurdybloop?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Autoconfig et al are not available on all the platforms where the IMAP
|
||
|
toolkit is supported; and do not work correctly on some of the
|
||
|
platforms where they do exist. Furthermore, these programs add another
|
||
|
layer of complexity to an already complex process.
|
||
|
|
||
|
<p>Coaxing software that uses autoconfig to build properly on platforms
|
||
|
which were not specifically considered by that software wastes an
|
||
|
inordinate amount of time. When (not if) autoconfig fails to do the
|
||
|
right thing, the result is an inpenetrable morass to untangle in order
|
||
|
to find the problem and fix it.</p>
|
||
|
|
||
|
<p>The concept behind autoconfig is good, but the execution is flawed.
|
||
|
It rarely does the right thing on a platform that wasn't specifically
|
||
|
considered. Human life is too short to debug autoconfig problems,
|
||
|
especially since the current mechanism is so much easier.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.2"><strong>6.2 Why do you insist upon a build with -g? Doesn't it
|
||
|
waste disk and memory space?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
From time to time a submitted port has snuck in without -g. This has
|
||
|
<em>always</em> ended up causing problems. There are only two valid
|
||
|
excuses for not using -g in a port:
|
||
|
|
||
|
<ul>
|
||
|
<li>The compiler does not support -g</li>
|
||
|
|
||
|
<li>An alternate form of -g is needed with optimization, e.g.
|
||
|
-g3.</li>
|
||
|
</ul>
|
||
|
|
||
|
<p>There will be no new ports added without -g (or a suitable
|
||
|
alternative) being set.</p>
|
||
|
|
||
|
<p>-g has not been arbitrarily added to the ports which do not
|
||
|
currently have it because we don't know if doing so would break the
|
||
|
build. However, any support issues with one of those port <em>will</em>
|
||
|
lead to the correct -g setting being determined and permanently
|
||
|
added.</p>
|
||
|
|
||
|
<p>Processors are fast enough (and disk space is cheap enough) that -g
|
||
|
should be automatic in all compilers with no way of turning it off, and
|
||
|
/bin/strip should be a symlink to /bin/true. Human life is too short to
|
||
|
deal with binaries built without -g. Such binaries should be a bad
|
||
|
memory of the days of KIPS processors and disks that costs several
|
||
|
dollars per kilobyte.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.3"><strong>6.3 Why don't you make c-client a shared
|
||
|
library?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
All too often, shared libraries create far more problems than they
|
||
|
solve.
|
||
|
|
||
|
<p>Remember that you only gain the benefit of a shared library when
|
||
|
there are multiple applications which use that shared library. Even
|
||
|
without shared libraries, on most modern operating systems (and many
|
||
|
ancient ones too!) applications will share their text segments between
|
||
|
across multiple processes running the same application. This means that
|
||
|
if your system only runs one application (e.g. imapd) that uses the
|
||
|
c-client library, then you gain no benefit from making c-client a
|
||
|
shared library even if it has 100 imapd processes. You will, however
|
||
|
suffer added complexity.</p>
|
||
|
|
||
|
<p>If you have a server system that just runs imapd and ipop3d, then
|
||
|
making c-client a shared library will save just one copy of c-client no
|
||
|
matter how many IMAP/POP3 processes are running.</p>
|
||
|
|
||
|
<p>The problem with shared libraries is that you have to keep around a
|
||
|
copy of the library every time something changes in the library that
|
||
|
would affect the interface the library presents to the application. So,
|
||
|
you end up having many copies of the same shared library.</p>
|
||
|
|
||
|
<p>If you don't keep multiple copies of the shared library, then one of
|
||
|
two things happens. If there was proper versioning, then you'll get a
|
||
|
message such as "cannot open shared object file" or "minor versions
|
||
|
don't match" and the application won't run. Otherwise, the application
|
||
|
will run, but will fail in mysterious ways.</p>
|
||
|
|
||
|
<p>Several sites and third-party distributors have modified the
|
||
|
c-client makefile in order to make c-client be a shared library.
|
||
|
<em>When</em> (not <em>if</em>) a c-client based application fails in
|
||
|
mysterious ways because of a library compatibility problem, the result
|
||
|
is a bug report. A lot of time and effort ends up getting wasted
|
||
|
investigating such bug reports.</p>
|
||
|
|
||
|
<p>Memory is so cheap these days that it's not worth it. Human life is
|
||
|
too short to deal with shared library compatibility problems.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.4"><strong>6.4 Why don't you use iconv() for internationalization
|
||
|
support?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>iconv() is not ubiquitous enough.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.5"><strong>6.5 Why is the IMAP server connected to the home
|
||
|
directory by default?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
The IMAP server has no way of knowing what you might call "mail" as
|
||
|
opposed to "some other file"; in fact, you can use IMAP to access any
|
||
|
file.
|
||
|
|
||
|
<p>The IMAP server also doesn't know whether your preferred
|
||
|
subdirectory for mailbox files is "mail/", ".mail/", "Mail/",
|
||
|
"Mailboxes/", or any of a zillion other possibilities. If one such name
|
||
|
were chosen, it would undoubtably anger the partisans of all the other
|
||
|
names.</p>
|
||
|
|
||
|
<p>It is possible to modify the software so that the default connected
|
||
|
directory is someplace else. Please read the file CONFIG for discussion
|
||
|
of this and other issues.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.6"><strong>6.6 I have a Windows system. Why isn't the server plug
|
||
|
and play for me?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
There is no standard for how mail is stored on Windows; nor a single
|
||
|
standard SMTP server. The closest to either would be the SMTP server in
|
||
|
Microsoft's IIS.
|
||
|
|
||
|
<p>So there's no default by which to make assumptions. As the software
|
||
|
is set up, it assumes that the each user has an Windows login account
|
||
|
and private home directory, and that mail is stored on that home
|
||
|
directory as files in one of the popular UNIX formats. It also assumes
|
||
|
that there is some tool equivalent to inetd on UNIX that does the
|
||
|
TCP/IP listening and server startup.</p>
|
||
|
|
||
|
<p>Basically, unless you're an email software hacker, you probably want
|
||
|
to look elsewhere if you want IMAP/POP servers for Windows.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.7"><strong>6.7 I looked at the UNIX SSL code and saw that you have
|
||
|
the SSL data payload size set to 8192 bytes. SSL allows 16K; why aren't
|
||
|
you using the full size?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is to avoid an interoperability problem with:
|
||
|
|
||
|
<ul>
|
||
|
<li>PC IMAP clients that use Microsoft's SChannel.DLL (SSPI) for SSL
|
||
|
support</li>
|
||
|
|
||
|
<li>Microsoft Exchange server (which also uses SChannel).</li>
|
||
|
</ul>
|
||
|
|
||
|
<p>SChannel has a bug that makes it think that the maximum SSL data
|
||
|
payload size is 16379 bytes -- 5 bytes too small. Thus, c-client has to
|
||
|
make sure that it never transmits full sized SSL packets.</p>
|
||
|
|
||
|
<p>The reason for using 8K (as opposed to, say, 16379 bytes, or 15K,
|
||
|
or...) is that it corresponds with the TCP buffer size that the
|
||
|
software uses elsewhere for input; there's a slight performance benefit
|
||
|
to having the two sizes correspond or at least be a multiple of each
|
||
|
other. Also, it keeps the size as a power of two, which might be
|
||
|
significant on some platforms.</p>
|
||
|
|
||
|
<p>There wasn't a significant difference that we could measure between
|
||
|
8K and 15K.</p>
|
||
|
|
||
|
<p>Microsoft has developed a hotfix for this bug. Look up MSKB article
|
||
|
number 300562. Contrary to the article text which implies that this is
|
||
|
a Pine issue, this bug also affects Microsoft Exchange server with
|
||
|
<em>any</em> client that transmits full-sized SSL payloads.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.8"><strong>6.8 Why is an mh format INBOX called #mhinbox instead
|
||
|
of just INBOX?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
It's a long story. In brief, the mh format driver is less functional
|
||
|
than any of the other drivers. It turned out that there were some users
|
||
|
(including high-level administrators) who tried mh years ago and no
|
||
|
longer use it, but still had an mh profile left behind.
|
||
|
|
||
|
<p>When the mh driver used INBOX, it would see the mh profile, and
|
||
|
proceed to move the user's INBOX into the mh format INBOX. This caused
|
||
|
considerable confusion as some things stopped working.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.9"><strong>6.9 Why don't you support the maildir
|
||
|
format?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
It is technically difficult to support maildir in IMAP while
|
||
|
maintaining acceptable performance, robustness, following the
|
||
|
requirements of the IMAP protocol specification, and following the
|
||
|
requirements of maildir.
|
||
|
|
||
|
<p>No one has succeeded in accomplishing all four together. The various
|
||
|
maildir drivers offered as patches all have these problems. The problem
|
||
|
is exacerbated because this implementation supports multiple formats;
|
||
|
consequently this implementation can't make any performance shortcuts
|
||
|
by assuming that all the world is maildir.</p>
|
||
|
|
||
|
<p>We can't do a better job than the maildir fan community has done
|
||
|
with their maildir drivers. Similarly, if the maildir fan community
|
||
|
provides the maildir driver, they take on the responsibility for
|
||
|
answering maildir-specific support questions. This is as it should be,
|
||
|
and that is why maildir support is left to the maildir fan
|
||
|
community.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.10"><strong>6.10 Why don't you support the Cyrus
|
||
|
format?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
There's no point to doing so. An implementation which supports multiple
|
||
|
formats will never do as well as one which is optimized to support one
|
||
|
single format.
|
||
|
|
||
|
<p>If you want to use Cyrus mailbox format, you should use the Cyrus
|
||
|
server, which is the native implementation of that format and is
|
||
|
specifically optimized for that format. That's also why Cyrus doesn't
|
||
|
implement any other format.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.11"><strong>6.11 Why is it creating extra forks on my SVR4
|
||
|
system?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is because your system only has fcntl() style locking and not
|
||
|
flock() style locking. fcntl() locking has a design flaw that causes a
|
||
|
close() to release any locks made by that process on the file opened on
|
||
|
that file descriptor, even if the lock was made on a different file
|
||
|
descriptor.
|
||
|
|
||
|
<p>This design flaw causes unexpected loss of lock, and consequent
|
||
|
mailbox corruption. The workaround is to do certain "dangerous
|
||
|
operations" in another fork, thus avoiding doing a close() in the
|
||
|
vulnerable fork.</p>
|
||
|
|
||
|
<p>The best way to solve this problem is to upgrade your SVR4 (Solaris,
|
||
|
AIX, HP-UX, SGI) or OSF/1 system to a more advanced operating system,
|
||
|
such as Linux or BSD. These more advanced operating systems have
|
||
|
fcntl() locking for compatibility with SVR4, but also have flock()
|
||
|
locking.</p>
|
||
|
|
||
|
<p>Beware of certain SVR4 systems, such as AIX, which have an "flock()"
|
||
|
function in their C library that is just a jacket that does an fcntl()
|
||
|
lock. This is not a true flock(), and has the same design flaw as
|
||
|
fcntl().</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.12"><strong>6.12 Why are you so fussy about the date/time format in
|
||
|
the internal <code>"From "</code> line in traditional UNIX mailbox
|
||
|
files? My other mail program just considers every line that starts with
|
||
|
<code>"From "</code> to be the start of the message.</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
You just answered your own question. If any line that starts with
|
||
|
<code>"From "</code> is treated as the start of a message, then
|
||
|
every message text line which starts with <code>"From "</code> has
|
||
|
to be quoted (typically by prefixing a ">" character). People
|
||
|
complain about this -- "why did a > get stuck in my message?"
|
||
|
|
||
|
<p>So, good mail reading software only considers a line to be a
|
||
|
<code>"From "</code> line if it follows the actual specification
|
||
|
for a "From " line. This means, among other things, that the day of
|
||
|
week is fixed-format: <code>"May 14"</code>, but
|
||
|
<code>"May 7"</code> (note the extra space) as opposed to
|
||
|
<code>"May 7"</code>. ctime() format for the date is the most
|
||
|
common, although POSIX also allows a numeric timezone after the
|
||
|
year. For compatibility with ancient software, the seconds are optional,
|
||
|
the timezone may appear before the year, the old 3-letter timezones are
|
||
|
also permitted, and "remote from xxx" may appear after the whole
|
||
|
thing.</p>
|
||
|
|
||
|
<p>Unfortunately, some software written by novices use other formats.
|
||
|
The most common error is to have a variable-width day of month, perhaps
|
||
|
in the erroneous belief that RFC 2822 (or RFC 822) defines the format of
|
||
|
the date/time in the <code>"From "</code> line (it doesn't; no RFC
|
||
|
describes internal formats). I've seen a few other goofs, such as a
|
||
|
single-digit second, but these are less common.</p>
|
||
|
|
||
|
<p>If you are writing your own software that writes mailbox files, and
|
||
|
you really aren't all that savvy with all the ins and outs and ancient
|
||
|
history, you should seriously consider using the c-client library (e.g.
|
||
|
routine mail_append()) instead of doing the file writes yourself. If
|
||
|
you must do it yourself, use ctime(), as in:</p>
|
||
|
<pre>
|
||
|
fprintf (mbx,"From %s@%h %s",user,host,ctime (time (0)));
|
||
|
</pre>rather than try to figure out a good format yourself. ctime() is the
|
||
|
most traditional format and nobody will flame you for using it.
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.13"><strong>6.13 Why is traditional UNIX format the default
|
||
|
format?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Compatibility with the past 30 or so years of UNIX history. This
|
||
|
server is the only one that completely interoperates with legacy UNIX
|
||
|
mail tools.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.14"><strong>6.14 Why do you write this "DON'T DELETE THIS MESSAGE
|
||
|
-- FOLDER INTERNAL DATA" message at the start of traditional UNIX and
|
||
|
MMDF format mailboxes?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This pseudo-message serves two purposes.
|
||
|
|
||
|
<p>First, it establishes the mailbox format even when the mailbox has
|
||
|
no messages. Otherwise, a mailbox with no messages is a zero-byte file,
|
||
|
which could be one of several formats.</p>
|
||
|
|
||
|
<p>Second, it holds mailbox metadata used by IMAP: the UID validity,
|
||
|
the last assigned UID, and mailbox keywords. Without this metadata,
|
||
|
which must be preserved even when the mailbox has no messages, the
|
||
|
traditional UNIX format wouldn't be able to support the full
|
||
|
capabilities of IMAP.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.15"><strong>6.15 Why don't you stash the mailbox metadata in the
|
||
|
first real message of the mailbox instead of writing this fake FOLDER
|
||
|
INTERNAL DATA message?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
In fact, that is what is done if the mailbox is non-empty and does not
|
||
|
already have a FOLDER INTERNAL DATA message.
|
||
|
|
||
|
<p>One problem with doing that is that if some external program removes
|
||
|
the first message, the metadata is lost and must be recreated, thus
|
||
|
losing any prior UID or keyword list status that IMAP clients may
|
||
|
depend upon.</p>
|
||
|
|
||
|
<p>Another problem is that this doesn't help if the last message is
|
||
|
deleted. This will result in an empty mailbox, and the necessity to
|
||
|
create a FOLDER INTERNAL DATA message.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.16"><strong>6.16 Why aren't "dual-use" mailboxes the
|
||
|
default?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Compatibility with the past 30 or so years of UNIX history, not to
|
||
|
mention compatibility with user expectations when using shell tools.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.17"><strong>6.17 Why do you use ucbcc to build on
|
||
|
Solaris?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
It is a long, long story about why cc is set to ucbcc. You need to
|
||
|
invoke the C compiler so that it links with the SVR4 libraries and not
|
||
|
the BSD libraries, otherwise readdir() will return the wrong
|
||
|
information.
|
||
|
|
||
|
<p>Of all the names in the most common path, ucbcc is the only name to
|
||
|
be found (on /usr/ccs/bin) that points to a suitable compiler. cc is
|
||
|
likely to be /usr/ucb/cc which is absolutely not the compiler that you
|
||
|
want. The real SVR4 cc is probably something like /opt/SUNWspro/bin/cc
|
||
|
which is rarely in anyone's path by default.</p>
|
||
|
|
||
|
<p>ucbcc is probably a link to acc, e.g. /opt/SUNWspro/SC4.0/bin/acc,
|
||
|
and is the UCB C compiler using the SVR4 libraries.</p>
|
||
|
|
||
|
<p>If ucbcc isn't on your system, then punt on the SUN C compiler and
|
||
|
use gcc instead (the gso port instead of the sol port).</p>
|
||
|
|
||
|
<p>If, in spite of all the above warnings, you choose to change "ucbcc"
|
||
|
to "cc", you will probably find that the -O2 needs to be changed to -O.
|
||
|
If you don't get any error messages with -O2, that's a pretty good
|
||
|
indicator that you goofed and are running the compiler that will link
|
||
|
with the BSD libraries.</p>
|
||
|
|
||
|
<p>To recap:</p>
|
||
|
|
||
|
<ul>
|
||
|
<li>The sol port is designed to be built using the UCB compiler using
|
||
|
the SVR4 libraries. This compiler is "ucbcc", which is lunk to acc.
|
||
|
You use -O2 as one of the CFLAGS.</li>
|
||
|
|
||
|
<li>If you build the sol port with the UCB compiler using the BSD
|
||
|
libraries, you will get no error messages but you will get bad
|
||
|
binaries (the most obvious symptom is dropping the first two
|
||
|
characters return filenames from the imapd LIST command. This
|
||
|
compiler also uses -O2, and is very often what the user gets from
|
||
|
"cc". <strong>BEWARE</strong></li>
|
||
|
|
||
|
<li>If you build the sol port with the real SVR4 compiler, which is
|
||
|
often hidden away or unavailable on many systems, then you will get
|
||
|
errors from -O2 and you need to change that to -O. But you will get a
|
||
|
good binary. However, you should try it with -O2 first, to make sure
|
||
|
that you got this compiler and not the UCB compiler using BSD
|
||
|
libraries.</li>
|
||
|
</ul>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.18"><strong>6.18 Why should I care about some old system with BSD
|
||
|
libraries? cc is the right thing on my Solaris system!</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Because there still are sites that use such systems. On those systems,
|
||
|
the assumption that "cc" does the right thing will lead to corrupt
|
||
|
binaries with no error message or other warning that anything is amiss.
|
||
|
|
||
|
<p>Too many sites have fallen victim to this problem.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.19"><strong>6.19 Why do you insist upon writing .lock files in the
|
||
|
spool directory?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>Compatibility with the past 30 years of UNIX software which deals
|
||
|
with the spool directory, especially software which delivers mail.
|
||
|
Otherwise, it is possible to lose mail.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="6.20"><strong>6.20 Why should I care about compatibility with the
|
||
|
past?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>This is one of those questions in which the answer never convinces
|
||
|
those who ask it. Somehow, everybody who ever asks this question ends up
|
||
|
answering it for themselves as they get older, with the very answer that
|
||
|
they rejected years earlier.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><br></p>
|
||
|
|
||
|
<h2><a name="problems">7. Problems and Annoyances</a></h2>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.1"><strong>7.1 Help! My INBOX is empty! What happened to my
|
||
|
messages?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
If you are seeing "0 messages" when you open INBOX and you know you
|
||
|
have messages there (and perhaps have looked at your mail spool file
|
||
|
and see that messages are there), then probably there is something
|
||
|
wrong with the very first line of your mail spool file. Make sure that
|
||
|
the first five bytes of the file are "From ", followed by an email
|
||
|
address and a date/time in ctime() format, e.g.:
|
||
|
<pre>
|
||
|
From fred@foo.bar Mon May 7 20:54:30 2001
|
||
|
</pre>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.2"><strong>7.2 Help! All my messages in a non-INBOX mailbox have
|
||
|
been concatenated into one message which claims to be from me and has a
|
||
|
subject of the file name of the mailbox! What's going
|
||
|
on?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Something wrong with the very first line of the mailbox. Make sure that
|
||
|
the first five bytes of the file are "From ", followed by an email
|
||
|
address and a date/time in ctime() format, e.g.:
|
||
|
<pre>
|
||
|
From fred@foo.bar Mon May 7 20:54:30 2001
|
||
|
</pre>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.3"><strong>7.3 Why do I get the message:</strong> <tt>CREATE
|
||
|
failed: Can't create mailbox node xxxxxxxxx: File exists</tt>
|
||
|
<strong>and how do I fix it?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>See the answer to the <a href="#1.8">Are hierarchical mailboxes
|
||
|
supported?</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.4"><strong>7.4 Why can't I log in to the server? The user name and
|
||
|
password are right!</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
There are a myriad number of possible answers to this question. The
|
||
|
only way to say for sure what is wrong is run the server under a
|
||
|
debugger such as gdb while root (yes, you must be root) with a
|
||
|
breakpoint at routines checkpw() and loginpw(), then single-step until
|
||
|
you see which test rejected you. The server isn't going to give any
|
||
|
error messages other than "login failed" in the name of not giving out
|
||
|
any unnecessary information to unauthorized individuals.
|
||
|
|
||
|
<p>Here are some of the more common reasons why login may fail:</p>
|
||
|
|
||
|
<ul>
|
||
|
<li>You didn't really give the correct user name and/or
|
||
|
password.</li>
|
||
|
|
||
|
<li>Your client doesn't send the LOGIN command correctly; for
|
||
|
example, IMAP2 clients won't send a password containing a "*"
|
||
|
correctly to an IMAP4 server.</li>
|
||
|
|
||
|
<li>If you have set up a CRAM-MD5 database, remember that the
|
||
|
password used is the one in the CRAM-MD5 database, and furthermore
|
||
|
that there must also be an entry in /etc/passwd (but the /etc/passwd
|
||
|
password is not used).</li>
|
||
|
|
||
|
<li>If you are using PAM, have you created a service file for the
|
||
|
server in /etc/pam.d?</li>
|
||
|
|
||
|
<li>If you are using shadow passwords, have you used an appropriate
|
||
|
port when building? In particular, note that "lnx" is for Linux
|
||
|
systems without shadow passwords; you probably want "slx" or "lnp"
|
||
|
instead.</li>
|
||
|
|
||
|
<li>If your system has account or password expirations, check to see
|
||
|
that the expiration date hasn't passed.</li>
|
||
|
|
||
|
<li>You can't log in as root or any other UID 0 user. This is for
|
||
|
your own safety, not to mention the fact that the servers use UID 0
|
||
|
as meaning "not logged in".</li>
|
||
|
</ul>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.5"><strong>7.5 Help! My load average is soaring and I see hundreds
|
||
|
of POP and IMAP servers, many logged in as the same
|
||
|
user!</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Certain inferior losing GUI mail reading programs have a "synchronize
|
||
|
all mailboxes at startup" (IMAP) or "check for new mail every second"
|
||
|
(POP) feature which causes a rapid and unchecked spawning of servers.
|
||
|
|
||
|
<p>This is not a problem in the server; the client is really asking for
|
||
|
all those server sessions. Unfortunately, there isn't much that the POP
|
||
|
and IMAP servers can do about it; they don't spawned themselves.</p>
|
||
|
|
||
|
<p>Some sites have added code to record the number of server sessions
|
||
|
spawned per user per hour, and disable login for a user who has
|
||
|
exceeded a predetermined rate. This doesn't stop the servers from being
|
||
|
spawned; it just means that a server session will commit suicide a bit
|
||
|
faster.</p>
|
||
|
|
||
|
<p>Another possibility is to detect excessive server spawning activity
|
||
|
at the level where the server is spawned, which would be inetd or
|
||
|
possibly tcpd. The problem here is that this is a hard time to
|
||
|
quantify. 50 sessions in a minute from a multi-user timesharing system
|
||
|
may be perfectly alright, whereas 10 sessions a minute from a PC may be
|
||
|
too much.</p>
|
||
|
|
||
|
<p>The real solution is to fix the client configuration, by disabling
|
||
|
those evil features. Also tell the vendors of those clients how you
|
||
|
feel about distributing denial-of-service attack tools in the guise of
|
||
|
mail reading programs.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.6"><strong>7.6 Why does mail disappear even though I set "keep
|
||
|
mail on server"?</strong></a><br>
|
||
|
<a name="7.7"><strong>7.7 Why do I get the message</strong> <tt>Moved #####
|
||
|
bytes of new mail to /home/user/mbox from /var/spool/mail/user</tt>
|
||
|
<strong>and why did this happen?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is probably caused by the mbox driver. If the file "mbox" exists
|
||
|
on the user's home directory and is in UNIX mailbox format, then when
|
||
|
INBOX is opened this file will be selected as INBOX instead of the mail
|
||
|
spool file. Messages will be automatically transferred from the mail
|
||
|
spool file into the mbox file.
|
||
|
|
||
|
<p>To disable this behavior, delete "mbox" from the EXTRADRIVERS list
|
||
|
in the top-level Makefile and rebuild. Note that if you do this, users
|
||
|
won't be able to access the messages that have already been moved to
|
||
|
mbox unless they open mbox instead of INBOX.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.8"><strong>7.8 Why isn't it showing the local host name as a
|
||
|
fully-qualified domain name?</strong></a><br>
|
||
|
<a name="7.9"><strong>7.9 Why is the local host name in the
|
||
|
From/Sender/Message-ID headers of outgoing mail not coming out as a
|
||
|
fully-qualified domain name?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Your UNIX system is misconfigured. The entry for your system in
|
||
|
/etc/hosts must have the fully-qualified domain name first, e.g.
|
||
|
<pre>
|
||
|
105.69.1.234 myserver.example.com myserver
|
||
|
</pre>
|
||
|
|
||
|
<p>A common mistake of novice system administrators is to have the
|
||
|
short name first, e.g.</p>
|
||
|
<pre>
|
||
|
105.69.1.234 myserver myserver.example.com
|
||
|
|
||
|
</pre>
|
||
|
|
||
|
<p>or to omit the fully qualified domain name entirely, e.g.</p>
|
||
|
<pre>
|
||
|
105.69.1.234 myserver
|
||
|
</pre>
|
||
|
|
||
|
<p>The result of this is that when the IMAP toolkit does a
|
||
|
gethostbyname() call to get the fully-qualified domain name, it would
|
||
|
get "myserver" instead of "myserver.example.com".</p>
|
||
|
|
||
|
<p>On some systems, a configuration file (typically named
|
||
|
/etc/svc.conf, /etc/netsvc.conf, or /etc/nsswitch.conf) can be used to
|
||
|
configure the system to use the domain name system (DNS) instead of
|
||
|
/etc/hosts, so it doesn't matter if /etc/hosts is misconfigured.</p>
|
||
|
|
||
|
<p>Check the man pages for gethostbyname, hosts, svc, and/or netsvc for
|
||
|
more information.</p>
|
||
|
|
||
|
<p>Unfortunately, certain vendors, most notably SUN, have failed to
|
||
|
make this clear in their documentation. Most of SUN's documentation
|
||
|
assumes a corporate network that is not connected to the Internet.</p>
|
||
|
|
||
|
<p>net.folklore once (late 1980s) held that the proper procedure was to
|
||
|
append the results of getdomainname() to the name returned by
|
||
|
gethostname(), and some versions of sendmail configuration files were
|
||
|
distributed that did this. This was incorrect; the string returned from
|
||
|
getdomainname() is the Yellow Pages (a.k.a NIS) domain name, which is a
|
||
|
completely different (albeit unfortunately named) entity from an
|
||
|
Internet domain. These were often fortuitously the same string, except
|
||
|
when they weren't. Frequently, this would result in host names with
|
||
|
spuriously doubled domain names, e.g.</p>
|
||
|
<pre>
|
||
|
myserver.example.com.example.com
|
||
|
|
||
|
</pre>
|
||
|
|
||
|
<p>This practice has been thoroughly discredited for many years, but
|
||
|
folklore dies hard.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.10"><strong>7.10 What does the message:</strong> <tt>Mailbox
|
||
|
vulnerable - directory /var/spool/mail must have 1777 protection</tt>
|
||
|
<strong>mean? How can I fix this?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
In order to update a mailbox in the default UNIX format, it is
|
||
|
necessary to create a lock file to prevent the mailer from delivering
|
||
|
mail while an update is in progress. Some systems use a directory
|
||
|
protection of 775, requiring that all mail handling programs be setgid
|
||
|
mail; or of 755, requiring that all mail handling programs be setuid
|
||
|
root.
|
||
|
|
||
|
<p>The IMAP toolkit does not run with any special privileges, and I
|
||
|
plan to keep it that way. It is antithetical to the concept of a
|
||
|
toolkit if users can't write their own programs to use it. Also, I've
|
||
|
had enough bad experiences with security bugs while running privileged;
|
||
|
the IMAP and POP servers have to be root when not logged in, in order
|
||
|
to be able to log themselves in. I don't want to go any deeper down
|
||
|
that slippery slope.</p>
|
||
|
|
||
|
<p>Directory protection 1777 is secure enough on most well-managed
|
||
|
systems. If you can't trust your users with a 1777 mail spool (petty
|
||
|
harassment is about the limit of the abuse exposure), then you have
|
||
|
much worse problems then that.</p>
|
||
|
|
||
|
<p>If you absolutely insist upon requiring privileges to create a lock
|
||
|
file, external file locking can be done via a setgid mail program named
|
||
|
/etc/mlock (this is defined by LOCKPGM in the c-client Makefile). If
|
||
|
the toolkit is unable to create a <...mailbox...>.lock file in
|
||
|
the directory by itself, it will try to call mlock to do it. I do not
|
||
|
recommend doing this for performance reasons.</p>
|
||
|
|
||
|
<p>A sample mlock program is included as part of imap-2007. We have
|
||
|
tried to make this sample program secure, but it has not been
|
||
|
thoroughly audited.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.11"><strong>7.11 What does the message:</strong> <tt>Mailbox is
|
||
|
open by another process, access is readonly</tt> <strong>mean? How do I
|
||
|
fix this?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
A problem occurred in applying a lock to a /tmp lock file. Either some
|
||
|
other program has the mailbox open and won't relenquish it, or
|
||
|
something is wrong with the protection of /tmp or the lock.
|
||
|
|
||
|
<p>Make sure that the /tmp directory is protected 1777. Some security
|
||
|
scripts incorrectly set the protection of the /tmp directory to 775,
|
||
|
which disables /tmp for all non-privileged programs.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.12"><strong>7.12 What does the message:</strong> <tt>Can't get
|
||
|
write access to mailbox, access is readonly</tt>
|
||
|
<strong>mean?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>The mailbox file is write-protected against you.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.13"><strong>7.13 I set my POP3 client to "delete messages from
|
||
|
server" but they never get deleted. What is wrong?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Make sure that your mailbox is not read-only: that the mailbox is owned
|
||
|
by you and write enabled (protection 0600), and that the /tmp directory
|
||
|
is longer world-writeable. /tmp must be world-writeable because lots of
|
||
|
applications use it for scratch space. To fix this, do
|
||
|
<pre>
|
||
|
|
||
|
chmod 1777 /tmp
|
||
|
</pre>as root.
|
||
|
|
||
|
<p>Make sure that your POP3 client issues a QUIT command when it
|
||
|
finishes. The POP3 protocol specifies that deletions are discarded
|
||
|
unless a proper QUIT is done.</p>
|
||
|
|
||
|
<p>Make sure that you are not opening multiple POP3 sessions to the
|
||
|
same mailbox. It is a requirement of the POP3 protocol than only one
|
||
|
POP3 session be in effect to a mailbox at a time, however some,
|
||
|
poorly-written POP3 clients violate this. Also, some background "check
|
||
|
for new mail" tasks also cause a violation. See the answer to the
|
||
|
<a href="#7.19">What does the syslog message: Killed (lost mailbox
|
||
|
lock) user=... host=... mean?</a> question for more details.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.14"><strong>7.14 What do messages such as:</strong></a></p>
|
||
|
<pre>
|
||
|
Message ... UID ... already has UID ...
|
||
|
Message ... UID ... less than ...
|
||
|
Message ... UID ... greater than last ...
|
||
|
Invalid UID ... in message ..., rebuilding UIDs
|
||
|
</pre>
|
||
|
|
||
|
<p><strong>mean?</strong></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Something happened to corrupt the unique identifier regime in the
|
||
|
mailbox. In traditional UNIX-format mailboxes, this can happen if the
|
||
|
user deleted the "DO NOT DELETE" internal message.
|
||
|
|
||
|
<p>This problem is relatively harmless; a new valid unique identifier
|
||
|
regime will be created. The main effect is that any references to the
|
||
|
old UIDs will no longer be useful.</p>
|
||
|
|
||
|
<p>So, unless it is a chronic problem or you feel like debugging, you
|
||
|
can safely ignore these messages.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.15"><strong>7.15 What do the error messages:</strong></a></p>
|
||
|
<pre>
|
||
|
Unable to read internal header at ...
|
||
|
Unable to find CRLF at ...
|
||
|
Unable to parse internal header at ...
|
||
|
Unable to parse message date at ...
|
||
|
Unable to parse message flags at ...
|
||
|
Unable to parse message UID at ...
|
||
|
Unable to parse message size at ...
|
||
|
Last message (at ... ) runs past end of file ...
|
||
|
</pre>
|
||
|
|
||
|
<p><strong>mean? I am using mbx format.</strong></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
The mbx-format mailbox is corrupted and needs to be repaired.
|
||
|
|
||
|
<p>You should make an effort to find out why the corruption happened.
|
||
|
Was there an obvious system problem (crash or disk failure)? Did the
|
||
|
user accidentally access the file via NFS? Mailboxes don't get
|
||
|
corrupted by themselves; something caused the problem.</p>
|
||
|
|
||
|
<p>Some people have developed automated scripts, but if you're
|
||
|
comfortable using emacs it's pretty easy to fix it manually. Do
|
||
|
<em>not</em> use vi or any other editor unless you are certain that
|
||
|
editor can handle binary!!!</p>
|
||
|
|
||
|
<p>If you are not comfortable with emacs, or if the file is too large
|
||
|
to read with emacs, see the "step-by-step" technique later on for
|
||
|
another way of doing it.</p>
|
||
|
|
||
|
<p>After the word "at" in the error message is the byte position it got
|
||
|
to when it got unhappy with the file, e.g. if you see:</p>
|
||
|
<pre>
|
||
|
Unable to parse internal header at 43921: ne bombastic blurdybloop
|
||
|
</pre>The problem occurs at the 43,931 byte in the file. That's the point you
|
||
|
need to fix. c-client is expecting an internal header at that byte number,
|
||
|
looking something like:
|
||
|
<pre>
|
||
|
6-Jan-1998 17:42:24 -0800,1045;000000100001-00000001
|
||
|
</pre>The format of this internal line is:
|
||
|
<pre>
|
||
|
dd-mmm-yyyy hh:mm:ss +zzzz,ssss;ffffffffFFFF-UUUUUUUU
|
||
|
</pre>The only thing that is variable is the "ssss" field, it can be as many
|
||
|
digits as needed. All other fields (inluding the "dd") are fixed width. So,
|
||
|
the easiest thing to do is to look forward in the file for the next internal
|
||
|
header, and delete everything from the error point to that internal header.
|
||
|
|
||
|
<p>Here's what to do if you want to be smarter and do a little bit more
|
||
|
work. Generally, you're in the middle of a message, and there's nothing
|
||
|
wrong with that message. The problem happened in the *previous*
|
||
|
message. So, search back to the previous internal header. Now, remember
|
||
|
that "ssss" field? That's the size of that message.</p>
|
||
|
|
||
|
<p>Mark where you are in the file, move the cursor to the line after
|
||
|
the internal header, and skip that many bytes ("ssss") forward. If
|
||
|
you're at the point of the error in the file, then that message is
|
||
|
corrupt. If you're at a different point, then perhaps the previous
|
||
|
message is corrupt and has a too long size count that "ate" into this
|
||
|
message.</p>
|
||
|
|
||
|
<p>Basically, what you need to do is make sure that all those size
|
||
|
counts are right, and that moving "ssss" bytes from the line after the
|
||
|
internal header will land you at another internal header.</p>
|
||
|
|
||
|
<p>Usually, once you know what you're looking at, it's pretty easy to
|
||
|
work out the corruption, and the best remedial action. Repair scripts
|
||
|
will make the problem go away but may not always do the smartest/best
|
||
|
salvage of the user's data. Manual repair is more flexible and usually
|
||
|
preferable.</p>
|
||
|
|
||
|
<p>Here is a step-by-step technique for fixing corrupt mbx files that's
|
||
|
a bit cruder than the procedure outlined above, but works for any size
|
||
|
file.</p>
|
||
|
|
||
|
<p>In this example, suppose that the corrupt file is INBOX, the error
|
||
|
message is</p>
|
||
|
<pre>
|
||
|
Unable to find CRLF at 132551754
|
||
|
</pre>and the size of the INBOX file is 132867870 bytes.
|
||
|
|
||
|
<p>The first step is to split the mailbox file at the point of the
|
||
|
error:</p>
|
||
|
|
||
|
<ul>
|
||
|
<li>Rename the INBOX file to some other name, such as INBOX.bad.</li>
|
||
|
|
||
|
<li>Copy the first 132,551,754 bytes of INBOX.bad to another file,
|
||
|
such as INBOX.new.</li>
|
||
|
|
||
|
<li>Extract the trailing 316,116 bytes (132867870-132551754) of
|
||
|
INBOX.bad into another file, such as INBOX.tail.</li>
|
||
|
|
||
|
<li>You no longer need INBOX.bad. Delete it.</li>
|
||
|
</ul>In other words, use the number from the "Unable to find CRLF at"
|
||
|
as the point to split INBOX into two new files, INBOX.new and
|
||
|
INBOX.tail.
|
||
|
|
||
|
<p>Now, remove the erroneous data:</p>
|
||
|
|
||
|
<ul>
|
||
|
<li>Verify that you can open INBOX.new in IMAP or Pine.</li>
|
||
|
|
||
|
<li>The last message of INBOX.new is probably corrupted. Copy it to
|
||
|
another file, such as badmsg.1, then delete and expunge that last
|
||
|
message from INBOX.new</li>
|
||
|
|
||
|
<li>Locate the first occurance of text in INBOX.tail which looks like
|
||
|
an internal header, as described above.</li>
|
||
|
|
||
|
<li>Remove all the text which occurs prior to that point, and place
|
||
|
it into another file, such as badmsg.2. Note that in the case of a
|
||
|
single digit date, there is a leading space which must not be removed
|
||
|
(e.g. " 6-Nov-2001" not "6-Nov-2001").</li>
|
||
|
</ul>
|
||
|
|
||
|
<p>Reassemble the mailbox:</p>
|
||
|
|
||
|
<ul>
|
||
|
<li>Append INBOX.tail to INBOX.new.</li>
|
||
|
|
||
|
<li>You no longer need INBOX.tail. Delete it.</li>
|
||
|
|
||
|
<li>Verify that you can open INBOX.new in IMAP or Pine.</li>
|
||
|
</ul>
|
||
|
|
||
|
<p>Reinstall INBOX.new as INBOX:</p>
|
||
|
|
||
|
<ul>
|
||
|
<li>Check to see if you have received any new messages while
|
||
|
repairing INBOX.</li>
|
||
|
|
||
|
<li>If you haven't received any new messages while repairing INBOX,
|
||
|
just rename INBOX.new to INBOX.</li>
|
||
|
|
||
|
<li>If you have received new messages, be sure to copy the new
|
||
|
messages from INBOX to INBOX.new before doing the rename.</li>
|
||
|
</ul>
|
||
|
|
||
|
<p>You now have a working INBOX, as well as two files with corrupted
|
||
|
data (badmsg.1 and badmsg.2). There may be some useful data in the two
|
||
|
badmsg files that you might want to try salvaging; otherwise you can
|
||
|
delete the two badmsg files.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.16"><strong>7.16 What do the syslog messages:</strong></a></p>
|
||
|
<pre>
|
||
|
|
||
|
imap/tcp server failing (looping)
|
||
|
pop3/tcp server failing (looping)
|
||
|
</pre>
|
||
|
|
||
|
<p><strong>mean? When it happens, the listed service shuts down. How can I
|
||
|
fix this?</strong></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
The error message "server failing (looping), service terminated" is not
|
||
|
from either the IMAP or POP servers. Instead, it comes from inetd, the
|
||
|
daemon which listens for TCP connections to a number of servers,
|
||
|
including the IMAP and POP servers.
|
||
|
|
||
|
<p>inetd has a limit of 40 new server sessions per minute for any
|
||
|
particular service. If more than 40 sessions are initiated in a minute,
|
||
|
inetd will issue the "failing (looping), service terminated" message
|
||
|
and shut down the service for 10 minutes. inetd does this to prevent
|
||
|
system resource consumption by a client which is spawning infinite
|
||
|
numbers of servers. It should be noted that this is a denial of
|
||
|
service; however for some systems the alternative is a crash which
|
||
|
would be a worse denial of service!</p>
|
||
|
|
||
|
<p>For larger server systems, the limit of 40 is much too low. The
|
||
|
limit was established many years ago when a system typically only ran a
|
||
|
few dozen servers.</p>
|
||
|
|
||
|
<p>On some versions of inetd, such as the one distributed with most
|
||
|
versions of Linux, you can modify the <strong>/etc/inetd.conf</strong>
|
||
|
file to have a larger number of servers by appending a period followed
|
||
|
by a number after the <strong>nowait</strong> word for the server
|
||
|
entry. For example, if your existing /etc/inetd.conf line reads:</p>
|
||
|
<pre>
|
||
|
imap stream tcp nowait root /usr/etc/imapd imapd
|
||
|
</pre>try changing it to be:
|
||
|
<pre>
|
||
|
imap stream tcp nowait.100 root /usr/etc/imapd imapd
|
||
|
</pre>Another example (using TCP wrappers):
|
||
|
<pre>
|
||
|
imap stream tcp nowait root /usr/sbin/tcpd imapd
|
||
|
</pre>try changing it to be:
|
||
|
<pre>
|
||
|
imap stream tcp nowait.100 root /usr/sbin/tcpd imapd
|
||
|
|
||
|
</pre>to increase the limit to 100 sessions/minute.
|
||
|
|
||
|
<p>Before making this change, please read the information in "man
|
||
|
inetd" to determine whether or not your inetd has this feature. If it
|
||
|
does not, and you make this change, the likely outcome is that you will
|
||
|
disable IMAP service entirely.</p>
|
||
|
|
||
|
<p>Another way to fix this problem is to edit the inetd.c source code
|
||
|
(provided by your UNIX system vendor) to set higher limits, rebuild
|
||
|
inetd, install the new binary, and reboot your system. This should only
|
||
|
be done by a UNIX system expert. In the inetd.c source code, the limits
|
||
|
<strong>TOOMANY</strong> (normally 40) is the maximum number of new
|
||
|
server sessions permitted per minute, and <strong>RETRYTIME</strong>
|
||
|
(normally 600) is the number of seconds inetd will shut down the server
|
||
|
after it exceeds TOOMANY.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.17"><strong>7.17 What does the syslog message:</strong>
|
||
|
<tt>Mailbox lock file /tmp/.600.1df3 open failure: Permission
|
||
|
denied</tt> <strong>mean?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This usually means that some "helpful" security script person has
|
||
|
protected /tmp so that it is no longer world-writeable. /tmp must be
|
||
|
world-writeable because lots of applications use it for scratch space.
|
||
|
To fix this, do
|
||
|
<pre>
|
||
|
chmod 1777 /tmp
|
||
|
|
||
|
</pre>as root.
|
||
|
|
||
|
<p>If that isn't the answer, check the protection of the named file. If
|
||
|
it is something other than 666, then either someone is hacking or some
|
||
|
"helpful" person modified the code to have a different default lock
|
||
|
file protection.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.18"><strong>7.18 What do the syslog messages:</strong></a></p>
|
||
|
<pre>
|
||
|
Command stream end of file, while reading line user=... host=...
|
||
|
Command stream end of file, while reading char user=... host=...
|
||
|
Command stream end of file, while writing text user=... host=...
|
||
|
</pre>
|
||
|
|
||
|
<p><strong>mean?</strong></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This message occurs when the session is disconnected without a proper
|
||
|
LOGOUT (IMAP) or QUIT (POP) command being received by the server first.
|
||
|
|
||
|
<p>In many cases, this is perfectly normal; many client implementations
|
||
|
are impolite and do this. Some programmers think this sort of rudeness
|
||
|
is "more efficient".</p>
|
||
|
|
||
|
<p>The condition could, however, indicate a client or network
|
||
|
connectivity problem. The server has no way of knowing whether there's
|
||
|
a problem or just a rude client, so it issues this message instead of a
|
||
|
Logout.</p>
|
||
|
|
||
|
<p>Certain inferior losing clients disconnect abruptly after a failed
|
||
|
login, and instead of saying that the login failed, just say that they
|
||
|
can't access the mailbox. They then complain to the system manager, who
|
||
|
looks in the syslog and finds this message. Not very helpful, eh? See
|
||
|
the answer to the <a href="#7.4">Why can't I log in to the server? The
|
||
|
user name and password are right!</a> question.</p>
|
||
|
|
||
|
<p>If the user isn't reporting a problem, you can probably ignore this
|
||
|
message.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.19"><strong>7.19 Why did my POP or IMAP session suddenly
|
||
|
disconnect? The syslog has the message:</strong> <tt>Killed (lost
|
||
|
mailbox lock) user=... host=...</tt></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This message only happens when either the traditional UNIX mailbox
|
||
|
format or MMDF format is in use. This format only allows one session to
|
||
|
have the mailbox open read/write at a time.
|
||
|
|
||
|
<p>The servers assume that if a second session attempts to open the
|
||
|
mailbox, that means that the first session is probably owned by an
|
||
|
abandoned client. The common scenario here is a user who leaves his
|
||
|
client running at the office, and then tries to read his mail from
|
||
|
home. Through an internal mechanism called <em>kiss of death</em>, the
|
||
|
second session requests the first session to kill itself. When the
|
||
|
first session receives the "kiss of death", it issues the "Killed (lost
|
||
|
mailbox lock)" syslog message and terminates. The second session then
|
||
|
seizes read/write access, and becomes the new "first" session.</p>
|
||
|
|
||
|
<p>Certain poorly-designed clients routinely open multiple sessions to
|
||
|
the same mailbox; the users of those clients tend to get this message a
|
||
|
lot.</p>
|
||
|
|
||
|
<p>Another cause of this message is a background "check for new mail"
|
||
|
task which does its work by opening a POP session to server every few
|
||
|
seconds. They do this because POP doesn't have a way to announce new
|
||
|
mail.</p>
|
||
|
|
||
|
<p>The solution to both situations is to replace the client with a good
|
||
|
online IMAP client such as Pine. Life is too short to waste on POP
|
||
|
clients and poorly-designed IMAP clients.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.20"><strong>7.20 Why does my IMAP client show all the files on the
|
||
|
system, recursively from the UNIX root directory?</strong></a><br>
|
||
|
<a name="7.21"><strong>7.21 Why does my IMAP client show all of my files,
|
||
|
recursively from my UNIX home directory?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
A well-written client should only show one level of hierarchy and then
|
||
|
stop, awaiting explicit user action before going lower. However, some
|
||
|
poorly-designed clients will recursively list all files, which may be a
|
||
|
very long list (especially if you have symbolic links to directories
|
||
|
that create a loop in the filesystem graph!).
|
||
|
|
||
|
<p>This behavior has also been observed in some third-party c-client
|
||
|
drivers, including maildir drivers. Consequently, this problem has even
|
||
|
been observed in Pine. It is important to understand that this is not a
|
||
|
problem in Pine or c-client; it is a problem in the third-party driver.
|
||
|
A Pine built without that third-party driver will not have this
|
||
|
problem.</p>
|
||
|
|
||
|
<p>See also the answer to <a href="#7.73">Why does my IMAP client show
|
||
|
all my files in my home directory?</a></p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.22"><strong>7.22 Why does my IMAP client show that I have
|
||
|
mailboxes named "#mhinbox", "#mh", "#shared", "#ftp", "#news", and
|
||
|
"#public"?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
These are IMAP namespace names. They represent other hierarchies in
|
||
|
which messages may exist. These hierarchies may not necessarily exist
|
||
|
on a server, but the namespace name is still in the namespace list in
|
||
|
order to mark it as reserved.
|
||
|
|
||
|
<p>A few poorly-designed clients display all namespace names as if they
|
||
|
were top-level mailboxes in a user's list of mailboxes, whether or not
|
||
|
they actually exist. This is a flaw in those clients.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.23"><strong>7.23 Why does my IMAP client show all my files in my
|
||
|
home directory?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
As distributed, the IMAP server is connected to your home directory by
|
||
|
default. It has no way of knowing what you might call "mail" as opposed
|
||
|
to "some other file"; in fact, you can use IMAP to access any file.
|
||
|
|
||
|
<p>Most clients have an option to configure your connected directory on
|
||
|
the IMAP server. For example, in Pine you can specify this as the
|
||
|
"Path" in your folder-collection, e.g.</p>
|
||
|
<pre>
|
||
|
Nickname : Secondary Folders
|
||
|
Server : imap.example.com
|
||
|
Path : mail/
|
||
|
View :
|
||
|
</pre>In this example, the user is connected to the "mail" subdirectory of
|
||
|
his home directory.
|
||
|
|
||
|
<p>Other servers call this the "folder prefix" or similar term.</p>
|
||
|
|
||
|
<p>It is possible to modify the IMAP server so that all users are
|
||
|
automatically connected to some other directory, e.g. a subdirectory of
|
||
|
the user's home directory. Read the file CONFIG for more details.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.24"><strong>7.24 Why is there a long delay before I get connected
|
||
|
to the IMAP or POP server, no matter what client I use?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
There are two common occurances of this problem:
|
||
|
|
||
|
<ul>
|
||
|
<li>You are running a system (e.g. certain versions of Linux) which
|
||
|
by default attempts to connect to an "IDENT" protocol (port 113)
|
||
|
server on your client. However, a firewall or NAT box is blocking
|
||
|
connections to that port, so the connection attempt times out.
|
||
|
|
||
|
<p>The IDENT protocol is a well-known bad idea that does not
|
||
|
deliver any real security but causes incredible problems. The idea
|
||
|
is that this will give the server a record of the user name, or at
|
||
|
least what some program listening on port 113 says is the user
|
||
|
name. So, if somebody coming from port nnnnn on a system does
|
||
|
something bad, IDENT may give you the userid of the bad guy.</p>
|
||
|
|
||
|
<p>The problem is, IDENT is only meaningful on a timesharing system
|
||
|
which has an administrator who is privileged and users who are not.
|
||
|
It is of no value on a personal system which has no separate
|
||
|
concept of "system administrator" vs. "unprivileged user".</p>
|
||
|
|
||
|
<p>On either type of system, security-minded people either turn
|
||
|
IDENT off or replace it with an IDENT server that lies. Among other
|
||
|
things, IDENT gives spammers the ability to harvest email addresses
|
||
|
from anyone who connects to a web page.</p>
|
||
|
|
||
|
<p>This problem has been showing up quite frequently on systems
|
||
|
which use xinetd instead of inetd. Look for files named
|
||
|
/etc/xinetd.conf, /etc/xinetd.d/imapd, /etc/inetd.d/ipop2d, and
|
||
|
/etc/xinetd.d/ipop3d. In those files, look for lines containing
|
||
|
"USERID", e.g.</p>
|
||
|
<pre>
|
||
|
log_on_success += USERID
|
||
|
</pre>Hunt down such lines, and delete them ruthlessly from all files in
|
||
|
which they occur. Don't be shy about it.
|
||
|
</li>
|
||
|
|
||
|
<li>The DNS is taking a long time to do a reverse DNS (PTR record)
|
||
|
lookup of the IP address of your client. This is a problem in your
|
||
|
DNS, which either you or you ISP need to resolve. Ideally, the DNS
|
||
|
should return the client's name; but if it can't it should at least
|
||
|
return an error quickly.</li>
|
||
|
</ul>
|
||
|
|
||
|
<p>As you may have noticed, neither of these are actual problems in the
|
||
|
IMAP or POP servers; they are configuration issues with either your
|
||
|
system or your network infrastructure. If this is all new to you, run
|
||
|
(don't walk) to the nearest technical bookstore and get yourself a good
|
||
|
pedagogical text on system administration for the type of system you
|
||
|
are running.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.25"><strong>7.25 Why is there a long delay in Pine or any other
|
||
|
c-client based application call before I get connected to the IMAP
|
||
|
server? The hang seems to be in the c-client mail_open() call. I don't
|
||
|
have this problem with any other IMAP client. There is no delay
|
||
|
connecting to a POP3 or NNTP server with mail_open().</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
By default, the c-client library attempts to make a connection through
|
||
|
rsh (and ssh, if you enable that). If the command:
|
||
|
<pre>
|
||
|
rsh imapserver exec /etc/rimapd
|
||
|
|
||
|
</pre>(or ssh if that is enabled) returns with a "* PREAUTH" response, it
|
||
|
will use the resulting rsh session as the IMAP session and not require an
|
||
|
authentication step on the server.
|
||
|
|
||
|
<p>Unfortunately, rsh has a design error that treats "TCP connection
|
||
|
refused" as "temporary failure, try again"; it expects the "rsh not
|
||
|
allowed" case to be implemented as a successful connection followed by
|
||
|
an error message and close the connection.</p>
|
||
|
|
||
|
<p>It must be emphasized that this is a bug in rsh. It is <em>not</em>
|
||
|
a bug in the IMAP toolkit.</p>
|
||
|
|
||
|
<p>The use of rsh can be disabled in any the following ways:</p>
|
||
|
|
||
|
<ul>
|
||
|
<li>You can disable it for this particular session by either:
|
||
|
|
||
|
<ul>
|
||
|
<li>setting an explicit port number in the mailbox name, e.g.
|
||
|
<pre>
|
||
|
{imapserver.foo.com:143}INBOX
|
||
|
</pre>
|
||
|
</li>
|
||
|
|
||
|
<li>using SSL (the /ssl switch)</li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
|
||
|
<li>You can disable rsh globally by setting the rsh timeout value to
|
||
|
0 with the call:
|
||
|
<pre>
|
||
|
mail_parameters (NIL,SET_RSHTIMEOUT,0);
|
||
|
</pre>
|
||
|
</li>
|
||
|
</ul>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.26"><strong>7.26 Why does a message sometimes get split into two
|
||
|
or more messages on my SUN system?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is caused by an interaction of two independent design problems in
|
||
|
SUN mail software. The first problem is that the "forward message"
|
||
|
option in SUN's <em>mail tool</em> program includes the internal "From
|
||
|
" header line in the text that it forwarded. This internal header line
|
||
|
is specific to traditional UNIX mailbox files and is not suitable for
|
||
|
use in forwarded messages.
|
||
|
|
||
|
<p>The second problem is that the mail delivery agent assumes that mail
|
||
|
reading programs will not use the traditional UNIX mailbox format but
|
||
|
instead an incompatible variant that depends upon a
|
||
|
<em>Content-Length:</em> message header. Content-Length is widely
|
||
|
recognized to have been a terrible mistake, and is no longer
|
||
|
recommended for use in mail (it is used in other facilities that use
|
||
|
MIME).</p>
|
||
|
|
||
|
<p>One symptom of the problem is that under certain circumstances, a
|
||
|
message may get broken up into several messages. I'm also aware of
|
||
|
security bugs caused by programs that foolishly trust "Content-Length:"
|
||
|
headers with evil values.</p>
|
||
|
|
||
|
<p>To fix the mailer on your system, edit your sendmail.cf to change
|
||
|
the <strong>Mlocal</strong> line to have the <strong>-E</strong> flag.
|
||
|
A typical entry will lool like:</p>
|
||
|
<pre>
|
||
|
Mlocal, P=/usr/lib/mail.local, F=flsSDFMmnPE, S=10, R=20,
|
||
|
A=mail.local -d $u
|
||
|
</pre>This fix will also work around the problem with mail tool, because it
|
||
|
will insert a ">" before the internal header line to prevent it from being
|
||
|
interpreted by mail reading software as an internal header line.
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.27"><strong>7.27 Why did my POP or IMAP session suddenly
|
||
|
disconnect? The syslog has the message:</strong></a></p>
|
||
|
<pre>
|
||
|
Autologout user=<...my user name...> host=<...my client system...>
|
||
|
|
||
|
</pre>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is a problem in your client.
|
||
|
|
||
|
<p>In the case of IMAP, it failed to communicate with the IMAP server
|
||
|
for over 30 minutes; in the case of POP, it failed to communicate with
|
||
|
the POP server for over 10 minutes.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.28"><strong>7.28 What does the UNIX error message:</strong>
|
||
|
<tt>TLS/SSL failure: myserver: SSL negotiation failed</tt>
|
||
|
<strong>mean?</strong></a><br>
|
||
|
<a name="7.29"><strong>7.29 What does the PC error message:</strong>
|
||
|
<tt>TLS/SSL failure: myserver: Unexpected TCP input disconnect</tt>
|
||
|
<strong>mean?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This usually means that an attempt to negotiate TLS encryption via the
|
||
|
STARTTLS command failed, because the server advertises STARTTLS
|
||
|
functionality, but doesn't actually have it (e.g. because no
|
||
|
certificates are installed).
|
||
|
|
||
|
<p>Use the /notls option in the mailbox name to disable TLS
|
||
|
negotiation.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.30"><strong>7.30 What does the error message:</strong> <tt>TLS/SSL
|
||
|
failure: myserver: Server name does not match certificate</tt>
|
||
|
<strong>mean?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
An SSL or TLS session encryption failed because the server name in the
|
||
|
server's certificate does not match the name that you gave it. This
|
||
|
could indicate that the server is not really the system you think that
|
||
|
it is, but can be also be called if you gave a nickname for the server
|
||
|
or name that was not fully-qualified. You must use the fully-qualified
|
||
|
domain name for the server in order to validate its certificate
|
||
|
|
||
|
<p>Use the /novalidate-cert option in the mailbox name to disable
|
||
|
validation of the certificate.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.31"><strong>7.31 What does the UNIX error message:</strong>
|
||
|
<tt>TLS/SSL failure: myserver: self-signed certificate</tt>
|
||
|
<strong>mean?</strong></a><br>
|
||
|
<a name="7.32"><strong>7.32 What does the PC error message:</strong>
|
||
|
<tt>TLS/SSL failure: myserver: Self-signed certificate or untrusted
|
||
|
authority</tt> <strong>mean?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
An SSL or TLS session encryption failed because your server's
|
||
|
certificate is "self-signed"; that is, it is not signed by any
|
||
|
Certificate Authority (CA) and thus can not be validated. A CA-signed
|
||
|
certificate costs money, and some smaller sites either don't want to
|
||
|
pay for it or haven't gotten one yet. The bad part about this is that
|
||
|
this means there is no guarantee that the server is really the system
|
||
|
you think that it is.
|
||
|
|
||
|
<p>Use the /novalidate-cert option in the mailbox name to disable
|
||
|
validation of the certificate.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.33"><strong>7.33 What does the UNIX error message:</strong>
|
||
|
<tt>TLS/SSL failure: myserver: unable to get local issuer
|
||
|
certificate</tt> <strong>mean?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
An SSL or TLS session encryption failed because your system does not
|
||
|
have the Certificate Authority (CA) certificates installed on OpenSSL's
|
||
|
certificates directory. On most systems, this directory is
|
||
|
/usr/local/ssl/certs). As a result, it is not possible to validate the
|
||
|
server's certificate.
|
||
|
|
||
|
<p>If CA certificates are properly installed, you should see
|
||
|
factory.pem and about a dozen other .pem names such as
|
||
|
thawteCb.pem.</p>
|
||
|
|
||
|
<p>As a workaround, you can use the /novalidate-cert option in the
|
||
|
mailbox name to disable validation of the certificate; however, note
|
||
|
that you are then vulnerable to various security attacks by bad
|
||
|
guys.</p>
|
||
|
|
||
|
<p>The correct fix is to copy all the files from the certs/ directory
|
||
|
in the OpenSSL distribution to the /usr/local/ssl/certs (or whatever)
|
||
|
directory. Note that you need to do this after building OpenSSL,
|
||
|
because the OpenSSL build creates a number of needed symbolic links.
|
||
|
For some bizarre reason, the OpenSSL "make install" doesn't do this for
|
||
|
you, so you must do it manually.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.34"><strong>7.34 Why does reading certain messages hang when using
|
||
|
Netscape? It works fine with Pine!</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
There are two possible causes.
|
||
|
|
||
|
<p>Check the mail syslog. If you see the message "Killed (lost mailbox
|
||
|
lock)" for the impacted user(s), read the FAQ entry regarding that
|
||
|
message.</p>
|
||
|
|
||
|
<p>Check the affected mailbox to see if there are embedded NUL
|
||
|
characters in the message. NULs in message texts are a technical
|
||
|
violation of both the message format and IMAP specifications. Most
|
||
|
clients don't care, but apparently Netscape does.</p>
|
||
|
|
||
|
<p>You can work around this by rebuilding imapd with the
|
||
|
<strong>NETSCAPE_BRAIN_DAMAGE</strong> option set (see
|
||
|
src/imapd/Makefile); this will cause imapd to convert all NULs to 0x80
|
||
|
characters. A better solution is to enable the feature in your MTA to
|
||
|
MIME-convert messages with binary content. See the documentation for
|
||
|
your MTA for how to do this.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.35"><strong>7.35 Why does Netscape say that there's a problem with
|
||
|
the IMAP server and that I should "Contact your mail server
|
||
|
administrator."?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Certain versions of Netscape do this when you click the Manage Mail
|
||
|
button, which uses an undocumented feature of Netscape's proprietary
|
||
|
IMAP server.
|
||
|
|
||
|
<p>You can work around this by rebuilding imapd with the
|
||
|
<strong>NETSCAPE_BRAIN_DAMAGE</strong> option set (see
|
||
|
src/imapd/Makefile) to a URL that points either to an alternative IMAP
|
||
|
client (e.g. Pine) or perhaps to a homebrew mail account management
|
||
|
page.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.36"><strong>7.36 Why is one user creating huge numbers of IMAP or
|
||
|
POP server sessions?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>The user is probably using Outlook Express, Eudora, or a similar
|
||
|
program. See the answer to the <a href="#7.5">Help! My load average is
|
||
|
soaring and I see hundreds of POP and IMAP servers, many logged in as the
|
||
|
same user!</a> question.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.37"><strong>7.37 Why don't I get any new mail notifications from
|
||
|
Outlook Express or Outlook after a while?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is a known bug in Outlook Express. Microsoft is aware of the
|
||
|
problem and its cause. They have informed us that they do not have any
|
||
|
plans to fix it at the present time.
|
||
|
|
||
|
<p>The problem is also reported in Outlook 2000, but not verified.</p>
|
||
|
|
||
|
<p>Outlook Express uses the IMAP IDLE command to avoid having to "ping"
|
||
|
the server every few minutes for new mail. Unfortunately, Outlook
|
||
|
Express overlooks the part in the IDLE specification which requires
|
||
|
that a client terminate and restart the IDLE before the IMAP 30 minute
|
||
|
inactivity autologout timer triggers.</p>
|
||
|
|
||
|
<p>When this happens, Outlook Express displays "Not connected" at the
|
||
|
bottom of the window. Since it's no longer connected to the IMAP
|
||
|
server, it isn't going to notice any new mail.</p>
|
||
|
|
||
|
<p>As soon as the user does anything that would cause an IMAP
|
||
|
operation, Outlook Express will reconnect and new mail will flow again.
|
||
|
If the user does something that causes an IMAP operation at least every
|
||
|
29 minutes, the problem won't happen.</p>
|
||
|
|
||
|
<p>Modern versions of imapd attempt to work around the problem by
|
||
|
automatically reporting fake new mail after 29 minutes. This causes
|
||
|
Outlook Express to exit the IDLE state; as soon as this happens imapd
|
||
|
revokes the fake new mail. As long as this behavior isn't known to
|
||
|
cause problems with other clients, this workaround will remain in
|
||
|
imapd.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.38"><strong>7.38 Why don't I get any new mail notifications from
|
||
|
Entourage?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is a known bug in Entourage.
|
||
|
|
||
|
<p>You built an older version of imapd with the
|
||
|
<strong>MICROSOFT_BRAIN_DAMAGE</strong> option set, in order to disable
|
||
|
support for the IDLE command. However, Entourage won't get new mail
|
||
|
unless IDLE command support exists.</p>
|
||
|
|
||
|
<p>Note: the MICROSOFT_BRAIN_DAMAGE option no longer exists in modern
|
||
|
versions, as the Outlook Express problem which it attempted to solve
|
||
|
has been worked around in another way.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.39"><strong>7.39 Why doesn't Entourage work at
|
||
|
all?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
It's hard to know. Entourage breaks almost every rule in the book for
|
||
|
IMAP. It is highly instructive to do a packet trace on Entourage, as an
|
||
|
example of how <em>not</em> to use IMAP. It does things like STATUS
|
||
|
(MESSAGES) on the currently selected mailbox and re-fetching the same
|
||
|
static data over and over again.
|
||
|
|
||
|
<p>It seems that every time we understand what it is doing wrong in
|
||
|
Entourage and come up with a workaround, we learn about something else
|
||
|
that's broken.</p>
|
||
|
|
||
|
<p>Try building imapd with the <strong>ENTOURAGE_BRAIN_DAMAGE</strong>
|
||
|
option set, in order to disable the diagnostic that occurs when doing
|
||
|
STATUS on the currently selected mailbox.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.40"><strong>7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE) work
|
||
|
at all?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is a bug in NSNOTIFY; it doesn't handle unsolicited data from the
|
||
|
server correctly.
|
||
|
|
||
|
<p>Fortunately, there is no reason to use this program with IMAP;
|
||
|
NSNOTIFY is a polling program to let you know when new mail has
|
||
|
appeared in your maildrop. This is necessary with POP; but since IMAP
|
||
|
dynamically announces new mail in the session you're better off (and
|
||
|
will actually cause less load on the server!) keeping your mail reading
|
||
|
program's IMAP session open and let IMAP do the notifying for you.</p>
|
||
|
|
||
|
<p>Consequently, the recommended fix for the NSNOTIFY problem is to
|
||
|
delete the NSNOTIFY binary.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.41"><strong>7.41 Why can't I connect via SSL to Eudora? It says
|
||
|
the connection has been broken, and in the server syslogs I see "Command
|
||
|
stream end of file".</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>There is a report that you can fix the problem by going into Eudora's
|
||
|
advanced network configuration menu and increasing the network buffer
|
||
|
size to 8192.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.42"><strong>7.42 Sheesh. Aren't there <em>any</em> good IMAP
|
||
|
clients out there?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Yes!
|
||
|
|
||
|
<p>Pine is a <em>wonderful</em> client. It's fast, it uses IMAP well,
|
||
|
and it generates text mail (life is too short to waste on HTML mail).
|
||
|
Also, there are some really wonderful things in progress in the Pine
|
||
|
world.</p>
|
||
|
|
||
|
<p>There are some good GUI clients out there, mostly from smaller
|
||
|
vendors. Without naming names, look for the vendors who are active in
|
||
|
the IMAP protocol development community, and their products.</p>
|
||
|
|
||
|
<p>Netscape, Eudora, and Outlook <em>can</em> be configured with enough
|
||
|
effort to be good citizens and work well for users, <em>but</em> they
|
||
|
can also be badly misconfigured, and often the misconfiguration is the
|
||
|
default.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.43"><strong>7.43 But wait! PC Pine (or other PC program build with
|
||
|
c-client) crashes with the message</strong> <tt>incomplete SecBuffer
|
||
|
exceeds maximum buffer size</tt> <strong>when I use SSL connections.
|
||
|
This is a bug in c-client, right?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
It's a bug in the Microsoft SChannel.DLL, which implements SSL.
|
||
|
Microsoft admits it (albeit with an unstatement: "it's not fully RFC
|
||
|
compliant"). The problem is that SChannel indicates that the maximum
|
||
|
SSL packet data size is 5 bytes smaller than the actual maximum. Thus,
|
||
|
any IMAP server which transmits a maximum sized SSL packet will not
|
||
|
work with PC Pine or any other program which uses SChannel.
|
||
|
|
||
|
<p>It can take a while for the problem to show up. The client has to do
|
||
|
something that causes at least 16K of contiguous data. Many clients do
|
||
|
partial fetching, which tends to reduce the number of cases where this
|
||
|
can happen. However, <em>all</em> software which uses SChannel to
|
||
|
support SSL is affected by this bug.</p>
|
||
|
|
||
|
<p>This problem does not affect UNIX code, since OpenSSL is used on
|
||
|
UNIX.</p>
|
||
|
|
||
|
<p>This problem most recently showed up with the CommunigatePro IMAP
|
||
|
server. They have an update which trims down their maximum contiguous
|
||
|
data to less than 16K, in order to work around the problem.</p>
|
||
|
|
||
|
<p>This problem has also shown up with the Exchange IMAP server with
|
||
|
UNIX clients (including Pine built with an older version of c-client)
|
||
|
which sends full-sized 16K SSL packets. Modern c-client works around
|
||
|
the problem by trimming down its maximum outgoing SSL packet size to
|
||
|
8K.</p>
|
||
|
|
||
|
<p>Microsoft has developed a hotfix for this bug. Look up MSKB article
|
||
|
number 300562. Contrary to the article text which implies that this is
|
||
|
a Pine issue, this bug also affect Microsoft Exchange server with *any*
|
||
|
UNIX based client that transmits full-sized SSL payloads.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.44"><strong>7.44 My qpopper users keep on getting the DON'T DELETE
|
||
|
THIS MESSAGE -- FOLDER INTERNAL DATA if they also use Pine or IMAP. How
|
||
|
can I fix this?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is an incompatibility between qpopper and the c-client library
|
||
|
used by Pine, imapd, and ipop[23]d.
|
||
|
|
||
|
<p>Assuming that you want to continue using qpopper, look into
|
||
|
qpopper's <strong>--enable-uw-kludge-flag</strong> configuration flag,
|
||
|
which is documented as "check for and hide UW 'Folder Internal Data'
|
||
|
messages".</p>
|
||
|
|
||
|
<p>The other alternative is to switch from qpopper to ipop3d.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.45"><strong>7.45 Help! I installed the servers but I can't connect
|
||
|
to them from my client!</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Review the installation instructions carefully. Make sure that you have
|
||
|
not skipped any of the steps. Make sure that you have made the correct
|
||
|
entries in the configuration files; pay careful attention to the exact
|
||
|
spelling of the service names and the path names. Make sure as well
|
||
|
that you have properly restarted inetd.
|
||
|
|
||
|
<p>If you have a system with Yellow Pages/NIS such as Solaris, have you
|
||
|
updated the service names there as well as in /etc/services?</p>
|
||
|
|
||
|
<p>If you have a system with TCP wrappers, have you properly updated
|
||
|
the TCP wrapper files (e.g. /etc/hosts.allow and /etc/hosts.deny) for
|
||
|
the servers?</p>
|
||
|
|
||
|
<p>If you have a system which uses xinetd instead of inetd, have you
|
||
|
made sure that you have made the correct corresponding xinetd changes
|
||
|
for those services?</p>
|
||
|
|
||
|
<p>Try telneting to the server port (143 for IMAP, 110 for POP3). If
|
||
|
you get a "refused" error, that probably means that you don't have the
|
||
|
service set up in inetd.conf. If the connection opens and then closes
|
||
|
with no message, the service is set up, but either the path name of the
|
||
|
server binary in inetd.conf is wrong or your TCP wrappers are
|
||
|
configured to deny access.</p>
|
||
|
|
||
|
<p>If you don't know how to make the corresponding changes to these
|
||
|
files, seek the help of a local expert for your system.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.46"><strong>7.46 Why do I get the message</strong> <tt>Can not
|
||
|
authenticate to SMTP server: 421 SMTP connection went away!</tt>
|
||
|
<strong>and why did this happen? There was also something about</strong>
|
||
|
<tt>SECURITY PROBLEM: insecure server advertised AUTH=PLAIN</tt></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
Some versions of qmail, including that running on mail.smtp.yahoo.com,
|
||
|
disconnect the SMTP session if you fail to authenticate prior to
|
||
|
attempting to transmit mail. An attempt to authenticate was made, but
|
||
|
it failed because the server had already disconnected.
|
||
|
|
||
|
<p>To work around this, you need to specify /user=... in the host name
|
||
|
specification.</p>
|
||
|
|
||
|
<p>The SECURITY PROBLEM came about because the server advertised the
|
||
|
AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted
|
||
|
session, in violation of RFC 4616. This message is just a warning, and
|
||
|
in fact occurred after the server had disconnected.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.47"><strong>7.47 Why do I get the message</strong> <tt>SMTP
|
||
|
Authentication cancelled</tt> <strong>and why did this happen? There was
|
||
|
also something about</strong> <tt>SECURITY PROBLEM: insecure server
|
||
|
advertised AUTH=PLAIN</tt></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This is a bug in the SMTP server.
|
||
|
|
||
|
<p>Some versions of qmail, including that running on
|
||
|
mail.smtp.yahoo.com, have a bug in their implementation of SASL in
|
||
|
their SMTP server, which renders it non-compliant with the
|
||
|
standard.</p>
|
||
|
|
||
|
<p>If the client does not provide an initial response in the command
|
||
|
line for an authentication mechanism whose profile does not have an
|
||
|
initial challenge, qmail issues a bogus response:</p>
|
||
|
<pre>
|
||
|
334 ok, go on
|
||
|
</pre>The problem is the "ok, go on". This violates RFC 4954's requirement
|
||
|
that the text part in a 334 response be a BASE64 encoded string; in other
|
||
|
words, it is a protocol syntax error.
|
||
|
|
||
|
<p>In the case of AUTH=PLAIN, RFC 4422 (page 7) requires that the
|
||
|
encoded string have no data. In other words, the appropropiate
|
||
|
standards-compliant server response is "334" followed by a SPACE and a
|
||
|
CRLF.</p>
|
||
|
|
||
|
<p>The SECURITY PROBLEM came about because the server advertised the
|
||
|
AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted
|
||
|
session, in violation of RFC 4616. This message is just a warning, and
|
||
|
is not related the "Authentication cancelled" problem.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="7.48"><strong>7.48 Why do I get the message</strong> <tt>Invalid
|
||
|
base64 string</tt> <strong>when I try to authenticate to a Cyrus
|
||
|
server?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
This slightly misleading message is the way that a Cyrus server
|
||
|
indicates that an authentication exchange was cancelled. It is not
|
||
|
indicative of a bug or protocol violation.
|
||
|
|
||
|
<p>The most common reason that this happens is if the Cyrus server
|
||
|
offers Kerberos authentication, c-client is built with Kerberos
|
||
|
support, but your client system is not within the Kerberos realm. In
|
||
|
this case, the client code will try to authenticate via Kerberos, fail
|
||
|
to get the Kerberos credentials, cancel the authentication attempt, and
|
||
|
try the next available authentication technology.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><br></p>
|
||
|
|
||
|
<h2><a name="additional">8. Where to Go For Additional Information</a></h2>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="8.1"><strong>8.1 Where can I go to ask questions?</strong></a><br>
|
||
|
<a name="8.2"><strong>8.2 I have some ideas for enhancements to IMAP. Where
|
||
|
should I go?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
If you have questions about the IMAP protocol, or want to participate
|
||
|
in discussions of future directions of the IMAP protocol, the
|
||
|
appropriate mailing list is imap-protocol@u.washington.edu. You can
|
||
|
subscribe to this list via <a href=
|
||
|
"mailto:imap-protocol-request@u.washington.edu"><tt>imap-protocol-request@u.washington.edu</tt></a>
|
||
|
|
||
|
<p>If you have questions about this software, you can send me email
|
||
|
directly or use the imap-uw@u.washington.edu mailing list. You can
|
||
|
subscribe to this list via <a href=
|
||
|
"mailto:imap-uw-request@u.washington.edu"><tt>imap-uw-request@u.washington.edu</tt></a></p>
|
||
|
|
||
|
<p>If you have general questions about the use of IMAP software
|
||
|
(not specific to the UW IMAP toolkit) use the
|
||
|
imap-use@u.washington.edu mailing list. You can subscribe to
|
||
|
this list via <a href=
|
||
|
"mailto:imap-use-request@u.washington.edu"><tt>imap-use-request@u.washington.edu</tt></a></p>
|
||
|
|
||
|
<p>You must be a subscriber to post to these lists. As an
|
||
|
alternative, you can use the
|
||
|
<strong>comp.mail.imap</strong> newsgroup.</p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="8.3"><strong>8.3 Where can I read more about IMAP and other email
|
||
|
protocols?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>We recommend <em>Internet Email Protocols: A Developer's Guide</em>,
|
||
|
by Kevin Johnson, published by Addison Wesley, ISBN 0-201-43288-9.</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
<hr>
|
||
|
|
||
|
<p><a name="8.4"><strong>8.4 Where can I find out more about setting up and
|
||
|
administering an IMAP server?</strong></a></p>
|
||
|
|
||
|
<dl>
|
||
|
<dd>
|
||
|
We recommend <em>Managing IMAP</em>, by Dianna Mullet & Kevin
|
||
|
Mullet, published by O'Reilly, ISBN 0-596-00012-X.
|
||
|
|
||
|
<p>This book also has an excellent comparison of the UW and Cyrus IMAP
|
||
|
servers.<br></p>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
|
||
|
<p><a href="#top">Back to top</a></p>
|
||
|
|
||
|
<p>Last Updated: 15 November 2007</p>
|
||
|
|
||
|
<!--chtml include "//imap/incs/bottom.inc"-->
|
||
|
|