[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-users] Re: Can post, but cannot reply
[Pan-users] Re: Can post, but cannot reply
Tue, 28 Oct 2008 04:35:15 +0000 (UTC)
Pan/0.133 (House of Butterflies)
Steven D'Aprano <address@hidden> posted
address@hidden, 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
> 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
> 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
> 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