diff options
Diffstat (limited to 'contrib/008523.html')
| -rw-r--r-- | contrib/008523.html | 141 |
1 files changed, 141 insertions, 0 deletions
diff --git a/contrib/008523.html b/contrib/008523.html new file mode 100644 index 00000000..535ffec5 --- /dev/null +++ b/contrib/008523.html @@ -0,0 +1,141 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [fetchmail]fetchmail vs Maillenium; mail truncated to 80K + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:jcfoley%40comcast.net"> + <META NAME="robots" CONTENT="index,nofollow"> + + <LINK REL="Previous" HREF="008522.html"> + <LINK REL="Next" HREF="008524.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[fetchmail]fetchmail vs Maillenium; mail truncated to 80K + </H1> + <B>jcfoley@comcast.net + </B> + <A HREF="mailto:jcfoley%40comcast.net" + TITLE="[fetchmail]fetchmail vs Maillenium; mail truncated to 80K">jcfoley@comcast.net + </A><BR> + <I>Fri, 23 Apr 2004 02:51:22 +0000</I> + <P><UL> + <LI> Previous message: <A HREF="008522.html">[fetchmail]fetchmail vs Maillenium; mail truncated to 80K +</A></li> + <LI> Next message: <A HREF="008524.html">[fetchmail]fetchmail vs Maillenium; mail truncated to 80K +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#8523">[ date ]</a> + <a href="thread.html#8523">[ thread ]</a> + <a href="subject.html#8523">[ subject ]</a> + <a href="author.html#8523">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>You're probably using a Comcast POP3 server. Many others have +experienced this problem. The problem is that the server truncates +the amount of data returned by the POP3 TOP command. Comcast changed +to the Maillennium POP3 server in Summer 2003. For several months +they refused to acknowledge any issue at their end that would account +for email truncation. Recently the Comcast Government Affairs Manager +at Comcast of Montgomery (Maryland) sent me the information at the end +of this message. + +I believe the Outlook Express flaw they reference was fixed a few +years ago. Regardless it does seem to be a strange and non-conforming +server implementation that silently does the wrong thing specified by +the RFC and every other server I've used. + +On the other hand, people have made the comment that fetchmail should +not be relying on TOP because a) that's not what it is for and/or b) +it is an optional POP3 command. + +Item I8 of the fetchmail FAQ which appears to be maintained by Eric +S. Raymond says, "Don't mistake this for a fetchmail bug." + +It would be nice to hear from a fetchmail expert/authority on whether +fetchmail is doing the right thing by using TOP and for a rationale of +the FAQ's response. + +If fetchmail's use of TOP is legitimate then maybe Comcast would +uncripple their server if more people complained. + +Jim Foley + +======================================================================= +======================================================================= + +Date: Wed, 3 Mar 2004 11:59:17 -0500 + +Mr. Foley, this email responds to the questions you posed following our +conference call. + +First, Comcast does support POP 3 TOP commands, however Comcast has found +that increasing the amount of data TOP returns beyond the value of 64K has a +tendency to crash Microsoft Outlook Express when an abnormally large header +is sent. Increasing the value beyond 64K would open the platform to +malicious use of large headers that adversely impacts system performance. +Virtually all of Comcast's high-speed Internet customers use Outlook +Express. Comcast has not received requests from other subscribers who seek +to use the TOP command in the manner you have requested. Further, Comcast +has not received any other complaints regarding email truncation with the +TOP command. Should you wish to continue checking your mail through manual +commands you might try using the RETR command, which will return the entire +message. + +... + + + +Date: Fri, 5 Mar 2004 16:28:11 -0500 + +Mr. Foley: + +This is in response to your question regarding "POP 3 RFC compliance." We +have tried to answer your question about Comcast's services by talking about +the specific application in which you are interested and how that +application relates to technical information regarding the configuration of +Comcast's Internet service. We have provided you all the information that +we can by explaining that Comcast limits the optional POP 3 Top Command to a +value of 64k because any larger value has a tendency to crash Microsoft +Outlook and could leave Comcast's system open to the malicious use of large +headers intended to impair system performance. + +The decision by Comcast to place limitations on the optional POP 3 TOP email +commands is a technical business decision made by Comcast in the best +interest of all its customers and its system. ... + +... + +With respect to the specific RFC at issue, RFC 1939, POP 3, it is our +understanding that it is a protocol "intended to permit a workstation to +dynamically access a maildrop on a server host in a useful fashion. +Usually, this means that the POP3 protocol is used to allow a workstation to +retrieve mail that the server is holding for it. Pop 3 is not intended to +provide extensive manipulation operations of mail on the server." POP 3 was +created in May 1996 and has not been revised since, despite the many changes +in computer hardware and software related to handling of email since that +time. In any event, the TOP command is identified as an optional POP 3 +command in RFC 1939. + +... + + +</PRE> +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI> Previous message: <A HREF="008522.html">[fetchmail]fetchmail vs Maillenium; mail truncated to 80K +</A></li> + <LI> Next message: <A HREF="008524.html">[fetchmail]fetchmail vs Maillenium; mail truncated to 80K +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#8523">[ date ]</a> + <a href="thread.html#8523">[ thread ]</a> + <a href="subject.html#8523">[ subject ]</a> + <a href="author.html#8523">[ author ]</a> + </LI> + </UL> +</body></html> |