diff options
Diffstat (limited to 'contrib')
| -rw-r--r-- | contrib/007705.html | 70 | ||||
| -rw-r--r-- | contrib/007713.html | 70 | ||||
| -rw-r--r-- | contrib/008523.html | 141 | ||||
| -rw-r--r-- | contrib/010015.html | 100 | ||||
| -rw-r--r-- | contrib/README | 4 |
5 files changed, 385 insertions, 0 deletions
diff --git a/contrib/007705.html b/contrib/007705.html new file mode 100644 index 00000000..88f85ecf --- /dev/null +++ b/contrib/007705.html @@ -0,0 +1,70 @@ +<!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> diff --git a/contrib/007713.html b/contrib/007713.html new file mode 100644 index 00000000..2f001ece --- /dev/null +++ b/contrib/007713.html @@ -0,0 +1,70 @@ +<!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> 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> diff --git a/contrib/010015.html b/contrib/010015.html new file mode 100644 index 00000000..4ba2faf8 --- /dev/null +++ b/contrib/010015.html @@ -0,0 +1,100 @@ +<!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> diff --git a/contrib/README b/contrib/README index 65d8a4ac..9ae463c2 100644 --- a/contrib/README +++ b/contrib/README @@ -3,6 +3,10 @@ Note: you're on your own using these -- I don't really understand them, I'm just passing them along. --esr +0*.html: +Messages from the archives of the old fetchmail-friends mailing list, +for off-line reading. + maildaemon: Larry Fahnoe wrote this for driving fetchmail from cron. It may be useful if |