| blob | 27d42aa4223f5a4daacddde254c894e02aa10a59 |
1 <html>
2 <!--
3 * ========================================================================
4 * Copyright 2008-2010 Mark Crispin
5 * ========================================================================
6 *
7 * Previous versions of this file were:
8 *
9 * Copyright 1988-2007 University of Washington
10 *
11 * Licensed under the Apache License, Version 2.0 (the "License");
12 * you may not use this file except in compliance with the License.
13 * You may obtain a copy of the License at
14 *
15 * http://www.apache.org/licenses/LICENSE-2.0
16 *
17 *
18 * ========================================================================
19 *
20 -->
21 <head>
23 <meta name="keywords" content="IMAP, Panda IMAP, Panda imapd, imap-2010, imap-2009, imap-2008, imap-2007b, imap-2007e, UW imapd, UW IMAP">
26 </head>
27 <body>
31 </H1>
35 <ul>
36 <li>
38 </li>
39 <li>
42 <ul>
44 UNIX/Linux/OSF/etc.?</a></li>
47 on UNIX. Do I need to replace it with ipop3d in order to run
48 imapd?</a></li>
57 Macintosh?</a></li>
60 VAX/VMS?</a></li>
70 and sub-mailboxes?</a></li>
76 internationalization?</a></li>
81 facility?</a></li>
90 passwords?</a></li>
93 passwords?</a></li>
96 passwords?</a></li>
99 passwords?</a></li>
102 plaintext passwords?</a></li>
107 unencrypted sessions, but allow them on encrypted sessions?</a></li>
122 format?</a></li>
125 format?</a></li>
128 </ul>
129 </li>
131 <li>
134 <ul>
136 on UNIX?</a></li>
139 Kerberos V on UNIX?</a></li>
142 software to build my own application?</a></li>
145 Windows?</a></li>
148 DOS?</a></li>
151 on the PC?</a></li>
154 Mac?</a></li>
157 VMS?</a></li>
166 Windows CE?</a></li>
167 </ul>
168 </li>
170 <li>
173 <ul>
175 UNIX?</a></li>
178 the BUILD instructions. It can't be that easy. Don't I need to write
179 a config file?</a></li>
182 for INBOX at some place other than the mail spool directory?</a></li>
185 secondary folders at some place other than the user's home
186 directory?</a></li>
191 facility?</a></li>
194 obtain/create certificates for use with SSL?</a></li>
197 authentication?</a></li>
200 authentication?</a></li>
205 passwords?</a></li>
208 server use Kerberos is to build with PAM on my Linux system, and set
209 it up in PAM for Kerberos passwords. Right?</a></li>
212 passwords?</a></li>
215 passwords?</a></li>
218 passwords?</a></li>
221 plaintext passwords?</a></li>
224 passwords?</a></li>
227 unencrypted sessions, but allow them in SSL or TLS sessions?</a></li>
231 <li>
233 as:
235 <ul>
237 type</li>
243 </li>
245 <li>
247 as
249 <ul>
251 allowed.</li>
260 </li>
262 <li>
264 as:
266 <ul>
268 be used.</li>
270 </li>
272 <li>
274 as:</a>
276 <ul>
278 not be used.</li>
279 </ul>during the build? Isn't this a security bug?
280 </li>
283 function being "dangerous and should not be used" for something other
284 than this gets() or tmpnam() call?</a></li>
285 </ul>
286 </li>
288 <li>
291 <ul>
293 logins?</a></li>
296 IMAP user will see?</a></li>
299 its several mechanisms to use to establish an IMAP connection to the
301 and via ssh.</a></li>
304 don't need to use /ssl to get encryption. However, I want to be
305 certain that my session is TLS encrypted before I send my password.
306 How to I do this?</a></li>
309 described in the formats.txt document? In particular, I hear that mbx
310 format will give me better performance and allow shared
311 access.</a></li>
316 someplace other than the mail syslog?</a></li>
317 </ul>
318 </li>
320 <li>
323 <ul>
325 arbitary files on the system, including /etc/passwd! How do I disable
326 this?</a></li>
329 this true?</a></li>
332 version of the server?</a></li>
335 those are unsafe, aren't they?</a></li>
338 that really right?</a></li>
339 </ul>
340 </li>
342 <li>
344 Questions</a>
346 <ul>
348 autoblurdybloop?</a></li>
351 Doesn't it waste disk and memory space?</a></li>
354 library?</a></li>
357 internationalization support?</a></li>
360 directory by default?</a></li>
363 plug and play for me?</a></li>
367 aren't you using the full size?</a></li>
370 instead of just INBOX?</a></li>
373 format?</a></li>
376 format?</a></li>
379 system?</a></li>
383 UNIX mailbox files? My other mail program just considers every line
385 message.</a></li>
388 format?</a></li>
391 MESSAGE -- FOLDER INTERNAL DATA" message at the start of traditional
392 UNIX and MMDF format mailboxes?</a></li>
395 the first real message of the mailbox instead of writing this fake
396 FOLDER INTERNAL DATA message?</a></li>
399 default?</a></li>
402 Solaris?</a></li>
405 BSD libraries? cc is the right thing on my Solaris system!</a></li>
408 in the spool directory?</a></li>
411 the past?</a></li>
412 </ul>
413 </li>
415 <li>
418 <ul>
420 messages?</a></li>
423 have been concatenated into one message which claims to be from me
424 and has a subject of the file name of the mailbox! What's going
425 on?</a></li>
427 <li>
430 <ul>
431 <li>CREATE failed: Can't create mailbox node xxxxxxxxx: File
432 exists</li>
434 </li>
437 name and password are right!</a></li>
440 hundreds of POP and IMAP servers, many logged in as the same
441 user!</a></li>
446 <li>
449 <ul>
450 <li>Moved ##### bytes of new mail to /home/user/mbox from
451 /var/spool/mail/user</li>
453 </li>
456 fully-qualified domain name?</a></li>
459 From/Sender/Message-ID headers of outgoing mail not coming out as a
460 fully-qualified domain name?</a></li>
462 <li>
465 <ul>
467 protection</li>
469 </li>
471 <li>
474 <ul>
477 </li>
479 <li>
482 <ul>
485 </li>
490 <li>
493 <ul>
502 </li>
504 <li>
507 <ul>
524 </li>
526 <li>
529 <ul>
533 </ul>mean? When it happens, the listed service shuts down. How can
534 I fix this?</a>
535 </li>
537 <li>
540 <ul>
542 denied</li>
544 </li>
546 <li>
549 <ul>
550 <li>Command stream end of file, while reading line user=...
551 host=...</li>
553 <li>Command stream end of file, while reading char user=...
554 host=...</li>
556 <li>Command stream end of file, while writing text user=...
557 host=...</li>
559 </li>
561 <li>
563 disconnect? The syslog has the message:
565 <ul>
567 </ul></a>
568 </li>
571 on the system, recursively from the UNIX root directory?</a></li>
574 files, recursively from my UNIX home directory?</a></li>
581 my home directory?</a></li>
584 connected to the IMAP or POP server, no matter what client I
585 use?</a></li>
588 other c-client based application call before I get connected to the
589 IMAP server? The hang seems to be in the c-client mail_open() call. I
590 don't have this problem with any other IMAP client. There is no delay
591 connecting to a POP3 or NNTP server with mail_open().</a></li>
594 two or more messages on my SUN system?</a></li>
596 <li>
598 disconnect? The syslog has the message:
600 <ul>
603 </ul></a>
604 </li>
606 <li>
609 <ul>
612 </li>
614 <li>
617 <ul>
618 <li>TLS/SSL failure: myserver: Unexpected TCP input
619 disconnect</li>
621 </li>
623 <li>
626 <ul>
627 <li>TLS/SSL failure: myserver: Server name does not match
628 certificate</li>
630 </li>
632 <li>
635 <ul>
638 </li>
640 <li>
643 <ul>
644 <li>TLS/SSL failure: myserver: Self-signed certificate or
645 untrusted authority</li>
647 </li>
649 <li>
652 <ul>
653 <li>TLS/SSL failure: myserver: unable to get local issuer
654 certificate</li>
656 </li>
659 using Netscape? It works fine with Alpine!</a></li>
662 with the IMAP server and that I should "Contact your mail server
666 IMAP or POP server sessions?</a></li>
669 from Outlook Express or Outlook after a while?</a></li>
672 from Entourage?</a></li>
677 work at all?</a></li>
680 says the connection has been broken, and in the server syslogs I see
684 clients out there?</a></li>
686 <li>
688 with c-client) crashes with the message
690 <ul>
693 </li>
696 DELETE THIS MESSAGE -- FOLDER INTERNAL DATA if they also use Alpine or
697 IMAP. How can I fix this?</a></li>
700 connect to them from my client!</a></li>
702 <li>
705 <ul>
707 away!</li>
708 </ul>and why did this happen? There was also something about
710 <ul>
712 </ul></a>
713 </li>
715 <li>
718 <ul>
720 </ul>and why did this happen? There was also something about
722 <ul>
724 </ul></a>
725 </li>
727 <li>
730 <ul>
732 </ul>when I try to authenticate to a Cyrus server?
733 </li></a>
734 </ul>
735 </li>
737 <li>
740 <ul>
744 Where should I go?</a></li>
747 email protocols?</a></li>
750 administering an IMAP server?</a></li>
751 </ul>
752 </li>
754 <hr>
757 <dl>
758 <dd>
759 Panda IMAP is a fork of the final University of Washington version
761 minor changes from imap-2007b. All of these changes (or something
762 better) are in Panda IMAP.
764 <p>Panda IMAP is available by donation.
766 </dd>
767 </dl>
770 <hr>
772 <hr>
775 UNIX/Linux/OSF/etc.?</strong></a></p>
777 <dl>
779 </dl>
782 <hr>
785 UNIX. Do I need to replace it with ipop3d in order to run
786 imapd?</strong></a></p>
788 <dl>
789 <dd>
790 Not necessarily.
792 <p>Although ipop3d interoperates with imapd better than qpopper, imapd
793 and qpopper will work together. The few qpopper/imapd interoperability
794 issues mostly affect users who use both IMAP and POP3 clients; those
795 users would probably be better served if their POP3 server is
796 ipop3d.</p>
798 <p>If you are happy with qpopper and just want to add imapd, you should
799 do that, and defer a decision on changing qpopper to ipop3d. That way,
800 you can get comfortable with imapd's performance, without changing
801 anything for your qpopper users.</p>
803 <p>Many sites have subsequently decided to change from qpopper to
804 ipop3d in order to get better POP3/IMAP interoperability. If you need
805 to do this, you'll know. There also seems to be a way to make qpopper
807 qpopper users keep on getting the DON'T DELETE THIS MESSAGE -- FOLDER
808 INTERNAL DATA if they also use Alpine or IMAP. How can I fix this?</a>
809 question.</p>
810 </dd>
811 </dl>
814 <hr>
819 <dl>
820 <dd>
821 Yes. Refer to the NT specific notes in files CONFIG and BUILD. Also,
823 set up CRAM-MD5 authentication, as described in md5.txt.
826 will have to do modifications to env_unix.c to prevent people from
827 hacking others' mail.</p>
829 <p>Note, however, that the server is not plug and play the way it is
830 for UNIX.</p>
831 </dd>
832 </dl>
835 <hr>
838 DOS?</strong></a><br>
840 Macintosh?</strong></a><br>
842 VAX/VMS?</strong></a></p>
844 <dl>
846 </dl>
849 <hr>
854 <dl>
855 <dd>
856 You have a TOPS-20 system? Cool.
859 is about the ultimate gonzo pure TOPS-20 extended addressing assembly
860 language program. Unfortunately, IMAP2 is barely good enough for Alpine
861 these days, and most other IMAP clients won't work with IMAP2 at all.
862 Maybe someone will hack MAPSER to do IMAP4rev1 some day.</p>
865 definitely was a POP2 server once upon a time.</p>
867 <p>Or you can port the POP and IMAP server from this IMAP toolkit to
868 it. All that you need for a first stab is to port the MTX driver.
869 That'll probably be just a couple of hours of hacking.</p>
870 </dd>
871 </dl>
874 <hr>
877 supported?</strong></a><br>
879 supported?</strong></a><br>
881 sub-mailboxes?</strong></a></p>
883 <dl>
884 <dd>
885 Yes. However, there is one important caveat.
887 <p>Some mailbox formats, including the default which is the traditional
888 UNIX mailbox format, are stored as a single file containing all the
889 messages. UNIX does not permit a name in the filesystem to be both a
890 file and a directory; consequently you can not have a sub-mailbox
891 within a mailbox that is in one of these formats.</p>
893 <p>This is not a limitation of the software; this is a limitation of
894 UNIX. For example, there are mailbox formats in which the name is a
895 directory and each message is a file within that directory; these
896 formats support sub-mailboxes within such mailboxes. However, for
897 technical reasons, the "flat file" formats are generally preferred
898 since they perform better. Read imap-2010/docs/formats.txt for more
899 information on this topic.</p>
901 <p>It is always permissible to create a directory that is not a
902 mailbox, and have sub-mailboxes under it. The easiest way to create a
903 directory is to create a new mailbox inside a directory that doesn't
904 already exist. For example, if you create "Mail/testbox" on UNIX, the
905 directory "Mail/" will automatically be created and then the mailbox
909 documentation for your client software to see how to do this with that
910 software.</p>
913 </dd>
914 </dl>
917 <hr>
922 <dl>
923 <dd>
924 The term "mailbox" is IMAP-speak for what a lot of software calls a
926 contexts to refer to a directory, for example, in the graphic user
927 interface on both Windows and Macintosh.
930 messages. It is not required to be capable of containing other types of
931 objects including other mailboxes; although some mailbox formats will
932 permit this.</p>
934 <p>In IMAP-speak, a mailbox which can not contain other mailboxes is
935 called a "no-inferiors mailbox". Similarly, a directory which can not
937 </dd>
938 </dl>
941 <hr>
944 internationalization?</strong></a></p>
946 <dl>
947 <dd>
948 The IMAP toolkit is partially internationalized and multilingualized.
956 CN-GB-12345, BIG5 (alias CN-BIG5), EUC-JP, EUC-KR, Shift_JIS,
967 <p>c-client library support also exists to convert text in any of the
968 above charsets into Unicode, including headers with MIME
969 encoded-words.</p>
971 <p>There is no support for localization (e.g. non-English error
972 messages) at the present time, but such support is planned.</p>
973 </dd>
974 </dl>
977 <hr>
981 <dl>
983 question.</dd>
984 </dl>
987 <hr>
990 facility?</strong></a></p>
992 <dl>
995 </dl>
998 <hr>
1001 authentication?</strong></a></p>
1003 <dl>
1006 </dl>
1009 <hr>
1013 <dl>
1014 <dd>
1016 question.
1019 </dd>
1020 </dl>
1023 <hr>
1027 <dl>
1030 </dl>
1033 <hr>
1036 passwords?</strong></a></p>
1038 <dl>
1041 </dl>
1044 <hr>
1047 passwords?</strong></a></p>
1049 <dl>
1052 </dl>
1055 <hr>
1058 passwords?</strong></a></p>
1060 <dl>
1063 </dl>
1066 <hr>
1069 passwords?</strong></a></p>
1071 <dl>
1074 </dl>
1077 <hr>
1080 passwords?</strong></a></p>
1082 <dl>
1085 </dl>
1088 <hr>
1091 passwords?</strong></a></p>
1093 <dl>
1096 </dl>
1099 <hr>
1102 sessions, but allow them on encrypted sessions?</strong></a></p>
1104 <dl>
1106 passwords on unencrypted sessions, but allow them in SSL or TLS
1108 </dl>
1111 <hr>
1115 <dl>
1118 </dl>
1121 <hr>
1125 <dl>
1127 </dl>
1130 <hr>
1134 <dl>
1135 <dd>
1136 Kerberos V4 is not supported.
1137 </dd>
1138 </dl>
1141 <hr>
1144 OTP?</strong></a></p>
1146 <dl>
1147 <dd>There is currently no support for S/Key or OTP. There may be an OTP
1148 SASL authenticator available from third parties.</dd>
1149 </dl>
1152 <hr>
1155 SPA?</strong></a></p>
1157 <dl>
1158 <dd>
1159 There is currently no support for NTLM or SPA, nor are there any plans
1160 to add such support. In general, I avoid vendor-specific mechanisms. I
1161 also believe that these mechanisms are being deprecated by their
1162 vendor.
1164 <p>There may be an NTLM SASL authenticator available from third
1165 parties.</p>
1166 </dd>
1167 </dl>
1170 <hr>
1174 <dl>
1175 <dd>
1176 Yes, but only as a legacy format. Your mh format INBOX is accessed by
1177 the name "#mhinbox", and all other mh format mailboxes are accessed by
1179 "Path:" entry in your .mh_profile file to identify the root directory
1180 of your mh format mailboxes.
1182 <p>Non-legacy use of mh format is not encouraged. There is no support
1183 for permanent flags or unique identifiers; furthermore there are known
1184 severe performance problems with the mh format.</p>
1185 </dd>
1186 </dl>
1189 <hr>
1192 format?</strong></a></p>
1194 <dl>
1195 <dd>There is no support for qmail or the maildir format in our
1196 distribution, nor are there any plans to add such support. Maildir
1197 support may be available from third parties.</dd>
1198 </dl>
1201 <hr>
1204 format?</strong></a></p>
1206 <dl>
1208 </dl>
1211 <hr>
1215 <dl>
1217 </dl>
1220 <hr>
1222 <p><br></p>
1225 <hr>
1228 UNIX?</strong></a></p>
1230 <dl>
1232 </dl>
1235 <hr>
1238 V on UNIX?</strong></a></p>
1240 <dl>
1242 </dl>
1245 <hr>
1248 software to build my own application?</strong></a></p>
1250 <dl>
1251 <dd>
1252 If you are building an application using the c-client library, use the
1253 new c-client.h file instead of including the other include files. It
1254 seems that c-client.h should define away all the troublesome names that
1255 conflict with C++.
1258 </dd>
1259 </dl>
1262 <hr>
1265 Windows?</strong></a></p>
1267 <dl>
1268 <dd>
1269 You need Microsoft Visual C++ 6.0, Visual C++ .NET, or Visual C# .NET
1270 (which you can buy from any computer store), along with the Microsoft
1271 Platform SDK (which you can download from Microsoft's web site).
1273 <p>You do not need to install the entire Platform SDK; it suffices to
1274 install just the Core SDK and the Internet Development SDK.</p>
1275 </dd>
1276 </dl>
1279 <hr>
1282 DOS?</strong></a></p>
1284 <dl>
1285 <dd>It's been several years since we last attempted to do this. At the
1286 time, we used Microsoft C.</dd>
1287 </dl>
1290 <hr>
1293 PC?</strong></a></p>
1295 <dl>
1297 </dl>
1300 <hr>
1303 Mac?</strong></a></p>
1305 <dl>
1306 <dd>It has been several years since we last attempted to do this. At the
1307 time, we used Symantec THINK C; but today you'll need a C compiler which
1309 </dl>
1312 <hr>
1315 VMS?</strong></a></p>
1317 <dl>
1318 <dd>You need the VMS C compiler, and either the Multinet or Netlib
1319 TCP.</dd>
1320 </dl>
1323 <hr>
1328 <dl>
1330 </dl>
1333 <hr>
1338 <dl>
1340 </dl>
1343 <hr>
1346 CE?</strong></a></p>
1348 <dl>
1350 </dl>
1353 <hr>
1355 <p><br></p>
1358 <hr>
1361 UNIX?</strong></a><br>
1363 BUILD instructions. It can't be that easy. Don't I need to write a
1364 config file?</strong></a></p>
1366 <dl>
1367 <dd>
1368 For ordinary "vanilla" UNIX systems, this software is plug and play;
1369 just build it, install it, and you're done. If you have a modified
1370 system, then you may want to do additional work; most of this is to a
1371 single source code file (env_unix.c on UNIX systems). Read the file
1372 CONFIG for more details.
1374 <p>Yes, it's that easy. There are some additional options, such as SSL
1375 or Kerberos, which require additional steps to build. See the relevant
1376 questions below.</p>
1377 </dd>
1378 </dl>
1381 <hr>
1384 INBOX at some place other than the mail spool
1385 directory?</strong></a><br>
1387 folders at some place other than the user's home
1388 directory?</strong></a></p>
1390 <dl>
1391 <dd>Please read the file CONFIG for discussion of this and other
1392 issues.</dd>
1393 </dl>
1396 <hr>
1400 facility?</strong></a></p>
1402 <dl>
1403 <dd>
1405 Windows for IMAP, POP3, SMTP, and NNTP; and SSL and TLS server
1406 functionality on UNIX for IMAP and POP3.
1408 <p>UNIX SSL build requires that a third-party software package,
1409 OpenSSL, be installed on the system first. Read imap-2010/docs/SSLBUILD
1410 for more information.</p>
1413 and NT4; and via standard interfaces in Windows 2000, Windows
1414 Millenium, and Windows XP.</p>
1415 </dd>
1416 </dl>
1419 <hr>
1422 certificates for use with SSL?</strong></a></p>
1424 <dl>
1425 <dd>If you need help in doing this, try the contacts mentioned in the
1426 OpenSSL README. We do not offer support for OpenSSL or certificates.</dd>
1427 </dl>
1430 <hr>
1433 authentication?</strong></a><br>
1435 authentication?</strong></a></p>
1437 <dl>
1438 <dd>
1439 CRAM-MD5 authentication is enabled in the IMAP and POP3 client code on
1440 all platforms. Read md5.txt to learn how to set up CRAM-MD5 and APOP
1441 authentication on UNIX and NT servers.
1444 </dd>
1445 </dl>
1448 <hr>
1452 <dl>
1453 <dd>
1455 Windows.
1458 <pre>
1459 nmake -f makefile.w2k
1460 </pre>
1462 <p>Other builds require that a third-party Kerberos package, e.g. MIT
1463 Kerberos, be installed on the system first.</p>
1465 <p>To build with Kerberos V5 on UNIX, include EXTRAAUTHENTICATORS=gss
1466 in the make command line, e.g.</p>
1467 <pre>
1468 make lnp EXTRAAUTHENTICATORS=gss
1469 </pre>
1473 <pre>
1475 nmake -f makefile.ntk
1476 </pre>
1477 </dd>
1478 </dl>
1481 <hr>
1484 passwords?</strong></a></p>
1486 <dl>
1487 <dd>
1488 On Linux systems, use the lnp port, e.g.
1489 <pre>
1490 make lnp
1492 </pre>On Solaris systems and other systems with defective PAM
1493 implementations, build with PASSWDTYPE=pmb, e.g.
1494 <pre>
1495 make sol PASSWDTYPE=pmb
1496 </pre>On all other systems, build with PASSWDTYPE=pam, e.g
1497 <pre>
1498 make foo PASSWDTYPE=pam
1499 </pre>If you build with PASSWDTYPE=pam and authentication does not work, try
1500 rebuilding (after a "make clean") with PASSWDTYPE=pmb.
1501 </dd>
1502 </dl>
1505 <hr>
1508 use Kerberos is to build with PAM on my Linux system, and set it up in
1509 PAM for Kerberos passwords. Right?</strong></a></p>
1511 <dl>
1512 <dd>
1513 Yes and no.
1515 <p>Doing this will make plaintext password authentication use the
1516 Kerberos password instead of the /etc/passwd password.</p>
1518 <p>However, this will NOT give you Kerberos-secure authentication. See
1520 question for how to build with Kerberos-secure authentication.</p>
1521 </dd>
1522 </dl>
1525 <hr>
1528 passwords?</strong></a></p>
1530 <dl>
1531 <dd>
1532 Build with PASSWDTYPE=gss, e.g.
1533 <pre>
1534 make sol PASSWDTYPE=gss
1535 </pre>However, this will NOT give you Kerberos-secure authentication. See the
1537 for how to build with Kerberos-secure authentication.
1538 </dd>
1539 </dl>
1542 <hr>
1545 passwords?</strong></a></p>
1547 <dl>
1548 <dd>
1549 Build with PASSWDTYPE=afs, e.g
1550 <pre>
1551 make sol PASSWDTYPE=afs
1553 </pre>
1554 </dd>
1555 </dl>
1558 <hr>
1561 passwords?</strong></a></p>
1563 <dl>
1564 <dd>
1565 Build with PASSWDTYPE=dce, e.g
1566 <pre>
1567 make sol PASSWDTYPE=dce
1568 </pre>
1569 </dd>
1570 </dl>
1573 <hr>
1576 plaintext passwords?</strong></a></p>
1578 <dl>
1579 <dd>
1580 The CRAM-MD5 password database is automatically used for plaintext
1581 password if it exists.
1583 <p>Note that this is NOT CRAM-MD5-secure authentication. You probably
1584 want to consider disabling plaintext passwords for non-SSL/TLS
1585 sessions. See the next two questions.</p>
1586 </dd>
1587 </dl>
1590 <hr>
1593 passwords?</strong></a></p>
1595 <dl>
1596 <dd>
1597 Server-level plaintext passwords can be disabled by setting
1598 PASSWDTYPE=nul, e.g.
1599 <pre>
1600 make lnx EXTRAAUTHENTICATORS=gss PASSWDTYPE=nul
1601 </pre>Note that you must have a CRAM-MD5 database installed or specify at
1602 least one EXTRAAUTHENTICATOR, otherwise it will not be possible to log in to
1603 the server.
1605 <p>When plaintext passwords are disabled, the IMAP server will
1606 advertise the LOGINDISABLED capability and the POP3 server will not
1607 advertise the USER capability.</p>
1608 </dd>
1609 </dl>
1614 unencrypted sessions, but allow them in SSL or TLS
1615 sessions?</strong></a></p>
1617 <dl>
1618 <dd>
1619 <p>Do not set PASSWDTYPE=nul or SSLTYPE=unix. Set SSLTYPE=nopwd
1620 instead, e.g.</p>
1621 <pre>
1622 make lnx SSLTYPE=nopwd
1623 </pre>
1625 <p>When plaintext passwords are disabled, the IMAP server will
1626 advertise the LOGINDISABLED capability and the POP3 server will not
1627 advertise the USER capability.</p>
1629 <p>Plaintext passwords will always be enabled in SSL sessions; the IMAP
1630 server will not advertise the LOGINDISABLED capability and the POP3
1631 server will advertise the USER capability.</p>
1633 <p>If the client does a successful start-TLS in a non-SSL session,
1634 plaintext passwords will be enabled, and a new CAPABILITY or CAPA
1635 command (which is required after start-TLS) will show the effect as in
1636 SSL sessions.</p>
1637 </dd>
1638 </dl>
1641 <hr>
1644 hosts?</strong></a></p>
1646 <dl>
1647 <dd>
1648 This is automatic, but with certain restrictions.
1650 <p>The most important one is that each virtual host must have its own
1651 IP address; otherwise the server has no way of knowing which virtual
1652 host is desired.</p>
1654 <p>As distributed, the software uses a global password file; hence user
1656 to modify the checkpw() routine to implement some other policy (e.g.
1657 separate password files).</p>
1659 <p>Note that the security model assumes that all users have their own
1660 unique UNIX UID number. So if you use separate password files you
1661 should make certain that the UID numbers do not overlap between
1662 different files.</p>
1664 <p>More advanced virtual host support may be available as patches from
1665 third parties.</p>
1666 </dd>
1667 </dl>
1670 <hr>
1673 as:</strong></a></p>
1674 <pre>
1675 passing arg 3 of `scandir' from incompatible pointer type
1676 Pointers are not assignment-compatible.
1677 Argument #4 is not the correct type.
1679 </pre>
1683 <dl>
1684 <dd>
1685 You can safely ignore these messages.
1687 <p>Over the years, the prototype for scandir() has changed, and thus is
1688 variant across different UNIX platforms. In particular, the definitions
1689 of the third argument (type select_t) and fourth argument (type
1690 compar_t) have changed over the years, the issue being whether or not
1691 the arguments to the functions pointed to by these function pointers
1692 are of type const or not.</p>
1694 <p>The way that c-client calls scandir() will tend to generate these
1695 compiler warnings on newer systems such as Linux; however, it will
1696 still build. The problem with fixing the call is that then it won't
1697 build on older systems.</p>
1698 </dd>
1699 </dl>
1702 <hr>
1705 as</strong></a></p>
1706 <pre>
1709 Pointers are not assignment-compatible.
1710 Argument #5 is not the correct type.
1711 </pre>
1715 <dl>
1716 <dd>
1717 You can safely ignore these messages.
1719 <p>All known systems have no problem with casting a function pointer
1720 to/from a void* pointer, certain C compilers issue a compiler
1721 diagnostic because this facility is listed as a "Common extension" by
1722 the C standard:</p>
1723 <pre>
1724 K.5.7 Function pointer casts
1725 [#1] A pointer to an object or to void may be cast to a pointer
1726 to a function, allowing data to be invoked as a function (6.3.4).
1727 [#2] A pointer to a function may be cast to a pointer to an
1728 object or to void, allowing a function to be inspected or
1729 modified (for example, by a debugger) (6.3.4).
1732 heavily by c-client.
1733 </dd>
1734 </dl>
1737 <hr>
1740 as:</strong></a></p>
1741 <pre>
1742 mtest.c:515: the `gets' function is dangerous and should not be used.
1743 </pre>
1747 <dl>
1748 <dd>
1749 You can safely ignore this message.
1751 <p>Certain linkers, most notably on Linux, give this warning message.
1752 It is indeed true that the traditional gets() function is not a safe
1753 one.</p>
1755 <p>However, the mtest program is only a demonstration program, a model
1756 of a very basic application program using c-client. It is not something
1757 that you would install, much less run in any security-sensitive
1758 context.</p>
1760 <p>mtest has numerous other shortcuts that you wouldn't want to do in a
1761 real application program.</p>
1764 script in a security-sensitive context, but mtest isn't particularly
1765 useful for such purposes. If you wanted to write a script to automate
1766 some email task using c-client, you'd be better off using imapd instead
1767 of mtest.</p>
1769 <p>mtest only has two legitimate uses. It's a useful testbed for me
1770 when debugging new versions of c-client, and it's useful as a model for
1771 someone writing a simple c-client application to see how the various
1772 calls work.</p>
1774 <p>By the way, if you need a more advanced example of c-client
1775 programming than mtest (and you probably will), I recommend that you
1776 look at the source code for imapd and Alpine.</p>
1777 </dd>
1778 </dl>
1781 <hr>
1784 as:</strong></a></p>
1785 <pre>
1786 auth_ssl.c:92: the `tmpnam' function is dangerous and should not be used.
1787 </pre>
1791 <dl>
1792 <dd>
1793 You can safely ignore this message.
1795 <p>Certain linkers, most notably on Linux, give this warning message,
1796 based upon two known issues with tmpnam():</p>
1798 <dl>
1799 <dd>there can be a buffer overflow if an inadequate buffer is
1800 allocated.</dd>
1802 <dd>there can be a timing race caused by certain incautious usage of
1803 the return value.</dd>
1804 </dl>
1806 <p>Neither of these issues applies in the particular use that is made
1807 of tmpnam(). More importantly, the tmpnam() call is never executed on
1808 Linux systems.</p>
1809 </dd>
1810 </dl>
1813 <hr>
1816 function being "dangerous and should not be used" for something other
1817 than this gets() or tmpnam() call?</strong></a></p>
1819 <dl>
1821 </dl>
1824 <hr>
1826 <p><br></p>
1829 <hr>
1832 logins?</strong></a></p>
1834 <dl>
1835 <dd>Create the file /etc/anonymous.newsgroups. At the present time, this
1836 file should be empty. This will permit IMAP logins as anonymous as well
1837 as the ANONYMOUS SASL authenticator. Anonymous users have access to
1838 mailboxes in the #news., #ftp/, and #public/ namespaces only.</dd>
1839 </dl>
1842 <hr>
1845 user will see?</strong></a></p>
1847 <dl>
1848 <dd>Create the file /etc/imapd.alert with the text of the message. This
1849 text should be kept to one line if possible. Note that this will cause an
1850 alert to every IMAP user every time they initiate an IMAP session, so it
1851 should only be used for critical messages.</dd>
1852 </dl>
1855 <hr>
1858 several mechanisms to use to establish an IMAP connection to the server?
1860 ssh.</strong></a></p>
1862 <dl>
1863 <dd>
1864 c-client chooses how to establish an IMAP connection via the following
1865 rules:
1867 <ul>
1871 works, use that</li>
1873 <li>Else if /tryssl is specified and an SSL connection works, use
1874 that.</li>
1877 works, use that.</li>
1880 </ul>
1881 </dd>
1882 </dl>
1885 <hr>
1888 need to use /ssl to get encryption. However, I want to be certain that
1889 my session is TLS encrypted before I send my password. How to I do
1890 this?</strong></a></p>
1892 <dl>
1893 <dd>Use the /tls option in the mailbox name. This will cause an error
1894 message and the connection to fail if the server does not negotiate
1895 STARTTLS.</dd>
1896 </dl>
1899 <hr>
1902 described in the formats.txt document? In particular, I hear that mix
1903 format will give me better performance and allow shared
1904 access.</strong></a></p>
1906 <dl>
1907 <dd>
1908 The rumors about mix format being preferred are true. It is faster than
1909 the traditional UNIX mailbox format and permits shared access.
1912 alternative mailbox format is an advanced facility, and only expert
1913 users should undertake it. If you don't understand any of the following
1914 notes, you may not be enough of an expert yet, and are probably better
1915 off not going this route until you are more comfortable with your
1916 understanding.</p>
1918 <p>Some of the formats, including mix, are only supported by the
1919 software based on the c-client library, and are not recognized by other
1920 mailbox programs. The "vi" editor may corrupt mailboxes written in these
1921 formats.</p>
1923 <p>Another problem is that the certain formats, including mix and mbx, use
1925 reliably with NFS. NFS is not a real filesystem. Use IMAP instead of
1926 NFS for distributed access.</p>
1928 <p>Each of the following steps are in escalating order of involvement.
1929 The further you go down this list, the more deeply committed you
1930 become:</p>
1932 <ul>
1933 <li>The simplest way to create a mix-format mailbox is to prefix the
1934 name with "#driver.mix/" when creating a mailbox through c-client.
1936 be created in mix format. Only use "#driver.mix/" when creating the
1937 mailbox. At all other times, just use the name ("foo" in this
1938 example); the software will automatically select the driver for mix
1939 whenever that mailbox is accessed without you doing anything
1940 else.</li>
1943 mailbox to a new mailbox in mix format. Read the man page provided
1944 with the mailutil program for details.</li>
1946 <li>If you create an mix-format INBOX, by creating
1948 subsequent access to INBOX by any c-client based application will use
1949 the mix-format INBOX. Any mail delivered to the traditional format
1950 mailbox in the spool directory (e.g. /var/spool/mail/$USER) will
1951 automatically be copied into the mix-format INBOX and the spool
1952 directory copy removed.</li>
1954 <li>You can cause any newly-created mailboxes to be in mix-format by
1955 default by changing the definition of CREATEPROTO=unixproto to be
1956 CREATEPROTO=mixproto in src/osdep/unix/Makefile, then rebuilding the
1957 IMAP toolkit (do a "make clean" first). Do not change EMPTYPROTO,
1958 since mix format mailboxes are directories and thus are never a
1959 zero-byte file. If you use Alpine or the imap-utils, you should
1960 probably also rebuild them with the new IMAP toolkit too.</li>
1962 <li>You can deliver directly to the mix-format INBOX by use of the
1963 tmail or dmail programs. tmail is for direct invocation from sendmail
1964 (or whatever MTA program you use); dmail is for calls from procmail.
1965 Both of these programs have man pages which must be read carefully
1966 before making this change.</li>
1967 </ul>
1969 <p>Most other servers (e.g. Cyrus) require use of a non-standard
1970 format. A full-fledged format conversion is not significantly different
1971 from what you have to do with other servers. The difference, which
1972 makes format conversion procedures somewhat more complicated with this
1973 server, is that there is no "all or nothing" requirement with this
1974 server. There are many points in between. A format conversion can be
1975 anything from a single mailbox or single user, to systemwide.</p>
1977 <p>This is good in that you can decide how far to go, or do the steps
1978 incrementally as you become more comfortable with the result. On the
1979 other hand, there's no "One True Way" which can be boiled down to a
1980 simple set of pedagogical instructions.</p>
1982 <p>A number of sites have done full-fledged format conversions, and are
1983 reportedly quite happy with the results. Feel free to ask in the
1984 comp.mail.imap newsgroup for help.</p>
1985 </dd>
1986 </dl>
1989 <hr>
1993 <dl>
1994 <dd>
1995 At the simplest level, a shared mailbox is one which has UNIX file and
1996 directory protections which permit multiple users to access it. What
1997 this means is that your existing skills and tools to create and manage
1998 shared files on your UNIX system apply to shared mailboxes; e.g.
1999 <pre>
2000 chmod 666 mailbox
2001 </pre>
2003 <p>You may want to consider the use of a mailbox format which permits
2004 multiple simultaneous read/write sessions, such as the mix format. The
2005 traditional UNIX format only allows one read/write session to a
2006 mailbox at a time.</p>
2008 <p>An additional convenience item are three system directories, which
2009 can be set up for shared namespaces. These are: #ftp, #shared, and
2010 #public, and are defined by creating the associated UNIX users and home
2011 directories as described below.</p>
2013 <p>#ftp/ refers to the anonymous ftp filesystem exported by the ftp
2014 server, and is equivalent to the home directory for UNIX user "ftp".
2015 For example, #ftp/foo/bar refers to the file /foo/bar in the anonymous
2016 FTP filesystem, or ~ftp/foo/bar for normal users. Anonymous FTP files
2017 are available to anonymous IMAP logins. By default, newly-created files
2021 and is equivalent to the home directory for UNIX user "imappublic". For
2022 example, #public/foo/bar refers to the file ~imappublic/foo/bar. Public
2023 files are available to anonymous IMAP logins. By default, newly-created
2027 and is equivalent to the home directory for UNIX user "imapshared". For
2028 example, #shared/foo/bar refers to the file ~imapshared/foo/bar. Shared
2031 </dd>
2032 </dl>
2035 <hr>
2038 other than the mail syslog?</strong></a></p>
2040 <dl>
2041 <dd>
2042 The openlog() call that sets the syslog facility is in
2045 the syslog facility from LOG_MAIL to the facility you want, then
2046 rebuild. You also need to set up your /etc/syslog.conf properly.
2048 <p>Refer to the man pages for syslog and syslogd for more information
2049 on what the available syslog facilities are and how to configure
2050 syslogs. If you still don't understand what to do, find a UNIX system
2051 expert.</p>
2052 </dd>
2053 </dl>
2056 <hr>
2058 <p><br></p>
2061 <hr>
2064 arbitary files on the system, including /etc/passwd! How do I disable
2065 this?</strong></a></p>
2067 <dl>
2068 <dd>
2069 You should not worry about this if your IMAP users are allowed shell
2070 access. The IMAP server does not permit any access that the user can
2071 not have via the shell.
2073 <p>If, and only if, you deny your IMAP users shell access, you may want
2074 to consider one of three choices. Note that these choices reduce IMAP
2075 functionality, and may have undesirable side effects. Each of these
2076 choices involves an edit to file
2079 <p>The first (and recommended) choice is to set
2081 disable access to the filesystem root, to other users' home directory,
2082 and to superior directory.</p>
2084 <p>The second (and strongly NOT recommended) choice is to set
2086 IMAP session into a so-called "chroot jail", and thus setting this
2088 less secure and open to root compromise attacks. So do not use this
2092 <p>The third choice is to rewrite routine
2094 mailbox name to filesystem name (and restrictions) that you wish. This
2095 is the most general choice. As a guide, you can see at the start of
2098 </dd>
2099 </dl>
2102 <hr>
2105 true?</strong></a></p>
2107 <dl>
2108 <dd>
2109 There are no known security problems in this version of the IMAP
2110 toolkit, including the IMAP and POP servers. The IMAP and POP servers
2111 limit what can be done while not logged in, and as part of the login
2112 process discard all privileges except those of the user.
2114 <p>As with other software packages, there have been buffer overflow
2115 vulnerabilities in past versions. All known problems of this nature are
2116 fixed in this version.</p>
2118 <p>There is every reason to believe that the bad guys are engaged in an
2119 ongoing effort to find vulnerabilities in the IMAP toolkit. We look for
2120 such problems, and when one is found we fix it.</p>
2122 <p>It's unfortunate that any vulnerabilities existed in past versions,
2123 and we're doing my best to keep the IMAP toolkit free of
2124 vulnerabilities. No new vulnerabilities have been discovered in quite a
2125 while, but efforts will not be relaxed.</p>
2127 <p>Beware of vendors who claim that their implementations can not have
2128 vulnerabilities.</p>
2129 </dd>
2130 </dl>
2133 <hr>
2136 of the server?</strong></a></p>
2138 <dl>
2139 <dd>
2140 The best way is to keep your server software up to date. The bad guys
2141 are always looking for ways to crack software, and when they find one,
2142 let all their friends know.
2145 your software hasn't been updated in a while, it would "rot" -- tend to
2146 acquire problems that it didn't have when it was new.</p>
2149 it is no longer being developed or maintained. If you have not yet
2150 switched to Panda IMAP, you should seriously consider doing so.
2152 <p>Panda IMAP is available by donation. Donors are given a URL which
2153 they can use to download Panda IMAP, including future versions.
2154 </dd>
2155 </dl>
2158 <hr>
2161 are unsafe, aren't they?</strong></a></p>
2163 <dl>
2164 <dd>
2165 Yes and no.
2167 <p>It can be unsafe to do these calls if you do not know that the
2168 string being written will fit in the buffer. However, they are
2169 perfectly safe if you do know that.</p>
2171 <p>Beware of programmers who advocate doing a brute-force change of all
2172 instances of</p>
2173 <pre>
2174 strcpy (s,t);
2175 </pre>to
2176 <pre>
2177 strncpy (s,t,n)[n] = '\0';
2179 overflows."
2181 <p>There are examples in which a security bug was introduced because of
2182 this type of "fix", due to the programmer using the wrong value for n.
2183 In one case, the programmer thought that n was larger than it actually
2184 was, causing a NUL to be written out of the buffer; in another, n was
2185 too small, and a security credential was truncated.</p>
2187 <p>What is particularly ironic was that in both cases, the original
2188 strcpy() was safe, because the size of the source string was known to
2189 be safe.</p>
2191 <p>With all this in mind, the software has been inspected, and it is
2192 believed that all places where buffer overflows can happen have been
2193 fixed. The strcpy()s that are still are in the code occur after a size
2194 check was done in some other way.</p>
2197 <pre>
2198 *s++ = c;
2199 </pre>is just as vulnerable to buffer overflows. You can't cure buffer
2200 overflows by outlawing certain functions, nor is it desirable to do so;
2201 sometimes operations like strcpy() translate into fast machine instructions
2202 for better performance.
2204 <p>Nothing replaces careful study of code. That's how the bad guys find
2205 bugs. Security is not accomplished by means of brute-force
2206 shortcuts.</p>
2207 </dd>
2208 </dl>
2211 <hr>
2214 really right?</strong></a></p>
2216 <dl>
2217 <dd>
2218 Yes. Shared mailboxes won't work otherwise. Also, you get into
2219 accidental denial of service problems with old lock files left lying
2220 around; this happens fairly frequently.
2222 <p>The deliberate mischief that can be caused by fiddling with the lock
2223 files is small-scale; harassment level at most. There are many -- and
2224 much more effective -- other ways of harassing another user on UNIX.
2225 It's usually not difficult to determine the culprit.</p>
2227 <p>Before worrying about deliberate mischief, worry first about things
2228 happening by accident!</p>
2229 </dd>
2230 </dl>
2233 <hr>
2235 <p><br></p>
2238 Questions</a></h2>
2239 <hr>
2242 autoblurdybloop?</strong></a></p>
2244 <dl>
2245 <dd>
2246 Autoconfig et al are not available on all the platforms where the IMAP
2247 toolkit is supported; and do not work correctly on some of the
2248 platforms where they do exist. Furthermore, these programs add another
2249 layer of complexity to an already complex process.
2251 <p>Coaxing software that uses autoconfig to build properly on platforms
2252 which were not specifically considered by that software wastes an
2253 inordinate amount of time. When (not if) autoconfig fails to do the
2254 right thing, the result is an inpenetrable morass to untangle in order
2255 to find the problem and fix it.</p>
2257 <p>The concept behind autoconfig is good, but the execution is flawed.
2258 It rarely does the right thing on a platform that wasn't specifically
2259 considered. Human life is too short to debug autoconfig problems,
2260 especially since the current mechanism is so much easier.</p>
2261 </dd>
2262 </dl>
2265 <hr>
2268 waste disk and memory space?</strong></a></p>
2270 <dl>
2271 <dd>
2272 From time to time a submitted port has snuck in without -g. This has
2274 excuses for not using -g in a port:
2276 <ul>
2279 <li>An alternate form of -g is needed with optimization, e.g.
2280 -g3.</li>
2281 </ul>
2283 <p>There will be no new ports added without -g (or a suitable
2284 alternative) being set.</p>
2286 <p>-g has not been arbitrarily added to the ports which do not
2287 currently have it because we don't know if doing so would break the
2289 lead to the correct -g setting being determined and permanently
2290 added.</p>
2292 <p>Processors are fast enough (and disk space is cheap enough) that -g
2293 should be automatic in all compilers with no way of turning it off, and
2294 /bin/strip should be a symlink to /bin/true. Human life is too short to
2295 deal with binaries built without -g. Such binaries should be a bad
2296 memory of the days of KIPS processors and disks that costs several
2297 dollars per kilobyte.</p>
2298 </dd>
2299 </dl>
2302 <hr>
2305 library?</strong></a></p>
2307 <dl>
2308 <dd>
2309 All too often, shared libraries create far more problems than they
2310 solve.
2312 <p>Remember that you only gain the benefit of a shared library when
2313 there are multiple applications which use that shared library. Even
2314 without shared libraries, on most modern operating systems (and many
2315 ancient ones too!) applications will share their text segments between
2316 across multiple processes running the same application. This means that
2317 if your system only runs one application (e.g. imapd) that uses the
2318 c-client library, then you gain no benefit from making c-client a
2319 shared library even if it has 100 imapd processes. You will, however
2320 suffer added complexity.</p>
2322 <p>If you have a server system that just runs imapd and ipop3d, then
2323 making c-client a shared library will save just one copy of c-client no
2324 matter how many IMAP/POP3 processes are running.</p>
2326 <p>The problem with shared libraries is that you have to keep around a
2327 copy of the library every time something changes in the library that
2328 would affect the interface the library presents to the application. So,
2329 you end up having many copies of the same shared library.</p>
2331 <p>If you don't keep multiple copies of the shared library, then one of
2332 two things happens. If there was proper versioning, then you'll get a
2334 don't match" and the application won't run. Otherwise, the application
2335 will run, but will fail in mysterious ways.</p>
2337 <p>Several sites and third-party distributors have modified the
2338 c-client makefile in order to make c-client be a shared library.
2340 mysterious ways because of a library compatibility problem, the result
2341 is a bug report. A lot of time and effort ends up getting wasted
2342 investigating such bug reports.</p>
2344 <p>Memory is so cheap these days that it's not worth it. Human life is
2345 too short to deal with shared library compatibility problems.</p>
2346 </dd>
2347 </dl>
2350 <hr>
2353 support?</strong></a></p>
2355 <dl>
2357 </dl>
2360 <hr>
2363 directory by default?</strong></a></p>
2365 <dl>
2366 <dd>
2367 The IMAP server has no way of knowing what you might call "mail" as
2368 opposed to "some other file"; in fact, you can use IMAP to access any
2369 file.
2371 <p>The IMAP server also doesn't know whether your preferred
2373 "Mailboxes/", or any of a zillion other possibilities. If one such name
2374 were chosen, it would undoubtably anger the partisans of all the other
2375 names.</p>
2377 <p>It is possible to modify the software so that the default connected
2378 directory is someplace else. Please read the file CONFIG for discussion
2379 of this and other issues.</p>
2380 </dd>
2381 </dl>
2384 <hr>
2387 and play for me?</strong></a></p>
2389 <dl>
2390 <dd>
2391 There is no standard for how mail is stored on Windows; nor a single
2392 standard SMTP server. The closest to either would be the SMTP server in
2393 Microsoft's IIS.
2395 <p>So there's no default by which to make assumptions. As the software
2396 is set up, it assumes that the each user has an Windows login account
2397 and private home directory, and that mail is stored on that home
2398 directory as files in one of the popular UNIX formats. It also assumes
2399 that there is some tool equivalent to inetd on UNIX that does the
2400 TCP/IP listening and server startup.</p>
2402 <p>Basically, unless you're an email software hacker, you probably want
2403 to look elsewhere if you want IMAP/POP servers for Windows.</p>
2404 </dd>
2405 </dl>
2408 <hr>
2412 you using the full size?</strong></a></p>
2414 <dl>
2415 <dd>
2416 This is to avoid an interoperability problem with:
2418 <ul>
2419 <li>PC IMAP clients that use Microsoft's SChannel.DLL (SSPI) for SSL
2420 support</li>
2423 </ul>
2425 <p>SChannel has a bug that makes it think that the maximum SSL data
2427 make sure that it never transmits full sized SSL packets.</p>
2430 or...) is that it corresponds with the TCP buffer size that the
2431 software uses elsewhere for input; there's a slight performance benefit
2432 to having the two sizes correspond or at least be a multiple of each
2433 other. Also, it keeps the size as a power of two, which might be
2434 significant on some platforms.</p>
2436 <p>There wasn't a significant difference that we could measure between
2439 <p>Microsoft has developed a hotfix for this bug. Look up MSKB article
2440 number 300562. Contrary to the article text which implies that this is
2441 a Alpine issue, this bug also affects Microsoft Exchange server with
2443 </dd>
2444 </dl>
2447 <hr>
2450 of just INBOX?</strong></a></p>
2452 <dl>
2453 <dd>
2454 It's a long story. In brief, the mh format driver is less functional
2455 than any of the other drivers. It turned out that there were some users
2456 (including high-level administrators) who tried mh years ago and no
2457 longer use it, but still had an mh profile left behind.
2459 <p>When the mh driver used INBOX, it would see the mh profile, and
2460 proceed to move the user's INBOX into the mh format INBOX. This caused
2461 considerable confusion as some things stopped working.</p>
2462 </dd>
2463 </dl>
2466 <hr>
2469 format?</strong></a></p>
2471 <dl>
2472 <dd>
2473 It is technically difficult to support maildir in IMAP while
2474 maintaining acceptable performance, robustness, following the
2475 requirements of the IMAP protocol specification, and following the
2476 requirements of maildir.
2478 <p>No one has succeeded in accomplishing all four together. The various
2479 maildir drivers offered as patches all have these problems. The problem
2480 is exacerbated because this implementation supports multiple formats;
2481 consequently this implementation can't make any performance shortcuts
2482 by assuming that all the world is maildir.</p>
2484 <p>We can't do a better job than the maildir fan community has done
2485 with their maildir drivers. Similarly, if the maildir fan community
2486 provides the maildir driver, they take on the responsibility for
2487 answering maildir-specific support questions. This is as it should be,
2488 and that is why maildir support is left to the maildir fan
2489 community.</p>
2490 </dd>
2491 </dl>
2494 <hr>
2497 format?</strong></a></p>
2499 <dl>
2500 <dd>
2501 There's no point to doing so. An implementation which supports multiple
2502 formats will never do as well as one which is optimized to support one
2503 single format.
2505 <p>If you want to use Cyrus mailbox format, you should use the Cyrus
2506 server, which is the native implementation of that format and is
2507 specifically optimized for that format. That's also why Cyrus doesn't
2508 implement any other format.</p>
2509 </dd>
2510 </dl>
2513 <hr>
2516 system?</strong></a></p>
2518 <dl>
2519 <dd>
2520 This is because your system only has fcntl() style locking and not
2521 flock() style locking. fcntl() locking has a design flaw that causes a
2522 close() to release any locks made by that process on the file opened on
2523 that file descriptor, even if the lock was made on a different file
2524 descriptor.
2526 <p>This design flaw causes unexpected loss of lock, and consequent
2527 mailbox corruption. The workaround is to do certain "dangerous
2528 operations" in another fork, thus avoiding doing a close() in the
2529 vulnerable fork.</p>
2531 <p>The best way to solve this problem is to upgrade your SVR4 (Solaris,
2532 AIX, HP-UX, SGI) or OSF/1 system to a more advanced operating system,
2533 such as Linux or BSD. These more advanced operating systems have
2534 fcntl() locking for compatibility with SVR4, but also have flock()
2535 locking.</p>
2538 function in their C library that is just a jacket that does an fcntl()
2539 lock. This is not a true flock(), and has the same design flaw as
2540 fcntl().</p>
2541 </dd>
2542 </dl>
2545 <hr>
2549 files? My other mail program just considers every line that starts with
2552 <dl>
2553 <dd>
2554 You just answered your own question. If any line that starts with
2557 to be quoted (typically by prefixing a ">" character). People
2558 complain about this -- "why did a > get stuck in my message?"
2560 <p>So, good mail reading software only considers a line to be a
2562 for a "From " line. This means, among other things, that the day of
2566 common, although POSIX also allows a numeric timezone after the
2567 year. For compatibility with ancient software, the seconds are optional,
2568 the timezone may appear before the year, the old 3-letter timezones are
2569 also permitted, and "remote from xxx" may appear after the whole
2570 thing.</p>
2572 <p>Unfortunately, some software written by novices use other formats.
2573 The most common error is to have a variable-width day of month, perhaps
2576 describes internal formats). I've seen a few other goofs, such as a
2577 single-digit second, but these are less common.</p>
2579 <p>If you are writing your own software that writes mailbox files, and
2580 you really aren't all that savvy with all the ins and outs and ancient
2581 history, you should seriously consider using the c-client library (e.g.
2582 routine mail_append()) instead of doing the file writes yourself. If
2583 you must do it yourself, use ctime(), as in:</p>
2584 <pre>
2586 </pre>rather than try to figure out a good format yourself. ctime() is the
2587 most traditional format and nobody will flame you for using it.
2588 </dd>
2589 </dl>
2592 <hr>
2595 format?</strong></a></p>
2597 <dl>
2599 server is the only one that completely interoperates with legacy UNIX
2600 mail tools.</dd>
2601 </dl>
2604 <hr>
2607 -- FOLDER INTERNAL DATA" message at the start of traditional UNIX and
2608 MMDF format mailboxes?</strong></a></p>
2610 <dl>
2611 <dd>
2612 This pseudo-message serves two purposes.
2614 <p>First, it establishes the mailbox format even when the mailbox has
2615 no messages. Otherwise, a mailbox with no messages is a zero-byte file,
2616 which could be one of several formats.</p>
2618 <p>Second, it holds mailbox metadata used by IMAP: the UID validity,
2619 the last assigned UID, and mailbox keywords. Without this metadata,
2620 which must be preserved even when the mailbox has no messages, the
2621 traditional UNIX format wouldn't be able to support the full
2622 capabilities of IMAP.</p>
2623 </dd>
2624 </dl>
2627 <hr>
2630 first real message of the mailbox instead of writing this fake FOLDER
2631 INTERNAL DATA message?</strong></a></p>
2633 <dl>
2634 <dd>
2635 In fact, that is what is done if the mailbox is non-empty and does not
2636 already have a FOLDER INTERNAL DATA message.
2638 <p>One problem with doing that is that if some external program removes
2639 the first message, the metadata is lost and must be recreated, thus
2640 losing any prior UID or keyword list status that IMAP clients may
2641 depend upon.</p>
2643 <p>Another problem is that this doesn't help if the last message is
2644 deleted. This will result in an empty mailbox, and the necessity to
2645 create a FOLDER INTERNAL DATA message.</p>
2646 </dd>
2647 </dl>
2650 <hr>
2653 default?</strong></a></p>
2655 <dl>
2657 mention compatibility with user expectations when using shell tools.</dd>
2658 </dl>
2661 <hr>
2664 Solaris?</strong></a></p>
2666 <dl>
2667 <dd>
2668 It is a long, long story about why cc is set to ucbcc. You need to
2669 invoke the C compiler so that it links with the SVR4 libraries and not
2670 the BSD libraries, otherwise readdir() will return the wrong
2671 information.
2673 <p>Of all the names in the most common path, ucbcc is the only name to
2674 be found (on /usr/ccs/bin) that points to a suitable compiler. cc is
2675 likely to be /usr/ucb/cc which is absolutely not the compiler that you
2676 want. The real SVR4 cc is probably something like /opt/SUNWspro/bin/cc
2677 which is rarely in anyone's path by default.</p>
2679 <p>ucbcc is probably a link to acc, e.g. /opt/SUNWspro/SC4.0/bin/acc,
2680 and is the UCB C compiler using the SVR4 libraries.</p>
2682 <p>If ucbcc isn't on your system, then punt on the SUN C compiler and
2683 use gcc instead (the gso port instead of the sol port).</p>
2686 to "cc", you will probably find that the -O2 needs to be changed to -O.
2687 If you don't get any error messages with -O2, that's a pretty good
2688 indicator that you goofed and are running the compiler that will link
2689 with the BSD libraries.</p>
2693 <ul>
2694 <li>The sol port is designed to be built using the UCB compiler using
2695 the SVR4 libraries. This compiler is "ucbcc", which is lunk to acc.
2696 You use -O2 as one of the CFLAGS.</li>
2698 <li>If you build the sol port with the UCB compiler using the BSD
2699 libraries, you will get no error messages but you will get bad
2700 binaries (the most obvious symptom is dropping the first two
2701 characters return filenames from the imapd LIST command. This
2702 compiler also uses -O2, and is very often what the user gets from
2705 <li>If you build the sol port with the real SVR4 compiler, which is
2706 often hidden away or unavailable on many systems, then you will get
2707 errors from -O2 and you need to change that to -O. But you will get a
2708 good binary. However, you should try it with -O2 first, to make sure
2709 that you got this compiler and not the UCB compiler using BSD
2710 libraries.</li>
2711 </ul>
2712 </dd>
2713 </dl>
2716 <hr>
2719 libraries? cc is the right thing on my Solaris system!</strong></a></p>
2721 <dl>
2722 <dd>
2723 Because there still are sites that use such systems. On those systems,
2724 the assumption that "cc" does the right thing will lead to corrupt
2725 binaries with no error message or other warning that anything is amiss.
2728 </dd>
2729 </dl>
2732 <hr>
2735 spool directory?</strong></a></p>
2737 <dl>
2739 with the spool directory, especially software which delivers mail.
2740 Otherwise, it is possible to lose mail.</dd>
2741 </dl>
2744 <hr>
2747 past?</strong></a></p>
2749 <dl>
2750 <dd>This is one of those questions in which the answer never convinces
2751 those who ask it. Somehow, everybody who ever asks this question ends up
2752 answering it for themselves as they get older, with the very answer that
2753 they rejected years earlier.</dd>
2754 </dl>
2757 <hr>
2759 <p><br></p>
2762 <hr>
2765 messages?</strong></a></p>
2767 <dl>
2768 <dd>
2769 If you are seeing "0 messages" when you open INBOX and you know you
2770 have messages there (and perhaps have looked at your mail spool file
2771 and see that messages are there), then probably there is something
2772 wrong with the very first line of your mail spool file. Make sure that
2773 the first five bytes of the file are "From ", followed by an email
2774 address and a date/time in ctime() format, e.g.:
2775 <pre>
2777 </pre>
2778 </dd>
2779 </dl>
2782 <hr>
2785 been concatenated into one message which claims to be from me and has a
2786 subject of the file name of the mailbox! What's going
2787 on?</strong></a></p>
2789 <dl>
2790 <dd>
2791 Something wrong with the very first line of the mailbox. Make sure that
2792 the first five bytes of the file are "From ", followed by an email
2793 address and a date/time in ctime() format, e.g.:
2794 <pre>
2796 </pre>
2797 </dd>
2798 </dl>
2801 <hr>
2804 failed: Can't create mailbox node xxxxxxxxx: File exists</tt>
2807 <dl>
2810 </dl>
2813 <hr>
2816 password are right!</strong></a></p>
2818 <dl>
2819 <dd>
2820 There are a myriad number of possible answers to this question. The
2821 only way to say for sure what is wrong is run the server under a
2822 debugger such as gdb while root (yes, you must be root) with a
2823 breakpoint at routines checkpw() and loginpw(), then single-step until
2824 you see which test rejected you. The server isn't going to give any
2825 error messages other than "login failed" in the name of not giving out
2826 any unnecessary information to unauthorized individuals.
2830 <ul>
2831 <li>You didn't really give the correct user name and/or
2832 password.</li>
2834 <li>Your client doesn't send the LOGIN command correctly; for
2835 example, IMAP2 clients won't send a password containing a "*"
2836 correctly to an IMAP4 server.</li>
2838 <li>If you have set up a CRAM-MD5 database, remember that the
2839 password used is the one in the CRAM-MD5 database, and furthermore
2840 that there must also be an entry in /etc/passwd (but the /etc/passwd
2841 password is not used).</li>
2843 <li>If you are using PAM, have you created a service file for the
2844 server in /etc/pam.d?</li>
2846 <li>If you are using shadow passwords, have you used an appropriate
2847 port when building? In particular, note that "lnx" is for Linux
2849 instead.</li>
2851 <li>If your system has account or password expirations, check to see
2852 that the expiration date hasn't passed.</li>
2855 your own safety, not to mention the fact that the servers use UID 0
2857 </ul>
2858 </dd>
2859 </dl>
2862 <hr>
2865 of POP and IMAP servers, many logged in as the same
2866 user!</strong></a></p>
2868 <dl>
2869 <dd>
2870 Certain inferior losing GUI mail reading programs have a "synchronize
2872 (POP) feature which causes a rapid and unchecked spawning of servers.
2874 <p>This is not a problem in the server; the client is really asking for
2875 all those server sessions. Unfortunately, there isn't much that the POP
2876 and IMAP servers can do about it; they don't spawned themselves.</p>
2878 <p>Some sites have added code to record the number of server sessions
2879 spawned per user per hour, and disable login for a user who has
2880 exceeded a predetermined rate. This doesn't stop the servers from being
2881 spawned; it just means that a server session will commit suicide a bit
2882 faster.</p>
2884 <p>Another possibility is to detect excessive server spawning activity
2885 at the level where the server is spawned, which would be inetd or
2886 possibly tcpd. The problem here is that this is a hard time to
2887 quantify. 50 sessions in a minute from a multi-user timesharing system
2888 may be perfectly alright, whereas 10 sessions a minute from a PC may be
2889 too much.</p>
2891 <p>The real solution is to fix the client configuration, by disabling
2892 those evil features. Also tell the vendors of those clients how you
2893 feel about distributing denial-of-service attack tools in the guise of
2894 mail reading programs.</p>
2895 </dd>
2896 </dl>
2899 <hr>
2904 bytes of new mail to /home/user/mbox from /var/spool/mail/user</tt>
2907 <dl>
2908 <dd>
2909 This is probably caused by the mbox driver. If the file "mbox" exists
2910 on the user's home directory and is in UNIX mailbox format, then when
2911 INBOX is opened this file will be selected as INBOX instead of the mail
2912 spool file. Messages will be automatically transferred from the mail
2913 spool file into the mbox file.
2916 in the top-level Makefile and rebuild. Note that if you do this, users
2917 won't be able to access the messages that have already been moved to
2918 mbox unless they open mbox instead of INBOX.</p>
2919 </dd>
2920 </dl>
2923 <hr>
2926 fully-qualified domain name?</strong></a><br>
2928 From/Sender/Message-ID headers of outgoing mail not coming out as a
2929 fully-qualified domain name?</strong></a></p>
2931 <dl>
2932 <dd>
2933 Your UNIX system is misconfigured. The entry for your system in
2934 /etc/hosts must have the fully-qualified domain name first, e.g.
2935 <pre>
2936 105.69.1.234 myserver.example.com myserver
2937 </pre>
2939 <p>A common mistake of novice system administrators is to have the
2940 short name first, e.g.</p>
2941 <pre>
2942 105.69.1.234 myserver myserver.example.com
2944 </pre>
2947 <pre>
2948 105.69.1.234 myserver
2949 </pre>
2951 <p>The result of this is that when the IMAP toolkit does a
2952 gethostbyname() call to get the fully-qualified domain name, it would
2955 <p>On some systems, a configuration file (typically named
2956 /etc/svc.conf, /etc/netsvc.conf, or /etc/nsswitch.conf) can be used to
2957 configure the system to use the domain name system (DNS) instead of
2958 /etc/hosts, so it doesn't matter if /etc/hosts is misconfigured.</p>
2960 <p>Check the man pages for gethostbyname, hosts, svc, and/or netsvc for
2961 more information.</p>
2963 <p>Unfortunately, certain vendors, most notably SUN, have failed to
2964 make this clear in their documentation. Most of SUN's documentation
2965 assumes a corporate network that is not connected to the Internet.</p>
2968 append the results of getdomainname() to the name returned by
2969 gethostname(), and some versions of sendmail configuration files were
2970 distributed that did this. This was incorrect; the string returned from
2971 getdomainname() is the Yellow Pages (a.k.a NIS) domain name, which is a
2972 completely different (albeit unfortunately named) entity from an
2973 Internet domain. These were often fortuitously the same string, except
2974 when they weren't. Frequently, this would result in host names with
2975 spuriously doubled domain names, e.g.</p>
2976 <pre>
2977 myserver.example.com.example.com
2979 </pre>
2981 <p>This practice has been thoroughly discredited for many years, but
2982 folklore dies hard.</p>
2983 </dd>
2984 </dl>
2987 <hr>
2993 <dl>
2994 <dd>
2995 In order to update a mailbox in the default UNIX format, it is
2996 necessary to create a lock file to prevent the mailer from delivering
2997 mail while an update is in progress. Some systems use a directory
2998 protection of 775, requiring that all mail handling programs be setgid
2999 mail; or of 755, requiring that all mail handling programs be setuid
3000 root.
3002 <p>The IMAP toolkit does not run with any special privileges, and I
3003 plan to keep it that way. It is antithetical to the concept of a
3004 toolkit if users can't write their own programs to use it. Also, I've
3005 had enough bad experiences with security bugs while running privileged;
3006 the IMAP and POP servers have to be root when not logged in, in order
3007 to be able to log themselves in. I don't want to go any deeper down
3008 that slippery slope.</p>
3011 systems. If you can't trust your users with a 1777 mail spool (petty
3012 harassment is about the limit of the abuse exposure), then you have
3013 much worse problems then that.</p>
3015 <p>If you absolutely insist upon requiring privileges to create a lock
3016 file, external file locking can be done via a setgid mail program named
3017 /etc/mlock (this is defined by LOCKPGM in the c-client Makefile). If
3019 the directory by itself, it will try to call mlock to do it. I do not
3020 recommend doing this for performance reasons.</p>
3023 tried to make this sample program secure, but it has not been
3024 thoroughly audited.</p>
3025 </dd>
3026 </dl>
3029 <hr>
3032 open by another process, access is readonly</tt> <strong>mean? How do I
3033 fix this?</strong></a></p>
3035 <dl>
3036 <dd>
3037 A problem occurred in applying a lock to a /tmp lock file. Either some
3038 other program has the mailbox open and won't relenquish it, or
3039 something is wrong with the protection of /tmp or the lock.
3042 scripts incorrectly set the protection of the /tmp directory to 775,
3043 which disables /tmp for all non-privileged programs.</p>
3044 </dd>
3045 </dl>
3048 <hr>
3051 write access to mailbox, access is readonly</tt>
3054 <dl>
3056 </dl>
3059 <hr>
3064 <dl>
3065 <dd>
3066 Make sure that your mailbox is not read-only: that the mailbox is owned
3067 by you and write enabled (protection 0600), and that the /tmp directory
3068 is longer world-writeable. /tmp must be world-writeable because lots of
3069 applications use it for scratch space. To fix this, do
3070 <pre>
3072 chmod 1777 /tmp
3073 </pre>as root.
3075 <p>Make sure that your POP3 client issues a QUIT command when it
3076 finishes. The POP3 protocol specifies that deletions are discarded
3077 unless a proper QUIT is done.</p>
3079 <p>Make sure that you are not opening multiple POP3 sessions to the
3080 same mailbox. It is a requirement of the POP3 protocol than only one
3081 POP3 session be in effect to a mailbox at a time, however some,
3082 poorly-written POP3 clients violate this. Also, some background "check
3083 for new mail" tasks also cause a violation. See the answer to the
3086 </dd>
3087 </dl>
3090 <hr>
3093 <pre>
3094 Message ... UID ... already has UID ...
3095 Message ... UID ... less than ...
3096 Message ... UID ... greater than last ...
3097 Invalid UID ... in message ..., rebuilding UIDs
3098 </pre>
3102 <dl>
3103 <dd>
3104 Something happened to corrupt the unique identifier regime in the
3105 mailbox. In traditional UNIX-format mailboxes, this can happen if the
3106 user deleted the "DO NOT DELETE" internal message.
3108 <p>This problem is relatively harmless; a new valid unique identifier
3109 regime will be created. The main effect is that any references to the
3110 old UIDs will no longer be useful.</p>
3112 <p>So, unless it is a chronic problem or you feel like debugging, you
3113 can safely ignore these messages.</p>
3114 </dd>
3115 </dl>
3118 <hr>
3121 <pre>
3122 Unable to read internal header at ...
3123 Unable to find CRLF at ...
3124 Unable to parse internal header at ...
3125 Unable to parse message date at ...
3126 Unable to parse message flags at ...
3127 Unable to parse message UID at ...
3128 Unable to parse message size at ...
3129 Last message (at ... ) runs past end of file ...
3130 </pre>
3134 <dl>
3135 <dd>
3136 The mbx-format mailbox is corrupted and needs to be repaired.
3138 <p>You should make an effort to find out why the corruption happened.
3139 Was there an obvious system problem (crash or disk failure)? Did the
3140 user accidentally access the file via NFS? Mailboxes don't get
3141 corrupted by themselves; something caused the problem.</p>
3143 <p>Some people have developed automated scripts, but if you're
3144 comfortable using emacs it's pretty easy to fix it manually. Do
3146 editor can handle binary!!!</p>
3148 <p>If you are not comfortable with emacs, or if the file is too large
3149 to read with emacs, see the "step-by-step" technique later on for
3150 another way of doing it.</p>
3153 to when it got unhappy with the file, e.g. if you see:</p>
3154 <pre>
3155 Unable to parse internal header at 43921: ne bombastic blurdybloop
3157 need to fix. c-client is expecting an internal header at that byte number,
3158 looking something like:
3159 <pre>
3161 </pre>The format of this internal line is:
3162 <pre>
3163 dd-mmm-yyyy hh:mm:ss +zzzz,ssss;ffffffffFFFF-UUUUUUUU
3165 digits as needed. All other fields (inluding the "dd") are fixed width. So,
3166 the easiest thing to do is to look forward in the file for the next internal
3167 header, and delete everything from the error point to that internal header.
3169 <p>Here's what to do if you want to be smarter and do a little bit more
3170 work. Generally, you're in the middle of a message, and there's nothing
3171 wrong with that message. The problem happened in the *previous*
3172 message. So, search back to the previous internal header. Now, remember
3175 <p>Mark where you are in the file, move the cursor to the line after
3176 the internal header, and skip that many bytes ("ssss") forward. If
3177 you're at the point of the error in the file, then that message is
3178 corrupt. If you're at a different point, then perhaps the previous
3179 message is corrupt and has a too long size count that "ate" into this
3180 message.</p>
3182 <p>Basically, what you need to do is make sure that all those size
3183 counts are right, and that moving "ssss" bytes from the line after the
3184 internal header will land you at another internal header.</p>
3186 <p>Usually, once you know what you're looking at, it's pretty easy to
3187 work out the corruption, and the best remedial action. Repair scripts
3188 will make the problem go away but may not always do the smartest/best
3189 salvage of the user's data. Manual repair is more flexible and usually
3190 preferable.</p>
3192 <p>Here is a step-by-step technique for fixing corrupt mbx files that's
3193 a bit cruder than the procedure outlined above, but works for any size
3194 file.</p>
3196 <p>In this example, suppose that the corrupt file is INBOX, the error
3197 message is</p>
3198 <pre>
3199 Unable to find CRLF at 132551754
3202 <p>The first step is to split the mailbox file at the point of the
3203 error:</p>
3205 <ul>
3209 such as INBOX.new.</li>
3212 INBOX.bad into another file, such as INBOX.tail.</li>
3216 as the point to split INBOX into two new files, INBOX.new and
3217 INBOX.tail.
3221 <ul>
3224 <li>The last message of INBOX.new is probably corrupted. Copy it to
3225 another file, such as badmsg.1, then delete and expunge that last
3226 message from INBOX.new</li>
3228 <li>Locate the first occurance of text in INBOX.tail which looks like
3229 an internal header, as described above.</li>
3231 <li>Remove all the text which occurs prior to that point, and place
3232 it into another file, such as badmsg.2. Note that in the case of a
3233 single digit date, there is a leading space which must not be removed
3235 </ul>
3239 <ul>
3245 </ul>
3249 <ul>
3250 <li>Check to see if you have received any new messages while
3251 repairing INBOX.</li>
3253 <li>If you haven't received any new messages while repairing INBOX,
3254 just rename INBOX.new to INBOX.</li>
3256 <li>If you have received new messages, be sure to copy the new
3257 messages from INBOX to INBOX.new before doing the rename.</li>
3258 </ul>
3260 <p>You now have a working INBOX, as well as two files with corrupted
3262 badmsg files that you might want to try salvaging; otherwise you can
3263 delete the two badmsg files.</p>
3264 </dd>
3265 </dl>
3268 <hr>
3271 <pre>
3273 imap/tcp server failing (looping)
3274 pop3/tcp server failing (looping)
3275 </pre>
3277 <p><strong>mean? When it happens, the listed service shuts down. How can I
3278 fix this?</strong></p>
3280 <dl>
3281 <dd>
3282 The error message "server failing (looping), service terminated" is not
3283 from either the IMAP or POP servers. Instead, it comes from inetd, the
3284 daemon which listens for TCP connections to a number of servers,
3285 including the IMAP and POP servers.
3288 particular service. If more than 40 sessions are initiated in a minute,
3289 inetd will issue the "failing (looping), service terminated" message
3290 and shut down the service for 10 minutes. inetd does this to prevent
3291 system resource consumption by a client which is spawning infinite
3292 numbers of servers. It should be noted that this is a denial of
3293 service; however for some systems the alternative is a crash which
3294 would be a worse denial of service!</p>
3297 limit was established many years ago when a system typically only ran a
3298 few dozen servers.</p>
3300 <p>On some versions of inetd, such as the one distributed with most
3302 file to have a larger number of servers by appending a period followed
3304 entry. For example, if your existing /etc/inetd.conf line reads:</p>
3305 <pre>
3306 imap stream tcp nowait root /usr/etc/imapd imapd
3307 </pre>try changing it to be:
3308 <pre>
3309 imap stream tcp nowait.100 root /usr/etc/imapd imapd
3310 </pre>Another example (using TCP wrappers):
3311 <pre>
3312 imap stream tcp nowait root /usr/sbin/tcpd imapd
3313 </pre>try changing it to be:
3314 <pre>
3315 imap stream tcp nowait.100 root /usr/sbin/tcpd imapd
3320 inetd" to determine whether or not your inetd has this feature. If it
3321 does not, and you make this change, the likely outcome is that you will
3322 disable IMAP service entirely.</p>
3324 <p>Another way to fix this problem is to edit the inetd.c source code
3325 (provided by your UNIX system vendor) to set higher limits, rebuild
3326 inetd, install the new binary, and reboot your system. This should only
3327 be done by a UNIX system expert. In the inetd.c source code, the limits
3330 (normally 600) is the number of seconds inetd will shut down the server
3331 after it exceeds TOOMANY.</p>
3332 </dd>
3333 </dl>
3336 <hr>
3342 <dl>
3343 <dd>
3344 This usually means that some "helpful" security script person has
3345 protected /tmp so that it is no longer world-writeable. /tmp must be
3346 world-writeable because lots of applications use it for scratch space.
3347 To fix this, do
3348 <pre>
3349 chmod 1777 /tmp
3351 </pre>as root.
3353 <p>If that isn't the answer, check the protection of the named file. If
3354 it is something other than 666, then either someone is hacking or some
3355 "helpful" person modified the code to have a different default lock
3356 file protection.</p>
3357 </dd>
3358 </dl>
3361 <hr>
3364 <pre>
3365 Command stream end of file, while reading line user=... host=...
3366 Command stream end of file, while reading char user=... host=...
3367 Command stream end of file, while writing text user=... host=...
3368 </pre>
3372 <dl>
3373 <dd>
3374 This message occurs when the session is disconnected without a proper
3375 LOGOUT (IMAP) or QUIT (POP) command being received by the server first.
3377 <p>In many cases, this is perfectly normal; many client implementations
3378 are impolite and do this. Some programmers think this sort of rudeness
3381 <p>The condition could, however, indicate a client or network
3382 connectivity problem. The server has no way of knowing whether there's
3383 a problem or just a rude client, so it issues this message instead of a
3384 Logout.</p>
3386 <p>Certain inferior losing clients disconnect abruptly after a failed
3387 login, and instead of saying that the login failed, just say that they
3388 can't access the mailbox. They then complain to the system manager, who
3389 looks in the syslog and finds this message. Not very helpful, eh? See
3393 <p>If the user isn't reporting a problem, you can probably ignore this
3394 message.</p>
3395 </dd>
3396 </dl>
3399 <hr>
3402 disconnect? The syslog has the message:</strong> <tt>Killed (lost
3403 mailbox lock) user=... host=...</tt></a></p>
3405 <dl>
3406 <dd>
3407 This message only happens when either the traditional UNIX mailbox
3408 format or MMDF format is in use. This format only allows one session to
3409 have the mailbox open read/write at a time.
3411 <p>The servers assume that if a second session attempts to open the
3412 mailbox, that means that the first session is probably owned by an
3413 abandoned client. The common scenario here is a user who leaves his
3414 client running at the office, and then tries to read his mail from
3416 second session requests the first session to kill itself. When the
3418 mailbox lock)" syslog message and terminates. The second session then
3421 <p>Certain poorly-designed clients routinely open multiple sessions to
3422 the same mailbox; the users of those clients tend to get this message a
3423 lot.</p>
3426 task which does its work by opening a POP session to server every few
3427 seconds. They do this because POP doesn't have a way to announce new
3428 mail.</p>
3430 <p>The solution to both situations is to replace the client with a good
3431 online IMAP client such as Alpine. Life is too short to waste on POP
3432 clients and poorly-designed IMAP clients.</p>
3433 </dd>
3434 </dl>
3437 <hr>
3440 system, recursively from the UNIX root directory?</strong></a><br>
3442 recursively from my UNIX home directory?</strong></a></p>
3444 <dl>
3445 <dd>
3446 A well-written client should only show one level of hierarchy and then
3447 stop, awaiting explicit user action before going lower. However, some
3448 poorly-designed clients will recursively list all files, which may be a
3449 very long list (especially if you have symbolic links to directories
3450 that create a loop in the filesystem graph!).
3452 <p>This behavior has also been observed in some third-party c-client
3453 drivers, including maildir drivers. Consequently, this problem has even
3454 been observed in Alpine. It is important to understand that this is not a
3455 problem in Alpine or c-client; it is a problem in the third-party driver.
3456 A Alpine built without that third-party driver will not have this
3457 problem.</p>
3460 all my files in my home directory?</a></p>
3461 </dd>
3462 </dl>
3465 <hr>
3471 <dl>
3472 <dd>
3473 These are IMAP namespace names. They represent other hierarchies in
3474 which messages may exist. These hierarchies may not necessarily exist
3475 on a server, but the namespace name is still in the namespace list in
3476 order to mark it as reserved.
3478 <p>A few poorly-designed clients display all namespace names as if they
3479 were top-level mailboxes in a user's list of mailboxes, whether or not
3480 they actually exist. This is a flaw in those clients.</p>
3481 </dd>
3482 </dl>
3485 <hr>
3488 home directory?</strong></a></p>
3490 <dl>
3491 <dd>
3492 As distributed, the IMAP server is connected to your home directory by
3493 default. It has no way of knowing what you might call "mail" as opposed
3494 to "some other file"; in fact, you can use IMAP to access any file.
3496 <p>Most clients have an option to configure your connected directory on
3497 the IMAP server. For example, in Alpine you can specify this as the
3499 <pre>
3500 Nickname : Secondary Folders
3501 Server : imap.example.com
3502 Path : mail/
3503 View :
3505 his home directory.
3509 <p>It is possible to modify the IMAP server so that all users are
3510 automatically connected to some other directory, e.g. a subdirectory of
3511 the user's home directory. Read the file CONFIG for more details.</p>
3512 </dd>
3513 </dl>
3516 <hr>
3519 to the IMAP or POP server, no matter what client I use?</strong></a></p>
3521 <dl>
3522 <dd>
3523 There are two common occurances of this problem:
3525 <ul>
3526 <li>You are running a system (e.g. certain versions of Linux) which
3528 server on your client. However, a firewall or NAT box is blocking
3529 connections to that port, so the connection attempt times out.
3531 <p>The IDENT protocol is a well-known bad idea that does not
3532 deliver any real security but causes incredible problems. The idea
3533 is that this will give the server a record of the user name, or at
3534 least what some program listening on port 113 says is the user
3535 name. So, if somebody coming from port nnnnn on a system does
3536 something bad, IDENT may give you the userid of the bad guy.</p>
3538 <p>The problem is, IDENT is only meaningful on a timesharing system
3539 which has an administrator who is privileged and users who are not.
3540 It is of no value on a personal system which has no separate
3543 <p>On either type of system, security-minded people either turn
3544 IDENT off or replace it with an IDENT server that lies. Among other
3545 things, IDENT gives spammers the ability to harvest email addresses
3546 from anyone who connects to a web page.</p>
3548 <p>This problem has been showing up quite frequently on systems
3549 which use xinetd instead of inetd. Look for files named
3550 /etc/xinetd.conf, /etc/xinetd.d/imapd, /etc/inetd.d/ipop2d, and
3551 /etc/xinetd.d/ipop3d. In those files, look for lines containing
3553 <pre>
3554 log_on_success += USERID
3555 </pre>Hunt down such lines, and delete them ruthlessly from all files in
3556 which they occur. Don't be shy about it.
3557 </li>
3559 <li>The DNS is taking a long time to do a reverse DNS (PTR record)
3560 lookup of the IP address of your client. This is a problem in your
3561 DNS, which either you or you ISP need to resolve. Ideally, the DNS
3562 should return the client's name; but if it can't it should at least
3563 return an error quickly.</li>
3564 </ul>
3566 <p>As you may have noticed, neither of these are actual problems in the
3567 IMAP or POP servers; they are configuration issues with either your
3568 system or your network infrastructure. If this is all new to you, run
3569 (don't walk) to the nearest technical bookstore and get yourself a good
3570 pedagogical text on system administration for the type of system you
3571 are running.</p>
3572 </dd>
3573 </dl>
3576 <hr>
3579 c-client based application call before I get connected to the IMAP
3580 server? The hang seems to be in the c-client mail_open() call. I don't
3581 have this problem with any other IMAP client. There is no delay
3582 connecting to a POP3 or NNTP server with mail_open().</strong></a></p>
3584 <dl>
3585 <dd>
3586 By default, the c-client library attempts to make a connection through
3587 rsh (and ssh, if you enable that). If the command:
3588 <pre>
3589 rsh imapserver exec /etc/rimapd
3592 will use the resulting rsh session as the IMAP session and not require an
3593 authentication step on the server.
3597 allowed" case to be implemented as a successful connection followed by
3598 an error message and close the connection.</p>
3601 a bug in the IMAP toolkit.</p>
3605 <ul>
3606 <li>You can disable it for this particular session by either:
3608 <ul>
3609 <li>setting an explicit port number in the mailbox name, e.g.
3610 <pre>
3611 {imapserver.foo.com:143}INBOX
3612 </pre>
3613 </li>
3616 </ul>
3617 </li>
3619 <li>You can disable rsh globally by setting the rsh timeout value to
3620 0 with the call:
3621 <pre>
3622 mail_parameters (NIL,SET_RSHTIMEOUT,0);
3623 </pre>
3624 </li>
3625 </ul>
3626 </dd>
3627 </dl>
3630 <hr>
3633 or more messages on my SUN system?</strong></a></p>
3635 <dl>
3636 <dd>
3637 This is caused by an interaction of two independent design problems in
3638 SUN mail software. The first problem is that the "forward message"
3640 " header line in the text that it forwarded. This internal header line
3641 is specific to traditional UNIX mailbox files and is not suitable for
3642 use in forwarded messages.
3644 <p>The second problem is that the mail delivery agent assumes that mail
3645 reading programs will not use the traditional UNIX mailbox format but
3646 instead an incompatible variant that depends upon a
3648 recognized to have been a terrible mistake, and is no longer
3649 recommended for use in mail (it is used in other facilities that use
3650 MIME).</p>
3652 <p>One symptom of the problem is that under certain circumstances, a
3653 message may get broken up into several messages. I'm also aware of
3654 security bugs caused by programs that foolishly trust "Content-Length:"
3655 headers with evil values.</p>
3657 <p>To fix the mailer on your system, edit your sendmail.cf to change
3659 A typical entry will lool like:</p>
3660 <pre>
3662 A=mail.local -d $u
3663 </pre>This fix will also work around the problem with mail tool, because it
3664 will insert a ">" before the internal header line to prevent it from being
3665 interpreted by mail reading software as an internal header line.
3666 </dd>
3667 </dl>
3670 <hr>
3673 disconnect? The syslog has the message:</strong></a></p>
3674 <pre>
3677 </pre>
3679 <dl>
3680 <dd>
3681 This is a problem in your client.
3683 <p>In the case of IMAP, it failed to communicate with the IMAP server
3684 for over 30 minutes; in the case of POP, it failed to communicate with
3686 </dd>
3687 </dl>
3690 <hr>
3699 <dl>
3700 <dd>
3701 This usually means that an attempt to negotiate TLS encryption via the
3702 STARTTLS command failed, because the server advertises STARTTLS
3703 functionality, but doesn't actually have it (e.g. because no
3704 certificates are installed).
3706 <p>Use the /notls option in the mailbox name to disable TLS
3707 negotiation.</p>
3708 </dd>
3709 </dl>
3712 <hr>
3715 failure: myserver: Server name does not match certificate</tt>
3718 <dl>
3719 <dd>
3720 An SSL or TLS session encryption failed because the server name in the
3721 server's certificate does not match the name that you gave it. This
3722 could indicate that the server is not really the system you think that
3723 it is, but can be also be called if you gave a nickname for the server
3724 or name that was not fully-qualified. You must use the fully-qualified
3725 domain name for the server in order to validate its certificate
3727 <p>Use the /novalidate-cert option in the mailbox name to disable
3728 validation of the certificate.</p>
3729 </dd>
3730 </dl>
3733 <hr>
3739 <tt>TLS/SSL failure: myserver: Self-signed certificate or untrusted
3742 <dl>
3743 <dd>
3744 An SSL or TLS session encryption failed because your server's
3745 certificate is "self-signed"; that is, it is not signed by any
3746 Certificate Authority (CA) and thus can not be validated. A CA-signed
3747 certificate costs money, and some smaller sites either don't want to
3748 pay for it or haven't gotten one yet. The bad part about this is that
3749 this means there is no guarantee that the server is really the system
3750 you think that it is.
3752 <p>Use the /novalidate-cert option in the mailbox name to disable
3753 validation of the certificate.</p>
3754 </dd>
3755 </dl>
3758 <hr>
3761 <tt>TLS/SSL failure: myserver: unable to get local issuer
3764 <dl>
3765 <dd>
3766 An SSL or TLS session encryption failed because your system does not
3767 have the Certificate Authority (CA) certificates installed on OpenSSL's
3768 certificates directory. On most systems, this directory is
3769 /usr/local/ssl/certs). As a result, it is not possible to validate the
3770 server's certificate.
3772 <p>If CA certificates are properly installed, you should see
3773 factory.pem and about a dozen other .pem names such as
3774 thawteCb.pem.</p>
3776 <p>As a workaround, you can use the /novalidate-cert option in the
3777 mailbox name to disable validation of the certificate; however, note
3778 that you are then vulnerable to various security attacks by bad
3779 guys.</p>
3781 <p>The correct fix is to copy all the files from the certs/ directory
3782 in the OpenSSL distribution to the /usr/local/ssl/certs (or whatever)
3783 directory. Note that you need to do this after building OpenSSL,
3784 because the OpenSSL build creates a number of needed symbolic links.
3785 For some bizarre reason, the OpenSSL "make install" doesn't do this for
3786 you, so you must do it manually.</p>
3787 </dd>
3788 </dl>
3791 <hr>
3794 Netscape? It works fine with Alpine!</strong></a></p>
3796 <dl>
3797 <dd>
3798 There are two possible causes.
3801 lock)" for the impacted user(s), read the FAQ entry regarding that
3802 message.</p>
3804 <p>Check the affected mailbox to see if there are embedded NUL
3805 characters in the message. NULs in message texts are a technical
3806 violation of both the message format and IMAP specifications. Most
3807 clients don't care, but apparently Netscape does.</p>
3809 <p>You can work around this by rebuilding imapd with the
3811 src/imapd/Makefile); this will cause imapd to convert all NULs to 0x80
3812 characters. A better solution is to enable the feature in your MTA to
3813 MIME-convert messages with binary content. See the documentation for
3814 your MTA for how to do this.</p>
3815 </dd>
3816 </dl>
3819 <hr>
3822 the IMAP server and that I should "Contact your mail server
3825 <dl>
3826 <dd>
3827 Certain versions of Netscape do this when you click the Manage Mail
3828 button, which uses an undocumented feature of Netscape's proprietary
3829 IMAP server.
3831 <p>You can work around this by rebuilding imapd with the
3833 src/imapd/Makefile) to a URL that points either to an alternative IMAP
3834 client (e.g. Alpine) or perhaps to a homebrew mail account management
3835 page.</p>
3836 </dd>
3837 </dl>
3840 <hr>
3843 POP server sessions?</strong></a></p>
3845 <dl>
3846 <dd>The user is probably using Outlook Express, Eudora, or a similar
3848 soaring and I see hundreds of POP and IMAP servers, many logged in as the
3850 </dl>
3853 <hr>
3856 Outlook Express or Outlook after a while?</strong></a></p>
3858 <dl>
3859 <dd>
3860 This is a known bug in Outlook Express. Microsoft is aware of the
3861 problem and its cause. They have informed us that they do not have any
3862 plans to fix it at the present time.
3867 the server every few minutes for new mail. Unfortunately, Outlook
3868 Express overlooks the part in the IDLE specification which requires
3869 that a client terminate and restart the IDLE before the IMAP 30 minute
3870 inactivity autologout timer triggers.</p>
3873 bottom of the window. Since it's no longer connected to the IMAP
3874 server, it isn't going to notice any new mail.</p>
3876 <p>As soon as the user does anything that would cause an IMAP
3877 operation, Outlook Express will reconnect and new mail will flow again.
3878 If the user does something that causes an IMAP operation at least every
3881 <p>Modern versions of imapd attempt to work around the problem by
3882 automatically reporting fake new mail after 29 minutes. This causes
3883 Outlook Express to exit the IDLE state; as soon as this happens imapd
3884 revokes the fake new mail. As long as this behavior isn't known to
3885 cause problems with other clients, this workaround will remain in
3886 imapd.</p>
3887 </dd>
3888 </dl>
3891 <hr>
3894 Entourage?</strong></a></p>
3896 <dl>
3897 <dd>
3898 This is a known bug in Entourage.
3900 <p>You built an older version of imapd with the
3902 support for the IDLE command. However, Entourage won't get new mail
3903 unless IDLE command support exists.</p>
3905 <p>Note: the MICROSOFT_BRAIN_DAMAGE option no longer exists in modern
3906 versions, as the Outlook Express problem which it attempted to solve
3907 has been worked around in another way.</p>
3908 </dd>
3909 </dl>
3912 <hr>
3915 all?</strong></a></p>
3917 <dl>
3918 <dd>
3919 It's hard to know. Entourage breaks almost every rule in the book for
3920 IMAP. It is highly instructive to do a packet trace on Entourage, as an
3922 (MESSAGES) on the currently selected mailbox and re-fetching the same
3923 static data over and over again.
3925 <p>It seems that every time we understand what it is doing wrong in
3926 Entourage and come up with a workaround, we learn about something else
3927 that's broken.</p>
3930 option set, in order to disable the diagnostic that occurs when doing
3931 STATUS on the currently selected mailbox.</p>
3932 </dd>
3933 </dl>
3936 <hr>
3939 at all?</strong></a></p>
3941 <dl>
3942 <dd>
3943 This is a bug in NSNOTIFY; it doesn't handle unsolicited data from the
3944 server correctly.
3946 <p>Fortunately, there is no reason to use this program with IMAP;
3947 NSNOTIFY is a polling program to let you know when new mail has
3948 appeared in your maildrop. This is necessary with POP; but since IMAP
3949 dynamically announces new mail in the session you're better off (and
3950 will actually cause less load on the server!) keeping your mail reading
3951 program's IMAP session open and let IMAP do the notifying for you.</p>
3953 <p>Consequently, the recommended fix for the NSNOTIFY problem is to
3954 delete the NSNOTIFY binary.</p>
3955 </dd>
3956 </dl>
3959 <hr>
3962 the connection has been broken, and in the server syslogs I see "Command
3965 <dl>
3966 <dd>There is a report that you can fix the problem by going into Eudora's
3967 advanced network configuration menu and increasing the network buffer
3969 </dl>
3972 <hr>
3975 clients out there?</strong></a></p>
3977 <dl>
3978 <dd>
3979 Yes!
3982 and it generates text mail (life is too short to waste on HTML mail).
3983 Also, there are some really wonderful things in progress in the Alpine
3984 world.</p>
3986 <p>There are some good GUI clients out there, mostly from smaller
3987 vendors. Without naming names, look for the vendors who are active in
3988 the IMAP protocol development community, and their products.</p>
3992 can also be badly misconfigured, and often the misconfiguration is the
3993 default.</p>
3994 </dd>
3995 </dl>
3998 <hr>
4001 c-client) crashes with the message</strong> <tt>incomplete SecBuffer
4002 exceeds maximum buffer size</tt> <strong>when I use SSL connections.
4003 This is a bug in c-client, right?</strong></a></p>
4005 <dl>
4006 <dd>
4007 It's a bug in the Microsoft SChannel.DLL, which implements SSL.
4008 Microsoft admits it (albeit with an unstatement: "it's not fully RFC
4009 compliant"). The problem is that SChannel indicates that the maximum
4010 SSL packet data size is 5 bytes smaller than the actual maximum. Thus,
4011 any IMAP server which transmits a maximum sized SSL packet will not
4012 work with PC Alpine or any other program which uses SChannel.
4014 <p>It can take a while for the problem to show up. The client has to do
4015 something that causes at least 16K of contiguous data. Many clients do
4016 partial fetching, which tends to reduce the number of cases where this
4018 support SSL is affected by this bug.</p>
4020 <p>This problem does not affect UNIX code, since OpenSSL is used on
4021 UNIX.</p>
4023 <p>This problem most recently showed up with the CommunigatePro IMAP
4024 server. They have an update which trims down their maximum contiguous
4027 <p>This problem has also shown up with the Exchange IMAP server with
4028 UNIX clients (including Alpine built with an older version of c-client)
4029 which sends full-sized 16K SSL packets. Modern c-client works around
4030 the problem by trimming down its maximum outgoing SSL packet size to
4033 <p>Microsoft has developed a hotfix for this bug. Look up MSKB article
4034 number 300562. Contrary to the article text which implies that this is
4035 a Alpine issue, this bug also affect Microsoft Exchange server with *any*
4036 UNIX based client that transmits full-sized SSL payloads.</p>
4037 </dd>
4038 </dl>
4041 <hr>
4044 THIS MESSAGE -- FOLDER INTERNAL DATA if they also use Alpine or IMAP. How
4045 can I fix this?</strong></a></p>
4047 <dl>
4048 <dd>
4049 This is an incompatibility between qpopper and the c-client library
4050 used by Alpine, imapd, and ipop[23]d.
4052 <p>Assuming that you want to continue using qpopper, look into
4054 which is documented as "check for and hide UW 'Folder Internal Data'
4058 </dd>
4059 </dl>
4062 <hr>
4065 to them from my client!</strong></a></p>
4067 <dl>
4068 <dd>
4069 Review the installation instructions carefully. Make sure that you have
4070 not skipped any of the steps. Make sure that you have made the correct
4071 entries in the configuration files; pay careful attention to the exact
4072 spelling of the service names and the path names. Make sure as well
4073 that you have properly restarted inetd.
4075 <p>If you have a system with Yellow Pages/NIS such as Solaris, have you
4076 updated the service names there as well as in /etc/services?</p>
4078 <p>If you have a system with TCP wrappers, have you properly updated
4079 the TCP wrapper files (e.g. /etc/hosts.allow and /etc/hosts.deny) for
4080 the servers?</p>
4082 <p>If you have a system which uses xinetd instead of inetd, have you
4083 made sure that you have made the correct corresponding xinetd changes
4084 for those services?</p>
4087 you get a "refused" error, that probably means that you don't have the
4088 service set up in inetd.conf. If the connection opens and then closes
4089 with no message, the service is set up, but either the path name of the
4090 server binary in inetd.conf is wrong or your TCP wrappers are
4091 configured to deny access.</p>
4093 <p>If you don't know how to make the corresponding changes to these
4094 files, seek the help of a local expert for your system.</p>
4095 </dd>
4096 </dl>
4099 <hr>
4106 <dl>
4107 <dd>
4108 Some versions of qmail, including that running on mail.smtp.yahoo.com,
4109 disconnect the SMTP session if you fail to authenticate prior to
4110 attempting to transmit mail. An attempt to authenticate was made, but
4111 it failed because the server had already disconnected.
4113 <p>To work around this, you need to specify /user=... in the host name
4114 specification.</p>
4116 <p>The SECURITY PROBLEM came about because the server advertised the
4117 AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted
4118 session, in violation of RFC 4616. This message is just a warning, and
4119 in fact occurred after the server had disconnected.</p>
4120 </dd>
4121 </dl>
4124 <hr>
4127 Authentication cancelled</tt> <strong>and why did this happen? There was
4128 also something about</strong> <tt>SECURITY PROBLEM: insecure server
4129 advertised AUTH=PLAIN</tt></a></p>
4131 <dl>
4132 <dd>
4133 This is a bug in the SMTP server.
4135 <p>Some versions of qmail, including that running on
4136 mail.smtp.yahoo.com, have a bug in their implementation of SASL in
4137 their SMTP server, which renders it non-compliant with the
4138 standard.</p>
4140 <p>If the client does not provide an initial response in the command
4141 line for an authentication mechanism whose profile does not have an
4142 initial challenge, qmail issues a bogus response:</p>
4143 <pre>
4144 334 ok, go on
4146 that the text part in a 334 response be a BASE64 encoded string; in other
4147 words, it is a protocol syntax error.
4150 encoded string have no data. In other words, the appropropiate
4151 standards-compliant server response is "334" followed by a SPACE and a
4152 CRLF.</p>
4154 <p>The SECURITY PROBLEM came about because the server advertised the
4155 AUTH=PLAIN SASL authentication mechanism outside of a TLS-encrypted
4156 session, in violation of RFC 4616. This message is just a warning, and
4158 </dd>
4159 </dl>
4162 <hr>
4165 base64 string</tt> <strong>when I try to authenticate to a Cyrus
4166 server?</strong></a></p>
4168 <dl>
4169 <dd>
4170 This slightly misleading message is the way that a Cyrus server
4171 indicates that an authentication exchange was cancelled. It is not
4172 indicative of a bug or protocol violation.
4174 <p>The most common reason that this happens is if the Cyrus server
4175 offers Kerberos authentication, c-client is built with Kerberos
4176 support, but your client system is not within the Kerberos realm. In
4177 this case, the client code will try to authenticate via Kerberos, fail
4178 to get the Kerberos credentials, cancel the authentication attempt, and
4179 try the next available authentication technology.</p>
4180 </dd>
4181 </dl>
4184 <hr>
4186 <p><br></p>
4189 <hr>
4193 should I go?</strong></a></p>
4195 <dl>
4196 <dd>
4197 If you have questions about the IMAP protocol, or want to participate
4198 in discussions of future directions of the IMAP protocol, the
4199 appropriate mailing list is imap-protocol@u.washington.edu. You can
4200 subscribe to this list via <a href=
4201 "mailto:imap-protocol-request@u.washington.edu"><tt>imap-protocol-request@u.washington.edu</tt></a>
4203 <p>You must be a subscriber to post to this list. As an
4204 alternative, you can use the
4206 </dd>
4207 </dl>
4210 <hr>
4213 protocols?</strong></a></p>
4215 <dl>
4218 </dl>
4221 <hr>
4224 administering an IMAP server?</strong></a></p>
4226 <dl>
4227 <dd>
4230 </dd>
4231 </dl>
4237 <!--chtml include "//imap/incs/bottom.inc"-->