imapext-2007

annotate docs/FAQ.txt @ 0:ada5e610ab86

imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1 /* ========================================================================
yuuji@0 2 * Copyright 1988-2007 University of Washington
yuuji@0 3 *
yuuji@0 4 * Licensed under the Apache License, Version 2.0 (the "License");
yuuji@0 5 * you may not use this file except in compliance with the License.
yuuji@0 6 * You may obtain a copy of the License at
yuuji@0 7 *
yuuji@0 8 * http://www.apache.org/licenses/LICENSE-2.0
yuuji@0 9 *
yuuji@0 10 *
yuuji@0 11 * ========================================================================
yuuji@0 12 */
yuuji@0 13
yuuji@0 14 IMAP Toolkit Frequently Asked Questions
yuuji@0 15
yuuji@0 16 Table of Contents
yuuji@0 17
yuuji@0 18 * 1. General/Software Feature Questions
yuuji@0 19 + 1.1 Can I set up a POP or IMAP server on UNIX/Linux/OSF/etc.?
yuuji@0 20 + 1.2 I am currently using qpopper as my POP3 server on UNIX.
yuuji@0 21 Do I need to replace it with ipop3d in order to run imapd?
yuuji@0 22 + 1.3 Can I set up a POP or IMAP server on Windows XP, 2000,
yuuji@0 23 NT, Me, 98, or 95?
yuuji@0 24 + 1.4 Can I set up a POP or IMAP server on Windows 3.1 or DOS?
yuuji@0 25 + 1.5 Can I set up a POP or IMAP server on Macintosh?
yuuji@0 26 + 1.6 Can I set up a POP or IMAP server on VAX/VMS?
yuuji@0 27 + 1.7 Can I set up a POP or IMAP server on TOPS-20?
yuuji@0 28 + 1.8 Are hierarchical mailboxes supported?
yuuji@0 29 + 1.9 Are "dual-use" mailboxes supported?
yuuji@0 30 + 1.10 Can I have a mailbox that has both messages and
yuuji@0 31 sub-mailboxes?
yuuji@0 32 + 1.11 What is the difference between "mailbox" and "folder"?
yuuji@0 33 + 1.12 What is the status of internationalization?
yuuji@0 34 + 1.13 Can I use SSL?
yuuji@0 35 + 1.14 Can I use TLS and the STARTTLS facility?
yuuji@0 36 + 1.15 Can I use CRAM-MD5 authentication?
yuuji@0 37 + 1.16 Can I use APOP authentication?
yuuji@0 38 + 1.17 Can I use Kerberos V5?
yuuji@0 39 + 1.18 Can I use PAM for plaintext passwords?
yuuji@0 40 + 1.19 Can I use Kerberos 5 for plaintext passwords?
yuuji@0 41 + 1.20 Can I use AFS for plaintext passwords?
yuuji@0 42 + 1.21 Can I use DCE for plaintext passwords?
yuuji@0 43 + 1.22 Can I use the CRAM-MD5 database for plaintext passwords?
yuuji@0 44 + 1.23 Can I disable plaintext passwords?
yuuji@0 45 + 1.24 Can I disable plaintext passwords on unencrypted
yuuji@0 46 sessions, but allow them on encrypted sessions?
yuuji@0 47 + 1.25 Can I use virtual hosts?
yuuji@0 48 + 1.26 Can I use RPOP authentication?
yuuji@0 49 + 1.27 Can I use Kerberos V4?
yuuji@0 50 + 1.28 Is there support for S/Key or OTP?
yuuji@0 51 + 1.29 Is there support for NTLM or SPA?
yuuji@0 52 + 1.30 Is there support for mh?
yuuji@0 53 + 1.31 Is there support for qmail and the maildir format?
yuuji@0 54 + 1.32 Is there support for the Cyrus mailbox format?
yuuji@0 55 + 1.33 Is this software Y2K compliant?
yuuji@0 56 * 2. What Do I Need to Build This Software?
yuuji@0 57 + 2.1 What do I need to build this software with SSL on UNIX?
yuuji@0 58 + 2.2 What do I need to build this software with Kerberos V on
yuuji@0 59 UNIX?
yuuji@0 60 + 2.3 What do I need to use a C++ compiler with this software
yuuji@0 61 to build my own application?
yuuji@0 62 + 2.4 What do I need to build this software on Windows?
yuuji@0 63 + 2.5 What do I need to build this software on DOS?
yuuji@0 64 + 2.6 Can't I use Borland C to build this software on the PC?
yuuji@0 65 + 2.7 What do I need to build this software on the Mac?
yuuji@0 66 + 2.8 What do I need to build this software on VMS?
yuuji@0 67 + 2.9 What do I need to build this software on TOPS-20?
yuuji@0 68 + 2.10 What do I need to build this software on Amiga or OS/2?
yuuji@0 69 + 2.11 What do I need to build this software on Windows CE?
yuuji@0 70 * 3. Build and Configuration Questions
yuuji@0 71 + 3.1 How do I configure the IMAP and POP servers on UNIX?
yuuji@0 72 + 3.2 I built and installed the servers according to the BUILD
yuuji@0 73 instructions. It can't be that easy. Don't I need to write a
yuuji@0 74 config file?
yuuji@0 75 + 3.3 How do I make the IMAP and POP servers look for INBOX at
yuuji@0 76 some place other than the mail spool directory?
yuuji@0 77 + 3.4 How do I make the IMAP server look for secondary folders
yuuji@0 78 at some place other than the user's home directory?
yuuji@0 79 + 3.5 How do I configure SSL?
yuuji@0 80 + 3.6 How do I configure TLS and the STARTTLS facility?
yuuji@0 81 + 3.7 How do I build/install OpenSSL and obtain/create
yuuji@0 82 certificates for use with SSL?
yuuji@0 83 + 3.8 How do I configure CRAM-MD5 authentication?
yuuji@0 84 + 3.9 How do I configure APOP authentication?
yuuji@0 85 + 3.10 How do I configure Kerberos V5?
yuuji@0 86 + 3.11 How do I configure PAM for plaintext passwords?
yuuji@0 87 + 3.12 It looks like all I have to do to make the server use
yuuji@0 88 Kerberos is to build with PAM on my Linux system, and set it
yuuji@0 89 up in PAM for Kerberos passwords. Right?
yuuji@0 90 + 3.13 How do I configure Kerberos 5 for plaintext passwords?
yuuji@0 91 + 3.14 How do I configure AFS for plaintext passwords?
yuuji@0 92 + 3.15 How do I configure DCE for plaintext passwords?
yuuji@0 93 + 3.16 How do I configure the CRAM-MD5 database for plaintext
yuuji@0 94 passwords?
yuuji@0 95 + 3.17 How do I disable plaintext passwords?
yuuji@0 96 + 3.18 How do I disable plaintext passwords on unencrypted
yuuji@0 97 sessions, but allow them in SSL or TLS sessions?
yuuji@0 98 + 3.19 How do I configure virtual hosts?
yuuji@0 99 + 3.20 Why do I get compiler warning messages such as:
yuuji@0 100 o passing arg 3 of `scandir' from incompatible pointer
yuuji@0 101 type
yuuji@0 102 o Pointers are not assignment-compatible.
yuuji@0 103 o Argument #4 is not the correct type.
yuuji@0 104 during the build?
yuuji@0 105 + 3.21 Why do I get compiler warning messages such as
yuuji@0 106 o Operation between types "void(*)(int)" and "void*" is
yuuji@0 107 not allowed.
yuuji@0 108 o Function argument assignment between types "void*" and
yuuji@0 109 "void(*)(int)" is not allowed.
yuuji@0 110 o Pointers are not assignment-compatible.
yuuji@0 111 o Argument #5 is not the correct type.
yuuji@0 112 during the build?
yuuji@0 113 + 3.22 Why do I get linker warning messages such as:
yuuji@0 114 o mtest.c:515: the `gets' function is dangerous and should
yuuji@0 115 not be used.
yuuji@0 116 during the build? Isn't this a security bug?
yuuji@0 117 + 3.23 Why do I get linker warning messages such as:
yuuji@0 118 o auth_ssl.c:92: the `tmpnam' function is dangerous and
yuuji@0 119 should not be used.
yuuji@0 120 during the build? Isn't this a security bug?
yuuji@0 121 + 3.24 OK, suppose I see a warning message about a function
yuuji@0 122 being "dangerous and should not be used" for something other
yuuji@0 123 than this gets() or tmpnam() call?
yuuji@0 124 * 4. Operational Questions
yuuji@0 125 + 4.1 How can I enable anonymous IMAP logins?
yuuji@0 126 + 4.2 How do I set up an alert message that each IMAP user will
yuuji@0 127 see?
yuuji@0 128 + 4.3 How does the c-client library choose which of its several
yuuji@0 129 mechanisms to use to establish an IMAP connection to the
yuuji@0 130 server? I noticed that it can connect on port 143, port 993,
yuuji@0 131 via rsh, and via ssh.
yuuji@0 132 + 4.4 I am using a TLS-capable IMAP server, so I don't need to
yuuji@0 133 use /ssl to get encryption. However, I want to be certain
yuuji@0 134 that my session is TLS encrypted before I send my password.
yuuji@0 135 How to I do this?
yuuji@0 136 + 4.5 How do I use one of the alternative formats described in
yuuji@0 137 the formats.txt document? In particular, I hear that mbx
yuuji@0 138 format will give me better performance and allow shared
yuuji@0 139 access.
yuuji@0 140 + 4.6 How do I set up shared mailboxes?
yuuji@0 141 + 4.7 How can I make the server syslogs go to someplace other
yuuji@0 142 than the mail syslog?
yuuji@0 143 * 5. Security Questions
yuuji@0 144 + 5.1 I see that the IMAP server allows access to arbitary
yuuji@0 145 files on the system, including /etc/passwd! How do I disable
yuuji@0 146 this?
yuuji@0 147 + 5.2 I've heard that IMAP servers are insecure. Is this true?
yuuji@0 148 + 5.3 How do I know that I have the most secure version of the
yuuji@0 149 server?
yuuji@0 150 + 5.4 I see all these strcpy() and sprintf() calls, those are
yuuji@0 151 unsafe, aren't they?
yuuji@0 152 + 5.5 Those /tmp lock files are protected 666, is that really
yuuji@0 153 right?
yuuji@0 154 * 6. Why Did You Do This Strange Thing? Questions
yuuji@0 155 + 6.1 Why don't you use GNU autoconfig / automake /
yuuji@0 156 autoblurdybloop?
yuuji@0 157 + 6.2 Why do you insist upon a build with -g? Doesn't it waste
yuuji@0 158 disk and memory space?
yuuji@0 159 + 6.3 Why don't you make c-client a shared library?
yuuji@0 160 + 6.4 Why don't you use iconv() for internationalization
yuuji@0 161 support?
yuuji@0 162 + 6.5 Why is the IMAP server connected to the home directory by
yuuji@0 163 default?
yuuji@0 164 + 6.6 I have a Windows system. Why isn't the server plug and
yuuji@0 165 play for me?
yuuji@0 166 + 6.7 I looked at the UNIX SSL code and saw that you have the
yuuji@0 167 SSL data payload size set to 8192 bytes. SSL allows 16K; why
yuuji@0 168 aren't you using the full size?
yuuji@0 169 + 6.8 Why is an mh format INBOX called #mhinbox instead of just
yuuji@0 170 INBOX?
yuuji@0 171 + 6.9 Why don't you support the maildir format?
yuuji@0 172 + 6.10 Why don't you support the Cyrus format?
yuuji@0 173 + 6.11 Why is it creating extra forks on my SVR4 system?
yuuji@0 174 + 6.12 Why are you so fussy about the date/time format in the
yuuji@0 175 internal "From " line in traditional UNIX mailbox files? My
yuuji@0 176 other mail program just considers every line that starts with
yuuji@0 177 "From " to be the start of the message.
yuuji@0 178 + 6.13 Why is traditional UNIX format the default format?
yuuji@0 179 + 6.14 Why do you write this "DON'T DELETE THIS MESSAGE --
yuuji@0 180 FOLDER INTERNAL DATA" message at the start of traditional
yuuji@0 181 UNIX and MMDF format mailboxes?
yuuji@0 182 + 6.15 Why don't you stash the mailbox metadata in the first
yuuji@0 183 real message of the mailbox instead of writing this fake
yuuji@0 184 FOLDER INTERNAL DATA message?
yuuji@0 185 + 6.16 Why aren't "dual-use" mailboxes the default?
yuuji@0 186 + 6.17 Why do you use ucbcc to build on Solaris?
yuuji@0 187 + 6.18 Why should I care about some old system with BSD
yuuji@0 188 libraries? cc is the right thing on my Solaris system!
yuuji@0 189 + 6.19 Why do you insist upon writing .lock files in the spool
yuuji@0 190 directory?
yuuji@0 191 + 6.20 Why should I care about compatibility with the past?
yuuji@0 192 * 7. Problems and Annoyances
yuuji@0 193 + 7.1 Help! My INBOX is empty! What happened to my messages?
yuuji@0 194 + 7.2 Help! All my messages in a non-INBOX mailbox have been
yuuji@0 195 concatenated into one message which claims to be from me and
yuuji@0 196 has a subject of the file name of the mailbox! What's going
yuuji@0 197 on?
yuuji@0 198 + 7.3 Why do I get the message:
yuuji@0 199 o CREATE failed: Can't create mailbox node xxxxxxxxx: File
yuuji@0 200 exists
yuuji@0 201 and how do I fix it?
yuuji@0 202 + 7.4 Why can't I log in to the server? The user name and
yuuji@0 203 password are right!
yuuji@0 204 + 7.5 Help! My load average is soaring and I see hundreds of
yuuji@0 205 POP and IMAP servers, many logged in as the same user!
yuuji@0 206 + 7.6 Why does mail disappear even though I set "keep mail on
yuuji@0 207 server"?
yuuji@0 208 + 7.7 Why do I get the message
yuuji@0 209 o Moved ##### bytes of new mail to /home/user/mbox from
yuuji@0 210 /var/spool/mail/user
yuuji@0 211 and why did this happen?
yuuji@0 212 + 7.8 Why isn't it showing the local host name as a
yuuji@0 213 fully-qualified domain name?
yuuji@0 214 + 7.9 Why is the local host name in the From/Sender/Message-ID
yuuji@0 215 headers of outgoing mail not coming out as a fully-qualified
yuuji@0 216 domain name?
yuuji@0 217 + 7.10 What does the message:
yuuji@0 218 o Mailbox vulnerable - directory /var/spool/mail must have
yuuji@0 219 1777 protection
yuuji@0 220 mean? How can I fix this?
yuuji@0 221 + 7.11 What does the message:
yuuji@0 222 o Mailbox is open by another process, access is readonly
yuuji@0 223 mean? How do I fix this?
yuuji@0 224 + 7.12 What does the message:
yuuji@0 225 o Can't get write access to mailbox, access is readonly
yuuji@0 226 mean?
yuuji@0 227 + 7.13 I set my POP3 client to "delete messages from server"
yuuji@0 228 but they never get deleted. What is wrong?
yuuji@0 229 + 7.14 What do messages such as:
yuuji@0 230 o Message ... UID ... already has UID ...
yuuji@0 231 o Message ... UID ... less than ...
yuuji@0 232 o Message ... UID ... greater than last ...
yuuji@0 233 o Invalid UID ... in message ..., rebuilding UIDs
yuuji@0 234 mean?
yuuji@0 235 + 7.15 What do the error messages:
yuuji@0 236 o Unable to read internal header at ...
yuuji@0 237 o Unable to find CRLF at ...
yuuji@0 238 o Unable to parse internal header at ...
yuuji@0 239 o Unable to parse message date at ...
yuuji@0 240 o Unable to parse message flags at ...
yuuji@0 241 o Unable to parse message UID at ...
yuuji@0 242 o Unable to parse message size at ...
yuuji@0 243 o Last message (at ... ) runs past end of file ...
yuuji@0 244 mean? I am using mbx format.
yuuji@0 245 + 7.16 What do the syslog messages:
yuuji@0 246 o imap/tcp server failing (looping)
yuuji@0 247 o pop3/tcp server failing (looping)
yuuji@0 248 mean? When it happens, the listed service shuts down. How can
yuuji@0 249 I fix this?
yuuji@0 250 + 7.17 What does the syslog message:
yuuji@0 251 o Mailbox lock file /tmp/.600.1df3 open failure:
yuuji@0 252 Permission denied
yuuji@0 253 mean?
yuuji@0 254 + 7.18 What do the syslog messages:
yuuji@0 255 o Command stream end of file, while reading line user=...
yuuji@0 256 host=...
yuuji@0 257 o Command stream end of file, while reading char user=...
yuuji@0 258 host=...
yuuji@0 259 o Command stream end of file, while writing text user=...
yuuji@0 260 host=...
yuuji@0 261 mean?
yuuji@0 262 + 7.19 Why did my POP or IMAP session suddenly disconnect? The
yuuji@0 263 syslog has the message:
yuuji@0 264 o Killed (lost mailbox lock) user=... host=...
yuuji@0 265 + 7.20 Why does my IMAP client show all the files on the
yuuji@0 266 system, recursively from the UNIX root directory?
yuuji@0 267 + 7.21 Why does my IMAP client show all of my files,
yuuji@0 268 recursively from my UNIX home directory?
yuuji@0 269 + 7.22 Why does my IMAP client show that I have mailboxes named
yuuji@0 270 "#mhinbox", "#mh", "#shared", "#ftp", "#news", and "#public"?
yuuji@0 271 + 7.23 Why does my IMAP client show all my files in my home
yuuji@0 272 directory?
yuuji@0 273 + 7.24 Why is there a long delay before I get connected to the
yuuji@0 274 IMAP or POP server, no matter what client I use?
yuuji@0 275 + 7.25 Why is there a long delay in Pine or any other c-client
yuuji@0 276 based application call before I get connected to the IMAP
yuuji@0 277 server? The hang seems to be in the c-client mail_open()
yuuji@0 278 call. I don't have this problem with any other IMAP client.
yuuji@0 279 There is no delay connecting to a POP3 or NNTP server with
yuuji@0 280 mail_open().
yuuji@0 281 + 7.26 Why does a message sometimes get split into two or more
yuuji@0 282 messages on my SUN system?
yuuji@0 283 + 7.27 Why did my POP or IMAP session suddenly disconnect? The
yuuji@0 284 syslog has the message:
yuuji@0 285 o Autologout user=<...my user name...> host=<...my imap
yuuji@0 286 server...>
yuuji@0 287 + 7.28 What does the UNIX error message:
yuuji@0 288 o TLS/SSL failure: myserver: SSL negotiation failed
yuuji@0 289 mean?
yuuji@0 290 + 7.29 What does the PC error message:
yuuji@0 291 o TLS/SSL failure: myserver: Unexpected TCP input
yuuji@0 292 disconnect
yuuji@0 293 mean?
yuuji@0 294 + 7.30 What does the error message:
yuuji@0 295 o TLS/SSL failure: myserver: Server name does not match
yuuji@0 296 certificate
yuuji@0 297 mean?
yuuji@0 298 + 7.31 What does the UNIX error message:
yuuji@0 299 o TLS/SSL failure: myserver: self-signed certificate
yuuji@0 300 mean?
yuuji@0 301 + 7.32 What does the PC error message
yuuji@0 302 o TLS/SSL failure: myserver: Self-signed certificate or
yuuji@0 303 untrusted authority
yuuji@0 304 mean?
yuuji@0 305 + 7.33 What does the UNIX error message:
yuuji@0 306 o TLS/SSL failure: myserver: unable to get local issuer
yuuji@0 307 certificate
yuuji@0 308 mean?
yuuji@0 309 + 7.34 Why does reading certain messages hang when using
yuuji@0 310 Netscape? It works fine with Pine!
yuuji@0 311 + 7.35 Why does Netscape say that there's a problem with the
yuuji@0 312 IMAP server and that I should "Contact your mail server
yuuji@0 313 administrator."?
yuuji@0 314 + 7.36 Why is one user creating huge numbers of IMAP or POP
yuuji@0 315 server sessions?
yuuji@0 316 + 7.37 Why don't I get any new mail notifications from Outlook
yuuji@0 317 Express or Outlook after a while?
yuuji@0 318 + 7.38 Why don't I get any new mail notifications from
yuuji@0 319 Entourage?
yuuji@0 320 + 7.39 Why doesn't Entourage work at all?
yuuji@0 321 + 7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE) work at all?
yuuji@0 322 + 7.41 Why can't I connect via SSL to Eudora? It says the
yuuji@0 323 connection has been broken, and in the server syslogs I see
yuuji@0 324 "Command stream end of file".
yuuji@0 325 + 7.42 Sheesh. Aren't there any good IMAP clients out there?
yuuji@0 326 + 7.43 But wait! PC Pine (or other PC program build with
yuuji@0 327 c-client) crashes with the message
yuuji@0 328 o incomplete SecBuffer exceeds maximum buffer size
yuuji@0 329 when I use SSL connections. This is a bug in c-client, right?
yuuji@0 330 + 7.44 My qpopper users keep on getting the DON'T DELETE THIS
yuuji@0 331 MESSAGE -- FOLDER INTERNAL DATA if they also use Pine or
yuuji@0 332 IMAP. How can I fix this?
yuuji@0 333 + 7.45 Help! I installed the servers but I can't connect to
yuuji@0 334 them from my client!
yuuji@0 335 + 7.46 Why do I get the message
yuuji@0 336 o Can not authenticate to SMTP server: 421 SMTP connection
yuuji@0 337 went away!
yuuji@0 338 and why did this happen? There was also something about
yuuji@0 339 o SECURITY PROBLEM: insecure server advertised AUTH=PLAIN
yuuji@0 340 + 7.47 Why do I get the message
yuuji@0 341 o SMTP Authentication cancelled
yuuji@0 342 and why did this happen? There was also something about
yuuji@0 343 o SECURITY PROBLEM: insecure server advertised AUTH=PLAIN
yuuji@0 344 + 7.48 Why do I get the message
yuuji@0 345 o Invalid base64 string
yuuji@0 346 when I try to authenticate to a Cyrus server?
yuuji@0 347 * 8. Where to Go For Additional Information
yuuji@0 348 + 8.1 Where can I go to ask questions?
yuuji@0 349 + 8.2 I have some ideas for enhancements to IMAP. Where should
yuuji@0 350 I go?
yuuji@0 351 + 8.3 Where can I read more about IMAP and other email
yuuji@0 352 protocols?
yuuji@0 353 + 8.4 Where can I find out more about setting up and
yuuji@0 354 administering an IMAP server?
yuuji@0 355 _________________________________________________________________
yuuji@0 356
yuuji@0 357 1. General/Software Feature Questions
yuuji@0 358 _________________________________________________________________
yuuji@0 359
yuuji@0 360 1.1 Can I set up a POP or IMAP server on UNIX/Linux/OSF/etc.?
yuuji@0 361
yuuji@0 362 Yes. Refer to the UNIX specific notes in files CONFIG and
yuuji@0 363 BUILD.
yuuji@0 364 _________________________________________________________________
yuuji@0 365
yuuji@0 366 1.2 I am currently using qpopper as my POP3 server on UNIX. Do I need
yuuji@0 367 to replace it with ipop3d in order to run imapd?
yuuji@0 368
yuuji@0 369 Not necessarily.
yuuji@0 370
yuuji@0 371 Although ipop3d interoperates with imapd better than qpopper,
yuuji@0 372 imapd and qpopper will work together. The few qpopper/imapd
yuuji@0 373 interoperability issues mostly affect users who use both IMAP
yuuji@0 374 and POP3 clients; those users would probably be better served
yuuji@0 375 if their POP3 server is ipop3d.
yuuji@0 376
yuuji@0 377 If you are happy with qpopper and just want to add imapd, you
yuuji@0 378 should do that, and defer a decision on changing qpopper to
yuuji@0 379 ipop3d. That way, you can get comfortable with imapd's
yuuji@0 380 performance, without changing anything for your qpopper users.
yuuji@0 381
yuuji@0 382 Many sites have subsequently decided to change from qpopper to
yuuji@0 383 ipop3d in order to get better POP3/IMAP interoperability. If
yuuji@0 384 you need to do this, you'll know. There also seems to be a way
yuuji@0 385 to make qpopper work better with imapd; see the answer to the
yuuji@0 386 My qpopper users keep on getting the DON'T DELETE THIS MESSAGE
yuuji@0 387 -- FOLDER INTERNAL DATA if they also use Pine or IMAP. How can
yuuji@0 388 I fix this? question.
yuuji@0 389 _________________________________________________________________
yuuji@0 390
yuuji@0 391 1.3 Can I set up a POP or IMAP server on Windows XP, 2000, NT, Me, 98,
yuuji@0 392 or 95?
yuuji@0 393
yuuji@0 394 Yes. Refer to the NT specific notes in files CONFIG and BUILD.
yuuji@0 395 Also, for DOS-based versions of Windows (Windows Me, 98, and
yuuji@0 396 95) you *must* set up CRAM-MD5 authentication, as described in
yuuji@0 397 md5.txt.
yuuji@0 398
yuuji@0 399 There is no file access control on Windows 9x or Me, so you
yuuji@0 400 probably will have to do modifications to env_unix.c to prevent
yuuji@0 401 people from hacking others' mail.
yuuji@0 402
yuuji@0 403 Note, however, that the server is not plug and play the way it
yuuji@0 404 is for UNIX.
yuuji@0 405 _________________________________________________________________
yuuji@0 406
yuuji@0 407 1.4 Can I set up a POP or IMAP server on Windows 3.1 or DOS?
yuuji@0 408 1.5 Can I set up a POP or IMAP server on Macintosh?
yuuji@0 409 1.6 Can I set up a POP or IMAP server on VAX/VMS?
yuuji@0 410
yuuji@0 411 Yes, it's just a small matter of programming.
yuuji@0 412 _________________________________________________________________
yuuji@0 413
yuuji@0 414 1.7 Can I set up a POP or IMAP server on TOPS-20?
yuuji@0 415
yuuji@0 416 You have a TOPS-20 system? Cool.
yuuji@0 417
yuuji@0 418 If IMAP2 (RFC 1176) is good enough for you, you can use MAPSER
yuuji@0 419 which is about the ultimate gonzo pure TOPS-20 extended
yuuji@0 420 addressing assembly language program. Unfortunately, IMAP2 is
yuuji@0 421 barely good enough for Pine these days, and most other IMAP
yuuji@0 422 clients won't work with IMAP2 at all. Maybe someone will hack
yuuji@0 423 MAPSER to do IMAP4rev1 some day.
yuuji@0 424
yuuji@0 425 We don't know if anyone wrote a POP3 server for TOPS-20. There
yuuji@0 426 definitely was a POP2 server once upon a time.
yuuji@0 427
yuuji@0 428 Or you can port the POP and IMAP server from this IMAP toolkit
yuuji@0 429 to it. All that you need for a first stab is to port the MTX
yuuji@0 430 driver. That'll probably be just a couple of hours of hacking.
yuuji@0 431 _________________________________________________________________
yuuji@0 432
yuuji@0 433 1.8 Are hierarchical mailboxes supported?
yuuji@0 434 1.9 Are "dual-use" mailboxes supported?
yuuji@0 435 1.10 Can I have a mailbox that has both messages and sub-mailboxes?
yuuji@0 436
yuuji@0 437 Yes. However, there is one important caveat.
yuuji@0 438
yuuji@0 439 Some mailbox formats, including the default which is the
yuuji@0 440 traditional UNIX mailbox format, are stored as a single file
yuuji@0 441 containing all the messages. UNIX does not permit a name in the
yuuji@0 442 filesystem to be both a file and a directory; consequently you
yuuji@0 443 can not have a sub-mailbox within a mailbox that is in one of
yuuji@0 444 these formats.
yuuji@0 445
yuuji@0 446 This is not a limitation of the software; this is a limitation
yuuji@0 447 of UNIX. For example, there are mailbox formats in which the
yuuji@0 448 name is a directory and each message is a file within that
yuuji@0 449 directory; these formats support sub-mailboxes within such
yuuji@0 450 mailboxes. However, for technical reasons, the "flat file"
yuuji@0 451 formats are generally preferred since they perform better. Read
yuuji@0 452 imap-2007/docs/formats.txt for more information on this topic.
yuuji@0 453
yuuji@0 454 It is always permissible to create a directory that is not a
yuuji@0 455 mailbox, and have sub-mailboxes under it. The easiest way to
yuuji@0 456 create a directory is to create a new mailbox inside a
yuuji@0 457 directory that doesn't already exist. For example, if you
yuuji@0 458 create "Mail/testbox" on UNIX, the directory "Mail/" will
yuuji@0 459 automatically be created and then the mailbox "testbox" will be
yuuji@0 460 created as a sub-mailbox of "Mail/".
yuuji@0 461
yuuji@0 462 It is also possible to create the name "Mail/" directly. Check
yuuji@0 463 the documentation for your client software to see how to do
yuuji@0 464 this with that software.
yuuji@0 465
yuuji@0 466 Of course, on Windows systems you would use "\" instead of "/".
yuuji@0 467 _________________________________________________________________
yuuji@0 468
yuuji@0 469 1.11 What is the difference between "mailbox" and "folder"?
yuuji@0 470
yuuji@0 471 The term "mailbox" is IMAP-speak for what a lot of software
yuuji@0 472 calls a "folder" or a "mail folder". However, "folder" is often
yuuji@0 473 used in other contexts to refer to a directory, for example, in
yuuji@0 474 the graphic user interface on both Windows and Macintosh.
yuuji@0 475
yuuji@0 476 A "mailbox" is specifically defined as a named object that
yuuji@0 477 contains messages. It is not required to be capable of
yuuji@0 478 containing other types of objects including other mailboxes;
yuuji@0 479 although some mailbox formats will permit this.
yuuji@0 480
yuuji@0 481 In IMAP-speak, a mailbox which can not contain other mailboxes
yuuji@0 482 is called a "no-inferiors mailbox". Similarly, a directory
yuuji@0 483 which can not contain messages is not a mailbox and is called a
yuuji@0 484 "no-select name".
yuuji@0 485 _________________________________________________________________
yuuji@0 486
yuuji@0 487 1.12 What is the status of internationalization?
yuuji@0 488
yuuji@0 489 The IMAP toolkit is partially internationalized and
yuuji@0 490 multilingualized.
yuuji@0 491
yuuji@0 492 Searching is supported in the following charsets: US-ASCII,
yuuji@0 493 UTF-8, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4,
yuuji@0 494 ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9,
yuuji@0 495 ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14,
yuuji@0 496 ISO-8859-15, ISO-8859-16, KOI8-R, KOI8-U (alias KOI8-RU),
yuuji@0 497 TIS-620, VISCII, ISO-2022-JP, ISO-2022-KR, ISO-2022-CN,
yuuji@0 498 ISO-2022-JP-1, ISO-2022-JP-2, GB2312 (alias CN-GB),
yuuji@0 499 CN-GB-12345, BIG5 (alias CN-BIG5), EUC-JP, EUC-KR, Shift_JIS,
yuuji@0 500 Shift-JIS, KS_C_5601-1987, KS_C_5601-1992, WINDOWS_874,
yuuji@0 501 WINDOWS-1250, WINDOWS-1251, WINDOWS-1252, WINDOWS-1253,
yuuji@0 502 WINDOWS-1254, WINDOWS-1255, WINDOWS-1256, WINDOWS-1257,
yuuji@0 503 WINDOWS-1258.
yuuji@0 504
yuuji@0 505 All ISO-2022-?? charsets are treated identically, and support
yuuji@0 506 ASCII, JIS Roman, hankaku katakana, ISO-8859-[1 - 10], TIS, GB
yuuji@0 507 2312, JIS X 0208, JIS X 0212, KSC 5601, and planes 1 and 2 of
yuuji@0 508 CNS 11643.
yuuji@0 509
yuuji@0 510 EUC-JP includes support for JIS X 0212 and hankaku katakana.
yuuji@0 511
yuuji@0 512 c-client library support also exists to convert text in any of
yuuji@0 513 the above charsets into Unicode, including headers with MIME
yuuji@0 514 encoded-words.
yuuji@0 515
yuuji@0 516 There is no support for localization (e.g. non-English error
yuuji@0 517 messages) at the present time, but such support is planned.
yuuji@0 518 _________________________________________________________________
yuuji@0 519
yuuji@0 520 1.13 Can I use SSL?
yuuji@0 521
yuuji@0 522 Yes. See the answer to the How do I configure SSL? question.
yuuji@0 523 _________________________________________________________________
yuuji@0 524
yuuji@0 525 1.14 Can I use TLS and the STARTTLS facility?
yuuji@0 526
yuuji@0 527 Yes. See the answer to the How do I configure TLS and the
yuuji@0 528 STARTTLS facility? question.
yuuji@0 529 _________________________________________________________________
yuuji@0 530
yuuji@0 531 1.15 Can I use CRAM-MD5 authentication?
yuuji@0 532
yuuji@0 533 Yes. See the answer to the How do I configure CRAM-MD5
yuuji@0 534 authentication? question.
yuuji@0 535 _________________________________________________________________
yuuji@0 536
yuuji@0 537 1.16 Can I use APOP authentication?
yuuji@0 538
yuuji@0 539 Yes. See the How do I configure APOP authentication? question.
yuuji@0 540
yuuji@0 541 Note that there is no client support for APOP authentication.
yuuji@0 542 _________________________________________________________________
yuuji@0 543
yuuji@0 544 1.17 Can I use Kerberos V5?
yuuji@0 545
yuuji@0 546 Yes. See the answer to the How do I configure Kerberos V5?
yuuji@0 547 question.
yuuji@0 548 _________________________________________________________________
yuuji@0 549
yuuji@0 550 1.18 Can I use PAM for plaintext passwords?
yuuji@0 551
yuuji@0 552 Yes. See the answer to the How do I configure PAM for plaintext
yuuji@0 553 passwords? question.
yuuji@0 554 _________________________________________________________________
yuuji@0 555
yuuji@0 556 1.19 Can I use Kerberos 5 for plaintext passwords?
yuuji@0 557
yuuji@0 558 Yes. See the answer to the How do I configure Kerberos 5 for
yuuji@0 559 plaintext passwords? question.
yuuji@0 560 _________________________________________________________________
yuuji@0 561
yuuji@0 562 1.20 Can I use AFS for plaintext passwords?
yuuji@0 563
yuuji@0 564 Yes. See the answer to the How do I configure AFS for plaintext
yuuji@0 565 passwords? question.
yuuji@0 566 _________________________________________________________________
yuuji@0 567
yuuji@0 568 1.21 Can I use DCE for plaintext passwords?
yuuji@0 569
yuuji@0 570 Yes. See the answer to the How do I configure DCE for plaintext
yuuji@0 571 passwords? question.
yuuji@0 572 _________________________________________________________________
yuuji@0 573
yuuji@0 574 1.22 Can I use the CRAM-MD5 database for plaintext passwords?
yuuji@0 575
yuuji@0 576 Yes. See the answer to the How do I configure the CRAM-MD5
yuuji@0 577 database for plaintext passwords? question.
yuuji@0 578 _________________________________________________________________
yuuji@0 579
yuuji@0 580 1.23 Can I disable plaintext passwords?
yuuji@0 581
yuuji@0 582 Yes. See the answer to the How do I disable plaintext
yuuji@0 583 passwords? question.
yuuji@0 584 _________________________________________________________________
yuuji@0 585
yuuji@0 586 1.24 Can I disable plaintext passwords on unencrypted sessions, but
yuuji@0 587 allow them on encrypted sessions?
yuuji@0 588
yuuji@0 589 Yes. See the answer to the How do I disable plaintext passwords
yuuji@0 590 on unencrypted sessions, but allow them in SSL or TLS sessions?
yuuji@0 591 question.
yuuji@0 592 _________________________________________________________________
yuuji@0 593
yuuji@0 594 1.25 Can I use virtual hosts?
yuuji@0 595
yuuji@0 596 Yes. See the answer to the How do I configure virtual hosts?
yuuji@0 597 question.
yuuji@0 598 _________________________________________________________________
yuuji@0 599
yuuji@0 600 1.26 Can I use RPOP authentication?
yuuji@0 601
yuuji@0 602 There is no support for RPOP authentication.
yuuji@0 603 _________________________________________________________________
yuuji@0 604
yuuji@0 605 1.27 Can I use Kerberos V4?
yuuji@0 606
yuuji@0 607 Kerberos V4 is not supported. Kerberos V4 client-only
yuuji@0 608 contributed code is available in
yuuji@0 609
yuuji@0 610 ftp://ftp.cac.washington.edu/mail/kerberos4-patches.tar.Z
yuuji@0 611
yuuji@0 612 This is a patchkit which must be applied to the IMAP toolkit
yuuji@0 613 according to the instructions in the patchkit's README. We can
yuuji@0 614 not promise that this code works.
yuuji@0 615 _________________________________________________________________
yuuji@0 616
yuuji@0 617 1.28 Is there support for S/Key or OTP?
yuuji@0 618
yuuji@0 619 There is currently no support for S/Key or OTP. There may be an
yuuji@0 620 OTP SASL authenticator available from third parties.
yuuji@0 621 _________________________________________________________________
yuuji@0 622
yuuji@0 623 1.29 Is there support for NTLM or SPA?
yuuji@0 624
yuuji@0 625 There is currently no support for NTLM or SPA, nor are there
yuuji@0 626 any plans to add such support. In general, I avoid
yuuji@0 627 vendor-specific mechanisms. I also believe that these
yuuji@0 628 mechanisms are being deprecated by their vendor.
yuuji@0 629
yuuji@0 630 There may be an NTLM SASL authenticator available from third
yuuji@0 631 parties.
yuuji@0 632 _________________________________________________________________
yuuji@0 633
yuuji@0 634 1.30 Is there support for mh?
yuuji@0 635
yuuji@0 636 Yes, but only as a legacy format. Your mh format INBOX is
yuuji@0 637 accessed by the name "#mhinbox", and all other mh format
yuuji@0 638 mailboxes are accessed by prefixing "#mh/" to the name, e.g.
yuuji@0 639 "#mh/foo". The mh support uses the "Path:" entry in your
yuuji@0 640 .mh_profile file to identify the root directory of your mh
yuuji@0 641 format mailboxes.
yuuji@0 642
yuuji@0 643 Non-legacy use of mh format is not encouraged. There is no
yuuji@0 644 support for permanent flags or unique identifiers; furthermore
yuuji@0 645 there are known severe performance problems with the mh format.
yuuji@0 646 _________________________________________________________________
yuuji@0 647
yuuji@0 648 1.31 Is there support for qmail and the maildir format?
yuuji@0 649
yuuji@0 650 There is no support for qmail or the maildir format in our
yuuji@0 651 distribution, nor are there any plans to add such support.
yuuji@0 652 Maildir support may be available from third parties.
yuuji@0 653 _________________________________________________________________
yuuji@0 654
yuuji@0 655 1.32 Is there support for the Cyrus mailbox format?
yuuji@0 656
yuuji@0 657 No.
yuuji@0 658 _________________________________________________________________
yuuji@0 659
yuuji@0 660 1.33 Is this software Y2K compliant?
yuuji@0 661
yuuji@0 662 Please read the files Y2K and calendar.txt.
yuuji@0 663 _________________________________________________________________
yuuji@0 664
yuuji@0 665 2. What Do I Need to Build This Software?
yuuji@0 666 _________________________________________________________________
yuuji@0 667
yuuji@0 668 2.1 What do I need to build this software with SSL on UNIX?
yuuji@0 669
yuuji@0 670 You need to build and install OpenSSL first.
yuuji@0 671 _________________________________________________________________
yuuji@0 672
yuuji@0 673 2.2 What do I need to build this software with Kerberos V on UNIX?
yuuji@0 674
yuuji@0 675 You need to build and install MIT Kerberos first.
yuuji@0 676 _________________________________________________________________
yuuji@0 677
yuuji@0 678 2.3 What do I need to use a C++ compiler with this software to build
yuuji@0 679 my own application?
yuuji@0 680
yuuji@0 681 If you are building an application using the c-client library,
yuuji@0 682 use the new c-client.h file instead of including the other
yuuji@0 683 include files. It seems that c-client.h should define away all
yuuji@0 684 the troublesome names that conflict with C++.
yuuji@0 685
yuuji@0 686 If you use gcc, you may need to use -fno-operator-names as
yuuji@0 687 well.
yuuji@0 688 _________________________________________________________________
yuuji@0 689
yuuji@0 690 2.4 What do I need to build this software on Windows?
yuuji@0 691
yuuji@0 692 You need Microsoft Visual C++ 6.0, Visual C++ .NET, or Visual
yuuji@0 693 C# .NET (which you can buy from any computer store), along with
yuuji@0 694 the Microsoft Platform SDK (which you can download from
yuuji@0 695 Microsoft's web site).
yuuji@0 696
yuuji@0 697 You do not need to install the entire Platform SDK; it suffices
yuuji@0 698 to install just the Core SDK and the Internet Development SDK.
yuuji@0 699 _________________________________________________________________
yuuji@0 700
yuuji@0 701 2.5 What do I need to build this software on DOS?
yuuji@0 702
yuuji@0 703 It's been several years since we last attempted to do this. At
yuuji@0 704 the time, we used Microsoft C.
yuuji@0 705 _________________________________________________________________
yuuji@0 706
yuuji@0 707 2.6 Can't I use Borland C to build this software on the PC?
yuuji@0 708
yuuji@0 709 Probably not. If you know otherwise, please let us know.
yuuji@0 710 _________________________________________________________________
yuuji@0 711
yuuji@0 712 2.7 What do I need to build this software on the Mac?
yuuji@0 713
yuuji@0 714 It has been several years since we last attempted to do this.
yuuji@0 715 At the time, we used Symantec THINK C; but today you'll need a
yuuji@0 716 C compiler which allows segments to be more than 32K.
yuuji@0 717 _________________________________________________________________
yuuji@0 718
yuuji@0 719 2.8 What do I need to build this software on VMS?
yuuji@0 720
yuuji@0 721 You need the VMS C compiler, and either the Multinet or Netlib
yuuji@0 722 TCP.
yuuji@0 723 _________________________________________________________________
yuuji@0 724
yuuji@0 725 2.9 What do I need to build this software on TOPS-20?
yuuji@0 726
yuuji@0 727 You need the TOPS-20 KCC compiler.
yuuji@0 728 _________________________________________________________________
yuuji@0 729
yuuji@0 730 2.10 What do I need to build this software on Amiga or OS/2?
yuuji@0 731
yuuji@0 732 We don't know.
yuuji@0 733 _________________________________________________________________
yuuji@0 734
yuuji@0 735 2.11 What do I need to build this software on Windows CE?
yuuji@0 736
yuuji@0 737 This port is incomplete. Someone needs to finish it.
yuuji@0 738 _________________________________________________________________
yuuji@0 739
yuuji@0 740 3. Build and Configuration Questions
yuuji@0 741 _________________________________________________________________
yuuji@0 742
yuuji@0 743 3.1 How do I configure the IMAP and POP servers on UNIX?
yuuji@0 744 3.2 I built and installed the servers according to the BUILD
yuuji@0 745 instructions. It can't be that easy. Don't I need to write a config
yuuji@0 746 file?
yuuji@0 747
yuuji@0 748 For ordinary "vanilla" UNIX systems, this software is plug and
yuuji@0 749 play; just build it, install it, and you're done. If you have a
yuuji@0 750 modified system, then you may want to do additional work; most
yuuji@0 751 of this is to a single source code file (env_unix.c on UNIX
yuuji@0 752 systems). Read the file CONFIG for more details.
yuuji@0 753
yuuji@0 754 Yes, it's that easy. There are some additional options, such as
yuuji@0 755 SSL or Kerberos, which require additional steps to build. See
yuuji@0 756 the relevant questions below.
yuuji@0 757 _________________________________________________________________
yuuji@0 758
yuuji@0 759 3.3 How do I make the IMAP and POP servers look for INBOX at some
yuuji@0 760 place other than the mail spool directory?
yuuji@0 761 3.4 How do I make the IMAP server look for secondary folders at some
yuuji@0 762 place other than the user's home directory?
yuuji@0 763
yuuji@0 764 Please read the file CONFIG for discussion of this and other
yuuji@0 765 issues.
yuuji@0 766 _________________________________________________________________
yuuji@0 767
yuuji@0 768 3.5 How do I configure SSL?
yuuji@0 769 3.6 How do I configure TLS and the STARTTLS facility?
yuuji@0 770
yuuji@0 771 imap-2007 supports SSL and TLS client functionality on UNIX and
yuuji@0 772 32-bit Windows for IMAP, POP3, SMTP, and NNTP; and SSL and TLS
yuuji@0 773 server functionality on UNIX for IMAP and POP3.
yuuji@0 774
yuuji@0 775 UNIX SSL build requires that a third-party software package,
yuuji@0 776 OpenSSL, be installed on the system first. Read
yuuji@0 777 imap-2007/docs/SSLBUILD for more information.
yuuji@0 778
yuuji@0 779 SSL is supported via undocumented Microsoft interfaces in
yuuji@0 780 Windows 9x and NT4; and via standard interfaces in Windows
yuuji@0 781 2000, Windows Millenium, and Windows XP.
yuuji@0 782 _________________________________________________________________
yuuji@0 783
yuuji@0 784 3.7 How do I build/install OpenSSL and obtain/create certificates for
yuuji@0 785 use with SSL?
yuuji@0 786
yuuji@0 787 If you need help in doing this, try the contacts mentioned in
yuuji@0 788 the OpenSSL README. We do not offer support for OpenSSL or
yuuji@0 789 certificates.
yuuji@0 790 _________________________________________________________________
yuuji@0 791
yuuji@0 792 3.8 How do I configure CRAM-MD5 authentication?
yuuji@0 793 3.9 How do I configure APOP authentication?
yuuji@0 794
yuuji@0 795 CRAM-MD5 authentication is enabled in the IMAP and POP3 client
yuuji@0 796 code on all platforms. Read md5.txt to learn how to set up
yuuji@0 797 CRAM-MD5 and APOP authentication on UNIX and NT servers.
yuuji@0 798
yuuji@0 799 There is no support for APOP client authentication.
yuuji@0 800 _________________________________________________________________
yuuji@0 801
yuuji@0 802 3.10 How do I configure Kerberos V5?
yuuji@0 803
yuuji@0 804 imap-2007 supports client and server functionality on UNIX and
yuuji@0 805 32-bit Windows.
yuuji@0 806
yuuji@0 807 Kerberos V5 is supported by default in Windows 2000 builds:
yuuji@0 808
yuuji@0 809 nmake -f makefile.w2k
yuuji@0 810
yuuji@0 811 Other builds require that a third-party Kerberos package, e.g.
yuuji@0 812 MIT Kerberos, be installed on the system first.
yuuji@0 813
yuuji@0 814 To build with Kerberos V5 on UNIX, include
yuuji@0 815 EXTRAAUTHENTICATORS=gss in the make command line, e.g.
yuuji@0 816
yuuji@0 817 make lnp EXTRAAUTHENTICATORS=gss
yuuji@0 818
yuuji@0 819 To build with Kerberos V5 on Windows 9x, Windows Millenium, and
yuuji@0 820 NT4, use the "makefile.ntk" file instead of "makefile.nt":
yuuji@0 821
yuuji@0 822
yuuji@0 823 nmake -f makefile.ntk
yuuji@0 824 _________________________________________________________________
yuuji@0 825
yuuji@0 826 3.11 How do I configure PAM for plaintext passwords?
yuuji@0 827
yuuji@0 828 On Linux systems, use the lnp port, e.g.
yuuji@0 829
yuuji@0 830 make lnp
yuuji@0 831
yuuji@0 832 On Solaris systems and other systems with defective PAM
yuuji@0 833 implementations, build with PASSWDTYPE=pmb, e.g.
yuuji@0 834
yuuji@0 835 make sol PASSWDTYPE=pmb
yuuji@0 836
yuuji@0 837 On all other systems, build with PASSWDTYPE=pam, e.g
yuuji@0 838
yuuji@0 839 make foo PASSWDTYPE=pam
yuuji@0 840
yuuji@0 841 If you build with PASSWDTYPE=pam and authentication does not
yuuji@0 842 work, try rebuilding (after a "make clean") with
yuuji@0 843 PASSWDTYPE=pmb.
yuuji@0 844 _________________________________________________________________
yuuji@0 845
yuuji@0 846 3.12 It looks like all I have to do to make the server use Kerberos is
yuuji@0 847 to build with PAM on my Linux system, and set it up in PAM for
yuuji@0 848 Kerberos passwords. Right?
yuuji@0 849
yuuji@0 850 Yes and no.
yuuji@0 851
yuuji@0 852 Doing this will make plaintext password authentication use the
yuuji@0 853 Kerberos password instead of the /etc/passwd password.
yuuji@0 854
yuuji@0 855 However, this will NOT give you Kerberos-secure authentication.
yuuji@0 856 See the answer to the How do I configure Kerberos V5? question
yuuji@0 857 for how to build with Kerberos-secure authentication.
yuuji@0 858 _________________________________________________________________
yuuji@0 859
yuuji@0 860 3.13 How do I configure Kerberos 5 for plaintext passwords?
yuuji@0 861
yuuji@0 862 Build with PASSWDTYPE=gss, e.g.
yuuji@0 863
yuuji@0 864 make sol PASSWDTYPE=gss
yuuji@0 865
yuuji@0 866 However, this will NOT give you Kerberos-secure authentication.
yuuji@0 867 See the answer to the How do I configure Kerberos V5? question
yuuji@0 868 for how to build with Kerberos-secure authentication.
yuuji@0 869 _________________________________________________________________
yuuji@0 870
yuuji@0 871 3.14 How do I configure AFS for plaintext passwords?
yuuji@0 872
yuuji@0 873 Build with PASSWDTYPE=afs, e.g
yuuji@0 874
yuuji@0 875 make sol PASSWDTYPE=afs
yuuji@0 876 _________________________________________________________________
yuuji@0 877
yuuji@0 878 3.15 How do I configure DCE for plaintext passwords?
yuuji@0 879
yuuji@0 880 Build with PASSWDTYPE=dce, e.g
yuuji@0 881
yuuji@0 882 make sol PASSWDTYPE=dce
yuuji@0 883 _________________________________________________________________
yuuji@0 884
yuuji@0 885 3.16 How do I configure the CRAM-MD5 database for plaintext passwords?
yuuji@0 886
yuuji@0 887 The CRAM-MD5 password database is automatically used for
yuuji@0 888 plaintext password if it exists.
yuuji@0 889
yuuji@0 890 Note that this is NOT CRAM-MD5-secure authentication. You
yuuji@0 891 probably want to consider disabling plaintext passwords for
yuuji@0 892 non-SSL/TLS sessions. See the next two questions.
yuuji@0 893 _________________________________________________________________
yuuji@0 894
yuuji@0 895 3.17 How do I disable plaintext passwords?
yuuji@0 896
yuuji@0 897 Server-level plaintext passwords can be disabled by setting
yuuji@0 898 PASSWDTYPE=nul, e.g.
yuuji@0 899
yuuji@0 900 make lnx EXTRAAUTHENTICATORS=gss PASSWDTYPE=nul
yuuji@0 901
yuuji@0 902 Note that you must have a CRAM-MD5 database installed or
yuuji@0 903 specify at least one EXTRAAUTHENTICATOR, otherwise it will not
yuuji@0 904 be possible to log in to the server.
yuuji@0 905
yuuji@0 906 When plaintext passwords are disabled, the IMAP server will
yuuji@0 907 advertise the LOGINDISABLED capability and the POP3 server will
yuuji@0 908 not advertise the USER capability.
yuuji@0 909
yuuji@0 910 3.18 How do I disable plaintext passwords on unencrypted sessions, but
yuuji@0 911 allow them in SSL or TLS sessions?
yuuji@0 912
yuuji@0 913 Do not set PASSWDTYPE=nul or SSLTYPE=unix. Set SSLTYPE=nopwd
yuuji@0 914 instead, e.g.
yuuji@0 915
yuuji@0 916 make lnx SSLTYPE=nopwd
yuuji@0 917
yuuji@0 918 When plaintext passwords are disabled, the IMAP server will
yuuji@0 919 advertise the LOGINDISABLED capability and the POP3 server will
yuuji@0 920 not advertise the USER capability.
yuuji@0 921
yuuji@0 922 Plaintext passwords will always be enabled in SSL sessions; the
yuuji@0 923 IMAP server will not advertise the LOGINDISABLED capability and
yuuji@0 924 the POP3 server will advertise the USER capability.
yuuji@0 925
yuuji@0 926 If the client does a successful start-TLS in a non-SSL session,
yuuji@0 927 plaintext passwords will be enabled, and a new CAPABILITY or
yuuji@0 928 CAPA command (which is required after start-TLS) will show the
yuuji@0 929 effect as in SSL sessions.
yuuji@0 930 _________________________________________________________________
yuuji@0 931
yuuji@0 932 3.19 How do I configure virtual hosts?
yuuji@0 933
yuuji@0 934 This is automatic, but with certain restrictions.
yuuji@0 935
yuuji@0 936 The most important one is that each virtual host must have its
yuuji@0 937 own IP address; otherwise the server has no way of knowing
yuuji@0 938 which virtual host is desired.
yuuji@0 939
yuuji@0 940 As distributed, the software uses a global password file; hence
yuuji@0 941 user "fred" on one virtual host is "fred" on all virtual hosts.
yuuji@0 942 You may want to modify the checkpw() routine to implement some
yuuji@0 943 other policy (e.g. separate password files).
yuuji@0 944
yuuji@0 945 Note that the security model assumes that all users have their
yuuji@0 946 own unique UNIX UID number. So if you use separate password
yuuji@0 947 files you should make certain that the UID numbers do not
yuuji@0 948 overlap between different files.
yuuji@0 949
yuuji@0 950 More advanced virtual host support may be available as patches
yuuji@0 951 from third parties.
yuuji@0 952 _________________________________________________________________
yuuji@0 953
yuuji@0 954 3.20 Why do I get compiler warning messages such as:
yuuji@0 955 passing arg 3 of `scandir' from incompatible pointer type
yuuji@0 956 Pointers are not assignment-compatible.
yuuji@0 957 Argument #4 is not the correct type.
yuuji@0 958
yuuji@0 959 during the build?
yuuji@0 960
yuuji@0 961 You can safely ignore these messages.
yuuji@0 962
yuuji@0 963 Over the years, the prototype for scandir() has changed, and
yuuji@0 964 thus is variant across different UNIX platforms. In particular,
yuuji@0 965 the definitions of the third argument (type select_t) and
yuuji@0 966 fourth argument (type compar_t) have changed over the years,
yuuji@0 967 the issue being whether or not the arguments to the functions
yuuji@0 968 pointed to by these function pointers are of type const or not.
yuuji@0 969
yuuji@0 970 The way that c-client calls scandir() will tend to generate
yuuji@0 971 these compiler warnings on newer systems such as Linux;
yuuji@0 972 however, it will still build. The problem with fixing the call
yuuji@0 973 is that then it won't build on older systems.
yuuji@0 974 _________________________________________________________________
yuuji@0 975
yuuji@0 976 3.21 Why do I get compiler warning messages such as
yuuji@0 977 Operation between types "void(*)(int)" and "void*" is not allowed.
yuuji@0 978 Function argument assignment between types "void*" and "void(*)(int)" is not a
yuuji@0 979 llowed.
yuuji@0 980 Pointers are not assignment-compatible.
yuuji@0 981 Argument #5 is not the correct type.
yuuji@0 982
yuuji@0 983 during the build?
yuuji@0 984
yuuji@0 985 You can safely ignore these messages.
yuuji@0 986
yuuji@0 987 All known systems have no problem with casting a function
yuuji@0 988 pointer to/from a void* pointer, certain C compilers issue a
yuuji@0 989 compiler diagnostic because this facility is listed as a
yuuji@0 990 "Common extension" by the C standard:
yuuji@0 991
yuuji@0 992 K.5.7 Function pointer casts
yuuji@0 993 [#1] A pointer to an object or to void may be cast to a pointer
yuuji@0 994 to a function, allowing data to be invoked as a function (6.3.4).
yuuji@0 995 [#2] A pointer to a function may be cast to a pointer to an
yuuji@0 996 object or to void, allowing a function to be inspected or
yuuji@0 997 modified (for example, by a debugger) (6.3.4).
yuuji@0 998
yuuji@0 999 It may be just a "common extension", but this facility is
yuuji@0 1000 relied upon heavily by c-client.
yuuji@0 1001 _________________________________________________________________
yuuji@0 1002
yuuji@0 1003 3.22 Why do I get linker warning messages such as:
yuuji@0 1004 mtest.c:515: the `gets' function is dangerous and should not be used.
yuuji@0 1005
yuuji@0 1006 during the build? Isn't this a security bug?
yuuji@0 1007
yuuji@0 1008 You can safely ignore this message.
yuuji@0 1009
yuuji@0 1010 Certain linkers, most notably on Linux, give this warning
yuuji@0 1011 message. It is indeed true that the traditional gets() function
yuuji@0 1012 is not a safe one.
yuuji@0 1013
yuuji@0 1014 However, the mtest program is only a demonstration program, a
yuuji@0 1015 model of a very basic application program using c-client. It is
yuuji@0 1016 not something that you would install, much less run in any
yuuji@0 1017 security-sensitive context.
yuuji@0 1018
yuuji@0 1019 mtest has numerous other shortcuts that you wouldn't want to do
yuuji@0 1020 in a real application program.
yuuji@0 1021
yuuji@0 1022 The only "security bug" with mtest would be if it was run by
yuuji@0 1023 some script in a security-sensitive context, but mtest isn't
yuuji@0 1024 particularly useful for such purposes. If you wanted to write a
yuuji@0 1025 script to automate some email task using c-client, you'd be
yuuji@0 1026 better off using imapd instead of mtest.
yuuji@0 1027
yuuji@0 1028 mtest only has two legitimate uses. It's a useful testbed for
yuuji@0 1029 me when debugging new versions of c-client, and it's useful as
yuuji@0 1030 a model for someone writing a simple c-client application to
yuuji@0 1031 see how the various calls work.
yuuji@0 1032
yuuji@0 1033 By the way, if you need a more advanced example of c-client
yuuji@0 1034 programming than mtest (and you probably will), I recommend
yuuji@0 1035 that you look at the source code for imapd and Pine.
yuuji@0 1036 _________________________________________________________________
yuuji@0 1037
yuuji@0 1038 3.23 Why do I get linker warning messages such as:
yuuji@0 1039 auth_ssl.c:92: the `tmpnam' function is dangerous and should not be used.
yuuji@0 1040
yuuji@0 1041 during the build? Isn't this a security bug?
yuuji@0 1042
yuuji@0 1043 You can safely ignore this message.
yuuji@0 1044
yuuji@0 1045 Certain linkers, most notably on Linux, give this warning
yuuji@0 1046 message, based upon two known issues with tmpnam():
yuuji@0 1047
yuuji@0 1048 there can be a buffer overflow if an inadequate buffer is
yuuji@0 1049 allocated.
yuuji@0 1050 there can be a timing race caused by certain incautious
yuuji@0 1051 usage of the return value.
yuuji@0 1052
yuuji@0 1053 Neither of these issues applies in the particular use that is
yuuji@0 1054 made of tmpnam(). More importantly, the tmpnam() call is never
yuuji@0 1055 executed on Linux systems.
yuuji@0 1056 _________________________________________________________________
yuuji@0 1057
yuuji@0 1058 3.24 OK, suppose I see a warning message about a function being
yuuji@0 1059 "dangerous and should not be used" for something other than this
yuuji@0 1060 gets() or tmpnam() call?
yuuji@0 1061
yuuji@0 1062 Please forward the details for investigation.
yuuji@0 1063 _________________________________________________________________
yuuji@0 1064
yuuji@0 1065 4. Operational Questions
yuuji@0 1066 _________________________________________________________________
yuuji@0 1067
yuuji@0 1068 4.1 How can I enable anonymous IMAP logins?
yuuji@0 1069
yuuji@0 1070 Create the file /etc/anonymous.newsgroups. At the present time,
yuuji@0 1071 this file should be empty. This will permit IMAP logins as
yuuji@0 1072 anonymous as well as the ANONYMOUS SASL authenticator.
yuuji@0 1073 Anonymous users have access to mailboxes in the #news., #ftp/,
yuuji@0 1074 and #public/ namespaces only.
yuuji@0 1075 _________________________________________________________________
yuuji@0 1076
yuuji@0 1077 4.2 How do I set up an alert message that each IMAP user will see?
yuuji@0 1078
yuuji@0 1079 Create the file /etc/imapd.alert with the text of the message.
yuuji@0 1080 This text should be kept to one line if possible. Note that
yuuji@0 1081 this will cause an alert to every IMAP user every time they
yuuji@0 1082 initiate an IMAP session, so it should only be used for
yuuji@0 1083 critical messages.
yuuji@0 1084 _________________________________________________________________
yuuji@0 1085
yuuji@0 1086 4.3 How does the c-client library choose which of its several
yuuji@0 1087 mechanisms to use to establish an IMAP connection to the server? I
yuuji@0 1088 noticed that it can connect on port 143, port 993, via rsh, and via
yuuji@0 1089 ssh.
yuuji@0 1090
yuuji@0 1091 c-client chooses how to establish an IMAP connection via the
yuuji@0 1092 following rules:
yuuji@0 1093
yuuji@0 1094 + If /ssl is specified, use an SSL connection. Fail otherwise.
yuuji@0 1095 + Else if client is a UNIX system and "ssh server exec
yuuji@0 1096 /etc/rimapd" works, use that
yuuji@0 1097 + Else if /tryssl is specified and an SSL connection works, use
yuuji@0 1098 that.
yuuji@0 1099 + Else if client is a UNIX system and "rsh server exec
yuuji@0 1100 /etc/rimapd" works, use that.
yuuji@0 1101 + Else use a non-SSL connection.
yuuji@0 1102 _________________________________________________________________
yuuji@0 1103
yuuji@0 1104 4.4 I am using a TLS-capable IMAP server, so I don't need to use /ssl
yuuji@0 1105 to get encryption. However, I want to be certain that my session is
yuuji@0 1106 TLS encrypted before I send my password. How to I do this?
yuuji@0 1107
yuuji@0 1108 Use the /tls option in the mailbox name. This will cause an
yuuji@0 1109 error message and the connection to fail if the server does not
yuuji@0 1110 negotiate STARTTLS.
yuuji@0 1111 _________________________________________________________________
yuuji@0 1112
yuuji@0 1113 4.5 How do I use one of the alternative formats described in the
yuuji@0 1114 formats.txt document? In particular, I hear that mbx format will give
yuuji@0 1115 me better performance and allow shared access.
yuuji@0 1116
yuuji@0 1117 The rumors about mbx format being preferred are true. It is
yuuji@0 1118 faster than the traditional UNIX mailbox format and permits
yuuji@0 1119 shared access.
yuuji@0 1120
yuuji@0 1121 However, and this is very important, note that using an
yuuji@0 1122 alternative mailbox format is an advanced facility, and only
yuuji@0 1123 expert users should undertake it. If you don't understand any
yuuji@0 1124 of the following notes, you may not be enough of an expert yet,
yuuji@0 1125 and are probably better off not going this route until you are
yuuji@0 1126 more comfortable with your understanding.
yuuji@0 1127
yuuji@0 1128 Some of the formats, including mbx, are only supported by the
yuuji@0 1129 software based on the c-client library, and are not recognized
yuuji@0 1130 by other mailbox programs. The "vi" editor will corrupt any mbx
yuuji@0 1131 format mailbox that it encounters.
yuuji@0 1132
yuuji@0 1133 Another problem is that the certain formats, including mbx, use
yuuji@0 1134 advanced file access and locking techniques that do not work
yuuji@0 1135 reliably with NFS. NFS is not a real filesystem. Use IMAP
yuuji@0 1136 instead of NFS for distributed access.
yuuji@0 1137
yuuji@0 1138 Each of the following steps are in escalating order of
yuuji@0 1139 involvement. The further you go down this list, the more deeply
yuuji@0 1140 committed you become:
yuuji@0 1141
yuuji@0 1142 + The simplest way to create a mbx-format mailbox is to prefix
yuuji@0 1143 the name with "#driver.mbx/" when creating a mailbox through
yuuji@0 1144 c-client. For example, if you create "#driver.mbx/foo", the
yuuji@0 1145 mailbox "foo" will be created in mbx format. Only use
yuuji@0 1146 "#driver.mbx/" when creating the mailbox. At all other times,
yuuji@0 1147 just use the name ("foo" in this example); the software will
yuuji@0 1148 automatically select the driver for mbx whenever that mailbox
yuuji@0 1149 is accessed without you doing anything else.
yuuji@0 1150 + You can use the "mailutil copy" command to copy an existing
yuuji@0 1151 mailbox to a new mailbox in mbx format. Read the man page
yuuji@0 1152 provided with the mailutil program for details.
yuuji@0 1153 + If you create an mbx-format INBOX, by creating
yuuji@0 1154 "#driver.mbx/INBOX" (note that "INBOX" must be all
yuuji@0 1155 uppercase), then subsequent access to INBOX by any c-client
yuuji@0 1156 based application will use the mbx-format INBOX. Any mail
yuuji@0 1157 delivered to the traditional format mailbox in the spool
yuuji@0 1158 directory (e.g. /var/spool/mail/$USER) will automatically be
yuuji@0 1159 copied into the mbx-format INBOX and the spool directory copy
yuuji@0 1160 removed.
yuuji@0 1161 + You can cause any newly-created mailboxes to be in mbx-format
yuuji@0 1162 by default by changing the definition of
yuuji@0 1163 CREATEPROTO=unixproto to be CREATEPROTO=mbxproto in
yuuji@0 1164 src/osdep/unix/Makefile, then rebuilding the IMAP toolkit (do
yuuji@0 1165 a "make clean" first). Do not change EMPTYPROTO, since mbx
yuuji@0 1166 format mailboxes are never a zero-byte file. If you use Pine
yuuji@0 1167 or the imap-utils, you should probably also rebuild them with
yuuji@0 1168 the new IMAP toolkit too.
yuuji@0 1169 + You can deliver directly to the mbx-format INBOX by use of
yuuji@0 1170 the tmail or dmail programs. tmail is for direct invocation
yuuji@0 1171 from sendmail (or whatever MTA program you use); dmail is for
yuuji@0 1172 calls from procmail. Both of these programs have man pages
yuuji@0 1173 which must be read carefully before making this change.
yuuji@0 1174
yuuji@0 1175 Most other servers (e.g. Cyrus) require use of a non-standard
yuuji@0 1176 format. A full-fledged format conversion is not significantly
yuuji@0 1177 different from what you have to do with other servers. The
yuuji@0 1178 difference, which makes format conversion procedures somewhat
yuuji@0 1179 more complicated with this server, is that there is no "all or
yuuji@0 1180 nothing" requirement with this server. There are many points in
yuuji@0 1181 between. A format conversion can be anything from a single
yuuji@0 1182 mailbox or single user, to systemwide.
yuuji@0 1183
yuuji@0 1184 This is good in that you can decide how far to go, or do the
yuuji@0 1185 steps incrementally as you become more comfortable with the
yuuji@0 1186 result. On the other hand, there's no "One True Way" which can
yuuji@0 1187 be boiled down to a simple set of pedagogical instructions.
yuuji@0 1188
yuuji@0 1189 A number of sites have done full-fledged format conversions,
yuuji@0 1190 and are reportedly quite happy with the results. Feel free to
yuuji@0 1191 ask in the comp.mail.imap newsgroup or the imap-uw mailing
yuuji@0 1192 list for advice or help.
yuuji@0 1193 _________________________________________________________________
yuuji@0 1194
yuuji@0 1195 4.6 How do I set up shared mailboxes?
yuuji@0 1196
yuuji@0 1197 At the simplest level, a shared mailbox is one which has UNIX
yuuji@0 1198 file and directory protections which permit multiple users to
yuuji@0 1199 access it. What this means is that your existing skills and
yuuji@0 1200 tools to create and manage shared files on your UNIX system
yuuji@0 1201 apply to shared mailboxes; e.g.
yuuji@0 1202
yuuji@0 1203 chmod 666 mailbox
yuuji@0 1204
yuuji@0 1205 You may want to consider the use of a mailbox format which
yuuji@0 1206 permits multiple simultaneous read/write sessions, such as the
yuuji@0 1207 mbx format. The traditional UNIX format only allows one
yuuji@0 1208 read/write session to a mailbox at a time.
yuuji@0 1209
yuuji@0 1210 An additional convenience item are three system directories,
yuuji@0 1211 which can be set up for shared namespaces. These are: #ftp,
yuuji@0 1212 #shared, and #public, and are defined by creating the
yuuji@0 1213 associated UNIX users and home directories as described below.
yuuji@0 1214
yuuji@0 1215 #ftp/ refers to the anonymous ftp filesystem exported by the
yuuji@0 1216 ftp server, and is equivalent to the home directory for UNIX
yuuji@0 1217 user "ftp". For example, #ftp/foo/bar refers to the file
yuuji@0 1218 /foo/bar in the anonymous FTP filesystem, or ~ftp/foo/bar for
yuuji@0 1219 normal users. Anonymous FTP files are available to anonymous
yuuji@0 1220 IMAP logins. By default, newly-created files in #ftp/ are
yuuji@0 1221 protected 644.
yuuji@0 1222
yuuji@0 1223 #public/ refers to an IMAP toolkit convention called "public"
yuuji@0 1224 files, and is equivalent to the home directory for UNIX user
yuuji@0 1225 "imappublic". For example, #public/foo/bar refers to the file
yuuji@0 1226 ~imappublic/foo/bar. Public files are available to anonymous
yuuji@0 1227 IMAP logins. By default, newly-created files in #public are
yuuji@0 1228 created with protection 0666.
yuuji@0 1229
yuuji@0 1230 #shared/ refers to an IMAP toolkit convention called "shared"
yuuji@0 1231 files, and is equivalent to the home directory for UNIX user
yuuji@0 1232 "imapshared". For example, #shared/foo/bar refers to the file
yuuji@0 1233 ~imapshared/foo/bar. Shared files are not available to
yuuji@0 1234 anonymous IMAP logins. By default, newly-created files in
yuuji@0 1235 #shared are created with protection 0660.
yuuji@0 1236 _________________________________________________________________
yuuji@0 1237
yuuji@0 1238 4.7 How can I make the server syslogs go to someplace other than the
yuuji@0 1239 mail syslog?
yuuji@0 1240
yuuji@0 1241 The openlog() call that sets the syslog facility is in
yuuji@0 1242 src/osdep/unix/env_unix.c in routine server_init(). You need to
yuuji@0 1243 edit this file to change the syslog facility from LOG_MAIL to
yuuji@0 1244 the facility you want, then rebuild. You also need to set up
yuuji@0 1245 your /etc/syslog.conf properly.
yuuji@0 1246
yuuji@0 1247 Refer to the man pages for syslog and syslogd for more
yuuji@0 1248 information on what the available syslog facilities are and how
yuuji@0 1249 to configure syslogs. If you still don't understand what to do,
yuuji@0 1250 find a UNIX system expert.
yuuji@0 1251 _________________________________________________________________
yuuji@0 1252
yuuji@0 1253 5. Security Questions
yuuji@0 1254 _________________________________________________________________
yuuji@0 1255
yuuji@0 1256 5.1 I see that the IMAP server allows access to arbitary files on the
yuuji@0 1257 system, including /etc/passwd! How do I disable this?
yuuji@0 1258
yuuji@0 1259 You should not worry about this if your IMAP users are allowed
yuuji@0 1260 shell access. The IMAP server does not permit any access that
yuuji@0 1261 the user can not have via the shell.
yuuji@0 1262
yuuji@0 1263 If, and only if, you deny your IMAP users shell access, you may
yuuji@0 1264 want to consider one of three choices. Note that these choices
yuuji@0 1265 reduce IMAP functionality, and may have undesirable side
yuuji@0 1266 effects. Each of these choices involves an edit to file
yuuji@0 1267 src/osdep/unix/env_unix.c
yuuji@0 1268
yuuji@0 1269 The first (and recommended) choice is to set restrictBox as
yuuji@0 1270 described in file CONFIG. This will disable access to the
yuuji@0 1271 filesystem root, to other users' home directory, and to
yuuji@0 1272 superior directory.
yuuji@0 1273
yuuji@0 1274 The second (and strongly NOT recommended) choice is to set
yuuji@0 1275 closedBox as described in file CONFIG. This puts each IMAP
yuuji@0 1276 session into a so-called "chroot jail", and thus setting this
yuuji@0 1277 option is extremely dangerous; it can make your system much
yuuji@0 1278 less secure and open to root compromise attacks. So do not use
yuuji@0 1279 this option unless you are absolutely certain that you
yuuji@0 1280 understand all the issues of a "chroot jail."
yuuji@0 1281
yuuji@0 1282 The third choice is to rewrite routine mailboxfile() to
yuuji@0 1283 implement whatever mapping from mailbox name to filesystem name
yuuji@0 1284 (and restrictions) that you wish. This is the most general
yuuji@0 1285 choice. As a guide, you can see at the start of routine
yuuji@0 1286 mailboxfile() what the restrictBox choice does.
yuuji@0 1287 _________________________________________________________________
yuuji@0 1288
yuuji@0 1289 5.2 I've heard that IMAP servers are insecure. Is this true?
yuuji@0 1290
yuuji@0 1291 There are no known security problems in this version of the
yuuji@0 1292 IMAP toolkit, including the IMAP and POP servers. The IMAP and
yuuji@0 1293 POP servers limit what can be done while not logged in, and as
yuuji@0 1294 part of the login process discard all privileges except those
yuuji@0 1295 of the user.
yuuji@0 1296
yuuji@0 1297 As with other software packages, there have been buffer
yuuji@0 1298 overflow vulnerabilities in past versions. All known problems
yuuji@0 1299 of this nature are fixed in this version.
yuuji@0 1300
yuuji@0 1301 There is every reason to believe that the bad guys are engaged
yuuji@0 1302 in an ongoing effort to find vulnerabilities in the IMAP
yuuji@0 1303 toolkit. We look for such problems, and when one is found we
yuuji@0 1304 fix it.
yuuji@0 1305
yuuji@0 1306 It's unfortunate that any vulnerabilities existed in past
yuuji@0 1307 versions, and we're doing my best to keep the IMAP toolkit free
yuuji@0 1308 of vulnerabilities. No new vulnerabilities have been discovered
yuuji@0 1309 in quite a while, but efforts will not be relaxed.
yuuji@0 1310
yuuji@0 1311 Beware of vendors who claim that their implementations can not
yuuji@0 1312 have vulnerabilities.
yuuji@0 1313 _________________________________________________________________
yuuji@0 1314
yuuji@0 1315 5.3 How do I know that I have the most secure version of the server?
yuuji@0 1316
yuuji@0 1317 The best way is to keep your server software up to date. The
yuuji@0 1318 bad guys are always looking for ways to crack software, and
yuuji@0 1319 when they find one, let all their friends know.
yuuji@0 1320
yuuji@0 1321 Oldtimers used to refer to a concept of software rot: if your
yuuji@0 1322 software hasn't been updated in a while, it would "rot" -- tend
yuuji@0 1323 to acquire problems that it didn't have when it was new.
yuuji@0 1324
yuuji@0 1325 The latest release version of the IMAP toolkit is always
yuuji@0 1326 available at ftp://ftp.cac.washington.edu/mail/imap.tar.Z
yuuji@0 1327 _________________________________________________________________
yuuji@0 1328
yuuji@0 1329 5.4 I see all these strcpy() and sprintf() calls, those are unsafe,
yuuji@0 1330 aren't they?
yuuji@0 1331
yuuji@0 1332 Yes and no.
yuuji@0 1333
yuuji@0 1334 It can be unsafe to do these calls if you do not know that the
yuuji@0 1335 string being written will fit in the buffer. However, they are
yuuji@0 1336 perfectly safe if you do know that.
yuuji@0 1337
yuuji@0 1338 Beware of programmers who advocate doing a brute-force change
yuuji@0 1339 of all instances of
yuuji@0 1340
yuuji@0 1341 strcpy (s,t);
yuuji@0 1342
yuuji@0 1343 to
yuuji@0 1344
yuuji@0 1345 strncpy (s,t,n)[n] = '\0';
yuuji@0 1346
yuuji@0 1347 and similar measures in the name of "fixing all possible buffer
yuuji@0 1348 overflows."
yuuji@0 1349
yuuji@0 1350 There are examples in which a security bug was introduced
yuuji@0 1351 because of this type of "fix", due to the programmer using the
yuuji@0 1352 wrong value for n. In one case, the programmer thought that n
yuuji@0 1353 was larger than it actually was, causing a NUL to be written
yuuji@0 1354 out of the buffer; in another, n was too small, and a security
yuuji@0 1355 credential was truncated.
yuuji@0 1356
yuuji@0 1357 What is particularly ironic was that in both cases, the
yuuji@0 1358 original strcpy() was safe, because the size of the source
yuuji@0 1359 string was known to be safe.
yuuji@0 1360
yuuji@0 1361 With all this in mind, the software has been inspected, and it
yuuji@0 1362 is believed that all places where buffer overflows can happen
yuuji@0 1363 have been fixed. The strcpy()s that are still are in the code
yuuji@0 1364 occur after a size check was done in some other way.
yuuji@0 1365
yuuji@0 1366 Note that the common C idiom of
yuuji@0 1367
yuuji@0 1368 *s++ = c;
yuuji@0 1369
yuuji@0 1370 is just as vulnerable to buffer overflows. You can't cure
yuuji@0 1371 buffer overflows by outlawing certain functions, nor is it
yuuji@0 1372 desirable to do so; sometimes operations like strcpy()
yuuji@0 1373 translate into fast machine instructions for better
yuuji@0 1374 performance.
yuuji@0 1375
yuuji@0 1376 Nothing replaces careful study of code. That's how the bad guys
yuuji@0 1377 find bugs. Security is not accomplished by means of brute-force
yuuji@0 1378 shortcuts.
yuuji@0 1379 _________________________________________________________________
yuuji@0 1380
yuuji@0 1381 5.5 Those /tmp lock files are protected 666, is that really right?
yuuji@0 1382
yuuji@0 1383 Yes. Shared mailboxes won't work otherwise. Also, you get into
yuuji@0 1384 accidental denial of service problems with old lock files left
yuuji@0 1385 lying around; this happens fairly frequently.
yuuji@0 1386
yuuji@0 1387 The deliberate mischief that can be caused by fiddling with the
yuuji@0 1388 lock files is small-scale; harassment level at most. There are
yuuji@0 1389 many -- and much more effective -- other ways of harassing
yuuji@0 1390 another user on UNIX. It's usually not difficult to determine
yuuji@0 1391 the culprit.
yuuji@0 1392
yuuji@0 1393 Before worrying about deliberate mischief, worry first about
yuuji@0 1394 things happening by accident!
yuuji@0 1395 _________________________________________________________________
yuuji@0 1396
yuuji@0 1397 6. Why Did You Do This Strange Thing? Questions
yuuji@0 1398 _________________________________________________________________
yuuji@0 1399
yuuji@0 1400 6.1 Why don't you use GNU autoconfig / automake / autoblurdybloop?
yuuji@0 1401
yuuji@0 1402 Autoconfig et al are not available on all the platforms where
yuuji@0 1403 the IMAP toolkit is supported; and do not work correctly on
yuuji@0 1404 some of the platforms where they do exist. Furthermore, these
yuuji@0 1405 programs add another layer of complexity to an already complex
yuuji@0 1406 process.
yuuji@0 1407
yuuji@0 1408 Coaxing software that uses autoconfig to build properly on
yuuji@0 1409 platforms which were not specifically considered by that
yuuji@0 1410 software wastes an inordinate amount of time. When (not if)
yuuji@0 1411 autoconfig fails to do the right thing, the result is an
yuuji@0 1412 inpenetrable morass to untangle in order to find the problem
yuuji@0 1413 and fix it.
yuuji@0 1414
yuuji@0 1415 The concept behind autoconfig is good, but the execution is
yuuji@0 1416 flawed. It rarely does the right thing on a platform that
yuuji@0 1417 wasn't specifically considered. Human life is too short to
yuuji@0 1418 debug autoconfig problems, especially since the current
yuuji@0 1419 mechanism is so much easier.
yuuji@0 1420 _________________________________________________________________
yuuji@0 1421
yuuji@0 1422 6.2 Why do you insist upon a build with -g? Doesn't it waste disk and
yuuji@0 1423 memory space?
yuuji@0 1424
yuuji@0 1425 From time to time a submitted port has snuck in without -g.
yuuji@0 1426 This has always ended up causing problems. There are only two
yuuji@0 1427 valid excuses for not using -g in a port:
yuuji@0 1428
yuuji@0 1429 + The compiler does not support -g
yuuji@0 1430 + An alternate form of -g is needed with optimization, e.g.
yuuji@0 1431 -g3.
yuuji@0 1432
yuuji@0 1433 There will be no new ports added without -g (or a suitable
yuuji@0 1434 alternative) being set.
yuuji@0 1435
yuuji@0 1436 -g has not been arbitrarily added to the ports which do not
yuuji@0 1437 currently have it because we don't know if doing so would break
yuuji@0 1438 the build. However, any support issues with one of those port
yuuji@0 1439 will lead to the correct -g setting being determined and
yuuji@0 1440 permanently added.
yuuji@0 1441
yuuji@0 1442 Processors are fast enough (and disk space is cheap enough)
yuuji@0 1443 that -g should be automatic in all compilers with no way of
yuuji@0 1444 turning it off, and /bin/strip should be a symlink to
yuuji@0 1445 /bin/true. Human life is too short to deal with binaries built
yuuji@0 1446 without -g. Such binaries should be a bad memory of the days of
yuuji@0 1447 KIPS processors and disks that costs several dollars per
yuuji@0 1448 kilobyte.
yuuji@0 1449 _________________________________________________________________
yuuji@0 1450
yuuji@0 1451 6.3 Why don't you make c-client a shared library?
yuuji@0 1452
yuuji@0 1453 All too often, shared libraries create far more problems than
yuuji@0 1454 they solve.
yuuji@0 1455
yuuji@0 1456 Remember that you only gain the benefit of a shared library
yuuji@0 1457 when there are multiple applications which use that shared
yuuji@0 1458 library. Even without shared libraries, on most modern
yuuji@0 1459 operating systems (and many ancient ones too!) applications
yuuji@0 1460 will share their text segments between across multiple
yuuji@0 1461 processes running the same application. This means that if your
yuuji@0 1462 system only runs one application (e.g. imapd) that uses the
yuuji@0 1463 c-client library, then you gain no benefit from making c-client
yuuji@0 1464 a shared library even if it has 100 imapd processes. You will,
yuuji@0 1465 however suffer added complexity.
yuuji@0 1466
yuuji@0 1467 If you have a server system that just runs imapd and ipop3d,
yuuji@0 1468 then making c-client a shared library will save just one copy
yuuji@0 1469 of c-client no matter how many IMAP/POP3 processes are running.
yuuji@0 1470
yuuji@0 1471 The problem with shared libraries is that you have to keep
yuuji@0 1472 around a copy of the library every time something changes in
yuuji@0 1473 the library that would affect the interface the library
yuuji@0 1474 presents to the application. So, you end up having many copies
yuuji@0 1475 of the same shared library.
yuuji@0 1476
yuuji@0 1477 If you don't keep multiple copies of the shared library, then
yuuji@0 1478 one of two things happens. If there was proper versioning, then
yuuji@0 1479 you'll get a message such as "cannot open shared object file"
yuuji@0 1480 or "minor versions don't match" and the application won't run.
yuuji@0 1481 Otherwise, the application will run, but will fail in
yuuji@0 1482 mysterious ways.
yuuji@0 1483
yuuji@0 1484 Several sites and third-party distributors have modified the
yuuji@0 1485 c-client makefile in order to make c-client be a shared
yuuji@0 1486 library. When (not if) a c-client based application fails in
yuuji@0 1487 mysterious ways because of a library compatibility problem, the
yuuji@0 1488 result is a bug report. A lot of time and effort ends up
yuuji@0 1489 getting wasted investigating such bug reports.
yuuji@0 1490
yuuji@0 1491 Memory is so cheap these days that it's not worth it. Human
yuuji@0 1492 life is too short to deal with shared library compatibility
yuuji@0 1493 problems.
yuuji@0 1494 _________________________________________________________________
yuuji@0 1495
yuuji@0 1496 6.4 Why don't you use iconv() for internationalization support?
yuuji@0 1497
yuuji@0 1498 iconv() is not ubiquitous enough.
yuuji@0 1499 _________________________________________________________________
yuuji@0 1500
yuuji@0 1501 6.5 Why is the IMAP server connected to the home directory by default?
yuuji@0 1502
yuuji@0 1503 The IMAP server has no way of knowing what you might call
yuuji@0 1504 "mail" as opposed to "some other file"; in fact, you can use
yuuji@0 1505 IMAP to access any file.
yuuji@0 1506
yuuji@0 1507 The IMAP server also doesn't know whether your preferred
yuuji@0 1508 subdirectory for mailbox files is "mail/", ".mail/", "Mail/",
yuuji@0 1509 "Mailboxes/", or any of a zillion other possibilities. If one
yuuji@0 1510 such name were chosen, it would undoubtably anger the partisans
yuuji@0 1511 of all the other names.
yuuji@0 1512
yuuji@0 1513 It is possible to modify the software so that the default
yuuji@0 1514 connected directory is someplace else. Please read the file
yuuji@0 1515 CONFIG for discussion of this and other issues.
yuuji@0 1516 _________________________________________________________________
yuuji@0 1517
yuuji@0 1518 6.6 I have a Windows system. Why isn't the server plug and play for
yuuji@0 1519 me?
yuuji@0 1520
yuuji@0 1521 There is no standard for how mail is stored on Windows; nor a
yuuji@0 1522 single standard SMTP server. The closest to either would be the
yuuji@0 1523 SMTP server in Microsoft's IIS.
yuuji@0 1524
yuuji@0 1525 So there's no default by which to make assumptions. As the
yuuji@0 1526 software is set up, it assumes that the each user has an
yuuji@0 1527 Windows login account and private home directory, and that mail
yuuji@0 1528 is stored on that home directory as files in one of the popular
yuuji@0 1529 UNIX formats. It also assumes that there is some tool
yuuji@0 1530 equivalent to inetd on UNIX that does the TCP/IP listening and
yuuji@0 1531 server startup.
yuuji@0 1532
yuuji@0 1533 Basically, unless you're an email software hacker, you probably
yuuji@0 1534 want to look elsewhere if you want IMAP/POP servers for
yuuji@0 1535 Windows.
yuuji@0 1536 _________________________________________________________________
yuuji@0 1537
yuuji@0 1538 6.7 I looked at the UNIX SSL code and saw that you have the SSL data
yuuji@0 1539 payload size set to 8192 bytes. SSL allows 16K; why aren't you using
yuuji@0 1540 the full size?
yuuji@0 1541
yuuji@0 1542 This is to avoid an interoperability problem with:
yuuji@0 1543
yuuji@0 1544 + PC IMAP clients that use Microsoft's SChannel.DLL (SSPI) for
yuuji@0 1545 SSL support
yuuji@0 1546 + Microsoft Exchange server (which also uses SChannel).
yuuji@0 1547
yuuji@0 1548 SChannel has a bug that makes it think that the maximum SSL
yuuji@0 1549 data payload size is 16379 bytes -- 5 bytes too small. Thus,
yuuji@0 1550 c-client has to make sure that it never transmits full sized
yuuji@0 1551 SSL packets.
yuuji@0 1552
yuuji@0 1553 The reason for using 8K (as opposed to, say, 16379 bytes, or
yuuji@0 1554 15K, or...) is that it corresponds with the TCP buffer size
yuuji@0 1555 that the software uses elsewhere for input; there's a slight
yuuji@0 1556 performance benefit to having the two sizes correspond or at
yuuji@0 1557 least be a multiple of each other. Also, it keeps the size as a
yuuji@0 1558 power of two, which might be significant on some platforms.
yuuji@0 1559
yuuji@0 1560 There wasn't a significant difference that we could measure
yuuji@0 1561 between 8K and 15K.
yuuji@0 1562
yuuji@0 1563 Microsoft has developed a hotfix for this bug. Look up MSKB
yuuji@0 1564 article number 300562. Contrary to the article text which
yuuji@0 1565 implies that this is a Pine issue, this bug also affects
yuuji@0 1566 Microsoft Exchange server with any client that transmits
yuuji@0 1567 full-sized SSL payloads.
yuuji@0 1568 _________________________________________________________________
yuuji@0 1569
yuuji@0 1570 6.8 Why is an mh format INBOX called #mhinbox instead of just INBOX?
yuuji@0 1571
yuuji@0 1572 It's a long story. In brief, the mh format driver is less
yuuji@0 1573 functional than any of the other drivers. It turned out that
yuuji@0 1574 there were some users (including high-level administrators) who
yuuji@0 1575 tried mh years ago and no longer use it, but still had an mh
yuuji@0 1576 profile left behind.
yuuji@0 1577
yuuji@0 1578 When the mh driver used INBOX, it would see the mh profile, and
yuuji@0 1579 proceed to move the user's INBOX into the mh format INBOX. This
yuuji@0 1580 caused considerable confusion as some things stopped working.
yuuji@0 1581 _________________________________________________________________
yuuji@0 1582
yuuji@0 1583 6.9 Why don't you support the maildir format?
yuuji@0 1584
yuuji@0 1585 It is technically difficult to support maildir in IMAP while
yuuji@0 1586 maintaining acceptable performance, robustness, following the
yuuji@0 1587 requirements of the IMAP protocol specification, and following
yuuji@0 1588 the requirements of maildir.
yuuji@0 1589
yuuji@0 1590 No one has succeeded in accomplishing all four together. The
yuuji@0 1591 various maildir drivers offered as patches all have these
yuuji@0 1592 problems. The problem is exacerbated because this
yuuji@0 1593 implementation supports multiple formats; consequently this
yuuji@0 1594 implementation can't make any performance shortcuts by assuming
yuuji@0 1595 that all the world is maildir.
yuuji@0 1596
yuuji@0 1597 We can't do a better job than the maildir fan community has
yuuji@0 1598 done with their maildir drivers. Similarly, if the maildir fan
yuuji@0 1599 community provides the maildir driver, they take on the
yuuji@0 1600 responsibility for answering maildir-specific support
yuuji@0 1601 questions. This is as it should be, and that is why maildir
yuuji@0 1602 support is left to the maildir fan community.
yuuji@0 1603 _________________________________________________________________
yuuji@0 1604
yuuji@0 1605 6.10 Why don't you support the Cyrus format?
yuuji@0 1606
yuuji@0 1607 There's no point to doing so. An implementation which supports
yuuji@0 1608 multiple formats will never do as well as one which is
yuuji@0 1609 optimized to support one single format.
yuuji@0 1610
yuuji@0 1611 If you want to use Cyrus mailbox format, you should use the
yuuji@0 1612 Cyrus server, which is the native implementation of that format
yuuji@0 1613 and is specifically optimized for that format. That's also why
yuuji@0 1614 Cyrus doesn't implement any other format.
yuuji@0 1615 _________________________________________________________________
yuuji@0 1616
yuuji@0 1617 6.11 Why is it creating extra forks on my SVR4 system?
yuuji@0 1618
yuuji@0 1619 This is because your system only has fcntl() style locking and
yuuji@0 1620 not flock() style locking. fcntl() locking has a design flaw
yuuji@0 1621 that causes a close() to release any locks made by that process
yuuji@0 1622 on the file opened on that file descriptor, even if the lock
yuuji@0 1623 was made on a different file descriptor.
yuuji@0 1624
yuuji@0 1625 This design flaw causes unexpected loss of lock, and consequent
yuuji@0 1626 mailbox corruption. The workaround is to do certain "dangerous
yuuji@0 1627 operations" in another fork, thus avoiding doing a close() in
yuuji@0 1628 the vulnerable fork.
yuuji@0 1629
yuuji@0 1630 The best way to solve this problem is to upgrade your SVR4
yuuji@0 1631 (Solaris, AIX, HP-UX, SGI) or OSF/1 system to a more advanced
yuuji@0 1632 operating system, such as Linux or BSD. These more advanced
yuuji@0 1633 operating systems have fcntl() locking for compatibility with
yuuji@0 1634 SVR4, but also have flock() locking.
yuuji@0 1635
yuuji@0 1636 Beware of certain SVR4 systems, such as AIX, which have an
yuuji@0 1637 "flock()" function in their C library that is just a jacket
yuuji@0 1638 that does an fcntl() lock. This is not a true flock(), and has
yuuji@0 1639 the same design flaw as fcntl().
yuuji@0 1640 _________________________________________________________________
yuuji@0 1641
yuuji@0 1642 6.12 Why are you so fussy about the date/time format in the internal
yuuji@0 1643 "From " line in traditional UNIX mailbox files? My other mail program
yuuji@0 1644 just considers every line that starts with "From " to be the start of
yuuji@0 1645 the message.
yuuji@0 1646
yuuji@0 1647 You just answered your own question. If any line that starts
yuuji@0 1648 with "From " is treated as the start of a message, then every
yuuji@0 1649 message text line which starts with "From " has to be quoted
yuuji@0 1650 (typically by prefixing a ">" character). People complain about
yuuji@0 1651 this -- "why did a > get stuck in my message?"
yuuji@0 1652
yuuji@0 1653 So, good mail reading software only considers a line to be a
yuuji@0 1654 "From " line if it follows the actual specification for a
yuuji@0 1655 "From " line. This means, among other things, that the day of
yuuji@0 1656 week is fixed-format: "May 14", but "May 7" (note the extra
yuuji@0 1657 space) as opposed to "May 7". ctime() format for the date is
yuuji@0 1658 the most common, although POSIX also allows a numeric timezone
yuuji@0 1659 after the year. For compatibility with ancient software, the
yuuji@0 1660 seconds are optional, the timezone may appear before the year,
yuuji@0 1661 the old 3-letter timezones are also permitted, and "remote from
yuuji@0 1662 xxx" may appear after the whole thing.
yuuji@0 1663
yuuji@0 1664 Unfortunately, some software written by novices use other
yuuji@0 1665 formats. The most common error is to have a variable-width day
yuuji@0 1666 of month, perhaps in the erroneous belief that RFC 2822 (or RFC
yuuji@0 1667 822) defines the format of the date/time in the "From " line
yuuji@0 1668 (it doesn't; no RFC describes internal formats). I've seen a
yuuji@0 1669 few other goofs, such as a single-digit second, but these are
yuuji@0 1670 less common.
yuuji@0 1671
yuuji@0 1672 If you are writing your own software that writes mailbox files,
yuuji@0 1673 and you really aren't all that savvy with all the ins and outs
yuuji@0 1674 and ancient history, you should seriously consider using the
yuuji@0 1675 c-client library (e.g. routine mail_append()) instead of doing
yuuji@0 1676 the file writes yourself. If you must do it yourself, use
yuuji@0 1677 ctime(), as in:
yuuji@0 1678
yuuji@0 1679 fprintf (mbx,"From %s@%h %s",user,host,ctime (time (0)));
yuuji@0 1680
yuuji@0 1681 rather than try to figure out a good format yourself. ctime()
yuuji@0 1682 is the most traditional format and nobody will flame you for
yuuji@0 1683 using it.
yuuji@0 1684 _________________________________________________________________
yuuji@0 1685
yuuji@0 1686 6.13 Why is traditional UNIX format the default format?
yuuji@0 1687
yuuji@0 1688 Compatibility with the past 30 or so years of UNIX history.
yuuji@0 1689 This server is the only one that completely interoperates with
yuuji@0 1690 legacy UNIX mail tools.
yuuji@0 1691 _________________________________________________________________
yuuji@0 1692
yuuji@0 1693 6.14 Why do you write this "DON'T DELETE THIS MESSAGE -- FOLDER
yuuji@0 1694 INTERNAL DATA" message at the start of traditional UNIX and MMDF
yuuji@0 1695 format mailboxes?
yuuji@0 1696
yuuji@0 1697 This pseudo-message serves two purposes.
yuuji@0 1698
yuuji@0 1699 First, it establishes the mailbox format even when the mailbox
yuuji@0 1700 has no messages. Otherwise, a mailbox with no messages is a
yuuji@0 1701 zero-byte file, which could be one of several formats.
yuuji@0 1702
yuuji@0 1703 Second, it holds mailbox metadata used by IMAP: the UID
yuuji@0 1704 validity, the last assigned UID, and mailbox keywords. Without
yuuji@0 1705 this metadata, which must be preserved even when the mailbox
yuuji@0 1706 has no messages, the traditional UNIX format wouldn't be able
yuuji@0 1707 to support the full capabilities of IMAP.
yuuji@0 1708 _________________________________________________________________
yuuji@0 1709
yuuji@0 1710 6.15 Why don't you stash the mailbox metadata in the first real
yuuji@0 1711 message of the mailbox instead of writing this fake FOLDER INTERNAL
yuuji@0 1712 DATA message?
yuuji@0 1713
yuuji@0 1714 In fact, that is what is done if the mailbox is non-empty and
yuuji@0 1715 does not already have a FOLDER INTERNAL DATA message.
yuuji@0 1716
yuuji@0 1717 One problem with doing that is that if some external program
yuuji@0 1718 removes the first message, the metadata is lost and must be
yuuji@0 1719 recreated, thus losing any prior UID or keyword list status
yuuji@0 1720 that IMAP clients may depend upon.
yuuji@0 1721
yuuji@0 1722 Another problem is that this doesn't help if the last message
yuuji@0 1723 is deleted. This will result in an empty mailbox, and the
yuuji@0 1724 necessity to create a FOLDER INTERNAL DATA message.
yuuji@0 1725 _________________________________________________________________
yuuji@0 1726
yuuji@0 1727 6.16 Why aren't "dual-use" mailboxes the default?
yuuji@0 1728
yuuji@0 1729 Compatibility with the past 30 or so years of UNIX history, not
yuuji@0 1730 to mention compatibility with user expectations when using
yuuji@0 1731 shell tools.
yuuji@0 1732 _________________________________________________________________
yuuji@0 1733
yuuji@0 1734 6.17 Why do you use ucbcc to build on Solaris?
yuuji@0 1735
yuuji@0 1736 It is a long, long story about why cc is set to ucbcc. You need
yuuji@0 1737 to invoke the C compiler so that it links with the SVR4
yuuji@0 1738 libraries and not the BSD libraries, otherwise readdir() will
yuuji@0 1739 return the wrong information.
yuuji@0 1740
yuuji@0 1741 Of all the names in the most common path, ucbcc is the only
yuuji@0 1742 name to be found (on /usr/ccs/bin) that points to a suitable
yuuji@0 1743 compiler. cc is likely to be /usr/ucb/cc which is absolutely
yuuji@0 1744 not the compiler that you want. The real SVR4 cc is probably
yuuji@0 1745 something like /opt/SUNWspro/bin/cc which is rarely in anyone's
yuuji@0 1746 path by default.
yuuji@0 1747
yuuji@0 1748 ucbcc is probably a link to acc, e.g.
yuuji@0 1749 /opt/SUNWspro/SC4.0/bin/acc, and is the UCB C compiler using
yuuji@0 1750 the SVR4 libraries.
yuuji@0 1751
yuuji@0 1752 If ucbcc isn't on your system, then punt on the SUN C compiler
yuuji@0 1753 and use gcc instead (the gso port instead of the sol port).
yuuji@0 1754
yuuji@0 1755 If, in spite of all the above warnings, you choose to change
yuuji@0 1756 "ucbcc" to "cc", you will probably find that the -O2 needs to
yuuji@0 1757 be changed to -O. If you don't get any error messages with -O2,
yuuji@0 1758 that's a pretty good indicator that you goofed and are running
yuuji@0 1759 the compiler that will link with the BSD libraries.
yuuji@0 1760
yuuji@0 1761 To recap:
yuuji@0 1762
yuuji@0 1763 + The sol port is designed to be built using the UCB compiler
yuuji@0 1764 using the SVR4 libraries. This compiler is "ucbcc", which is
yuuji@0 1765 lunk to acc. You use -O2 as one of the CFLAGS.
yuuji@0 1766 + If you build the sol port with the UCB compiler using the BSD
yuuji@0 1767 libraries, you will get no error messages but you will get
yuuji@0 1768 bad binaries (the most obvious symptom is dropping the first
yuuji@0 1769 two characters return filenames from the imapd LIST command.
yuuji@0 1770 This compiler also uses -O2, and is very often what the user
yuuji@0 1771 gets from "cc". BEWARE
yuuji@0 1772 + If you build the sol port with the real SVR4 compiler, which
yuuji@0 1773 is often hidden away or unavailable on many systems, then you
yuuji@0 1774 will get errors from -O2 and you need to change that to -O.
yuuji@0 1775 But you will get a good binary. However, you should try it
yuuji@0 1776 with -O2 first, to make sure that you got this compiler and
yuuji@0 1777 not the UCB compiler using BSD libraries.
yuuji@0 1778 _________________________________________________________________
yuuji@0 1779
yuuji@0 1780 6.18 Why should I care about some old system with BSD libraries? cc is
yuuji@0 1781 the right thing on my Solaris system!
yuuji@0 1782
yuuji@0 1783 Because there still are sites that use such systems. On those
yuuji@0 1784 systems, the assumption that "cc" does the right thing will
yuuji@0 1785 lead to corrupt binaries with no error message or other warning
yuuji@0 1786 that anything is amiss.
yuuji@0 1787
yuuji@0 1788 Too many sites have fallen victim to this problem.
yuuji@0 1789 _________________________________________________________________
yuuji@0 1790
yuuji@0 1791 6.19 Why do you insist upon writing .lock files in the spool
yuuji@0 1792 directory?
yuuji@0 1793
yuuji@0 1794 Compatibility with the past 30 years of UNIX software which
yuuji@0 1795 deals with the spool directory, especially software which
yuuji@0 1796 delivers mail. Otherwise, it is possible to lose mail.
yuuji@0 1797 _________________________________________________________________
yuuji@0 1798
yuuji@0 1799 6.20 Why should I care about compatibility with the past?
yuuji@0 1800
yuuji@0 1801 This is one of those questions in which the answer never
yuuji@0 1802 convinces those who ask it. Somehow, everybody who ever asks
yuuji@0 1803 this question ends up answering it for themselves as they get
yuuji@0 1804 older, with the very answer that they rejected years earlier.
yuuji@0 1805 _________________________________________________________________
yuuji@0 1806
yuuji@0 1807 7. Problems and Annoyances
yuuji@0 1808 _________________________________________________________________
yuuji@0 1809
yuuji@0 1810 7.1 Help! My INBOX is empty! What happened to my messages?
yuuji@0 1811
yuuji@0 1812 If you are seeing "0 messages" when you open INBOX and you know
yuuji@0 1813 you have messages there (and perhaps have looked at your mail
yuuji@0 1814 spool file and see that messages are there), then probably
yuuji@0 1815 there is something wrong with the very first line of your mail
yuuji@0 1816 spool file. Make sure that the first five bytes of the file are
yuuji@0 1817 "From ", followed by an email address and a date/time in
yuuji@0 1818 ctime() format, e.g.:
yuuji@0 1819
yuuji@0 1820 From fred@foo.bar Mon May 7 20:54:30 2001
yuuji@0 1821 _________________________________________________________________
yuuji@0 1822
yuuji@0 1823 7.2 Help! All my messages in a non-INBOX mailbox have been
yuuji@0 1824 concatenated into one message which claims to be from me and has a
yuuji@0 1825 subject of the file name of the mailbox! What's going on?
yuuji@0 1826
yuuji@0 1827 Something wrong with the very first line of the mailbox. Make
yuuji@0 1828 sure that the first five bytes of the file are "From ",
yuuji@0 1829 followed by an email address and a date/time in ctime() format,
yuuji@0 1830 e.g.:
yuuji@0 1831
yuuji@0 1832 From fred@foo.bar Mon May 7 20:54:30 2001
yuuji@0 1833 _________________________________________________________________
yuuji@0 1834
yuuji@0 1835 7.3 Why do I get the message: CREATE failed: Can't create mailbox node
yuuji@0 1836 xxxxxxxxx: File exists and how do I fix it?
yuuji@0 1837
yuuji@0 1838 See the answer to the Are hierarchical mailboxes supported?
yuuji@0 1839 question.
yuuji@0 1840 _________________________________________________________________
yuuji@0 1841
yuuji@0 1842 7.4 Why can't I log in to the server? The user name and password are
yuuji@0 1843 right!
yuuji@0 1844
yuuji@0 1845 There are a myriad number of possible answers to this question.
yuuji@0 1846 The only way to say for sure what is wrong is run the server
yuuji@0 1847 under a debugger such as gdb while root (yes, you must be root)
yuuji@0 1848 with a breakpoint at routines checkpw() and loginpw(), then
yuuji@0 1849 single-step until you see which test rejected you. The server
yuuji@0 1850 isn't going to give any error messages other than "login
yuuji@0 1851 failed" in the name of not giving out any unnecessary
yuuji@0 1852 information to unauthorized individuals.
yuuji@0 1853
yuuji@0 1854 Here are some of the more common reasons why login may fail:
yuuji@0 1855
yuuji@0 1856 + You didn't really give the correct user name and/or password.
yuuji@0 1857 + Your client doesn't send the LOGIN command correctly; for
yuuji@0 1858 example, IMAP2 clients won't send a password containing a "*"
yuuji@0 1859 correctly to an IMAP4 server.
yuuji@0 1860 + If you have set up a CRAM-MD5 database, remember that the
yuuji@0 1861 password used is the one in the CRAM-MD5 database, and
yuuji@0 1862 furthermore that there must also be an entry in /etc/passwd
yuuji@0 1863 (but the /etc/passwd password is not used).
yuuji@0 1864 + If you are using PAM, have you created a service file for the
yuuji@0 1865 server in /etc/pam.d?
yuuji@0 1866 + If you are using shadow passwords, have you used an
yuuji@0 1867 appropriate port when building? In particular, note that
yuuji@0 1868 "lnx" is for Linux systems without shadow passwords; you
yuuji@0 1869 probably want "slx" or "lnp" instead.
yuuji@0 1870 + If your system has account or password expirations, check to
yuuji@0 1871 see that the expiration date hasn't passed.
yuuji@0 1872 + You can't log in as root or any other UID 0 user. This is for
yuuji@0 1873 your own safety, not to mention the fact that the servers use
yuuji@0 1874 UID 0 as meaning "not logged in".
yuuji@0 1875 _________________________________________________________________
yuuji@0 1876
yuuji@0 1877 7.5 Help! My load average is soaring and I see hundreds of POP and
yuuji@0 1878 IMAP servers, many logged in as the same user!
yuuji@0 1879
yuuji@0 1880 Certain inferior losing GUI mail reading programs have a
yuuji@0 1881 "synchronize all mailboxes at startup" (IMAP) or "check for new
yuuji@0 1882 mail every second" (POP) feature which causes a rapid and
yuuji@0 1883 unchecked spawning of servers.
yuuji@0 1884
yuuji@0 1885 This is not a problem in the server; the client is really
yuuji@0 1886 asking for all those server sessions. Unfortunately, there
yuuji@0 1887 isn't much that the POP and IMAP servers can do about it; they
yuuji@0 1888 don't spawned themselves.
yuuji@0 1889
yuuji@0 1890 Some sites have added code to record the number of server
yuuji@0 1891 sessions spawned per user per hour, and disable login for a
yuuji@0 1892 user who has exceeded a predetermined rate. This doesn't stop
yuuji@0 1893 the servers from being spawned; it just means that a server
yuuji@0 1894 session will commit suicide a bit faster.
yuuji@0 1895
yuuji@0 1896 Another possibility is to detect excessive server spawning
yuuji@0 1897 activity at the level where the server is spawned, which would
yuuji@0 1898 be inetd or possibly tcpd. The problem here is that this is a
yuuji@0 1899 hard time to quantify. 50 sessions in a minute from a
yuuji@0 1900 multi-user timesharing system may be perfectly alright, whereas
yuuji@0 1901 10 sessions a minute from a PC may be too much.
yuuji@0 1902
yuuji@0 1903 The real solution is to fix the client configuration, by
yuuji@0 1904 disabling those evil features. Also tell the vendors of those
yuuji@0 1905 clients how you feel about distributing denial-of-service
yuuji@0 1906 attack tools in the guise of mail reading programs.
yuuji@0 1907 _________________________________________________________________
yuuji@0 1908
yuuji@0 1909 7.6 Why does mail disappear even though I set "keep mail on server"?
yuuji@0 1910 7.7 Why do I get the message Moved ##### bytes of new mail to
yuuji@0 1911 /home/user/mbox from /var/spool/mail/user and why did this happen?
yuuji@0 1912
yuuji@0 1913 This is probably caused by the mbox driver. If the file "mbox"
yuuji@0 1914 exists on the user's home directory and is in UNIX mailbox
yuuji@0 1915 format, then when INBOX is opened this file will be selected as
yuuji@0 1916 INBOX instead of the mail spool file. Messages will be
yuuji@0 1917 automatically transferred from the mail spool file into the
yuuji@0 1918 mbox file.
yuuji@0 1919
yuuji@0 1920 To disable this behavior, delete "mbox" from the EXTRADRIVERS
yuuji@0 1921 list in the top-level Makefile and rebuild. Note that if you do
yuuji@0 1922 this, users won't be able to access the messages that have
yuuji@0 1923 already been moved to mbox unless they open mbox instead of
yuuji@0 1924 INBOX.
yuuji@0 1925 _________________________________________________________________
yuuji@0 1926
yuuji@0 1927 7.8 Why isn't it showing the local host name as a fully-qualified
yuuji@0 1928 domain name?
yuuji@0 1929 7.9 Why is the local host name in the From/Sender/Message-ID headers
yuuji@0 1930 of outgoing mail not coming out as a fully-qualified domain name?
yuuji@0 1931
yuuji@0 1932 Your UNIX system is misconfigured. The entry for your system in
yuuji@0 1933 /etc/hosts must have the fully-qualified domain name first,
yuuji@0 1934 e.g.
yuuji@0 1935
yuuji@0 1936 105.69.1.234 myserver.example.com myserver
yuuji@0 1937
yuuji@0 1938 A common mistake of novice system administrators is to have the
yuuji@0 1939 short name first, e.g.
yuuji@0 1940
yuuji@0 1941 105.69.1.234 myserver myserver.example.com
yuuji@0 1942
yuuji@0 1943 or to omit the fully qualified domain name entirely, e.g.
yuuji@0 1944
yuuji@0 1945 105.69.1.234 myserver
yuuji@0 1946
yuuji@0 1947 The result of this is that when the IMAP toolkit does a
yuuji@0 1948 gethostbyname() call to get the fully-qualified domain name, it
yuuji@0 1949 would get "myserver" instead of "myserver.example.com".
yuuji@0 1950
yuuji@0 1951 On some systems, a configuration file (typically named
yuuji@0 1952 /etc/svc.conf, /etc/netsvc.conf, or /etc/nsswitch.conf) can be
yuuji@0 1953 used to configure the system to use the domain name system
yuuji@0 1954 (DNS) instead of /etc/hosts, so it doesn't matter if /etc/hosts
yuuji@0 1955 is misconfigured.
yuuji@0 1956
yuuji@0 1957 Check the man pages for gethostbyname, hosts, svc, and/or
yuuji@0 1958 netsvc for more information.
yuuji@0 1959
yuuji@0 1960 Unfortunately, certain vendors, most notably SUN, have failed
yuuji@0 1961 to make this clear in their documentation. Most of SUN's
yuuji@0 1962 documentation assumes a corporate network that is not connected
yuuji@0 1963 to the Internet.
yuuji@0 1964
yuuji@0 1965 net.folklore once (late 1980s) held that the proper procedure
yuuji@0 1966 was to append the results of getdomainname() to the name
yuuji@0 1967 returned by gethostname(), and some versions of sendmail
yuuji@0 1968 configuration files were distributed that did this. This was
yuuji@0 1969 incorrect; the string returned from getdomainname() is the
yuuji@0 1970 Yellow Pages (a.k.a NIS) domain name, which is a completely
yuuji@0 1971 different (albeit unfortunately named) entity from an Internet
yuuji@0 1972 domain. These were often fortuitously the same string, except
yuuji@0 1973 when they weren't. Frequently, this would result in host names
yuuji@0 1974 with spuriously doubled domain names, e.g.
yuuji@0 1975
yuuji@0 1976 myserver.example.com.example.com
yuuji@0 1977
yuuji@0 1978 This practice has been thoroughly discredited for many years,
yuuji@0 1979 but folklore dies hard.
yuuji@0 1980 _________________________________________________________________
yuuji@0 1981
yuuji@0 1982 7.10 What does the message: Mailbox vulnerable - directory
yuuji@0 1983 /var/spool/mail must have 1777 protection mean? How can I fix this?
yuuji@0 1984
yuuji@0 1985 In order to update a mailbox in the default UNIX format, it is
yuuji@0 1986 necessary to create a lock file to prevent the mailer from
yuuji@0 1987 delivering mail while an update is in progress. Some systems
yuuji@0 1988 use a directory protection of 775, requiring that all mail
yuuji@0 1989 handling programs be setgid mail; or of 755, requiring that all
yuuji@0 1990 mail handling programs be setuid root.
yuuji@0 1991
yuuji@0 1992 The IMAP toolkit does not run with any special privileges, and
yuuji@0 1993 I plan to keep it that way. It is antithetical to the concept
yuuji@0 1994 of a toolkit if users can't write their own programs to use it.
yuuji@0 1995 Also, I've had enough bad experiences with security bugs while
yuuji@0 1996 running privileged; the IMAP and POP servers have to be root
yuuji@0 1997 when not logged in, in order to be able to log themselves in. I
yuuji@0 1998 don't want to go any deeper down that slippery slope.
yuuji@0 1999
yuuji@0 2000 Directory protection 1777 is secure enough on most well-managed
yuuji@0 2001 systems. If you can't trust your users with a 1777 mail spool
yuuji@0 2002 (petty harassment is about the limit of the abuse exposure),
yuuji@0 2003 then you have much worse problems then that.
yuuji@0 2004
yuuji@0 2005 If you absolutely insist upon requiring privileges to create a
yuuji@0 2006 lock file, external file locking can be done via a setgid mail
yuuji@0 2007 program named /etc/mlock (this is defined by LOCKPGM in the
yuuji@0 2008 c-client Makefile). If the toolkit is unable to create a
yuuji@0 2009 <...mailbox...>.lock file in the directory by itself, it will
yuuji@0 2010 try to call mlock to do it. I do not recommend doing this for
yuuji@0 2011 performance reasons.
yuuji@0 2012
yuuji@0 2013 A sample mlock program is included as part of imap-2007. We
yuuji@0 2014 have tried to make this sample program secure, but it has not
yuuji@0 2015 been thoroughly audited.
yuuji@0 2016 _________________________________________________________________
yuuji@0 2017
yuuji@0 2018 7.11 What does the message: Mailbox is open by another process, access
yuuji@0 2019 is readonly mean? How do I fix this?
yuuji@0 2020
yuuji@0 2021 A problem occurred in applying a lock to a /tmp lock file.
yuuji@0 2022 Either some other program has the mailbox open and won't
yuuji@0 2023 relenquish it, or something is wrong with the protection of
yuuji@0 2024 /tmp or the lock.
yuuji@0 2025
yuuji@0 2026 Make sure that the /tmp directory is protected 1777. Some
yuuji@0 2027 security scripts incorrectly set the protection of the /tmp
yuuji@0 2028 directory to 775, which disables /tmp for all non-privileged
yuuji@0 2029 programs.
yuuji@0 2030 _________________________________________________________________
yuuji@0 2031
yuuji@0 2032 7.12 What does the message: Can't get write access to mailbox, access
yuuji@0 2033 is readonly mean?
yuuji@0 2034
yuuji@0 2035 The mailbox file is write-protected against you.
yuuji@0 2036 _________________________________________________________________
yuuji@0 2037
yuuji@0 2038 7.13 I set my POP3 client to "delete messages from server" but they
yuuji@0 2039 never get deleted. What is wrong?
yuuji@0 2040
yuuji@0 2041 Make sure that your mailbox is not read-only: that the mailbox
yuuji@0 2042 is owned by you and write enabled (protection 0600), and that
yuuji@0 2043 the /tmp directory is longer world-writeable. /tmp must be
yuuji@0 2044 world-writeable because lots of applications use it for scratch
yuuji@0 2045 space. To fix this, do
yuuji@0 2046
yuuji@0 2047
yuuji@0 2048 chmod 1777 /tmp
yuuji@0 2049
yuuji@0 2050 as root.
yuuji@0 2051
yuuji@0 2052 Make sure that your POP3 client issues a QUIT command when it
yuuji@0 2053 finishes. The POP3 protocol specifies that deletions are
yuuji@0 2054 discarded unless a proper QUIT is done.
yuuji@0 2055
yuuji@0 2056 Make sure that you are not opening multiple POP3 sessions to
yuuji@0 2057 the same mailbox. It is a requirement of the POP3 protocol than
yuuji@0 2058 only one POP3 session be in effect to a mailbox at a time,
yuuji@0 2059 however some, poorly-written POP3 clients violate this. Also,
yuuji@0 2060 some background "check for new mail" tasks also cause a
yuuji@0 2061 violation. See the answer to the What does the syslog message:
yuuji@0 2062 Killed (lost mailbox lock) user=... host=... mean? question for
yuuji@0 2063 more details.
yuuji@0 2064 _________________________________________________________________
yuuji@0 2065
yuuji@0 2066 7.14 What do messages such as:
yuuji@0 2067 Message ... UID ... already has UID ...
yuuji@0 2068 Message ... UID ... less than ...
yuuji@0 2069 Message ... UID ... greater than last ...
yuuji@0 2070 Invalid UID ... in message ..., rebuilding UIDs
yuuji@0 2071
yuuji@0 2072 mean?
yuuji@0 2073
yuuji@0 2074 Something happened to corrupt the unique identifier regime in
yuuji@0 2075 the mailbox. In traditional UNIX-format mailboxes, this can
yuuji@0 2076 happen if the user deleted the "DO NOT DELETE" internal
yuuji@0 2077 message.
yuuji@0 2078
yuuji@0 2079 This problem is relatively harmless; a new valid unique
yuuji@0 2080 identifier regime will be created. The main effect is that any
yuuji@0 2081 references to the old UIDs will no longer be useful.
yuuji@0 2082
yuuji@0 2083 So, unless it is a chronic problem or you feel like debugging,
yuuji@0 2084 you can safely ignore these messages.
yuuji@0 2085 _________________________________________________________________
yuuji@0 2086
yuuji@0 2087 7.15 What do the error messages:
yuuji@0 2088 Unable to read internal header at ...
yuuji@0 2089 Unable to find CRLF at ...
yuuji@0 2090 Unable to parse internal header at ...
yuuji@0 2091 Unable to parse message date at ...
yuuji@0 2092 Unable to parse message flags at ...
yuuji@0 2093 Unable to parse message UID at ...
yuuji@0 2094 Unable to parse message size at ...
yuuji@0 2095 Last message (at ... ) runs past end of file ...
yuuji@0 2096
yuuji@0 2097 mean? I am using mbx format.
yuuji@0 2098
yuuji@0 2099 The mbx-format mailbox is corrupted and needs to be repaired.
yuuji@0 2100
yuuji@0 2101 You should make an effort to find out why the corruption
yuuji@0 2102 happened. Was there an obvious system problem (crash or disk
yuuji@0 2103 failure)? Did the user accidentally access the file via NFS?
yuuji@0 2104 Mailboxes don't get corrupted by themselves; something caused
yuuji@0 2105 the problem.
yuuji@0 2106
yuuji@0 2107 Some people have developed automated scripts, but if you're
yuuji@0 2108 comfortable using emacs it's pretty easy to fix it manually. Do
yuuji@0 2109 not use vi or any other editor unless you are certain that
yuuji@0 2110 editor can handle binary!!!
yuuji@0 2111
yuuji@0 2112 If you are not comfortable with emacs, or if the file is too
yuuji@0 2113 large to read with emacs, see the "step-by-step" technique
yuuji@0 2114 later on for another way of doing it.
yuuji@0 2115
yuuji@0 2116 After the word "at" in the error message is the byte position
yuuji@0 2117 it got to when it got unhappy with the file, e.g. if you see:
yuuji@0 2118
yuuji@0 2119 Unable to parse internal header at 43921: ne bombastic blurdybloop
yuuji@0 2120
yuuji@0 2121 The problem occurs at the 43,931 byte in the file. That's the
yuuji@0 2122 point you need to fix. c-client is expecting an internal header
yuuji@0 2123 at that byte number, looking something like:
yuuji@0 2124
yuuji@0 2125 6-Jan-1998 17:42:24 -0800,1045;000000100001-00000001
yuuji@0 2126
yuuji@0 2127 The format of this internal line is:
yuuji@0 2128
yuuji@0 2129 dd-mmm-yyyy hh:mm:ss +zzzz,ssss;ffffffffFFFF-UUUUUUUU
yuuji@0 2130
yuuji@0 2131 The only thing that is variable is the "ssss" field, it can be
yuuji@0 2132 as many digits as needed. All other fields (inluding the "dd")
yuuji@0 2133 are fixed width. So, the easiest thing to do is to look forward
yuuji@0 2134 in the file for the next internal header, and delete everything
yuuji@0 2135 from the error point to that internal header.
yuuji@0 2136
yuuji@0 2137 Here's what to do if you want to be smarter and do a little bit
yuuji@0 2138 more work. Generally, you're in the middle of a message, and
yuuji@0 2139 there's nothing wrong with that message. The problem happened
yuuji@0 2140 in the *previous* message. So, search back to the previous
yuuji@0 2141 internal header. Now, remember that "ssss" field? That's the
yuuji@0 2142 size of that message.
yuuji@0 2143
yuuji@0 2144 Mark where you are in the file, move the cursor to the line
yuuji@0 2145 after the internal header, and skip that many bytes ("ssss")
yuuji@0 2146 forward. If you're at the point of the error in the file, then
yuuji@0 2147 that message is corrupt. If you're at a different point, then
yuuji@0 2148 perhaps the previous message is corrupt and has a too long size
yuuji@0 2149 count that "ate" into this message.
yuuji@0 2150
yuuji@0 2151 Basically, what you need to do is make sure that all those size
yuuji@0 2152 counts are right, and that moving "ssss" bytes from the line
yuuji@0 2153 after the internal header will land you at another internal
yuuji@0 2154 header.
yuuji@0 2155
yuuji@0 2156 Usually, once you know what you're looking at, it's pretty easy
yuuji@0 2157 to work out the corruption, and the best remedial action.
yuuji@0 2158 Repair scripts will make the problem go away but may not always
yuuji@0 2159 do the smartest/best salvage of the user's data. Manual repair
yuuji@0 2160 is more flexible and usually preferable.
yuuji@0 2161
yuuji@0 2162 Here is a step-by-step technique for fixing corrupt mbx files
yuuji@0 2163 that's a bit cruder than the procedure outlined above, but
yuuji@0 2164 works for any size file.
yuuji@0 2165
yuuji@0 2166 In this example, suppose that the corrupt file is INBOX, the
yuuji@0 2167 error message is
yuuji@0 2168
yuuji@0 2169 Unable to find CRLF at 132551754
yuuji@0 2170
yuuji@0 2171 and the size of the INBOX file is 132867870 bytes.
yuuji@0 2172
yuuji@0 2173 The first step is to split the mailbox file at the point of the
yuuji@0 2174 error:
yuuji@0 2175
yuuji@0 2176 + Rename the INBOX file to some other name, such as INBOX.bad.
yuuji@0 2177 + Copy the first 132,551,754 bytes of INBOX.bad to another
yuuji@0 2178 file, such as INBOX.new.
yuuji@0 2179 + Extract the trailing 316,116 bytes (132867870-132551754) of
yuuji@0 2180 INBOX.bad into another file, such as INBOX.tail.
yuuji@0 2181 + You no longer need INBOX.bad. Delete it.
yuuji@0 2182
yuuji@0 2183 In other words, use the number from the "Unable to find CRLF
yuuji@0 2184 at" as the point to split INBOX into two new files, INBOX.new
yuuji@0 2185 and INBOX.tail.
yuuji@0 2186
yuuji@0 2187 Now, remove the erroneous data:
yuuji@0 2188
yuuji@0 2189 + Verify that you can open INBOX.new in IMAP or Pine.
yuuji@0 2190 + The last message of INBOX.new is probably corrupted. Copy it
yuuji@0 2191 to another file, such as badmsg.1, then delete and expunge
yuuji@0 2192 that last message from INBOX.new
yuuji@0 2193 + Locate the first occurance of text in INBOX.tail which looks
yuuji@0 2194 like an internal header, as described above.
yuuji@0 2195 + Remove all the text which occurs prior to that point, and
yuuji@0 2196 place it into another file, such as badmsg.2. Note that in
yuuji@0 2197 the case of a single digit date, there is a leading space
yuuji@0 2198 which must not be removed (e.g. " 6-Nov-2001" not
yuuji@0 2199 "6-Nov-2001").
yuuji@0 2200
yuuji@0 2201 Reassemble the mailbox:
yuuji@0 2202
yuuji@0 2203 + Append INBOX.tail to INBOX.new.
yuuji@0 2204 + You no longer need INBOX.tail. Delete it.
yuuji@0 2205 + Verify that you can open INBOX.new in IMAP or Pine.
yuuji@0 2206
yuuji@0 2207 Reinstall INBOX.new as INBOX:
yuuji@0 2208
yuuji@0 2209 + Check to see if you have received any new messages while
yuuji@0 2210 repairing INBOX.
yuuji@0 2211 + If you haven't received any new messages while repairing
yuuji@0 2212 INBOX, just rename INBOX.new to INBOX.
yuuji@0 2213 + If you have received new messages, be sure to copy the new
yuuji@0 2214 messages from INBOX to INBOX.new before doing the rename.
yuuji@0 2215
yuuji@0 2216 You now have a working INBOX, as well as two files with
yuuji@0 2217 corrupted data (badmsg.1 and badmsg.2). There may be some
yuuji@0 2218 useful data in the two badmsg files that you might want to try
yuuji@0 2219 salvaging; otherwise you can delete the two badmsg files.
yuuji@0 2220 _________________________________________________________________
yuuji@0 2221
yuuji@0 2222 7.16 What do the syslog messages:
yuuji@0 2223
yuuji@0 2224 imap/tcp server failing (looping)
yuuji@0 2225 pop3/tcp server failing (looping)
yuuji@0 2226
yuuji@0 2227 mean? When it happens, the listed service shuts down. How can I fix
yuuji@0 2228 this?
yuuji@0 2229
yuuji@0 2230 The error message "server failing (looping), service
yuuji@0 2231 terminated" is not from either the IMAP or POP servers.
yuuji@0 2232 Instead, it comes from inetd, the daemon which listens for TCP
yuuji@0 2233 connections to a number of servers, including the IMAP and POP
yuuji@0 2234 servers.
yuuji@0 2235
yuuji@0 2236 inetd has a limit of 40 new server sessions per minute for any
yuuji@0 2237 particular service. If more than 40 sessions are initiated in a
yuuji@0 2238 minute, inetd will issue the "failing (looping), service
yuuji@0 2239 terminated" message and shut down the service for 10 minutes.
yuuji@0 2240 inetd does this to prevent system resource consumption by a
yuuji@0 2241 client which is spawning infinite numbers of servers. It should
yuuji@0 2242 be noted that this is a denial of service; however for some
yuuji@0 2243 systems the alternative is a crash which would be a worse
yuuji@0 2244 denial of service!
yuuji@0 2245
yuuji@0 2246 For larger server systems, the limit of 40 is much too low. The
yuuji@0 2247 limit was established many years ago when a system typically
yuuji@0 2248 only ran a few dozen servers.
yuuji@0 2249
yuuji@0 2250 On some versions of inetd, such as the one distributed with
yuuji@0 2251 most versions of Linux, you can modify the /etc/inetd.conf file
yuuji@0 2252 to have a larger number of servers by appending a period
yuuji@0 2253 followed by a number after the nowait word for the server
yuuji@0 2254 entry. For example, if your existing /etc/inetd.conf line
yuuji@0 2255 reads:
yuuji@0 2256
yuuji@0 2257 imap stream tcp nowait root /usr/etc/imapd imapd
yuuji@0 2258
yuuji@0 2259 try changing it to be:
yuuji@0 2260
yuuji@0 2261 imap stream tcp nowait.100 root /usr/etc/imapd imapd
yuuji@0 2262
yuuji@0 2263 Another example (using TCP wrappers):
yuuji@0 2264
yuuji@0 2265 imap stream tcp nowait root /usr/sbin/tcpd imapd
yuuji@0 2266
yuuji@0 2267 try changing it to be:
yuuji@0 2268
yuuji@0 2269 imap stream tcp nowait.100 root /usr/sbin/tcpd imapd
yuuji@0 2270
yuuji@0 2271 to increase the limit to 100 sessions/minute.
yuuji@0 2272
yuuji@0 2273 Before making this change, please read the information in "man
yuuji@0 2274 inetd" to determine whether or not your inetd has this feature.
yuuji@0 2275 If it does not, and you make this change, the likely outcome is
yuuji@0 2276 that you will disable IMAP service entirely.
yuuji@0 2277
yuuji@0 2278 Another way to fix this problem is to edit the inetd.c source
yuuji@0 2279 code (provided by your UNIX system vendor) to set higher
yuuji@0 2280 limits, rebuild inetd, install the new binary, and reboot your
yuuji@0 2281 system. This should only be done by a UNIX system expert. In
yuuji@0 2282 the inetd.c source code, the limits TOOMANY (normally 40) is
yuuji@0 2283 the maximum number of new server sessions permitted per minute,
yuuji@0 2284 and RETRYTIME (normally 600) is the number of seconds inetd
yuuji@0 2285 will shut down the server after it exceeds TOOMANY.
yuuji@0 2286 _________________________________________________________________
yuuji@0 2287
yuuji@0 2288 7.17 What does the syslog message: Mailbox lock file /tmp/.600.1df3
yuuji@0 2289 open failure: Permission denied mean?
yuuji@0 2290
yuuji@0 2291 This usually means that some "helpful" security script person
yuuji@0 2292 has protected /tmp so that it is no longer world-writeable.
yuuji@0 2293 /tmp must be world-writeable because lots of applications use
yuuji@0 2294 it for scratch space. To fix this, do
yuuji@0 2295
yuuji@0 2296 chmod 1777 /tmp
yuuji@0 2297
yuuji@0 2298 as root.
yuuji@0 2299
yuuji@0 2300 If that isn't the answer, check the protection of the named
yuuji@0 2301 file. If it is something other than 666, then either someone is
yuuji@0 2302 hacking or some "helpful" person modified the code to have a
yuuji@0 2303 different default lock file protection.
yuuji@0 2304 _________________________________________________________________
yuuji@0 2305
yuuji@0 2306 7.18 What do the syslog messages:
yuuji@0 2307 Command stream end of file, while reading line user=... host=...
yuuji@0 2308 Command stream end of file, while reading char user=... host=...
yuuji@0 2309 Command stream end of file, while writing text user=... host=...
yuuji@0 2310
yuuji@0 2311 mean?
yuuji@0 2312
yuuji@0 2313 This message occurs when the session is disconnected without a
yuuji@0 2314 proper LOGOUT (IMAP) or QUIT (POP) command being received by
yuuji@0 2315 the server first.
yuuji@0 2316
yuuji@0 2317 In many cases, this is perfectly normal; many client
yuuji@0 2318 implementations are impolite and do this. Some programmers
yuuji@0 2319 think this sort of rudeness is "more efficient".
yuuji@0 2320
yuuji@0 2321 The condition could, however, indicate a client or network
yuuji@0 2322 connectivity problem. The server has no way of knowing whether
yuuji@0 2323 there's a problem or just a rude client, so it issues this
yuuji@0 2324 message instead of a Logout.
yuuji@0 2325
yuuji@0 2326 Certain inferior losing clients disconnect abruptly after a
yuuji@0 2327 failed login, and instead of saying that the login failed, just
yuuji@0 2328 say that they can't access the mailbox. They then complain to
yuuji@0 2329 the system manager, who looks in the syslog and finds this
yuuji@0 2330 message. Not very helpful, eh? See the answer to the Why can't
yuuji@0 2331 I log in to the server? The user name and password are right!
yuuji@0 2332 question.
yuuji@0 2333
yuuji@0 2334 If the user isn't reporting a problem, you can probably ignore
yuuji@0 2335 this message.
yuuji@0 2336 _________________________________________________________________
yuuji@0 2337
yuuji@0 2338 7.19 Why did my POP or IMAP session suddenly disconnect? The syslog
yuuji@0 2339 has the message: Killed (lost mailbox lock) user=... host=...
yuuji@0 2340
yuuji@0 2341 This message only happens when either the traditional UNIX
yuuji@0 2342 mailbox format or MMDF format is in use. This format only
yuuji@0 2343 allows one session to have the mailbox open read/write at a
yuuji@0 2344 time.
yuuji@0 2345
yuuji@0 2346 The servers assume that if a second session attempts to open
yuuji@0 2347 the mailbox, that means that the first session is probably
yuuji@0 2348 owned by an abandoned client. The common scenario here is a
yuuji@0 2349 user who leaves his client running at the office, and then
yuuji@0 2350 tries to read his mail from home. Through an internal mechanism
yuuji@0 2351 called kiss of death, the second session requests the first
yuuji@0 2352 session to kill itself. When the first session receives the
yuuji@0 2353 "kiss of death", it issues the "Killed (lost mailbox lock)"
yuuji@0 2354 syslog message and terminates. The second session then seizes
yuuji@0 2355 read/write access, and becomes the new "first" session.
yuuji@0 2356
yuuji@0 2357 Certain poorly-designed clients routinely open multiple
yuuji@0 2358 sessions to the same mailbox; the users of those clients tend
yuuji@0 2359 to get this message a lot.
yuuji@0 2360
yuuji@0 2361 Another cause of this message is a background "check for new
yuuji@0 2362 mail" task which does its work by opening a POP session to
yuuji@0 2363 server every few seconds. They do this because POP doesn't have
yuuji@0 2364 a way to announce new mail.
yuuji@0 2365
yuuji@0 2366 The solution to both situations is to replace the client with a
yuuji@0 2367 good online IMAP client such as Pine. Life is too short to
yuuji@0 2368 waste on POP clients and poorly-designed IMAP clients.
yuuji@0 2369 _________________________________________________________________
yuuji@0 2370
yuuji@0 2371 7.20 Why does my IMAP client show all the files on the system,
yuuji@0 2372 recursively from the UNIX root directory?
yuuji@0 2373 7.21 Why does my IMAP client show all of my files, recursively from my
yuuji@0 2374 UNIX home directory?
yuuji@0 2375
yuuji@0 2376 A well-written client should only show one level of hierarchy
yuuji@0 2377 and then stop, awaiting explicit user action before going
yuuji@0 2378 lower. However, some poorly-designed clients will recursively
yuuji@0 2379 list all files, which may be a very long list (especially if
yuuji@0 2380 you have symbolic links to directories that create a loop in
yuuji@0 2381 the filesystem graph!).
yuuji@0 2382
yuuji@0 2383 This behavior has also been observed in some third-party
yuuji@0 2384 c-client drivers, including maildir drivers. Consequently, this
yuuji@0 2385 problem has even been observed in Pine. It is important to
yuuji@0 2386 understand that this is not a problem in Pine or c-client; it
yuuji@0 2387 is a problem in the third-party driver. A Pine built without
yuuji@0 2388 that third-party driver will not have this problem.
yuuji@0 2389
yuuji@0 2390 See also the answer to Why does my IMAP client show all my
yuuji@0 2391 files in my home directory?
yuuji@0 2392 _________________________________________________________________
yuuji@0 2393
yuuji@0 2394 7.22 Why does my IMAP client show that I have mailboxes named
yuuji@0 2395 "#mhinbox", "#mh", "#shared", "#ftp", "#news", and "#public"?
yuuji@0 2396
yuuji@0 2397 These are IMAP namespace names. They represent other
yuuji@0 2398 hierarchies in which messages may exist. These hierarchies may
yuuji@0 2399 not necessarily exist on a server, but the namespace name is
yuuji@0 2400 still in the namespace list in order to mark it as reserved.
yuuji@0 2401
yuuji@0 2402 A few poorly-designed clients display all namespace names as if
yuuji@0 2403 they were top-level mailboxes in a user's list of mailboxes,
yuuji@0 2404 whether or not they actually exist. This is a flaw in those
yuuji@0 2405 clients.
yuuji@0 2406 _________________________________________________________________
yuuji@0 2407
yuuji@0 2408 7.23 Why does my IMAP client show all my files in my home directory?
yuuji@0 2409
yuuji@0 2410 As distributed, the IMAP server is connected to your home
yuuji@0 2411 directory by default. It has no way of knowing what you might
yuuji@0 2412 call "mail" as opposed to "some other file"; in fact, you can
yuuji@0 2413 use IMAP to access any file.
yuuji@0 2414
yuuji@0 2415 Most clients have an option to configure your connected
yuuji@0 2416 directory on the IMAP server. For example, in Pine you can
yuuji@0 2417 specify this as the "Path" in your folder-collection, e.g.
yuuji@0 2418
yuuji@0 2419 Nickname : Secondary Folders
yuuji@0 2420 Server : imap.example.com
yuuji@0 2421 Path : mail/
yuuji@0 2422 View :
yuuji@0 2423
yuuji@0 2424 In this example, the user is connected to the "mail"
yuuji@0 2425 subdirectory of his home directory.
yuuji@0 2426
yuuji@0 2427 Other servers call this the "folder prefix" or similar term.
yuuji@0 2428
yuuji@0 2429 It is possible to modify the IMAP server so that all users are
yuuji@0 2430 automatically connected to some other directory, e.g. a
yuuji@0 2431 subdirectory of the user's home directory. Read the file CONFIG
yuuji@0 2432 for more details.
yuuji@0 2433 _________________________________________________________________
yuuji@0 2434
yuuji@0 2435 7.24 Why is there a long delay before I get connected to the IMAP or
yuuji@0 2436 POP server, no matter what client I use?
yuuji@0 2437
yuuji@0 2438 There are two common occurances of this problem:
yuuji@0 2439
yuuji@0 2440 + You are running a system (e.g. certain versions of Linux)
yuuji@0 2441 which by default attempts to connect to an "IDENT" protocol
yuuji@0 2442 (port 113) server on your client. However, a firewall or NAT
yuuji@0 2443 box is blocking connections to that port, so the connection
yuuji@0 2444 attempt times out.
yuuji@0 2445 The IDENT protocol is a well-known bad idea that does not
yuuji@0 2446 deliver any real security but causes incredible problems. The
yuuji@0 2447 idea is that this will give the server a record of the user
yuuji@0 2448 name, or at least what some program listening on port 113
yuuji@0 2449 says is the user name. So, if somebody coming from port nnnnn
yuuji@0 2450 on a system does something bad, IDENT may give you the userid
yuuji@0 2451 of the bad guy.
yuuji@0 2452 The problem is, IDENT is only meaningful on a timesharing
yuuji@0 2453 system which has an administrator who is privileged and users
yuuji@0 2454 who are not. It is of no value on a personal system which has
yuuji@0 2455 no separate concept of "system administrator" vs.
yuuji@0 2456 "unprivileged user".
yuuji@0 2457 On either type of system, security-minded people either turn
yuuji@0 2458 IDENT off or replace it with an IDENT server that lies. Among
yuuji@0 2459 other things, IDENT gives spammers the ability to harvest
yuuji@0 2460 email addresses from anyone who connects to a web page.
yuuji@0 2461 This problem has been showing up quite frequently on systems
yuuji@0 2462 which use xinetd instead of inetd. Look for files named
yuuji@0 2463 /etc/xinetd.conf, /etc/xinetd.d/imapd, /etc/inetd.d/ipop2d,
yuuji@0 2464 and /etc/xinetd.d/ipop3d. In those files, look for lines
yuuji@0 2465 containing "USERID", e.g.
yuuji@0 2466 log_on_success += USERID
yuuji@0 2467 Hunt down such lines, and delete them ruthlessly from all
yuuji@0 2468 files in which they occur. Don't be shy about it.
yuuji@0 2469 + The DNS is taking a long time to do a reverse DNS (PTR
yuuji@0 2470 record) lookup of the IP address of your client. This is a
yuuji@0 2471 problem in your DNS, which either you or you ISP need to
yuuji@0 2472 resolve. Ideally, the DNS should return the client's name;
yuuji@0 2473 but if it can't it should at least return an error quickly.
yuuji@0 2474
yuuji@0 2475 As you may have noticed, neither of these are actual problems
yuuji@0 2476 in the IMAP or POP servers; they are configuration issues with
yuuji@0 2477 either your system or your network infrastructure. If this is
yuuji@0 2478 all new to you, run (don't walk) to the nearest technical
yuuji@0 2479 bookstore and get yourself a good pedagogical text on system
yuuji@0 2480 administration for the type of system you are running.
yuuji@0 2481 _________________________________________________________________
yuuji@0 2482
yuuji@0 2483 7.25 Why is there a long delay in Pine or any other c-client based
yuuji@0 2484 application call before I get connected to the IMAP server? The hang
yuuji@0 2485 seems to be in the c-client mail_open() call. I don't have this
yuuji@0 2486 problem with any other IMAP client. There is no delay connecting to a
yuuji@0 2487 POP3 or NNTP server with mail_open().
yuuji@0 2488
yuuji@0 2489 By default, the c-client library attempts to make a connection
yuuji@0 2490 through rsh (and ssh, if you enable that). If the command:
yuuji@0 2491
yuuji@0 2492 rsh imapserver exec /etc/rimapd
yuuji@0 2493
yuuji@0 2494 (or ssh if that is enabled) returns with a "* PREAUTH"
yuuji@0 2495 response, it will use the resulting rsh session as the IMAP
yuuji@0 2496 session and not require an authentication step on the server.
yuuji@0 2497
yuuji@0 2498 Unfortunately, rsh has a design error that treats "TCP
yuuji@0 2499 connection refused" as "temporary failure, try again"; it
yuuji@0 2500 expects the "rsh not allowed" case to be implemented as a
yuuji@0 2501 successful connection followed by an error message and close
yuuji@0 2502 the connection.
yuuji@0 2503
yuuji@0 2504 It must be emphasized that this is a bug in rsh. It is not a
yuuji@0 2505 bug in the IMAP toolkit.
yuuji@0 2506
yuuji@0 2507 The use of rsh can be disabled in any the following ways:
yuuji@0 2508
yuuji@0 2509 + You can disable it for this particular session by either:
yuuji@0 2510 o setting an explicit port number in the mailbox name,
yuuji@0 2511 e.g.
yuuji@0 2512 {imapserver.foo.com:143}INBOX
yuuji@0 2513 o using SSL (the /ssl switch)
yuuji@0 2514 + You can disable rsh globally by setting the rsh timeout value
yuuji@0 2515 to 0 with the call:
yuuji@0 2516 mail_parameters (NIL,SET_RSHTIMEOUT,0);
yuuji@0 2517 _________________________________________________________________
yuuji@0 2518
yuuji@0 2519 7.26 Why does a message sometimes get split into two or more messages
yuuji@0 2520 on my SUN system?
yuuji@0 2521
yuuji@0 2522 This is caused by an interaction of two independent design
yuuji@0 2523 problems in SUN mail software. The first problem is that the
yuuji@0 2524 "forward message" option in SUN's mail tool program includes
yuuji@0 2525 the internal "From " header line in the text that it forwarded.
yuuji@0 2526 This internal header line is specific to traditional UNIX
yuuji@0 2527 mailbox files and is not suitable for use in forwarded
yuuji@0 2528 messages.
yuuji@0 2529
yuuji@0 2530 The second problem is that the mail delivery agent assumes that
yuuji@0 2531 mail reading programs will not use the traditional UNIX mailbox
yuuji@0 2532 format but instead an incompatible variant that depends upon a
yuuji@0 2533 Content-Length: message header. Content-Length is widely
yuuji@0 2534 recognized to have been a terrible mistake, and is no longer
yuuji@0 2535 recommended for use in mail (it is used in other facilities
yuuji@0 2536 that use MIME).
yuuji@0 2537
yuuji@0 2538 One symptom of the problem is that under certain circumstances,
yuuji@0 2539 a message may get broken up into several messages. I'm also
yuuji@0 2540 aware of security bugs caused by programs that foolishly trust
yuuji@0 2541 "Content-Length:" headers with evil values.
yuuji@0 2542
yuuji@0 2543 To fix the mailer on your system, edit your sendmail.cf to
yuuji@0 2544 change the Mlocal line to have the -E flag. A typical entry
yuuji@0 2545 will lool like:
yuuji@0 2546
yuuji@0 2547 Mlocal, P=/usr/lib/mail.local, F=flsSDFMmnPE, S=10, R=20,
yuuji@0 2548 A=mail.local -d $u
yuuji@0 2549
yuuji@0 2550 This fix will also work around the problem with mail tool,
yuuji@0 2551 because it will insert a ">" before the internal header line to
yuuji@0 2552 prevent it from being interpreted by mail reading software as
yuuji@0 2553 an internal header line.
yuuji@0 2554 _________________________________________________________________
yuuji@0 2555
yuuji@0 2556 7.27 Why did my POP or IMAP session suddenly disconnect? The syslog
yuuji@0 2557 has the message:
yuuji@0 2558 Autologout user=<...my user name...> host=<...my client system...>
yuuji@0 2559
yuuji@0 2560 This is a problem in your client.
yuuji@0 2561
yuuji@0 2562 In the case of IMAP, it failed to communicate with the IMAP
yuuji@0 2563 server for over 30 minutes; in the case of POP, it failed to
yuuji@0 2564 communicate with the POP server for over 10 minutes.
yuuji@0 2565 _________________________________________________________________
yuuji@0 2566
yuuji@0 2567 7.28 What does the UNIX error message: TLS/SSL failure: myserver: SSL
yuuji@0 2568 negotiation failed mean?
yuuji@0 2569 7.29 What does the PC error message: TLS/SSL failure: myserver:
yuuji@0 2570 Unexpected TCP input disconnect mean?
yuuji@0 2571
yuuji@0 2572 This usually means that an attempt to negotiate TLS encryption
yuuji@0 2573 via the STARTTLS command failed, because the server advertises
yuuji@0 2574 STARTTLS functionality, but doesn't actually have it (e.g.
yuuji@0 2575 because no certificates are installed).
yuuji@0 2576
yuuji@0 2577 Use the /notls option in the mailbox name to disable TLS
yuuji@0 2578 negotiation.
yuuji@0 2579 _________________________________________________________________
yuuji@0 2580
yuuji@0 2581 7.30 What does the error message: TLS/SSL failure: myserver: Server
yuuji@0 2582 name does not match certificate mean?
yuuji@0 2583
yuuji@0 2584 An SSL or TLS session encryption failed because the server name
yuuji@0 2585 in the server's certificate does not match the name that you
yuuji@0 2586 gave it. This could indicate that the server is not really the
yuuji@0 2587 system you think that it is, but can be also be called if you
yuuji@0 2588 gave a nickname for the server or name that was not
yuuji@0 2589 fully-qualified. You must use the fully-qualified domain name
yuuji@0 2590 for the server in order to validate its certificate
yuuji@0 2591
yuuji@0 2592 Use the /novalidate-cert option in the mailbox name to disable
yuuji@0 2593 validation of the certificate.
yuuji@0 2594 _________________________________________________________________
yuuji@0 2595
yuuji@0 2596 7.31 What does the UNIX error message: TLS/SSL failure: myserver:
yuuji@0 2597 self-signed certificate mean?
yuuji@0 2598 7.32 What does the PC error message: TLS/SSL failure: myserver:
yuuji@0 2599 Self-signed certificate or untrusted authority mean?
yuuji@0 2600
yuuji@0 2601 An SSL or TLS session encryption failed because your server's
yuuji@0 2602 certificate is "self-signed"; that is, it is not signed by any
yuuji@0 2603 Certificate Authority (CA) and thus can not be validated. A
yuuji@0 2604 CA-signed certificate costs money, and some smaller sites
yuuji@0 2605 either don't want to pay for it or haven't gotten one yet. The
yuuji@0 2606 bad part about this is that this means there is no guarantee
yuuji@0 2607 that the server is really the system you think that it is.
yuuji@0 2608
yuuji@0 2609 Use the /novalidate-cert option in the mailbox name to disable
yuuji@0 2610 validation of the certificate.
yuuji@0 2611 _________________________________________________________________
yuuji@0 2612
yuuji@0 2613 7.33 What does the UNIX error message: TLS/SSL failure: myserver:
yuuji@0 2614 unable to get local issuer certificate mean?
yuuji@0 2615
yuuji@0 2616 An SSL or TLS session encryption failed because your system
yuuji@0 2617 does not have the Certificate Authority (CA) certificates
yuuji@0 2618 installed on OpenSSL's certificates directory. On most systems,
yuuji@0 2619 this directory is /usr/local/ssl/certs). As a result, it is not
yuuji@0 2620 possible to validate the server's certificate.
yuuji@0 2621
yuuji@0 2622 If CA certificates are properly installed, you should see
yuuji@0 2623 factory.pem and about a dozen other .pem names such as
yuuji@0 2624 thawteCb.pem.
yuuji@0 2625
yuuji@0 2626 As a workaround, you can use the /novalidate-cert option in the
yuuji@0 2627 mailbox name to disable validation of the certificate; however,
yuuji@0 2628 note that you are then vulnerable to various security attacks
yuuji@0 2629 by bad guys.
yuuji@0 2630
yuuji@0 2631 The correct fix is to copy all the files from the certs/
yuuji@0 2632 directory in the OpenSSL distribution to the
yuuji@0 2633 /usr/local/ssl/certs (or whatever) directory. Note that you
yuuji@0 2634 need to do this after building OpenSSL, because the OpenSSL
yuuji@0 2635 build creates a number of needed symbolic links. For some
yuuji@0 2636 bizarre reason, the OpenSSL "make install" doesn't do this for
yuuji@0 2637 you, so you must do it manually.
yuuji@0 2638 _________________________________________________________________
yuuji@0 2639
yuuji@0 2640 7.34 Why does reading certain messages hang when using Netscape? It
yuuji@0 2641 works fine with Pine!
yuuji@0 2642
yuuji@0 2643 There are two possible causes.
yuuji@0 2644
yuuji@0 2645 Check the mail syslog. If you see the message "Killed (lost
yuuji@0 2646 mailbox lock)" for the impacted user(s), read the FAQ entry
yuuji@0 2647 regarding that message.
yuuji@0 2648
yuuji@0 2649 Check the affected mailbox to see if there are embedded NUL
yuuji@0 2650 characters in the message. NULs in message texts are a
yuuji@0 2651 technical violation of both the message format and IMAP
yuuji@0 2652 specifications. Most clients don't care, but apparently
yuuji@0 2653 Netscape does.
yuuji@0 2654
yuuji@0 2655 You can work around this by rebuilding imapd with the
yuuji@0 2656 NETSCAPE_BRAIN_DAMAGE option set (see src/imapd/Makefile); this
yuuji@0 2657 will cause imapd to convert all NULs to 0x80 characters. A
yuuji@0 2658 better solution is to enable the feature in your MTA to
yuuji@0 2659 MIME-convert messages with binary content. See the
yuuji@0 2660 documentation for your MTA for how to do this.
yuuji@0 2661 _________________________________________________________________
yuuji@0 2662
yuuji@0 2663 7.35 Why does Netscape say that there's a problem with the IMAP server
yuuji@0 2664 and that I should "Contact your mail server administrator."?
yuuji@0 2665
yuuji@0 2666 Certain versions of Netscape do this when you click the Manage
yuuji@0 2667 Mail button, which uses an undocumented feature of Netscape's
yuuji@0 2668 proprietary IMAP server.
yuuji@0 2669
yuuji@0 2670 You can work around this by rebuilding imapd with the
yuuji@0 2671 NETSCAPE_BRAIN_DAMAGE option set (see src/imapd/Makefile) to a
yuuji@0 2672 URL that points either to an alternative IMAP client (e.g.
yuuji@0 2673 Pine) or perhaps to a homebrew mail account management page.
yuuji@0 2674 _________________________________________________________________
yuuji@0 2675
yuuji@0 2676 7.36 Why is one user creating huge numbers of IMAP or POP server
yuuji@0 2677 sessions?
yuuji@0 2678
yuuji@0 2679 The user is probably using Outlook Express, Eudora, or a
yuuji@0 2680 similar program. See the answer to the Help! My load average is
yuuji@0 2681 soaring and I see hundreds of POP and IMAP servers, many logged
yuuji@0 2682 in as the same user! question.
yuuji@0 2683 _________________________________________________________________
yuuji@0 2684
yuuji@0 2685 7.37 Why don't I get any new mail notifications from Outlook Express
yuuji@0 2686 or Outlook after a while?
yuuji@0 2687
yuuji@0 2688 This is a known bug in Outlook Express. Microsoft is aware of
yuuji@0 2689 the problem and its cause. They have informed us that they do
yuuji@0 2690 not have any plans to fix it at the present time.
yuuji@0 2691
yuuji@0 2692 The problem is also reported in Outlook 2000, but not verified.
yuuji@0 2693
yuuji@0 2694 Outlook Express uses the IMAP IDLE command to avoid having to
yuuji@0 2695 "ping" the server every few minutes for new mail.
yuuji@0 2696 Unfortunately, Outlook Express overlooks the part in the IDLE
yuuji@0 2697 specification which requires that a client terminate and
yuuji@0 2698 restart the IDLE before the IMAP 30 minute inactivity
yuuji@0 2699 autologout timer triggers.
yuuji@0 2700
yuuji@0 2701 When this happens, Outlook Express displays "Not connected" at
yuuji@0 2702 the bottom of the window. Since it's no longer connected to the
yuuji@0 2703 IMAP server, it isn't going to notice any new mail.
yuuji@0 2704
yuuji@0 2705 As soon as the user does anything that would cause an IMAP
yuuji@0 2706 operation, Outlook Express will reconnect and new mail will
yuuji@0 2707 flow again. If the user does something that causes an IMAP
yuuji@0 2708 operation at least every 29 minutes, the problem won't happen.
yuuji@0 2709
yuuji@0 2710 Modern versions of imapd attempt to work around the problem by
yuuji@0 2711 automatically reporting fake new mail after 29 minutes. This
yuuji@0 2712 causes Outlook Express to exit the IDLE state; as soon as this
yuuji@0 2713 happens imapd revokes the fake new mail. As long as this
yuuji@0 2714 behavior isn't known to cause problems with other clients, this
yuuji@0 2715 workaround will remain in imapd.
yuuji@0 2716 _________________________________________________________________
yuuji@0 2717
yuuji@0 2718 7.38 Why don't I get any new mail notifications from Entourage?
yuuji@0 2719
yuuji@0 2720 This is a known bug in Entourage.
yuuji@0 2721
yuuji@0 2722 You built an older version of imapd with the
yuuji@0 2723 MICROSOFT_BRAIN_DAMAGE option set, in order to disable support
yuuji@0 2724 for the IDLE command. However, Entourage won't get new mail
yuuji@0 2725 unless IDLE command support exists.
yuuji@0 2726
yuuji@0 2727 Note: the MICROSOFT_BRAIN_DAMAGE option no longer exists in
yuuji@0 2728 modern versions, as the Outlook Express problem which it
yuuji@0 2729 attempted to solve has been worked around in another way.
yuuji@0 2730 _________________________________________________________________
yuuji@0 2731
yuuji@0 2732 7.39 Why doesn't Entourage work at all?
yuuji@0 2733
yuuji@0 2734 It's hard to know. Entourage breaks almost every rule in the
yuuji@0 2735 book for IMAP. It is highly instructive to do a packet trace on
yuuji@0 2736 Entourage, as an example of how not to use IMAP. It does things
yuuji@0 2737 like STATUS (MESSAGES) on the currently selected mailbox and
yuuji@0 2738 re-fetching the same static data over and over again.
yuuji@0 2739
yuuji@0 2740 It seems that every time we understand what it is doing wrong
yuuji@0 2741 in Entourage and come up with a workaround, we learn about
yuuji@0 2742 something else that's broken.
yuuji@0 2743
yuuji@0 2744 Try building imapd with the ENTOURAGE_BRAIN_DAMAGE option set,
yuuji@0 2745 in order to disable the diagnostic that occurs when doing
yuuji@0 2746 STATUS on the currently selected mailbox.
yuuji@0 2747 _________________________________________________________________
yuuji@0 2748
yuuji@0 2749 7.40 Why doesn't Netscape Notify (NSNOTIFY.EXE) work at all?
yuuji@0 2750
yuuji@0 2751 This is a bug in NSNOTIFY; it doesn't handle unsolicited data
yuuji@0 2752 from the server correctly.
yuuji@0 2753
yuuji@0 2754 Fortunately, there is no reason to use this program with IMAP;
yuuji@0 2755 NSNOTIFY is a polling program to let you know when new mail has
yuuji@0 2756 appeared in your maildrop. This is necessary with POP; but
yuuji@0 2757 since IMAP dynamically announces new mail in the session you're
yuuji@0 2758 better off (and will actually cause less load on the server!)
yuuji@0 2759 keeping your mail reading program's IMAP session open and let
yuuji@0 2760 IMAP do the notifying for you.
yuuji@0 2761
yuuji@0 2762 Consequently, the recommended fix for the NSNOTIFY problem is
yuuji@0 2763 to delete the NSNOTIFY binary.
yuuji@0 2764 _________________________________________________________________
yuuji@0 2765
yuuji@0 2766 7.41 Why can't I connect via SSL to Eudora? It says the connection has
yuuji@0 2767 been broken, and in the server syslogs I see "Command stream end of
yuuji@0 2768 file".
yuuji@0 2769
yuuji@0 2770 There is a report that you can fix the problem by going into
yuuji@0 2771 Eudora's advanced network configuration menu and increasing the
yuuji@0 2772 network buffer size to 8192.
yuuji@0 2773 _________________________________________________________________
yuuji@0 2774
yuuji@0 2775 7.42 Sheesh. Aren't there any good IMAP clients out there?
yuuji@0 2776
yuuji@0 2777 Yes!
yuuji@0 2778
yuuji@0 2779 Pine is a wonderful client. It's fast, it uses IMAP well, and
yuuji@0 2780 it generates text mail (life is too short to waste on HTML
yuuji@0 2781 mail). Also, there are some really wonderful things in progress
yuuji@0 2782 in the Pine world.
yuuji@0 2783
yuuji@0 2784 There are some good GUI clients out there, mostly from smaller
yuuji@0 2785 vendors. Without naming names, look for the vendors who are
yuuji@0 2786 active in the IMAP protocol development community, and their
yuuji@0 2787 products.
yuuji@0 2788
yuuji@0 2789 Netscape, Eudora, and Outlook can be configured with enough
yuuji@0 2790 effort to be good citizens and work well for users, but they
yuuji@0 2791 can also be badly misconfigured, and often the misconfiguration
yuuji@0 2792 is the default.
yuuji@0 2793 _________________________________________________________________
yuuji@0 2794
yuuji@0 2795 7.43 But wait! PC Pine (or other PC program build with c-client)
yuuji@0 2796 crashes with the message incomplete SecBuffer exceeds maximum buffer
yuuji@0 2797 size when I use SSL connections. This is a bug in c-client, right?
yuuji@0 2798
yuuji@0 2799 It's a bug in the Microsoft SChannel.DLL, which implements SSL.
yuuji@0 2800 Microsoft admits it (albeit with an unstatement: "it's not
yuuji@0 2801 fully RFC compliant"). The problem is that SChannel indicates
yuuji@0 2802 that the maximum SSL packet data size is 5 bytes smaller than
yuuji@0 2803 the actual maximum. Thus, any IMAP server which transmits a
yuuji@0 2804 maximum sized SSL packet will not work with PC Pine or any
yuuji@0 2805 other program which uses SChannel.
yuuji@0 2806
yuuji@0 2807 It can take a while for the problem to show up. The client has
yuuji@0 2808 to do something that causes at least 16K of contiguous data.
yuuji@0 2809 Many clients do partial fetching, which tends to reduce the
yuuji@0 2810 number of cases where this can happen. However, all software
yuuji@0 2811 which uses SChannel to support SSL is affected by this bug.
yuuji@0 2812
yuuji@0 2813 This problem does not affect UNIX code, since OpenSSL is used
yuuji@0 2814 on UNIX.
yuuji@0 2815
yuuji@0 2816 This problem most recently showed up with the CommunigatePro
yuuji@0 2817 IMAP server. They have an update which trims down their maximum
yuuji@0 2818 contiguous data to less than 16K, in order to work around the
yuuji@0 2819 problem.
yuuji@0 2820
yuuji@0 2821 This problem has also shown up with the Exchange IMAP server
yuuji@0 2822 with UNIX clients (including Pine built with an older version
yuuji@0 2823 of c-client) which sends full-sized 16K SSL packets. Modern
yuuji@0 2824 c-client works around the problem by trimming down its maximum
yuuji@0 2825 outgoing SSL packet size to 8K.
yuuji@0 2826
yuuji@0 2827 Microsoft has developed a hotfix for this bug. Look up MSKB
yuuji@0 2828 article number 300562. Contrary to the article text which
yuuji@0 2829 implies that this is a Pine issue, this bug also affect
yuuji@0 2830 Microsoft Exchange server with *any* UNIX based client that
yuuji@0 2831 transmits full-sized SSL payloads.
yuuji@0 2832 _________________________________________________________________
yuuji@0 2833
yuuji@0 2834 7.44 My qpopper users keep on getting the DON'T DELETE THIS MESSAGE --
yuuji@0 2835 FOLDER INTERNAL DATA if they also use Pine or IMAP. How can I fix
yuuji@0 2836 this?
yuuji@0 2837
yuuji@0 2838 This is an incompatibility between qpopper and the c-client
yuuji@0 2839 library used by Pine, imapd, and ipop[23]d.
yuuji@0 2840
yuuji@0 2841 Assuming that you want to continue using qpopper, look into
yuuji@0 2842 qpopper's --enable-uw-kludge-flag configuration flag, which is
yuuji@0 2843 documented as "check for and hide UW 'Folder Internal Data'
yuuji@0 2844 messages".
yuuji@0 2845
yuuji@0 2846 The other alternative is to switch from qpopper to ipop3d.
yuuji@0 2847 _________________________________________________________________
yuuji@0 2848
yuuji@0 2849 7.45 Help! I installed the servers but I can't connect to them from my
yuuji@0 2850 client!
yuuji@0 2851
yuuji@0 2852 Review the installation instructions carefully. Make sure that
yuuji@0 2853 you have not skipped any of the steps. Make sure that you have
yuuji@0 2854 made the correct entries in the configuration files; pay
yuuji@0 2855 careful attention to the exact spelling of the service names
yuuji@0 2856 and the path names. Make sure as well that you have properly
yuuji@0 2857 restarted inetd.
yuuji@0 2858
yuuji@0 2859 If you have a system with Yellow Pages/NIS such as Solaris,
yuuji@0 2860 have you updated the service names there as well as in
yuuji@0 2861 /etc/services?
yuuji@0 2862
yuuji@0 2863 If you have a system with TCP wrappers, have you properly
yuuji@0 2864 updated the TCP wrapper files (e.g. /etc/hosts.allow and
yuuji@0 2865 /etc/hosts.deny) for the servers?
yuuji@0 2866
yuuji@0 2867 If you have a system which uses xinetd instead of inetd, have
yuuji@0 2868 you made sure that you have made the correct corresponding
yuuji@0 2869 xinetd changes for those services?
yuuji@0 2870
yuuji@0 2871 Try telneting to the server port (143 for IMAP, 110 for POP3).
yuuji@0 2872 If you get a "refused" error, that probably means that you
yuuji@0 2873 don't have the service set up in inetd.conf. If the connection
yuuji@0 2874 opens and then closes with no message, the service is set up,
yuuji@0 2875 but either the path name of the server binary in inetd.conf is
yuuji@0 2876 wrong or your TCP wrappers are configured to deny access.
yuuji@0 2877
yuuji@0 2878 If you don't know how to make the corresponding changes to
yuuji@0 2879 these files, seek the help of a local expert for your system.
yuuji@0 2880 _________________________________________________________________
yuuji@0 2881
yuuji@0 2882 7.46 Why do I get the message Can not authenticate to SMTP server: 421
yuuji@0 2883 SMTP connection went away! and why did this happen? There was also
yuuji@0 2884 something about SECURITY PROBLEM: insecure server advertised
yuuji@0 2885 AUTH=PLAIN
yuuji@0 2886
yuuji@0 2887 Some versions of qmail, including that running on
yuuji@0 2888 mail.smtp.yahoo.com, disconnect the SMTP session if you fail to
yuuji@0 2889 authenticate prior to attempting to transmit mail. An attempt
yuuji@0 2890 to authenticate was made, but it failed because the server had
yuuji@0 2891 already disconnected.
yuuji@0 2892
yuuji@0 2893 To work around this, you need to specify /user=... in the host
yuuji@0 2894 name specification.
yuuji@0 2895
yuuji@0 2896 The SECURITY PROBLEM came about because the server advertised
yuuji@0 2897 the AUTH=PLAIN SASL authentication mechanism outside of a
yuuji@0 2898 TLS-encrypted session, in violation of RFC 4616. This message
yuuji@0 2899 is just a warning, and in fact occurred after the server had
yuuji@0 2900 disconnected.
yuuji@0 2901 _________________________________________________________________
yuuji@0 2902
yuuji@0 2903 7.47 Why do I get the message SMTP Authentication cancelled and why
yuuji@0 2904 did this happen? There was also something about SECURITY PROBLEM:
yuuji@0 2905 insecure server advertised AUTH=PLAIN
yuuji@0 2906
yuuji@0 2907 This is a bug in the SMTP server.
yuuji@0 2908
yuuji@0 2909 Some versions of qmail, including that running on
yuuji@0 2910 mail.smtp.yahoo.com, have a bug in their implementation of SASL
yuuji@0 2911 in their SMTP server, which renders it non-compliant with the
yuuji@0 2912 standard.
yuuji@0 2913
yuuji@0 2914 If the client does not provide an initial response in the
yuuji@0 2915 command line for an authentication mechanism whose profile does
yuuji@0 2916 not have an initial challenge, qmail issues a bogus response:
yuuji@0 2917
yuuji@0 2918 334 ok, go on
yuuji@0 2919
yuuji@0 2920 The problem is the "ok, go on". This violates RFC 4954's
yuuji@0 2921 requirement that the text part in a 334 response be a BASE64
yuuji@0 2922 encoded string; in other words, it is a protocol syntax error.
yuuji@0 2923
yuuji@0 2924 In the case of AUTH=PLAIN, RFC 4422 (page 7) requires that the
yuuji@0 2925 encoded string have no data. In other words, the appropropiate
yuuji@0 2926 standards-compliant server response is "334" followed by a
yuuji@0 2927 SPACE and a CRLF.
yuuji@0 2928
yuuji@0 2929 The SECURITY PROBLEM came about because the server advertised
yuuji@0 2930 the AUTH=PLAIN SASL authentication mechanism outside of a
yuuji@0 2931 TLS-encrypted session, in violation of RFC 4616. This message
yuuji@0 2932 is just a warning, and is not related the "Authentication
yuuji@0 2933 cancelled" problem.
yuuji@0 2934 _________________________________________________________________
yuuji@0 2935
yuuji@0 2936 7.48 Why do I get the message Invalid base64 string when I try to
yuuji@0 2937 authenticate to a Cyrus server?
yuuji@0 2938
yuuji@0 2939 This slightly misleading message is the way that a Cyrus server
yuuji@0 2940 indicates that an authentication exchange was cancelled. It is
yuuji@0 2941 not indicative of a bug or protocol violation.
yuuji@0 2942
yuuji@0 2943 The most common reason that this happens is if the Cyrus server
yuuji@0 2944 offers Kerberos authentication, c-client is built with Kerberos
yuuji@0 2945 support, but your client system is not within the Kerberos
yuuji@0 2946 realm. In this case, the client code will try to authenticate
yuuji@0 2947 via Kerberos, fail to get the Kerberos credentials, cancel the
yuuji@0 2948 authentication attempt, and try the next available
yuuji@0 2949 authentication technology.
yuuji@0 2950 _________________________________________________________________
yuuji@0 2951
yuuji@0 2952 8. Where to Go For Additional Information
yuuji@0 2953 _________________________________________________________________
yuuji@0 2954
yuuji@0 2955 8.1 Where can I go to ask questions?
yuuji@0 2956 8.2 I have some ideas for enhancements to IMAP. Where should I go?
yuuji@0 2957
yuuji@0 2958 If you have questions about the IMAP protocol, or want to
yuuji@0 2959 participate in discussions of future directions of the IMAP
yuuji@0 2960 protocol, the appropriate mailing list is
yuuji@0 2961 imap-protocol@u.washington.edu. You can subscribe to this
yuuji@0 2962 list via imap-protocol-request@u.washington.edu
yuuji@0 2963
yuuji@0 2964 If you have questions about this software, you can send me
yuuji@0 2965 email directly or use the imap-uw@u.washington.edu mailing
yuuji@0 2966 list. You can subscribe to this list via
yuuji@0 2967 imap-uw-request@u.washington.edu
yuuji@0 2968
yuuji@0 2969 If you have general questions about the use of IMAP software
yuuji@0 2970 (not specific to the UW IMAP toolkit) use the
yuuji@0 2971 imap-use@u.washington.edu mailing list. You can subscribe to
yuuji@0 2972 this list via imap-use-request@u.washington.edu
yuuji@0 2973
yuuji@0 2974 You must be a subscriber to post to these lists. As an
yuuji@0 2975 alternative, you can use the comp.mail.imap newsgroup.
yuuji@0 2976 _________________________________________________________________
yuuji@0 2977
yuuji@0 2978 8.3 Where can I read more about IMAP and other email protocols?
yuuji@0 2979
yuuji@0 2980 We recommend Internet Email Protocols: A Developer's Guide, by
yuuji@0 2981 Kevin Johnson, published by Addison Wesley, ISBN 0-201-43288-9.
yuuji@0 2982 _________________________________________________________________
yuuji@0 2983
yuuji@0 2984 8.4 Where can I find out more about setting up and administering an
yuuji@0 2985 IMAP server?
yuuji@0 2986
yuuji@0 2987 We recommend Managing IMAP, by Dianna Mullet & Kevin Mullet,
yuuji@0 2988 published by O'Reilly, ISBN 0-596-00012-X.
yuuji@0 2989
yuuji@0 2990 This book also has an excellent comparison of the UW and Cyrus
yuuji@0 2991 IMAP servers.
yuuji@0 2992
yuuji@0 2993 Last Updated: 15 November 2007

UW-IMAP'd extensions by yuuji