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 --- 007705.html | 70 -------------------------- 007713.html | 70 -------------------------- 008523.html | 141 ---------------------------------------------------- 010015.html | 100 ------------------------------------- Makefile.am | 7 +-- TODO.txt | 1 - contrib/007705.html | 70 ++++++++++++++++++++++++++ contrib/007713.html | 70 ++++++++++++++++++++++++++ contrib/008523.html | 141 ++++++++++++++++++++++++++++++++++++++++++++++++++++ contrib/010015.html | 100 +++++++++++++++++++++++++++++++++++++ contrib/README | 4 ++ 11 files changed, 386 insertions(+), 388 deletions(-) delete mode 100644 007705.html delete mode 100644 007713.html delete mode 100644 008523.html delete mode 100644 010015.html create mode 100644 contrib/007705.html create mode 100644 contrib/007713.html create mode 100644 contrib/008523.html create mode 100644 contrib/010015.html diff --git a/007705.html b/007705.html deleted file mode 100644 index 88f85ecf..00000000 --- a/007705.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - [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 deleted file mode 100644 index 2f001ece..00000000 --- a/007713.html +++ /dev/null @@ -1,70 +0,0 @@ - - - - [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 deleted file mode 100644 index 535ffec5..00000000 --- a/008523.html +++ /dev/null @@ -1,141 +0,0 @@ - - - - [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 deleted file mode 100644 index 4ba2faf8..00000000 --- a/010015.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - [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 31ac75dd..82fb7d7a 100644 --- a/Makefile.am +++ b/Makefile.am @@ -132,12 +132,7 @@ 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 \ - 007705.html \ - 007713.html \ - 008523.html \ - 010015.html - + fetchmail-SA-2005-03.txt # extra directories to ship distdirs = rh-config contrib beos diff --git a/TODO.txt b/TODO.txt index a282d2d0..34ef153a 100644 --- a/TODO.txt +++ b/TODO.txt @@ -1,5 +1,4 @@ 6.3.6: -- move .html files from list archive to some doc directory - Zak's further minor issues - Debian Bug #400950: SSL cert CN overrides --user, since Götz Nimrill's authenticate external patch. 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