imapext-2007: docs/FAQ.html annotate

imapext-2007

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