From d5f3d1a041239f89088972e79a4f55e1acd41179 Mon Sep 17 00:00:00 2001 From: Matthias Andree Date: Wed, 22 Nov 2006 00:20:51 +0000 Subject: Add list messages, top-level for the nonce. svn path=/branches/BRANCH_6-3/; revision=4960 --- 007705.html | 70 ++++++++++++++++++++++++++++++ 007713.html | 70 ++++++++++++++++++++++++++++++ 008523.html | 141 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 010015.html | 100 ++++++++++++++++++++++++++++++++++++++++++ Makefile.am | 7 ++- TODO.txt | 3 ++ 6 files changed, 390 insertions(+), 1 deletion(-) create mode 100644 007705.html create mode 100644 007713.html create mode 100644 008523.html create mode 100644 010015.html diff --git a/007705.html b/007705.html new file mode 100644 index 00000000..88f85ecf --- /dev/null +++ b/007705.html @@ -0,0 +1,70 @@ + + + + [fetchmail] Patch for IMAP idling where idling is unsupported + + + + + + + + + +

[fetchmail] Patch for IMAP idling where idling is unsupported +

+ Chris Boyle + + fetchmail-friends@cmb.is-a-geek.org +
+ 21 Jul 2003 18:20:43 +0100 +

+
+ +
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. :-)
+
+http://cmb.is-a-geek.org/downloads/fetchmail-6.2.2+noopidle.diff.gz
+
+-- 
+Chris Boyle - http://people.debian.org/~cmb/
+GPG: B7D86E0F, MSN: shortcipher@hotmail.com, ICQ: 24151961,
+AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on freenode.net
+
+
+ +
+

+ diff --git a/007713.html b/007713.html new file mode 100644 index 00000000..2f001ece --- /dev/null +++ b/007713.html @@ -0,0 +1,70 @@ + + + + [fetchmail] Patch for IMAP idling where idling is unsupported + + + + + + + + + +

[fetchmail] Patch for IMAP idling where idling is unsupported +

+ Eric S. Raymond + + esr@thyrsus.com +
+ Mon, 21 Jul 2003 22:32:31 -0400 +

+
+ +
Chris Boyle <fetchmail-friends@cmb.is-a-geek.org>:
+> 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. :-)
+> 
+> http://cmb.is-a-geek.org/downloads/fetchmail-6.2.2+noopidle.diff.gz
+
+Nice work.  This will be in 6.2.4.
+-- 
+		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
+
+
+ +
+

+ diff --git a/008523.html b/008523.html new file mode 100644 index 00000000..535ffec5 --- /dev/null +++ b/008523.html @@ -0,0 +1,141 @@ + + + + [fetchmail]fetchmail vs Maillenium; mail truncated to 80K + + + + + + + + + +

[fetchmail]fetchmail vs Maillenium; mail truncated to 80K +

+ jcfoley@comcast.net + + jcfoley@comcast.net +
+ Fri, 23 Apr 2004 02:51:22 +0000 +

+
+ +
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.
+
+...
+
+
+
+ +
+

+ diff --git a/010015.html b/010015.html new file mode 100644 index 00000000..4ba2faf8 --- /dev/null +++ b/010015.html @@ -0,0 +1,100 @@ + + + + [fetchmail]Domino IMAP and missing Content-Transfer-Encoding + + + + + + + + + +

[fetchmail]Domino IMAP and missing Content-Transfer-Encoding +

+ Anthony Kim + + Anthony.Kim@walgreens.com +
+ Wed, 1 Mar 2006 23:02:52 -0600 +

+
+ +
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:
+
+> In 6.4.X, we might implement an option so that fetchmail does not
+> split header/body fetch but get the whole message including
+> header in one huge piece as POP3 does which makes undeliverable
+> mail more expensive though.
+
+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] http://www-128.ibm.com/developerworks/lotus/library/ls-D6_IMAP_Perf/?OpenDocument
+
+
+
+
+ +
+

+ diff --git a/Makefile.am b/Makefile.am index 916e63fb..27b302e9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -132,7 +132,12 @@ DISTDOCS= FAQ FEATURES NOTES OLDNEWS fetchmail-man.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 diff --git a/TODO.txt b/TODO.txt index 89a9016e..5591b7c1 100644 --- a/TODO.txt +++ b/TODO.txt @@ -1,3 +1,6 @@ +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 -- cgit v1.2.3