Re: [Pan-users] [Gentoo] custom pan-9999 ebuild Was: Articles Pan Can't Read

[Duncan]

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