From 425874d5e6a59726db8c0ee88431ab01af6b3ac4 Mon Sep 17 00:00:00 2001
From: "Eric S. Raymond" <esr@thyrsus.com>
Date: Tue, 22 Feb 2000 06:51:31 +0000
Subject: Rearranged autoprobe code.

svn path=/trunk/; revision=2767
---
 fetchmailconf | 168 +++++++++++++++++++++++++++++-----------------------------
 1 file changed, 85 insertions(+), 83 deletions(-)

(limited to 'fetchmailconf')

diff --git a/fetchmailconf b/fetchmailconf
index cbbf1339..88804ccd 100755
--- a/fetchmailconf
+++ b/fetchmailconf
@@ -1117,17 +1117,63 @@ switch --enable-POP2.
 
 """
 
+### POP3 servers start here
+
+	    if string.find(greetline, "1.003") > 0 or string.find(greetline, "1.004") > 0:
+                warnings = warnings + """
+This appears to be an old version of the UC Davis POP server.  These are
+dangerously unreliable (among other problems, they may drop your mailbox
+on the floor if your connection is interrupted during the session).
+
+It is strongly recommended that you find a better POP3 server.  The fetchmail
+FAQ includes pointers to good ones.
+
+"""
+# Steve VanDevender <stevev@efn.org> writes:
+# The only system I have seen this happen with is cucipop-1.31
+# under SunOS 4.1.4.  cucipop-1.31 runs fine on at least Solaris
+# 2.x and probably quite a few other systems.  It appears to be a
+# bug or bad interaction with the SunOS realloc() -- it turns out
+# that internally cucipop does allocate a certain data structure in
+# multiples of 16, using realloc() to bump it up to the next
+# multiple if it needs more.
+# 
+# The distinctive symptom is that when there are 16 messages in the
+# inbox, you can RETR and DELE all 16 messages successfully, but on
+# QUIT cucipop returns something like "-ERR Error locking your
+# mailbox" and aborts without updating it.
+# 
+# The cucipop banner looks like:
+# 
+# +OK Cubic Circle's v1.31 1998/05/13 POP3 ready <6229000062f95036@wakko>
+#
+	    if string.find(greetline, "Cubic Circle") > 0:
+                warnings = warnings + """
+I see your server is running cucipop.  Better make sure the server box
+isn't a SunOS 4.1.4 machine; cucipop tickles a bug in SunOS realloc()
+under that version, and doesn't cope with the result gracefully.  Newer
+SunOS and Solaris machines run cucipop OK.
+
+"""
 # The greeting line on the server known to be buggy is:
 # +OK POP3 server ready (running FTGate V2, 2, 1, 0 Jun 21 1999 09:55:01)
 #
-            if string.find(greetline, "FTGate") > 0:
+	    if string.find(greetline, "FTGate") > 0:
                 warnings = warnings + """
 This POP server has a weird bug; it says OK twice in response to TOP.
 Its response to RETR is normal, so use the `fetchall' option.
 
 """
+            if string.find(greetline, "OpenMail") > 0:
+                warnings = warnings + """
+You appear to be using some version of HP OpenMail.  Many versions of
+OpenMail do not process the "TOP" command correctly; the symptom is that
+only the header and first line of each message is retrieved.  To work
+around this bug, turn on `fetchall' on all user entries associated with
+this server.  
 
-            if string.find(greetline, "POP-Max") > 0:
+"""
+	    if string.find(greetline, "POP-Max") > 0:
                 warnings = warnings + """
 The Mail Max POP3 server screws up on mail with attachments.  It reports
 the message size with attachments included, but doesn't download them on a
@@ -1135,23 +1181,37 @@ RETR or TOP (this violates the IMAP RFCs).  You should get rid of it --
 and the brain-dead NT server it rode in on. 
 
 """
-
-            if string.find(greetline, "InterChange") > 0:
+            if string.find(greetline, "POP3 Server Ready") > 0:
                 warnings = warnings + """
-The InterChange IMAP server screws up on mail with attachments.  It reports
-the message size with attachments included, but doesn't download them on a
-RETR or TOP (this violates the IMAP RFCs).  You should get rid of it. 
+Some server that uses this greeting line has been observed to choke on
+TOP %d 99999999.  Use the fetchall option. if necessary, to force RETR.
 
 """
+	    if string.find(greetline, "QPOP") > 0:
+                warnings = warnings + """
+This appears to be a version of Eudora qpopper.  That's good.  Fetchmail
+knows all about qpopper.  However, be aware that the 2.53 version of
+qpopper does something odd that causes fetchmail to hang with a socket
+error on very large messages.  This is probably not a fetchmail bug, as
+it has been observed with fetchpop.  The fix is to upgrade to qpopper
+3.0beta or a more recent version.  Better yet, switch to IMAP.
 
-            if string.find(greetline, "1.003") > 0 or string.find(greetline, "1.004") > 0:
+"""
+            if string.find(greetline, "sprynet.com") > 0:
                 warnings = warnings + """
-This appears to be an old version of the UC Davis POP server.  These are
-dangerously unreliable (among other problems, they may drop your mailbox
-on the floor if your connection is interrupted during the session).
+You appear to be using a SpryNet server.  In mid-1999 it was reported that
+the SpryNet TOP command marks messages seen.  Therefore, for proper error
+recovery in the event of a line drop, it is strongly recommended that you
+turn on `fetchall' on all user entries associated with this server.  
 
-It is strongly recommended that you find a better POP3 server.  The fetchmail
-FAQ includes pointers to good ones.
+"""
+            if string.find(greetline, "TEMS POP3") > 0:
+                warnings = warnings + """
+Your POP3 server has "TEMS" in its header line.  At least one such
+server does not process the "TOP" command correctly; the symptom is
+that fetchmail hangs when trying to retrieve mail.  To work around
+this bug, turn on `fetchall' on all user entries associated with this
+server.
 
 """
             if string.find(greetline, "usa.net") > 0:
@@ -1168,24 +1228,9 @@ Therefore, it is strongly recommended that you turn on `fetchall' on all
 user entries associated with this server.  
 
 """
