diff options
| -rwxr-xr-x | fetchmailconf | 168 |
1 files changed, 85 insertions, 83 deletions
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 |