Heinrich Mueller posted on Wed, 31 Aug 2011 15:58:25 +0200 as excerpted: > Am 31.08.2011 14:30, schrieb Duncan: >> There does seem to be a bit of implementation cruft ATM (headers that >> aren't, well, headers), but the basics do seem to work. =:^) > Please explain further, I'm curious to fix this ...
I had intended to do just that when I had a bit more time, which I do now, so... Since the posts are to this list (just up-thread in this thread, too), it should be easy to reference them, to see what I'm talking about. When I first looked at the attachment posts, I noted this at the top of the body, before the "attachments", which being plain-text, I had sent as unencoded: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="pan-9999" That's obviously MIME headers, I thought, but why were they appearing in the body? A quick toggle-headers revealed what I suspected, that the actual headers contained the usual blank line separating them from these "pseudo- headers", with the real headers including: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That did happen to be correct, but then after the blank line indicating the end of the headers was the second set of "pseudo-headers" posted above. If I have my MIME-header conditions correct, if there are multiple parts, the main content-type header should be one of: Content-Type: multipart/alternative; boundary="xxx" Content-Type: multipart/related; boundary="xxx" (I believe I've also seen multipart/mixed, but I don't have a quick example at hand and this isn't intended to be a rigorous description, just a quick intro/review.) * xxx as a boundary is then some sequence unlikely to match real content. * Multipart/alternative would be used for text/plain vs text/html, for instance, the client is supposed to choose ONE of the alternatives to display, depending on what it handles best or user preference. * Multipart/Related is instead used for attachments, etc, where all may be shown if the client has the capacity to do so and considers it useful or appropriate or is appropriately configured. * (Multipart/mixed would IIRC be for general attachments of no specific relationship.) * Parts can be nested, so a multipart/related can contain a multipart/ alternative with a different boundary sequence for the inner one, for instance, in say a message with html vs plain text with attachments displayed inline in the html version for html rendering clients, or after the plain-text version for non-html rendering clients. Another example of nesting is messages forwarded "as attachments". Note that such forwarded-message-nesting is often several layers deep after several rounds of forwarding, as often happens with jokes, etc. It works so long as each level of nesting has its own distinct boundary sequence so the client can sort it all out correctly. But since the content-type was NOT multipart, there was only the single part. The second set of "pseudo-headers" thus appeared in the body as part of the message text, because to the client, it appears that they're intended to be part of the literal message text (data not metadata), exactly as they actually *are* part of the message, here, since I'm discussing the content of a previous message. Now, I'm not sure how your code now handles yenc since my only test of that was rather earlier code, but at least with this plain-text encoding, assuming you're not going to try to get all complicated with multipart, you need to merge the two sets of headers, basically: a) doing away with the Mime-version: header in the body b) setting the Content-type and Content-transfer-encoding headers only once, appropriately for the message as a whole, in the main headers (doing away with the second set in the pseudo-headers that appear as part of the body) c) moving Content-Disposition from the body as a pseudo-header into the main headers. The alternative, of course, would be the significantly more complex choice of coding, testing, and debugging proper MIME-multipart handling, but IMO that's definitely a "bluesky" target challenge. It's just not worth worrying about at this point, when attachments-as-separate-followup- articles works in practice and is SO much less complex to deal with, coding, testing AND debugging. I hope that all makes sense. Again, refer to the attachment-articles themselves, up-thread, for concrete examples. View-headers or open the raw text messages in a text editor, if necessary. Between that and knowing that the first blank line is to be treated as the end of headers and beginning of the body, according to the RFCs, it should hopefully be clear. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