-            if string.find(greetline, "OpenMail") > 0:
-                warnings = warnings + """
-You appear to be using some version of HP OpenMail.  Many versions of
-OpenMail do not process the "TOP" command correctly; the symptom is that
-only the header and first line of each message is retrieved.  To work
-around this bug, turn on `fetchall' on all user entries associated with
-this server.  
 
-"""
-            if string.find(greetline, "TEMS POP3") > 0:
-                warnings = warnings + """
-Your POP3 server has "TEMS" in its header line.  At least one such
-server does not process the "TOP" command correctly; the symptom is
-that fetchmail hangs when trying to retrieve mail.  To work around
-this bug, turn on `fetchall' on all user entries associated with this
-server.
+### IMAP servers start here
 
-"""
             if string.find(greetline, "GroupWise") > 0:
                 warnings = warnings + """
 The Novell GroupWise IMAP server would be better named GroupFoolish;
@@ -1199,49 +1244,18 @@ with code as shoddy as GroupWise seems to be, you will probably pay
 for it with other problems.<p>
 
 """
-            if string.find(greetline, "sprynet.com") > 0:
-                warnings = warnings + """
-You appear to be using a SpryNet server.  In mid-1999 it was reported that
-the SpryNet TOP command marks messages seen.  Therefore, for proper error
-recovery in the event of a line drop, it is strongly recommended that you
-turn on `fetchall' on all user entries associated with this server.  
-
-"""
-
-# Steve VanDevender <stevev@efn.org> writes:
-# The only system I have seen this happen with is cucipop-1.31
-# under SunOS 4.1.4.  cucipop-1.31 runs fine on at least Solaris
-# 2.x and probably quite a few other systems.  It appears to be a
-# bug or bad interaction with the SunOS realloc() -- it turns out
-# that internally cucipop does allocate a certain data structure in
-# multiples of 16, using realloc() to bump it up to the next
-# multiple if it needs more.
-# 
-# The distinctive symptom is that when there are 16 messages in the
-# inbox, you can RETR and DELE all 16 messages successfully, but on
-# QUIT cucipop returns something like "-ERR Error locking your
-# mailbox" and aborts without updating it.
-# 
-# The cucipop banner looks like:
-# 
-# +OK Cubic Circle's v1.31 1998/05/13 POP3 ready <6229000062f95036@wakko>
-#
-            if string.find(greetline, "Cubic Circle") > 0:
+            if string.find(greetline, "Netscape IMAP4rev1 Service 3.6") > 0:
                 warnings = warnings + """
-I see your server is running cucipop.  Better make sure the server box
-isn't a SunOS 4.1.4 machine; cucipop tickles a bug in SunOS realloc()
-under that version, and doesn't cope with the result gracefully.  Newer
-SunOS and Solaris machines run cucipop OK.
+This server violates the RFC2060 requirement that a BODY[TEXT] fetch should
+set the messages's Seen flag.  As a result, if you use the keep option the
+same messages will be downloaded over and over.
 
 """
-            if string.find(greetline, "QPOP") > 0:
+            if string.find(greetline, "InterChange") > 0:
                 warnings = warnings + """
-This appears to be a version of Eudora qpopper.  That's good.  Fetchmail
-knows all about qpopper.  However, be aware that the 2.53 version of
-qpopper does something odd that causes fetchmail to hang with a socket
-error on very large messages.  This is probably not a fetchmail bug, as
-it has been observed with fetchpop.  The fix is to upgrade to qpopper
-3.0beta or a more recent version.  Better yet, switch to IMAP.
+The InterChange IMAP server screws up on mail with attachments.  It reports
+the message size with attachments included, but doesn't download them on a
+RETR or TOP (this violates the IMAP RFCs).  You should get rid of it. 
 
 """
             if string.find(greetline, "Imail") > 0:
@@ -1252,6 +1266,9 @@ attachments; the effect is to drop the attachments on the floor.  We
 recommend you upgrade to a non-broken IMAP server.
 
 """
+
+### Checks for protocol variants start here
+
             closebrak = string.find(greetline, ">")
             if  closebrak > 0 and greetline[closebrak+1] == "\r":
                 warnings = warnings + """
@@ -1274,21 +1291,6 @@ To fix this bug, upgrade to an IMAP4 server.  The fetchmail FAQ includes
 a pointer to an open-source implementation.
 
 """
-            if string.find(greetline, "POP3 Server Ready") > 0:
-                warnings = warnings + """
-Some server that uses this greeting line has been observed to choke on
-TOP %d 99999999.  Use the fetchall option. if necessary, to force RETR.
-
-"""
-
-            if string.find(greetline, "Netscape IMAP4rev1 Service 3.6") > 0:
-                warnings = warnings + """
-This server violates the RFC2060 requirement that a BODY[TEXT] fetch should
-set the messages's Seen flag.  As a result, if you use the keep option the
-same messages will be downloaded over and over.
-
-"""
-                
             if string.find(greetline, "IMAP4rev1") > 0:
                 warnings = warnings + """
 I see an IMAP4rev1 server.  Excellent.  This is (a) the best kind of
-- 
cgit v1.2.3