Anthony Kim <Anthony(_dot_)Kim(_at_)walgreens(_dot_)com> writes:
It's doing a FETCH -- I assume in standard fashion.
Client sends:
0x0030: 0500 4fff 6130 3035 3220 4645 5443 4820 ..O.a0052.FETCH.
0x0040: 313a 3120 2855 4944 2046 4c41 4753 2049 1:1.(UID.FLAGS.I
0x0050: 4e54 4552 4e41 4c44 4154 4520 5246 4338 NTERNALDATE.RFC8
0x0060: 3232 2e53 495a 4520 424f 4459 2e50 4545 22.SIZE.BODY.PEE
0x0070: 4b5b 4845 4144 4552 2e46 4945 4c44 5320 K[HEADER.FIELDS.
0x0080: 2844 4154 4520 4652 4f4d 2053 5542 4a45 (DATE.FROM.SUBJE
0x0090: 4354 2054 4f20 4343 204d 4553 5341 4745 CT.TO.CC.MESSAGE
0x00a0: 2d49 4420 5245 4645 5245 4e43 4553 2043 -ID.REFERENCES.C
0x00b0: 4f4e 5445 4e54 2d54 5950 4520 434f 4e54 ONTENT-TYPE.CONT
0x00c0: 454e 542d 4445 5343 5249 5054 494f 4e20 ENT-DESCRIPTION.
0x00d0: 494e 2d52 4550 4c59 2d54 4f20 5245 504c IN-REPLY-TO.REPL
0x00e0: 592d 544f 204c 494e 4553 204c 4953 542d Y-TO.LINES.LIST-
0x00f0: 504f 5354 2058 2d4c 4142 454c 295d 290d POST.X-LABEL)]).
mutt requests a specific subset of headers by means of
BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES
CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO REPLY-TO LINES LIST-POST X-LABEL)]
No Content-Transfer-Encoding.
Server says OK FETCH completed although you don't see the
Content-Transfer-Encoding header here. Is that normal?
In this case, yes.
Now, when the server responds with BODY - you DO see the
Content-Transfer-Encoding header:
...
0x0030: 48b8 0a86 2a20 3120 4645 5443 4820 2842 H...*.1.FETCH.(B
0x0040: 4f44 595b 5d20 7b32 3431 367d 0d0a 5265 ODY[].{2416}..Re
0x0050: 6365 6976 6564 3a20 6672 6f6d 2064 6f6d ceived:.from.dom
0x0060: 736d 7470 312e 7761 6c67 7265 656e 732e smtp1.walgreens.
0x0430: 636f 6d3e 0d0a 5375 626a 6563 743a 2052 com>..Subject:.R
0x0440: 653a 2054 6869 7320 6973 2061 2074 6573 e:.This.is.a.tes
0x0450: 740d 0a54 6f3a 2061 6e74 686f 6e79 2e6b t..To:.anthony.k
0x0460: 696d 4077 616c 6772 6565 6e73 2e63 6f6d im(_at_)walgreens(_dot_)com
0x0470: 0d0a 436f 6e74 656e 742d 5479 7065 3a20 ..Content-Type:.
0x0480: 7465 7874 2f70 6c61 696e 3b20 6368 6172 text/plain;.char
0x0490: 7365 743d 6973 6f2d 3838 3539 2d31 0d0a set=iso-8859-1..
0x04a0: 436f 6e74 656e 742d 5472 616e 7366 6572 Content-Transfer
0x04b0: 2d45 6e63 6f64 696e 673a 2071 756f 7465 -Encoding:.quote
0x04c0: 642d 7072 696e 7461 626c 650d 0a44 6f6d d-printable..Dom
0x04d0: 6169 6e4b 6579 2d53 6967 6e61 7475 7265 ainKey-Signature
0x04e0: 3a20 613d 7273 612d 7368 6131 3b20 713d :.a=rsa-sha1;.q=
0x04f0: 646e 733b 2063 3d6e 6f66 7773 3b0d 0a20 dns;.c=nofws;...
So BODY[] works and the data are there,
but RFC822.HEADER (fetchmail) does not return the complete header.
And then when I run fetchmail, like before, I'm not given the
CTE header and the quoted-printable output looks like garbage.
I don't know if the problem in fact is Domino being stupid and due
to some strange reaction from our antispam engine. I see this
later in the mail headers:
X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.0, Antispam-Data:
2006.02.15.154604
X-MIME-Autoconverted: from 8bit to quoted-printable by
iwagmail7.walgreens.com id k1G07s8X
030905
X-MIMETrack: Itemize by SMTP Server on DomSMTP1/Walgreens(Release
6.5.5|November 30, 2005)
...
I don't see how that would make a difference to the IMAP server, but
then I don't see its insides either.
The additional headers surely should not make the CTE header disappear.
Could you manually log into the server with telnet or netcat or perhaps
openssl and see if the BODY.PEEK[HEADER] works?
You'd type (including the leading A0 A1 A2...)
telnet yourimap.walgreens.com 143
A0 CAPABILITY
check if the output doesn't have LOGINDISABLED, if it has, you'll need
to try a debugging wrapper that can use other authentication schemes, or
resort to OpenSSL
A1 LOGIN user password
A2 SELECT "INBOX"
A3 FETCH 1 BODY.PEEK[HEADER]
A4 LOGOUT
Check if the response to the A3 FETCH command includes the CTE header.
If it does, using this command and making fetchmail parse the different
response format would be the cheapest workaround I could think of, and,
unless someone else has a good idea, the only that might get implemented
in 6.3.X.
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.
It's that Autoconvert line that has me thinking. But since I'm not
the server admin, I'll have to make due.
Is there any harm in a procmail recipe that adds CTE:
quoted-printable to my mails?
Well, aside from the general dangers of procmail integration, no (its
error fallthrough behavior is the main problem).
But it's not a complete solution either, since you wouldn't have this
X-MIME-Autoconverted header if the original message arrived as
quoted-printable already.
--
Matthias Andree
_______________________________________________
Fetchmail-friends mailing list
Fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org
http://lists.ccil.org/cgi-bin/mailman/listinfo/fetchmail-friends