On 02/10/2011 1:11 AM, Travis wrote:
On Tue, 27 Sep 2011 09:42:57 -0400, Wolf K wrote:

On 27/09/2011 8:29 AM, Mad Cow wrote:
[ Section: 1/1 File: zCistus01.jpg UUencoded by: Turnpike Integrated
Version 5.02 S ]

begin 644 zCistus01.jpg
M_]C_X``02D9)1@`!`0$`2`!(``#_X1E017AI9@``34T`*@````@` #`$/``(`
M```&````G@$0``(````.````I`$2``,````!``$```$:``4`` ``!````L@$;
M``4````!````N@$H``,````!``(```$R``(````4````P@$[``(````!```
[etc]

As you can see, your image doesn't open automatically in my news reader
(Thunderbird). [...]

My newsreader is Pan and it displayed the picture just fine.

I've filed a bug-report with Thunderbird. It does in fact use only
message header information for decoding. That is, it expects the
standard message structure. Putting encoding data within the message
body is a no-no, but it seems Turnpike does this. If there are enough
"malformed" messages out there, the bug will be fixed.

Have a good day.

Wolf K.

In article , Wolf K
writes
On 02/10/2011 1:11 AM, Travis wrote:
On Tue, 27 Sep 2011 09:42:57 -0400, Wolf K wrote:

On 27/09/2011 8:29 AM, Mad Cow wrote:
[ Section: 1/1 File: zCistus01.jpg UUencoded by: Turnpike Integrated
Version 5.02 S ]

begin 644 zCistus01.jpg
M_]C_X``02D9)1@`!`0$`2`!(``#_X1E017AI9@``34T`*@````@` #`$/``(`
M```&````G@$0``(````.````I`$2``,````!``$```$:``4`` ``!````L@$;
M``4````!````N@$H``,````!``(```$R``(````4````P@$[``(````!```
[etc]

As you can see, your image doesn't open automatically in my news reader
(Thunderbird). [...]

My newsreader is Pan and it displayed the picture just fine.

I've filed a bug-report with Thunderbird. It does in fact use only
message header information for decoding. That is, it expects the
standard message structure. Putting encoding data within the message
body is a no-no, but it seems Turnpike does this. If there are enough
"malformed" messages out there, the bug will be fixed.


Interesting: my expert says nothing in the message header relates to
attachments. What matters is the blank line followed by 'begin 664
filename' (or 'begin 666 filename' if you have a Microsoft emanation)
and the end markers.
That means if you attach one UUencoded and one MIME encoded file to a
message they should both be decoded successfully.
I'd like to try that in an e-mail to Thunderbird since I can't try it in
news; I haven't time just now but will try to remember it when I return
home...

Happy snapping
--
Sue ]

On 03/10/2011 1:31 PM, Mad Cow wrote:
Interesting: my expert says nothing in the message header relates to
attachments. What matters is the blank line followed by 'begin 664
filename' (or 'begin 666 filename' if you have a Microsoft emanation)
and the end markers.

OK, I'll try to explain what's going on. Bewar with me. ;-)

In your message there are two lines:
"begin 644 zCistus01.jpg"

That's the file type, and it will be there whether the image is attached
or "in-line". But it is the file type, _not_ the encoding type. The
encoding applies to the message as a whole. (1)

Before that there's
"[ Section: 1/1 File: zCistus01.jpg UUencoded by: Turnpike Integrated
Version 5.02 S ]"

That refers to a message encoding method. It should be in the message
header, but there I find:

"mime-version: 1.0"

That refers to the encoding of the message as whole, attachments and
all. Since there is only one section (the jpg image) there's only one
line referring to the encoding method.

The problem is that Turnpike adds the "UUencoded" bit before that.
However, because the message header says it's mime-encoded, TB
reads/decodes the whole message as a mime-encoded message, and that's
why I see a jumble of random characters. It sees the bit about
UUencoding as part of the message body, and not as a directive to switch
decoding methods. Turnpike should _not_ refer to one encoding method in
the message header, and another one within the message body. That's very
bad manners. Really. ;-)

The problem is more complicated by the fact that in the message as sent,
the image is actually not an attachment. It's "in line". Attachments
follow the message body. Um, that's why they are called "attachments", I
guess. ;-)

By contrast: In a message I sent with an attachment, the message header
says:
mime-version:1.0

It also says, lower down:
content-type:multipart/mixed; boundary="------------080503000101000907090103

This warns the receiving news-reader that there are several parts to the
message, in different file formats, and that it will have to use
different methods to display the different parts. There is no such line
in your message, which by default means "there is only one type of
content in this message", and by default, that is always taken to be
plain text. So you see, TB just did as it was told by the instructions
that Turnpike placed in your post: it converted every chunk of 8 bits
into a text character, did not look for a boundary between data-types,
and did not look for "begin 644 zCistus01.jpg".

Obviously, other news readers can deal with mixed decoding instructions,
and decoding instructions elsewhere than in the header. TB cannot.
That's why I filed a bug-report.

And that I think, is about as clearly as I can explain the problem(s).

;-)

Wolf K.

(1) What confuses is that an internet message must be encoded before it
is sent, regardless of what types of files it contains. Displaying an
internet message takes three steps: first, decode it into the original
data; second, determine the file type(s); third, deal with each file
type as needed for display.

The reason mime and UUencode (and a few others) are used to encode
messages before they are sent is history. If you really want on know,
Wikipedia will tell you. ;-)

WK.

On 03/10/2011 1:31 PM, Mad Cow wrote:
Interesting: my expert says nothing in the message header relates to
attachments.

Your expert is mistaken. If there is an attachment, and/or there are
several file types within a message, your newsreader should insert a
line that begins "content-type", and indicate where the boundaries
between the different content types occur. If there is no such line in
the header the news reader or email client will interpret the message as
"all plain text."

See my longer post for clarification. At least, I hope it's
clarification. ;-)

Wolf K.

On 03/10/2011 1:31 PM, Mad Cow wrote:
That means if you attach one UUencoded and one MIME encoded file to a
message they should both be decoded successfully.

You don't control that. The newsreader or e-mail client does. the most
you can do (with some clients) is to set the encoding method, which will
apply to the whole message.

If Turnpike allows you to mix encoding within a message, its programmers
were very naughty. You shouldn't be able to do it.

HTH
Wolf K.

In article , Wolf K
writes
On 03/10/2011 1:31 PM, Mad Cow wrote:
Interesting: my expert says nothing in the message header relates to
attachments.

Your expert is mistaken. If there is an attachment, and/or there are
several file types within a message, your newsreader should insert a
line that begins "content-type", and indicate where the boundaries
between the different content types occur. If there is no such line in
the header the news reader or email client will interpret the message as
"all plain text."


It's far more likely that I've misunderstood him, but he's away at the
moment and I leave before he gets back.

I think I've now understood your explanation of how Thunderbird works,
but I'm pretty confident Turnpike conforms to the protocol because it
was written in the days when Usenet mattered, and its users were about
95% geek. They'd have objected to any departure from the rules even if
it wasn't a problem for them. The good old days...
--
Sue ]