From de26c86dffa492ba2ffdff021e88d9891f8be9f3 Mon Sep 17 00:00:00 2001 From: Matthias Andree Date: Mon, 11 Dec 2006 00:24:06 +0000 Subject: Shuffle 0*.html files from ML archive into contrib/ directory. svn path=/branches/BRANCH_6-3/; revision=4987 --- contrib/007705.html | 70 ++++++++++++++++++++++++++ contrib/007713.html | 70 ++++++++++++++++++++++++++ contrib/008523.html | 141 ++++++++++++++++++++++++++++++++++++++++++++++++++++ contrib/010015.html | 100 +++++++++++++++++++++++++++++++++++++ contrib/README | 4 ++ 5 files changed, 385 insertions(+) create mode 100644 contrib/007705.html create mode 100644 contrib/007713.html create mode 100644 contrib/008523.html create mode 100644 contrib/010015.html (limited to 'contrib') 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 @@ + + + + [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/contrib/007713.html b/contrib/007713.html new file mode 100644 index 00000000..2f001ece --- /dev/null +++ b/contrib/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/contrib/008523.html b/contrib/008523.html new file mode 100644 index 00000000..535ffec5 --- /dev/null +++ b/contrib/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/contrib/010015.html b/contrib/010015.html new file mode 100644 index 00000000..4ba2faf8 --- /dev/null +++ b/contrib/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/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 -- cgit v1.2.3