Thorsten Froehlich wrote:
>>>What a great argument.  It is not web clients, it is *every* newsreader that
>>>has to do guessing where attachments start if a message is not in MIME
>>>multipart format.
>>
>>I'm still not understanding why you'd expect the newsreader to ignore a
>>content-type of text/plain but obey a content-type of multipart/*?
> 
> I don't *expect* newsreaders to do anything.  I am just quoting a fact, is
> that really so difficult to grasp?

Well, you're claiming that every newsreader has to do this, and that 
isn't true. What I think you're saying is that in order to display every 
possible form of "attachment", the newsreader must sometimes look at the 
content of messages declared as "text/plain" explicitly, in order to see 
if that header is accurate.

Which is fine, if that's what you want to require. I just think it's 
quite unusual to expect that.

>>I find that most all messages either post correct MIME
> 
> That is because you don't know the MIME specification!

Of course I do. I've been writing programs that read and write MIME 
messages for longer than the WWW has been around. I worked for the guy 
who invented MIME while I did that. Many times I telnetted to an SMTP 
server and typed MIME multipart messages directly into the mail server. 
I've written mail-driven online shopping malls. I'm pretty sure I 
understand how MIME works.

Admittedly, there's no specific RFC that says MIME should be applied to 
messages delivered via NNTP. But if you claim a message is 
MIME-complient in an NNTP-based message, I think it's reasonable 
behavior for the mail reader to take your word for that and not go 
groping around for non-MIME attachments in the middle.

If you don't think that's reasonable, power to you. It's your server, 
and I'm not about to browbeat you over it. :-) I just won't be looking 
at most of those posts.

>>I find that the clients that try to guess content in spite of MIME
>>headers saying what the content are are the clients that are
>>traditionally most heinously insecure because of that, which is why I
>>don't use them.
> 
> 
> Sorry, but you just don't know what you are talking about here.  If your
> client won't be guessing, you couldn't see most of the messages on this
> server at all.

No, most of them either aren't labeled as MIME-complient, or they use 
MIME correctly. It's the half-and-half bit that doesn't work right on 
this client. If you post a uuencoded message with no mime headers, the 
client I'm using tries to guess.

And what I was referring to in that particular paragraph is the tendency 
for Outlook et al to run executable programs when the content type 
doesn't match the extension on the file, which is where many many many 
of the viri currently circulating come from.

>>OK. I'm boggled by the concept that a client should, based on the
>>protocol used to retrieve the message, obey a content-type multipart/*,
>>ignore *half* of the content-type text/plain, and ... um ... what about
>>other content types? What would you do?
> 
> 
> You really don't want to understand what I am saying, you you?  It does not
> matter what anybody *expects*!  I am just saying what clients do!  And we
> cannot change what clients do, now can we?  So we have to deal with it.

You're saying what *some* clients do. I saw quite a few posts saying 
that their clients couldn't handle it. And there's no need to yell. And 
the right way of dealing with clients that accept "broken" messages 
isn't to generate "broken" messages, is my point. There are a number of 
ways of attaching images to mail messages, and attaching them using 
uuencode inside a message declared as mime-complient is probably the 
brokennest. I understand *why* you did it; I'm just saying it's the 
wrong solution, with the right solution being to bite the bullet and 
generate a mime-multipart.

>> > The catch is, if you
>> > just put in a Content-Type header without claiming a message to be
>> > compatible with MIME, some newsreaders will ignore the
>> > Content-Type header
>> > completely also many will still interpret it correctly.
>>
>>But you want them to ignore half the content type, apparently? :-)
> 
> 
> Sorry, but now you repeated the same nonsense three times in this message...

I don't see what's nonsensical about it. You think they should look at 
something, show half of it as text in the character set you suggested, 
and decode the other half. I'm saying "that's a bad way to do it, given 
the other standards about that people have actually widely implemented."

Is there any client out there that will display the image in a uuencoded 
message inside a MIME message that will *not* handle a mime multipart?

-- 
Darren New, San Diego CA USA (PST)
   I am in geosynchronous orbit, supported by
   a quantum photon exchange drive....

Post a reply to this message