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/010015.html | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 contrib/010015.html (limited to 'contrib/010015.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 @@ + + + + [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
+
+
+
+
+ +
+

+ -- cgit v1.2.3