Steven D'Aprano <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 28 Oct 2008 08:58:07 +1100:
> On Mon, 27 Oct 2008 07:56:52 am Duncan wrote: >> Please can the HTML. There's a reason (security, respect for those who >> have plain text clients) pan doesn't do HTML. > > That's a bogus argument. The poster's message contained a perfectly > valid, readable, secure plain text message attachment. If he was sending > HTML mail without a plain text body, then I would agree with your > criticism 100%. But that's not what happened. He did the right thing: > plain text for those who don't trust Yahoo or have a plain text client, > and HTML for those who want the "Rich Text experience". But the existence of the plain text doesn't eliminate the security issue, for those clients that parse it. The sender must choose plain text /only/ in ordered to eliminate it. > If Pan doesn't want to render the HTML attachment as HTML (a wise > choice) there's no reason for it to run the plain text message and the > HTML message together. That's just crazy, and it suggests either lousy > programming or dumb insolence. Since Charles isn't a lousy programmer, > I'm going with dumb insolence: rather than doing the right thing, he's > chosen to deliberately be inconvenient for people who send HTML mail. Yes, running them together isn't ideal. I'll agree there. Really, the problem is sending clients, however. The default should be plain text (only) unless the user deliberately sets otherwise. GNKSA gets this right as do various other recommendations. Far too often people don't even know they are sending HTML. They shouldn't have to care. Plain text should be the default "don't know" format. > Except it's actually inconvenient for *everyone*, and makes Pan look > stupid. > > If Pan is not going to render the HTML (as I said, a wise choice) then > the right thing to do is to treat it like any other attachment it > doesn't render. It didn't take me long to find a message on another > newsgroup with this: > > Attachment not shown: MIME type application/x-pkcs7-signature; filename > smime.p7s > > Why does Pan not do this? > > Attachment not shown: MIME type text/html; filename <unnamed> That would be the best, certainly. If pan can do it with signatures, it could certainly do it with HTML. Hmm, anyone up to writing a patch? But while that would indeed change the view of the problem at the (pan) reader end, it wouldn't change the problem itself, that being people sending HTML posts, with all the security and spamming implications thereof. So the requests, at least in my posts (see below), would of necessity continue. > The KDE newsreader, knode, does the right thing. It's time Pan entered > the 1990s and did too. > > Duncan, it's time for you to move on. This battle was lost ten years > ago. In the absence of a widely supported "Rich Text" format for email > without the disadvantages of HTML, complaining about HTML attachments > when the email includes a perfectly valid plain text body is like one of > those curmudgeonly old men complaining about those young > whipper-snappers and their "Walkmen". The basic tenet is that if it needs "rich text" to dress up the presentation in ordered to keep the readers interest or be worth reading, it's not worth reading in any case. That's why HTML spam filters are relatively effective -- the salesmen have to dress it up the scammers have to obfuscate, and the spyware folks want to know when their message is read and/or infect the reader, and they think HTML the perfect tool for doing so. Those sending valid messages that actually need to be read don't need any of that in ordered to get the message across, and a little thought will lead to choosing to avoid it, to avoid the association with the the scum of the net that use it so much, and the filtering that can come with that. So maybe I should switch to that. Simply tell folks that if it's worth saying, they can say it in plain text, and that's the only reply they'll get from me until they do. OTOH, it's my reply. If they post a question looking for an answer and I reply, in that reply goes that no HTML request (or no upside down aka top- posting request) if appropriate. The one doesn't come without the other. If they don't like my reply style, they don't have to read it. That's what filters are for. OTOH, I expect few will dispute that my answers often provide details and explanations missing in the replies of others (as the reply did here), so if they choose to cut themselves off from that, they'll be missing quite some useful information. Again, you get one, the other comes with it. It's a package deal. If I were to stop posting the no HTML requests, I'd be simply ignoring the posts entirely, and the user (and other list/group subscribers) would miss the generally unique and I expect many would agree valuable content my posts provide. Certainly the status quo is better than either of the alternatives, no replies at all, or only a plain text before answer reply. There's effectively no other choices, since it's my replies and they'd simply not be made (the no reply choice) otherwise. -- 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 http://lists.nongnu.org/mailman/listinfo/pan-users
