[Pan-users] Re: Can post, but cannot reply

[Duncan]

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
> 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