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

+ -- cgit v1.2.3