[fetchmail-devel] RFC: Workaround for comcast bug - 6.3.X or 6.4.X stuff?

[Matthias A. <mat...@gm...>]

Greetings,

I prepared this patch in response to the many comcast ("Maillennium")
problem reports all across the net, which blacklists the POP3 TOP
command on servers that greet us with "Maillennium POP3/PROXY server".

I'm asking for comments: do others think avoiding the truncation of
messages after approx. 82 kB justifies this incompatible bug fix (it is
incompatible because it marks messages read on the server)?

Should we apply this patch on the 6.3.X branch or should it wait for
6.4.X?

I also found out that many people try to ask on random forums,
vendor-forums such as SUSE, independent forums, rather than asking on
the official fetchmail support lists, and apparently without checking
the FAQ first.  How do users procure information where to post their 
question?

(I'd like to post a prominent notice referring them to our FAQ and lists.)


This is the patch:

--------------------------------------------------------------------------------
--- pop3.c	(Revision 4585)
+++ pop3.c	(Arbeitskopie)
@@ -611,6 +611,12 @@
 #endif
 
     set_peek_capable(ctl);
+    /* comcast's Maillennium POP3/PROXY is full of bugs and truncates
+     * TOP replies after c. 80 kByte, so disable TOP. */
+    if (peek_capable && strstr(greeting, "Maillennium POP3/PROXY server")) {
+	report(stdout, GT_("Warning: Maillennium POP3/PROXY server found, using RETR command.\n"));
+	peek_capable = 0;
+    }
 
     /* we're approved */
     return(PS_SUCCESS);
--- NEWS	(Revision 4597)
+++ NEWS	(Arbeitskopie)
@@ -24,6 +24,17 @@
 
 fetchmail 6.3.2 (to be released):
 
+# INCOMPATIBLE CHANGE:
+* Automatically disable the POP3 TOP command if the greeting string contains
+  "Maillennium POP3/PROXY server", which is used by comcast and known to
+  truncate messages after 80 kByte. Fall back to RETR, and complain if we had
+  used TOP otherwise.  Suggested by Ed Wilts.
+  *Note* that this means messages are marked read on these servers, which is a
+  deviation from how 6.3.1 behaved, but we have no alternative, comcast haven't
+  fixed this bug in years.  Preventing the loss of the remainder of the message
+  justifies this incompatible fix.  Matthias Andree
+
+# BUG FIXES:
 * SMTP/LMTP cleanup to fix these two bugs:
   - switch back to SMTP after having tried LMTP hosts (multiple smtphost hosts)
   - switch back to LMTP after sending a bounce.
--- fetchmail-FAQ.html	(Revision 4585)
+++ fetchmail-FAQ.html	(Arbeitskopie)
@@ -2004,13 +2004,19 @@
 <h2><a id="I8" name="I8">I8. How can I use fetchmail with comcast.net?</a></h2>
 
 <p>Stock fetchmail will work with a comcast.net server...<em>but</em>
-the Maillennium POP3 server comcat uses seems to have an 80K limit on
+the Maillennium POP3 server comcast use seems to have an 80&nbsp;kB limit on
 the length of downloaded messages if you use POP3 TOP to retrieve.
 Anything larger is silently truncated.  Don't mistake this for a
 fetchmail bug. (Reported July 2003.)</p>
 
-<p>Workaround: use the <tt>fetchall</tt> option.</p>
+<p>Beginning with version 6.3.2,
+fetchmail will fall back to the RETR command if the greeting string
+contains "Maillennium POP3/PROXY server". This means however that
+fetchmail has no means to prevent the "seen" flag from being set on the
+server.</p>
 
+<p>Workaround for older versions: use the <tt>fetchall</tt> option.</p>
+
 <hr/>
 <h1>How to set up well-known security and authentication
 methods</h1>
--------------------------------------------------------------------------------

Thanks,

-- 
Matthias Andree