[fetchmail]comcast.net and attachments - workaround

[Matthias Andree]

--BOKacYhQ+x31HxR3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, 03 Jan 2006, Ed Wilts wrote:

> On Tue, Jan 03, 2006 at 04:43:28PM +0100, Matthias Andree wrote:
> > In the meanwhile, please complain to comcast.net for violating the POP3
> > standard, which states expressis verbis that the full message is to be
> > fetched if the number passed to TOP exceeds the actual number of lines
> > in the message.
> 
> That would be a waste of time.  After all, it works fine with all the
> normal Windows clients.

The bug doesn't depend on the operating system.

After all, comcast need not offer TOP at all if they don't plan to do it
right. TOP is optional.

Now, if Novell or Red Hat could phone comcast (rather than individual
users) and demand the fix, that might make a difference...

> In my opinion, we (the Linux community) need to spend more time working
> around broken implementations and less time standing on our podiums
> claiming we're right.

I don't plan to spend much time working around broken implementations,
there are more important things to do in fetchmail.

Standards are there for a reason, and not only Microsoft will notice
that soon enough.

In this particular example, you're lucky as the test is trivial and
"more RETR, less TOP" coincides with my goals for fetchmail.

Please test the attached patch (save it to a file, type "patch
<workaround-Maillennium.patch"), then recompile ("make") and reinstall
("make install") fetchmail and see if it solves your problem. It will
however mark messages as downloaded on the server, so I'm not sure if
or how I'll merge it into 6.3.2 or if it needs to wait until 6.4.0.

It is untested (I have no comcast account) and should apply against 6.3.1.
As usual, no warranties, use at your own risk.

If someone else wishes to test, go ahead and let me know what you find.
The warning message only appears if fetchmail had used TOP otherwise.

> I know it's disgusting, but unfortunately we're
> propogating the attitudes that Windows works better than Linux, because
> in this case, it does.  My Windows clients work fine (which is how I
> narrowed it down to fetchmail), my Linux one doesn't (until I
> implemented my workaround), yet the server is unlikely to change.

They, too, must learn that standards conformance is a way to keep
customers happy and money flowing in. If they truncate your messages
because their server is buggy, why give them your best^W money?

> I do see that fetchmail will be fixed to work better in cases like this
> so I'm not putting you in the same camp as some other Linux developers
> I've run into.

My motivation to add _complex_ workaround code as little as that of many
fellow developers. You may get the workaround if it's simple and the
problem hurts really bad.

Software should work efficiently on conformant servers, and our
installed base is large enough we can take some risks of not pleasing
everyone.  Fetchmail is default install in many systems.

I won't be adding workarounds that are disadvantages to users of intact
servers.

Kind regards,

-- 
Matthias Andree

--BOKacYhQ+x31HxR3
Content-Type: text/x-patch; charset=us-ascii
Content-Disposition: attachment; filename="workaround-Maillennium.patch"

Index: pop3.c
===================================================================
--- 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, "Warning: Maillennium POP3/PROXY server found, using RETR command.\n");
+	peek_capable = 0;
+    }
 
     /* we're approved */
     return(PS_SUCCESS);

--BOKacYhQ+x31HxR3--