e servers don't follow rfc recommendations
aboutsummaryrefslogtreecommitdiffstats
path: root/contrib/010015.html
blob: 4ba2faf8143ae8075bc7020b1f4074b0a41f3f90 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [fetchmail]Domino IMAP and missing Content-Transfer-Encoding
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:Anthony.Kim%40walgreens.com">
   <META NAME="robots" CONTENT="index,nofollow">
   
   
   <LINK REL="Next"  HREF="010016.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[fetchmail]Domino IMAP and missing Content-Transfer-Encoding
   </H1>
    <B>Anthony Kim
    </B> 
    <A HREF="mailto:Anthony.Kim%40walgreens.com"
       TITLE="[fetchmail]Domino IMAP and missing Content-Transfer-Encoding">Anthony.Kim@walgreens.com
       </A><BR>
    <I>Wed, 1 Mar 2006 23:02:52 -0600</I>
    <P><UL>
        
        <LI> Next message: <A HREF="010016.html">[fetchmail]Domino IMAP and missing Content-Transfer-Encoding
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#10015">[ date ]</a>
              <a href="thread.html#10015">[ thread ]</a>
              <a href="subject.html#10015">[ subject ]</a>
              <a href="author.html#10015">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>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:

&gt;<i> In 6.4.X, we might implement an option so that fetchmail does not
</I>&gt;<i> split header/body fetch but get the whole message including
</I>&gt;<i> header in one huge piece as POP3 does which makes undeliverable
</I>&gt;<i> mail more expensive though.
</I>
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 &quot;Prefers MIME&quot;.  Switching to &quot;Keep in Sender's
format&quot; solved the missing encoding header problem.

According to IBM, &quot;Prefers MIME&quot; offers the best IMAP performance
in Domino &quot;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.&quot; [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] <A HREF="http://www-128.ibm.com/developerworks/lotus/library/ls-D6_IMAP_Perf/?OpenDocument">http://www-128.ibm.com/developerworks/lotus/library/ls-D6_IMAP_Perf/?OpenDocument</A>



</PRE>
<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	
	<LI> Next message: <A HREF="010016.html">[fetchmail]Domino IMAP and missing Content-Transfer-Encoding
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#10015">[ date ]</a>
              <a href="thread.html#10015">[ thread ]</a>
              <a href="subject.html#10015">[ subject ]</a>
              <a href="author.html#10015">[ author ]</a>
         </LI>
       </UL>
</body></html>