--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [fetchmail] Patch for IMAP idling where idling is unsupported
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:fetchmail-friends%40cmb.is-a-geek.org">
+ <META NAME="robots" CONTENT="index,nofollow">
+
+ <LINK REL="Previous" HREF="007711.html">
+ <LINK REL="Next" HREF="007713.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[fetchmail] Patch for IMAP idling where idling is unsupported
+ </H1>
+ <B>Chris Boyle
+ </B>
+ <A HREF="mailto:fetchmail-friends%40cmb.is-a-geek.org"
+ TITLE="[fetchmail] Patch for IMAP idling where idling is unsupported">fetchmail-friends@cmb.is-a-geek.org
+ </A><BR>
+ <I>21 Jul 2003 18:20:43 +0100</I>
+ <P><UL>
+ <LI> Previous message: <A HREF="007711.html">[fetchmail] Problem - truncated messages
+</A></li>
+ <LI> Next message: <A HREF="007713.html">[fetchmail] Patch for IMAP idling where idling is unsupported
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#7705">[ date ]</a>
+ <a href="thread.html#7705">[ thread ]</a>
+ <a href="subject.html#7705">[ subject ]</a>
+ <a href="author.html#7705">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>Here's a patch I've written: where IDLE is unavailable, it uses periodic
+NOOP commands instead (every 28 seconds). Important behavioural change:
+the option "idle" will now always result in *some* form of idle. I think
+I read somewhere that some servers will unilaterally send status updates
+if you just hold the connection open, i.e. NOOPs would be unnecessary,
+but that doesn't seem to be the case anywhere I've tried. In any case,
+this patch copes with updates both as a response to the NOOPs and
+unilaterally sent between them. It functions exactly like normal idling
+(N.B. like normal idling, it is single-folder only), and hopefully
+includes all the appropriate changes to the documentation. Enjoy. :-)
+
+<A HREF="http://cmb.is-a-geek.org/downloads/fetchmail-6.2.2+noopidle.diff.gz">http://cmb.is-a-geek.org/downloads/fetchmail-6.2.2+noopidle.diff.gz</A>
+
+--
+Chris Boyle - <A HREF="http://people.debian.org/~cmb/">http://people.debian.org/~cmb/</A>
+GPG: B7D86E0F, MSN: <A HREF="mailto:shortcipher@hotmail.com">shortcipher@hotmail.com</A>, ICQ: 24151961,
+AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on freenode.net
+
+</PRE>
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI> Previous message: <A HREF="007711.html">[fetchmail] Problem - truncated messages
+</A></li>
+ <LI> Next message: <A HREF="007713.html">[fetchmail] Patch for IMAP idling where idling is unsupported
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#7705">[ date ]</a>
+ <a href="thread.html#7705">[ thread ]</a>
+ <a href="subject.html#7705">[ subject ]</a>
+ <a href="author.html#7705">[ author ]</a>
+ </LI>
+ </UL>
+</body></html>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [fetchmail] Patch for IMAP idling where idling is unsupported
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:esr%40thyrsus.com">
+ <META NAME="robots" CONTENT="index,nofollow">
+
+ <LINK REL="Previous" HREF="007705.html">
+ <LINK REL="Next" HREF="007706.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[fetchmail] Patch for IMAP idling where idling is unsupported
+ </H1>
+ <B>Eric S. Raymond
+ </B>
+ <A HREF="mailto:esr%40thyrsus.com"
+ TITLE="[fetchmail] Patch for IMAP idling where idling is unsupported">esr@thyrsus.com
+ </A><BR>
+ <I>Mon, 21 Jul 2003 22:32:31 -0400</I>
+ <P><UL>
+ <LI> Previous message: <A HREF="007705.html">[fetchmail] Patch for IMAP idling where idling is unsupported
+</A></li>
+ <LI> Next message: <A HREF="007706.html">[fetchmail] [PATCH] Debian bug #156592 again + update
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#7713">[ date ]</a>
+ <a href="thread.html#7713">[ thread ]</a>
+ <a href="subject.html#7713">[ subject ]</a>
+ <a href="author.html#7713">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>Chris Boyle <<A HREF="mailto:fetchmail-friends@cmb.is-a-geek.org">fetchmail-friends@cmb.is-a-geek.org</A>>:
+><i> Here's a patch I've written: where IDLE is unavailable, it uses periodic
+</I>><i> NOOP commands instead (every 28 seconds). Important behavioural change:
+</I>><i> the option "idle" will now always result in *some* form of idle. I think
+</I>><i> I read somewhere that some servers will unilaterally send status updates
+</I>><i> if you just hold the connection open, i.e. NOOPs would be unnecessary,
+</I>><i> but that doesn't seem to be the case anywhere I've tried. In any case,
+</I>><i> this patch copes with updates both as a response to the NOOPs and
+</I>><i> unilaterally sent between them. It functions exactly like normal idling
+</I>><i> (N.B. like normal idling, it is single-folder only), and hopefully
+</I>><i> includes all the appropriate changes to the documentation. Enjoy. :-)
+</I>><i>
+</I>><i> <A HREF="http://cmb.is-a-geek.org/downloads/fetchmail-6.2.2+noopidle.diff.gz">http://cmb.is-a-geek.org/downloads/fetchmail-6.2.2+noopidle.diff.gz</A>
+</I>
+Nice work. This will be in 6.2.4.
+--
+ <a href="<A HREF="http://www.catb.org/~esr/"">http://www.catb.org/~esr/"</A>>Eric S. Raymond</a>
+
+</PRE>
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI> Previous message: <A HREF="007705.html">[fetchmail] Patch for IMAP idling where idling is unsupported
+</A></li>
+ <LI> Next message: <A HREF="007706.html">[fetchmail] [PATCH] Debian bug #156592 again + update
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#7713">[ date ]</a>
+ <a href="thread.html#7713">[ thread ]</a>
+ <a href="subject.html#7713">[ subject ]</a>
+ <a href="author.html#7713">[ author ]</a>
+ </LI>
+ </UL>
+</body></html>
--- /dev/null
+<!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>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [fetchmail]Domino IMAP and missing Content-Transfer-Encoding
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:Anthony.Kim%40walgreens.com">
+ <META NAME="robots" CONTENT="index,nofollow">
+
+
+ <LINK REL="Next" HREF="010016.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[fetchmail]Domino IMAP and missing Content-Transfer-Encoding
+ </H1>
+ <B>Anthony Kim
+ </B>
+ <A HREF="mailto:Anthony.Kim%40walgreens.com"
+ TITLE="[fetchmail]Domino IMAP and missing Content-Transfer-Encoding">Anthony.Kim@walgreens.com
+ </A><BR>
+ <I>Wed, 1 Mar 2006 23:02:52 -0600</I>
+ <P><UL>
+
+ <LI> Next message: <A HREF="010016.html">[fetchmail]Domino IMAP and missing Content-Transfer-Encoding
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#10015">[ date ]</a>
+ <a href="thread.html#10015">[ thread ]</a>
+ <a href="subject.html#10015">[ subject ]</a>
+ <a href="author.html#10015">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>Summary: fetchmail was not retrieving Content-Transfer-Encoding
+header via Domino IMAP.
+
+As it turns out, it was the Domino IMAP server that wasn't offering
+up the header.
+
+On Fri, Feb 17, 2006, Matthias Andree wrote:
+
+><i> In 6.4.X, we might implement an option so that fetchmail does not
+</I>><i> split header/body fetch but get the whole message including
+</I>><i> header in one huge piece as POP3 does which makes undeliverable
+</I>><i> mail more expensive though.
+</I>
+Thankfully, I won't have to wait for this.
+
+Much of Domino's IMAP behavior depends on the mail storage format
+specified in the Person document in the Public Name and Address
+Book.
+
+There are three options for mail storage for incoming mail:
+
+1. Keep in Sender's format
+2. Prefers MIME
+3. Prefers Notes Rich Text
+
+My setting was "Prefers MIME". Switching to "Keep in Sender's
+format" solved the missing encoding header problem.
+
+According to IBM, "Prefers MIME" offers the best IMAP performance
+in Domino "When you choose this option, the router converts all
+incoming messages to the MIME storage format at delivery time. The
+messages are therefore stored in your mail file in MIME format.
+This lets the IMAP server quickly serve all information about the
+document (such as size) as well as the body of the document to an
+IMAP client because the document is already stored in the necessary
+MIME format for the client to read." [0]
+
+I can only surmise this MIME storage results in some rather
+non-standard IMAP behavior.
+
+So long my goofy procmail hacks.
+
+Thanks to Matthias Andress and Rob Funk for helping me troubleshoot.
+
+Anthony
+
+[0] <A HREF="http://www-128.ibm.com/developerworks/lotus/library/ls-D6_IMAP_Perf/?OpenDocument">http://www-128.ibm.com/developerworks/lotus/library/ls-D6_IMAP_Perf/?OpenDocument</A>
+
+
+
+</PRE>
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+
+ <LI> Next message: <A HREF="010016.html">[fetchmail]Domino IMAP and missing Content-Transfer-Encoding
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#10015">[ date ]</a>
+ <a href="thread.html#10015">[ thread ]</a>
+ <a href="subject.html#10015">[ subject ]</a>
+ <a href="author.html#10015">[ author ]</a>
+ </LI>
+ </UL>
+</body></html>
fetchmail-SA-2006-01.txt \
fetchmail-SA-2005-01.txt \
fetchmail-SA-2005-02.txt \
- fetchmail-SA-2005-03.txt
+ fetchmail-SA-2005-03.txt \
+ 007705.html \
+ 007713.html \
+ 008523.html \
+ 010015.html
+
# extra directories to ship
distdirs = rh-config contrib beos
+6.3.6:
+- move .html files from list archive to some doc directory
+
CODE:
- check recent list mail
- check Debian BTS and other bug trackers
projects / ~andy / fetchmail / commitdiff