[alpine] multipart quoting of big5 [Was: making posts unreadable ...]
Jeffrey Goldberg
In <slrnffffrm...@dost.mchm.siemens.de>, Thomas Wiegner wrote:
> On 2007–09—24, Thomas Wiegner <wie...@gmx.de> wrote:
>> Useless use of multipart postings is something which does *not*
>> improve the usenet.
How thoroughly embarrassing.
>> I'm pretty sure it is possible to turn off this braindead default
>> behaviour of alpine (I know it's possible for pain^Wpine)
It appears that in my quoting of a message that used charset=big5, alpine
decided to package my entire message as the only part of MULTIPART/MIXED
message.
(Al)pine's default behavior, as far as I know, has always been to use
text/plain without creating a multipart message.
> UPS, this should have been a reply to
> <alpine.OSX.0.9999...@hagrid.ewd.goldmark.org>
That really is odd looking. I don't understand why alpine would want to
create a single part, "multipart" message.
> Anyway, good you changed this.
I did nothing. Apparently it has to do with what kind of stuff I'm
quoting. As I'm sure you've noticed, this message that you are reading
right now is an offender as well. I think that date in your own reply
lead-in is what triggered it in this instance, but I don't why alpine
behaves this way.
Thanks for letting me know about this.
-j
--
Jeffrey Goldberg http://www.goldmark.org/jeff/
I rarely read top-posted, over-quoting or HTML postings.
http://improve-usenet.org/
Eduardo Chappa
:) > > I'm pretty sure it is possible to turn off this braindead default
:) > > behaviour of alpine (I know it's possible for pain^Wpine)
:)
:) It appears that in my quoting of a message that used charset=big5,
:) alpine decided to package my entire message as the only part of
:) MULTIPART/MIXED message.
:)
:) (Al)pine's default behavior, as far as I know, has always been to use
:) text/plain without creating a multipart message.
There is a feature in Pine which controls this. It is disabled in this
case in your configuration. Its help text is below
(x-pine-help:h_downgrade_multipart_to_text). I hope this helps.
FEATURE: Downgrade-Multipart-To-Text
This feature affects Pine's behavior when sending mail. Internet standards
require Pine to translate all non-ASCII characters in messages that it
sends using MIME encoding. This encoding can be ostensibly broken for
recipients if any agent between Pine and the recipient, such as an email
list expander, appends text to the message, such as list information or
advertising. When sending such messages Pine attempts to protect such
encoding by placing extra MIME boundaries around the message text.
These extra boundaries are invisible to recipients that use MIME-aware
email programs (the vast majority). However, if you correspond with users
of email programs that are not MIME-aware, or do not handle the extra
boundaries gracefully, you can use this feature to prevent Pine from
including the extra MIME information. Of course, it will increase the
likelihood that non-ASCII text you send may appear corrupt to the
recipient.
--
Eduardo
http://staff.washington.edu/chappa/pine/
Jeffrey Goldberg
> There is a feature in Pine which controls this. It is disabled in this
> case in your configuration. Its help text is below
> (x-pine-help:h_downgrade_multipart_to_text). I hope this helps.
>
> FEATURE: Downgrade-Multipart-To-Text
>
> This feature affects Pine's behavior when sending mail. Internet standards
> require Pine to translate all non-ASCII characters in messages that it
> sends using MIME encoding. This encoding can be ostensibly broken for
> recipients if any agent between Pine and the recipient, such as an email
> list expander, appends text to the message, such as list information or
> advertising. When sending such messages Pine attempts to protect such
> encoding by placing extra MIME boundaries around the message text.
Eduardo,
That makes absolute sense for mail. (Al)pine's default before is the
correct choice for mail. The difficulty it seems is that there are a lot
of people using newsreaders that don't do MIME properly.
So I guess what I would want is a
"Downgrade-multipart-to-single-part-when-posting-to-news"
which seems like a lot to ask.
Peter J Ross
Chappa <cha...@u.washington.edu> wrote:
> There is a feature in Pine which controls this. It is disabled in this
> case in your configuration. Its help text is below
> (x-pine-help:h_downgrade_multipart_to_text). I hope this helps.
>
> FEATURE: Downgrade-Multipart-To-Text
>
> This feature affects Pine's behavior when sending mail. Internet standards
> require Pine to translate all non-ASCII characters in messages that it
> sends using MIME encoding. This encoding can be ostensibly broken for
> recipients if any agent between Pine and the recipient, such as an email
> list expander, appends text to the message, such as list information or
> advertising. When sending such messages Pine attempts to protect such
> encoding by placing extra MIME boundaries around the message text.
There has been no such added text in Jeffrey's posts.
> These extra boundaries are invisible to recipients that use MIME-aware
> email programs (the vast majority). However, if you correspond with users
> of email programs that are not MIME-aware, or do not handle the extra
> boundaries gracefully, you can use this feature to prevent Pine from
> including the extra MIME information. Of course, it will increase the
> likelihood that non-ASCII text you send may appear corrupt to the
> recipient.
I have no problem reading other MIME-encoded posts with slrn.
The problem is that multipart MIME posts are being sent when all
that's needed is a character-set declaration in the headers of a
*single-part* post.
I'll add this:
é
just to see what happens if a pine user replies to this. It would also
be interesting to know what users of other newsreaders are seeing in
the questionable posts, just in case it's really a bug in slrn.
It would be better to test this in a *.test group, but we'd all have
to agree to subscribe to the same one.
--
PJR :-)
Peter J Ross
Goldberg <nob...@goldmark.org> wrote:
> So I guess what I would want is a
>
> "Downgrade-multipart-to-single-part-when-posting-to-news"
>
> which seems like a lot to ask.
Unicode would be preferable, and one day perhaps all these legacy
character sets will die out and stop causing confusion. Does pine
support Unicode, e.g. UTF-8?
Most of your posts cause no problems at all; only the ones that used a
"Big-5" character set (in response to a post that included three
Chinese characters) were messed up.
By the way, is comp.mail.pine a proper place for discussion of pine
when it's used for Usenet, not for mail? I'm wondering, just in case
we get any pine questions in news.software.readers that could be
redirected to pine experts.
Once again, here's an "é". I want to know what happens.
--
PJR :-)
Eduardo Chappa
:) Eduardo,
:)
:) That makes absolute sense for mail. (Al)pine's default before is the
:) correct choice for mail. The difficulty it seems is that there are a
:) lot of people using newsreaders that don't do MIME properly.
:)
:) So I guess what I would want is a
:)
:) "Downgrade-multipart-to-single-part-when-posting-to-news"
:)
:) which seems like a lot to ask.
But consider that there could be a "free" news server out there that is
appending stuff (e.g. ads) to free posts and appends these messages
without regards to the charset of the message. Then wrapping makes sense.
I do not claim this is right or wrong. I only claim that this is the way
it works and why it works this way.
--
Eduardo
http://staff.washington.edu/chappa/pine/
Eduardo Chappa
:) I have no problem reading other MIME-encoded posts with slrn.
Well, you have found a case where you have a problem reading a
MIME-encoded message with slrn. The question is whose fault is it? lack of
support in slrn? over zealous behavior of Pine? Take your pick.
:) The problem is that multipart MIME posts are being sent when all that's
:) needed is a character-set declaration in the headers of a *single-part*
:) post.
Unless there is a news server that adds advertisement to every post
regardless of charset, then you are right.
In my opinion Pine's behavior is safer in terms of taking care of the
content of the message, but it might be unnecessary for news. I would
choose being cautious, though. I admit that I prefer a world where this
behavior is not necessary, but apparently we can not guarantee that we
live in such world. In fact, this "feature" (or bug, take your pick) came
as a response that the world we live in does not behave properly.
:) I'll add this:
:) é
:) just to see what happens if a pine user replies to this. It would also
:) be interesting to know what users of other newsreaders are seeing in
:) the questionable posts, just in case it's really a bug in slrn.
Your test should fail with my message. I have enabled that feature in
Pine, so my messages get downgraded automatically.
--
Eduardo
http://staff.washington.edu/chappa/pine/
Jeffrey Goldberg
> In news.software.readers on Mon, 24 Sep 2007 12:37:52 -0700, Eduardo
> Chappa <cha...@u.washington.edu> wrote:
>
>> There is a feature in Pine which controls this. It is disabled in this
>> case in your configuration. Its help text is below
>> (x-pine-help:h_downgrade_multipart_to_text). I hope this helps.
>>
>> FEATURE: Downgrade-Multipart-To-Text
>>
>> This feature affects Pine's behavior when sending mail. Internet standards
>> require Pine to translate all non-ASCII characters in messages that it
>> sends using MIME encoding. This encoding can be ostensibly broken for
>> recipients if any agent between Pine and the recipient, such as an email
>> list expander, appends text to the message, such as list information or
>> advertising. When sending such messages Pine attempts to protect such
>> encoding by placing extra MIME boundaries around the message text.
>
> There has been no such added text in Jeffrey's posts.
No, but when one sends to a mailing list text is added. (Al)pine doesn't
know what will happen to the message after it's sent it off. And because
things do occasionally get appended, it is the right decision to
encapsulate it in its own part.
> I have no problem reading other MIME-encoded posts with slrn.
Apparently slrn can deal with
content-type: text/plain; charset=whatever
just fine. But it is falling down on multipart/mixed, even when the
part(s) are things that it would otherwise be able to cope with. So slrn
is only partially MIME aware.
> The problem is that multipart MIME posts are being sent when all
> that's needed is a character-set declaration in the headers of a
> *single-part* post.
While that might always be safe for news to help out newsclients that
only do MIME halfway that won't generally work for mail for the reasons
quoted (which hadn't occurred to me until Eduardo posted that bit from the
documentation.
> I'll add this:
> é
> just to see what happens if a pine user replies to this.
From what I now understand of how alpine works, this will trigger the
multipart/mixed message.
> It would also
> be interesting to know what users of other newsreaders are seeing in
> the questionable posts, just in case it's really a bug in slrn.
Yes. But I fear that those who are experiencing the problem aren't going
to have the patience to read through the messages posted by (al)pine
users.
Cheers,
Jeffrey Goldberg
> Unicode would be preferable, and one day perhaps all these legacy
> character sets will die out and stop causing confusion. Does pine
> support Unicode, e.g. UTF-8?
Pine does. But that doesn't solve this problem. Until we know that
anything added to a message would be expecting to add to a UTF8 single
part, Pine (and other mailers) should behave as Pine does.
> Most of your posts cause no problems at all; only the ones that used a
> "Big-5" character set (in response to a post that included three
> Chinese characters) were messed up.
There was also a UTF8 message with non-ASCII characters I quoted that also
behaved this way.
> Once again, here's an [...]
I'm not quoting that this time because I do want people to be able to more
easily read my response to you.
Blinky the Shark
I see from you (and still here in my editor) the same e with the mark
over it that I saw in Peter's orignal send. I don't know what you'll
see when I send *this*, but I'm using the same client he is although his
has different tweaks.
--
Blinky RLU 297263
Killing all posts from Google Groups
The Usenet Improvement Project moved to this site August 28th:
http://improve-usenet.org
Peter J Ross
Goldberg <nob...@goldmark.org> wrote:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>
> --0-1219551813-1190669052=:468
> Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: QUOTED-PRINTABLE
You're doing it again, and this time it's ordinary UTF-8 that's being
sent as multipart/mixed for no reason. Why can't pine just specify the
charset in the headers for the whole post, like other newsreaders?
I'm now satisfied that the bug is in pine, not in slrn.
--
PJR :-)
Peter J Ross
Chappa <cha...@u.washington.edu> wrote:
> On Mon, 24 Sep 2007, Peter J Ross wrote:
>
>:) I have no problem reading other MIME-encoded posts with slrn.
>
> Well, you have found a case where you have a problem reading a
> MIME-encoded message with slrn. The question is whose fault is it? lack of
> support in slrn? over zealous behavior of Pine? Take your pick.
Pine seems to be the only newsreader that sends non-ASCII posts as
multipart MIME messages.
To me, it's a bug. To you, it's a feature. *shrug*
<...>
> Your test should fail with my message. I have enabled that feature in
> Pine, so my messages get downgraded automatically.
Compliance with standard Usenet conventions isn't "downgrading".
--
PJR :-)
Eduardo Chappa
:) > This message is in MIME format. The first part should be readable
:) > text, while the remaining parts are likely unreadable without
:) > MIME-aware tools.
:) >
:) > --0-1219551813-1190669052=:468
:) > Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
:) > Content-Transfer-Encoding: QUOTED-PRINTABLE
:)
:) You're doing it again, and this time it's ordinary UTF-8 that's being
:) sent as multipart/mixed for no reason. Why can't pine just specify the
:) charset in the headers for the whole post, like other newsreaders?
Let me put it this way, maybe you will get it now.
Imagine I send you letters to your home. Normally I would just put them
in an envelope and you can just open it and read it at home as is normally
done. You do not have problems with that mail.
Assume that for whatever reason, I decided to send you a letter in a box
that requires a special kind of scissors for it to be opened. Scissors can
be found in any store.
Now if you do not have scissors at home, is it my fault that you can not
open the box where I put the letter? Of course you can be mad at me for
sending the letter in a box, but it is not my fault that you can not read
it; after all anyone with scissors can open the box.
You have to make a choice:
* Get the scissors and open the box
* Do not get scissors.
Of course in the future you can request, and even ignore all people that
send you letters in boxes, but that won't stop the world from using boxes,
so it's up to you.
The encoding of the message was done in a standard compliant way. Known
and practicesd for years already. If slrn does not support it, you may
want to request to anyone developing it that they add support to it,
because it seems to be that people exchange messages in that form, even if
you see no reason for it. If the feature gets added, great.
--
Eduardo
http://staff.washington.edu/chappa/pine/
Peter J Ross
Chappa <cha...@u.washington.edu> wrote:
> Let me put it this way, maybe you will get it now.
Let me put it this way:
"Content-Type: multipart/mixed" has no place in Usenet outside
alt.binaries, with the sole exception of PGP/MIME signatures, and even
they're generally disliked and are likely to result in the poster
being widely killfiled.
Please encourage the pine developers to fix the bug in their software
that prevents pine users from sending anything other than US-ASCII
without perpetrating an approximate equivalent to text/html.
--
PJR :-)
Jeffrey Goldberg
> Am I the only one who thinks that (a) pine is broken and (b) some
> comp.mail.pine posters are in danger of disappearing up their own
> arses?
The rational for (al)pine using multipart/mixed was explained in the
material Eduardo posted. Do you have an argument with that rationale?
If so, don't just bitch about it among yourselves, tell it to the pine
people.
> Pine is sending "multipart/mixed" articles, and they think that's
> *good*.
Apparently slrn only implements MIME standards in a half-assed way, and
they think that that is good. Furthermore those users want the rest of
the world to adjust slrn's non-standard implementation.
> (I've snecked the crosspost, because I'm talking about them, not to
> them.)
Ooops. I put it back in because now I'm talking about slrn users who like
to lecture others about standards and correctly say that people shouldn't
"break" their own software to adjust to others' non-standard
implementations. We like talking *about* such things on comp.mail.pine.
Top
It does happen and it happens because the server allows it and people that
never heard of USENET are running the show. They look and see a way to get
some "free advertizing". Then they don't even know how to do it cleanly.
Top
Mark Crispin
> It does happen and it happens because the server allows it and people that
> never heard of USENET are running the show. They look and see a way to get
> some "free advertizing". Then they don't even know how to do it cleanly.
The good news in all of this is that USENET is dying rapidly and in a few
years nobody will care. Many formerly-respectable newsgroups have become
sewers, with the result that many former participants have dropped out.
Our USENET servers will probably be shut down due to disuse (only a few
dozen people still read news) in the not-too-distant future. I read fewer
than 10 newsgroups these days.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Blinky the Shark
> On Mon, 24 Sep 2007, Top wrote:
>> It does happen and it happens because the server allows it and people
>> that never heard of USENET are running the show. They look and see a
>> way to get some "free advertizing". Then they don't even know how to
>> do it cleanly.
>
> The good news in all of this is that USENET is dying rapidly and in a
> few years nobody will care. Many formerly-respectable newsgroups have
> become sewers, with the result that many former participants have
> dropped out.
>
> Our USENET servers will probably be shut down due to disuse (only a
> few dozen people still read news) in the not-too-distant future. I
> read fewer than 10 newsgroups these days.
I saw something about a major state university turning off its servers a
month or two ago; I think it was in Virginia, but it might have been in
North Carolina -- I just have a vague memory of the general area.
That was sad; two is sadder yet.
Dan C
> On 2007-09-25, Mark Crispin wrote:
>> It does happen and it happens because the server allows it and people that
>> never heard of USENET are running the show. They look and see a way to get
>> some "free advertizing". Then they don't even know how to do it cleanly.
> The good news in all of this is that USENET is dying rapidly and in a few
> years nobody will care.
How is that "good news"?
--
"Ubuntu" - an African word meaning "Slackware is too hard for me".
Thomas Wiegner
> On Mon, 24 Sep 2007, Jeffrey Goldberg wrote:
>
>:) That makes absolute sense for mail. (Al)pine's default before is the
>:) correct choice for mail. The difficulty it seems is that there are a
>:) lot of people using newsreaders that don't do MIME properly.
>:)
>:) So I guess what I would want is a
>:)
>:) "Downgrade-multipart-to-single-part-when-posting-to-news"
>:)
>:) which seems like a lot to ask.
>
> But consider that there could be a "free" news server out there that is
> appending stuff (e.g. ads) to free posts and appends these messages
> without regards to the charset of the message. Then wrapping makes sense.
And why are only posts with non-ascii characters mangled to pseudo
multipart postings? The above argument is also valid for pure us-ascii
postings.
I've never seen newsservers adding ads to postings. I've seen that on
mailing lists.
Thomas
Thomas Wiegner
> In <slrnffgke...@pjr.gotdns.org>, Peter J Ross wrote:
>
>> Am I the only one who thinks that (a) pine is broken and (b) some
>> comp.mail.pine posters are in danger of disappearing up their own
>> arses?
>
> The rational for (al)pine using multipart/mixed was explained in the
> material Eduardo posted. Do you have an argument with that rationale?
> If so, don't just bitch about it among yourselves, tell it to the pine
> people.
The reason is simply not true. It makes no sense to do what pine does,
to create "multipart" posts for articles with 8 bit characters and not
to do so for us-ascii. At least with the argument he said, why paine
does this.
The only reason why I could imagine to do this IMHO is that they did
implement a different behavior when talking to mailservers which are 8
bit aware or not.
The way pine is encoding mails it will never have a different
content-type in the header except from:
| Content-Type: text/plain; charset=us-ascii
And this has nothing to do with protecting Emails/News from ads. This
has to do with the old times when there where mailservers not accepting
8bit mails.
>> Pine is sending "multipart/mixed" articles, and they think that's
>> *good*.
>
> Apparently slrn only implements MIME standards in a half-assed way, and
> they think that that is good. Furthermore those users want the rest of
> the world to adjust slrn's non-standard implementation.
I agree, that at least the multipart handling of slrn is not so good. I
wrote a patch for slrn, that can ease the pain when reading pine
articels. Those guys here using my patch (included in pl2.1) should be
able to see the difference when adding
| set minimal_multipart 0
to the slrnrc.
But the thing is, usenet is a text only medium, there is no need for
multipart/mixed, except for binary groups. slrn focussed on the
important features of a newsreader, like threading, scoring etc.
Since when pine was able to to threading?
Cheers,
Thomas
--
slrn charset patches: http://www.foory.de/thw/slrn/
Eduardo Chappa
:) On 2007-09-24, Eduardo Chappa <cha...@u.washington.edu> wrote:
:) > On Mon, 24 Sep 2007, Jeffrey Goldberg wrote:
:) >
:) >:) That makes absolute sense for mail. (Al)pine's default before is
:) >:) the correct choice for mail. The difficulty it seems is that there
:) >:) are a lot of people using newsreaders that don't do MIME properly.
:) >:)
:) >:) So I guess what I would want is a
:) >:)
:) >:) "Downgrade-multipart-to-single-part-when-posting-to-news"
:) >:)
:) >:) which seems like a lot to ask.
:) >
:) > But consider that there could be a "free" news server out there that
:) > is appending stuff (e.g. ads) to free posts and appends these
:) > messages without regards to the charset of the message. Then wrapping
:) > makes sense.
:)
:) And why are only posts with non-ascii characters mangled to pseudo
:) multipart postings? The above argument is also valid for pure us-ascii
:) postings.
How? If a post contains only us-ascii, then that message is labeled as
such, and adding ascii to it won't do anything.
Now if you have a text encoded, and add ascii, then things get mangled,
and that's where the problem comes from.
:) I've never seen newsservers adding ads to postings. I've seen that on
:) mailing lists.
I said I don't know if it makes sense to do this for news. I said that
wrapping could be necessary in a situation like this. I do not know of any
news server that does what I told you, but I don't discard that behavior.
To me the behavior makes sense. It might be undesirable, but it's a
reality and improving slrn will make the "problem" go away.
--
Eduardo
http://staff.washington.edu/chappa/pine/
Blinky the Shark
It's common, Thomas. I see it all the time -- three- or four-line
server ad sigs below what the poster has posted.
Eduardo Chappa
:) But the thing is, usenet is a text only medium, there is no need for
:) multipart/mixed, except for binary groups.
Aha!, that's your point. No wonder Mark is predicting the end of usenet. A
text only medium in this age? I hope Mark is starts advocating for a new
USENET++ based on IMAP ;). Then this argument wouldn't even make sense.
You see, I've never converted anyone to Pine, because despite Pine being a
wonderful program does not have a GUI. It's time to move to a new usenet,
one that follows the trends of the time.
:) slrn focussed on the important features of a newsreader, like
:) threading, scoring etc.
:)
:) Since when pine was able to to threading?
I understand, but USENET is not about threading or scoring. Threading and
scoring exists because users want to be able to read news more
conveniently, and programs like Pine support such features. Similarly,
MIME exists so that users can exchange information. Some people are being
hurt for the lack of a feature of a program and blame the people that
point that out to them for their grief. I am sure that slrn must be a very
good program. It just needs an update to deal with some already old
technology.
--
Eduardo
http://staff.washington.edu/chappa/pine/
Thomas Wiegner
> On Tue, 25 Sep 2007, Thomas Wiegner wrote:
>:) And why are only posts with non-ascii characters mangled to pseudo
>:) multipart postings? The above argument is also valid for pure us-ascii
>:) postings.
>
> How? If a post contains only us-ascii, then that message is labeled as
> such, and adding ascii to it won't do anything.
And what's know the difference if the post contains iso-8859-1 or
utf-8, then that message would be labeled as such, and adding ascii to
it won't do anything.
You see my point?
> Now if you have a text encoded, and add ascii, then things get mangled,
> and that's where the problem comes from.
No it does not, adding ascii won't do anything, because the plain ascii
characters are encoded in every encoding the same.
>:) I've never seen newsservers adding ads to postings. I've seen that on
>:) mailing lists.
>
> I said I don't know if it makes sense to do this for news. I said that
> wrapping could be necessary in a situation like this. I do not know of any
> news server that does what I told you, but I don't discard that behavior.
> To me the behavior makes sense.
Wrapping might make sense to protect messages, but it should not be the
default behaviour.
It was already the default behavior, when I used it 15 years back at the
university and at this time adding ads to postings or emails was
definitely *not* the problem.
This wrapping was done because of not 8 bit aware mailservers and it
seems to me the programmers did not want to implement the smtp dialog in
a way to figure out whether the mailserver was 8 bit capable or not.
> It might be undesirable, but it's a reality and improving slrn will
> make the "problem" go away.
Yes, in this point you are right, that's the reason, why I changed this
in slrn. With my patches slrn displays multipart mangled postings how
they should look.
Thomas
--
multipart support for slrn: http://www.foory.de/thw/slrn/
Blinky the Shark
> On Tue, 25 Sep 2007, Thomas Wiegner wrote:
>
>:) But the thing is, usenet is a text only medium, there is no need for
>:) multipart/mixed, except for binary groups.
>
> Aha!, that's your point. No wonder Mark is predicting the end of
> usenet. A text only medium in this age? I hope Mark is starts
> advocating for a new USENET++ based on IMAP ;). Then this argument
> wouldn't even make sense.
>
> You see, I've never converted anyone to Pine, because despite Pine
> being a wonderful program does not have a GUI. It's time to move to a
> new usenet, one that follows the trends of the time.
So the trend being to Google Groups and other klunky web gateways for
the incompetent, you're sending them there where they may not even know
they're *using* Usenet? No, I'm not suggesting that that's a good idea;
please see my sig for an indication of my stance on that.
Rob van der Putten
On Tue, 25 Sep 2007, Peter J Ross wrote:
> Let me put it this way:
>
> "Content-Type: multipart/mixed" has no place in Usenet outside
> alt.binaries, with the sole exception of PGP/MIME signatures, and even
> they're generally disliked and are likely to result in the poster
> being widely killfiled.
>
> Please encourage the pine developers to fix the bug in their software
> that prevents pine users from sending anything other than US-ASCII
> without perpetrating an approximate equivalent to text/html.
So, if I put something like '£ € ¥ ⅟₁₆' here, this post becomes
multipart?
Or did I miss something?
Regards,
Rob
--
+----------------------------------------------------------------------+
| Rob van der Putten, r...@sput.nl |
| http://www.sput.nl/spam/spam-policy.html |
+----------------------------------------------------------------------+
Rob van der Putten
Rob van der Putten wrote:
> So, if I put something like '£ € ¥ ⅟₁₆' here, this post becomes multipart?
> Or did I miss something?
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Message-ID: <alpine.DEB.0.9999....@sput.int.sput.nl>
Regards,
Rob
--
Terry Gilliam's Brazil is here and now
Jeffrey Goldberg
> Jeffrey Goldberg <nob...@goldmark.org> wrote:
>> The rational for (al)pine using multipart/mixed was explained in the
>> material Eduardo posted.
> The reason is simply not true. It makes no sense to do what pine does,
> to create "multipart" posts for articles with 8 bit characters and not
> to do so for us-ascii. At least with the argument he said, why paine
> does this.
I will leave this for others to discuss. My opinions on this are far from
solid. I assume that the pine people put that in to solve some real
problem. But what you say also makes sense.
> I agree, that at least the multipart handling of slrn is not so good. I
> wrote a patch for slrn, that can ease the pain when reading pine
> articels. Those guys here using my patch (included in pl2.1) should be
> able to see the difference when adding
>
> | set minimal_multipart 0
That is good news. I know nothing about the slrn development process, but
I hope that your patch becomes "official" and it seems that the setting
it introduces ought to be the default.
> But the thing is, usenet is a text only medium, there is no need for
> multipart/mixed, except for binary groups.
As you can imagine, Pine users also agree that usenet should be text only.
But the way for slrn to support that while still complying with MIME
standards is not to simply barf at multipart/mixed, but to reject parts
which are something other than text/plain (or arguably text/enriched).
The non-patched behavior of slrn is to fail to process properly standards
compliant text/plain parts. There are better ways to be text only.
> slrn focussed on the important features of a newsreader, like threading,
> scoring etc.
I don't want to get into slrn vs pine as a newsreader. If I didn't want
access to my IMAP folders when reading news, I wouldn't be using (al)pine
for news.
> Since when pine was able to to threading?
Someone can dig through revision history, but I think that it's been at
least eight years.
Ted S.
> On Tue, 25 Sep 2007, Thomas Wiegner wrote:
>
> :) But the thing is, usenet is a text only medium, there is no need for
> :) multipart/mixed, except for binary groups.
Please use a standard quote marker.
--
Ted S.
fedya at bestweb dot net
Eduardo Chappa
:) > You see, I've never converted anyone to Pine, because despite Pine
:) > being a wonderful program does not have a GUI. It's time to move to a
:) > new usenet, one that follows the trends of the time.
:)
:) So the trend being to Google Groups and other klunky web gateways for
:) the incompetent, you're sending them there where they may not even know
:) they're *using* Usenet? No, I'm not suggesting that that's a good
:) idea; please see my sig for an indication of my stance on that.
I am only suggesting that technology is there for a purpose. To improve
your life. Some people think that those gateways are good. One does not
need to know the final technology that supports it, like most people do
not know that webmail is an interfacte to IMAP. In fact, I've seen many
people that think that webmail is better than pop3, but would not try
IMAP. lol.
Interfaces are not the issue. The point is where the technology that
sustains that interface is going. I've always defended text messages, over
any other content, but I am not blind to see that sometimes plain test
just doesn't cut it, Now if you don't believe in technology, I have a 1897
cart that I am selling. It does not have gps, but is 2WD. Interested?
--
Eduardo
http://staff.washington.edu/chappa/pine/
Thomas Wiegner
>> The reason is simply not true. It makes no sense to do what pine does,
>> to create "multipart" posts for articles with 8 bit characters and not
>> to do so for us-ascii. At least with the argument he said, why paine
>> does this.
>
> I will leave this for others to discuss. My opinions on this are far from
> solid. I assume that the pine people put that in to solve some real
> problem. But what you say also makes sense.
Thank you.
> As you can imagine, Pine users also agree that usenet should be text only.
> But the way for slrn to support that while still complying with MIME
> standards is not to simply barf at multipart/mixed, but to reject parts
> which are something other than text/plain (or arguably text/enriched).
Thats exactly what my minimal_mutlipart patch does.
> The non-patched behavior of slrn is to fail to process properly standards
> compliant text/plain parts. There are better ways to be text only.
>
>> Since when pine was able to to threading?
>
> Someone can dig through revision history, but I think that it's been at
> least eight years.
I just dug a little bit, it's been introduced 5 years ago with version
4.50 but IMHO at this time the threading did not work very well. This
came later (I'm not sure if this was with version 4.60).
Cheers,
Thomas
--
slrn multipart and other patches: http://www.foory.de/thw/slrn/
Thomas Wiegner
>
> On Tue, 25 Sep 2007, Peter J Ross wrote:
>
>> Please encourage the pine developers to fix the bug in their software
>> that prevents pine users from sending anything other than US-ASCII
>> without perpetrating an approximate equivalent to text/html.
>
> So, if I put something like '£ € ¥ ⅟₁₆' here, this post becomes
> multipart?
With the default behavior of pine, yes. If you configure it properly
(like you obviously did) no.
Cheers,
Thomas
Vitus Jensen
On Tue, 25 Sep 2007, Rob van der Putten wrote:
> Rob van der Putten wrote:
>
>> So, if I put something like '£ € ¥ ⅟₁₆' here, this post becomes multipart?
>> Or did I miss something?
>
> Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8BIT
> Message-ID: <alpine.DEB.0.9999....@sput.int.sput.nl>
As already explained in another post for safety it *should* become
multipart to guard against newsserver, news/mail-gateways, mailinglists
via news which add a signature which doesn't use the same character set as
you do.
You have enabled a feature which removes the "multipart" if there is only
one part and rely therefore on that nobody ever will add something to your
post. I've enabled it, too but seriously consider disabling that feature
as I think the rationale about multipart is correct.
Anybody else: please killfile me if you don't want to read those
mimemultiparts.
By[e]e,
Vitus
--
Vitus Jensen, Hannover, Germany, Earth, Universe (current)
Thomas Wiegner
> As already explained in another post for safety it *should* become
> multipart to guard against newsserver, news/mail-gateways, mailinglists
> via news which add a signature which doesn't use the same character set as
> you do.
And again, what exactly was the reason why a plain us-ascii posting
should not be protected in the same way?
Believe me or not, but the original intention was not to protect mails
from evil gateways or mailinglists, it had to do with mailservers not
being 8 bit aware.
Cheers,
Thomas
Rob van der Putten
Vitus Jensen wrote:
> As already explained in another post for safety it *should* become
> multipart to guard against newsserver, news/mail-gateways, mailinglists
> via news which add a signature which doesn't use the same character set
> as you do.
An alternative is to convert the charset to UTF-8 and then add a UTF-8 text.
This also what happens when I reply to a message quoting the original
message. The original message gets converted to UTF-8 and the text that
I type is also UTF-8.
> You have enabled a feature which removes the "multipart" if there is
> only one part and rely therefore on that nobody ever will add something
> to your post. I've enabled it, too but seriously consider disabling
> that feature as I think the rationale about multipart is correct.
Software should be charset aware. It appears to me that this mime trick
is designed to work around somebody else's bugs.
Then again, maybe I'm a bit BOFH.
> Anybody else: please killfile me if you don't want to read those
> mimemultiparts.
I won't.
Rob van der Putten
Thomas Wiegner wrote:
> And again, what exactly was the reason why a plain us-ascii posting
> should not be protected in the same way?
>
> Believe me or not, but the original intention was not to protect mails
> from evil gateways or mailinglists, it had to do with mailservers not
> being 8 bit aware.
That's negotiated isn't it?
So if a system isn't 8 bit aware, one could convert the message before
sending it to the 7 bit system.
Rob van der Putten
Thomas Wiegner wrote:
> With the default behavior of pine, yes. If you configure it properly
> (like you obviously did) no.
And I thought it was a HTML option.
Thomas Wiegner
>> Believe me or not, but the original intention was not to protect mails
>> from evil gateways or mailinglists, it had to do with mailservers not
>> being 8 bit aware.
>
> That's negotiated isn't it?
> So if a system isn't 8 bit aware, one could convert the message before
> sending it to the 7 bit system.
Yes, exactly. If you configure you mailer to send 8 bit, it should
interpret the smtp dialog and convert the transport encoding of the mail
to QP or base64.
Pine just sends everything multipart/mixed where there might be a
decision whether to send 8bit or QP, because multipart/mixed is
7 bit clean by definition.
Cheers,
Thomas
Rob van der Putten
Thomas Wiegner wrote:
> Yes, exactly. If you configure you mailer to send 8 bit, it should
> interpret the smtp dialog and convert the transport encoding of the mail
> to QP or base64.
It seems plausible that something similar happens in NNTP.
More recent implementations use UTF-8 as the default charset. So
capabilities and version should tell you if the remote system is 8 bit
clean.
> Pine just sends everything multipart/mixed where there might be a
> decision whether to send 8bit or QP, because multipart/mixed is
> 7 bit clean by definition.
Blinky the Shark
> On Tue, 25 Sep 2007, Blinky the Shark wrote:
>
>:) > You see, I've never converted anyone to Pine, because despite Pine
>:) > being a wonderful program does not have a GUI. It's time to move to a
>:) > new usenet, one that follows the trends of the time.
>:)
>:) So the trend being to Google Groups and other klunky web gateways for
>:) the incompetent, you're sending them there where they may not even know
>:) they're *using* Usenet? No, I'm not suggesting that that's a good
>:) idea; please see my sig for an indication of my stance on that.
>
> I am only suggesting that technology is there for a purpose. To improve
> your life. Some people think that those gateways are good. One does not
> need to know the final technology that supports it, like most people do
> not know that webmail is an interfacte to IMAP. In fact, I've seen many
> people that think that webmail is better than pop3, but would not try
> IMAP. lol.
Heh.
> Interfaces are not the issue. The point is where the technology that
> sustains that interface is going. I've always defended text messages, over
> any other content, but I am not blind to see that sometimes plain test
> just doesn't cut it, Now if you don't believe in technology, I have a 1897
> cart that I am selling. It does not have gps, but is 2WD. Interested?
Sure. I like collectables.
Blinky the Shark
> Thats exactly what my minimal_mutlipart patch does.
Is that already in pl2.1 and only requires that .slrnrc command you or
someone mentioned, or is it a separate patch?
Adam Funk
> Once again, here's an "é". I want to know what happens.
Using the luit + slrn thing, I see e+acute.
Eduardo Chappa
:) On 2007-09-25, Eduardo Chappa <cha...@u.washington.edu> wrote:
:)
:) > On Tue, 25 Sep 2007, Thomas Wiegner wrote:
:)
:) >:) And why are only posts with non-ascii characters mangled to pseudo
:) >:) multipart postings? The above argument is also valid for pure
:) >:) us-ascii postings.
:) >
:) > How? If a post contains only us-ascii, then that message is labeled
:) > as such, and adding ascii to it won't do anything.
:)
:) And what's know the difference if the post contains iso-8859-1 or
:) utf-8, then that message would be labeled as such, and adding ascii to
:) it won't do anything.
:)
:) You see my point?
Yes, but what if the list adds a different charset for which the original
charset is not a superset, or what if the original message is quoted
printable, or encoded in a way in which adding us-ascii breaks the
encoding? That's the point of the feature. See more details below.
:) > Now if you have a text encoded, and add ascii, then things get
:) > mangled, and that's where the problem comes from.
:)
:) No it does not, adding ascii won't do anything, because the plain ascii
:) characters are encoded in every encoding the same.
Ok, you do not understand. Let me go back. Imagine that your original post
was in quoted printable, and the server adds and ad, and in order to
separate that ad from the message it adds a full line of "=" characters.
That is just plain ascii, but not quoted printable. In fact "==" is not
quoted printable. In this case you broke the encoding. The boundary is
there to protect the content, so that when the ad is added the receiving
client will still be able to decode properly the original and intended
message.
Do you get why the boundary was necessary in this case?
:) >:) I've never seen newsservers adding ads to postings. I've seen that
:) >:) on mailing lists.
:) >
:) > I said I don't know if it makes sense to do this for news. I said
:) > that wrapping could be necessary in a situation like this. I do not
:) > know of any news server that does what I told you, but I don't
:) > discard that behavior. To me the behavior makes sense.
:)
:) Wrapping might make sense to protect messages, but it should not be the
:) default behaviour.
That's a judgment call, and there are other people that think differently
than you. If that message had contained relevant information that you had
no been able to read because it got corrupted, who would you have been
upset with? Think about it. The safer practice protects you, does not harm
you.
:) It was already the default behavior, when I used it 15 years back at
:) the university and at this time adding ads to postings or emails was
:) definitely *not* the problem.
:)
:) This wrapping was done because of not 8 bit aware mailservers and it
:) seems to me the programmers did not want to implement the smtp dialog
:) in a way to figure out whether the mailserver was 8 bit capable or not.
No, that was not the issue. It's not eight bit. It is wrong encoding.
:) > It might be undesirable, but it's a reality and improving slrn will
:) > make the "problem" go away.
:)
:) Yes, in this point you are right, that's the reason, why I changed this
:) in slrn. With my patches slrn displays multipart mangled postings how
:) they should look.
Great. I hope that now you understand the rationale behind this feature.
--
Eduardo
http://staff.washington.edu/chappa/pine/
Ted S.
> I don't want to get into slrn vs pine as a newsreader.
That's because they're both inferior to Xnews and Dialog. :-p
Vitus Jensen
Did someone try to pipe that (or probably this) mail to cat/less using
pine? The dump stops at the é!
I wanted to check some postings whether they are multimimepart or not and
got hit by this feature. Bug in alpine 0.999 or Kubuntu 6.04?
By[t]e,
Blinky the Shark
> On Tue, 25 Sep 2007 08:26:07 -0500, Jeffrey Goldberg wrote:
>
>> I don't want to get into slrn vs pine as a newsreader.
>
> That's because they're both inferior to Xnews and Dialog. :-p
Bzzzzt! Thanks for playing. You've been a great guest and we'll
have some nice parting gifts for you on your way out of the studio. ;)
Mark Crispin
>> The good news in all of this is that USENET is dying rapidly and in a few
>> years nobody will care.
> How is that "good news"?
Because in a few years, nobody will care.
It is jaw-dropping to me that, something like 17 years after MIME was
defined, that there are still a few Luddites who get bent out of shape
over MIME appearing in USENET. Such people are badly in need of a life.
Between the Luddites and Hipcrime, I won't miss USENET.
Now, to answer a few questions:
Q: Why isn't this done with ASCII content?
A: There is no need.
Contrary to what some messages here have implied, the need is not to
protect against charset mixing, although that is a happy consequence.
The specific need is to protect QUOTED-PRINTABLE and BASE64 content; and
that in turn is specific to 8-bit content. Thus, ASCII and ISO 2022
content does NOT need protections.
The problem is the potential addition of content to the text that violates
the rules of QUOTED-PRINTABLE or BASE64. It is unsafe for top-level
content to have a transfer encoding of other than 7BIT or 8BIT;
specifically, top-level QUOTED-PRINTABLE, BASE64, and BINARY content is
unsafe as appended data will alter it.
Q: When is this not needed?
A: When the path is 8-bit clean and 8BIT encoding can be used. 8-bit
content does not need to be wrapped.
Q: Why is this done to news? News is 8-bit.
A: Because you didn't configure things for 8-bit mail. We want to avoid
having to generate the message twice (one 7-bit form and one 8-bit form).
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Vitus Jensen
> On Tue, 25 Sep 2007, Vitus Jensen wrote:
>
>> As already explained in another post for safety it *should* become
>> multipart to guard against newsserver, news/mail-gateways, mailinglists
>> via news which add a signature which doesn't use the same character set as
>> you do.
>
> And again, what exactly was the reason why a plain us-ascii posting
> should not be protected in the same way?
Hmm, if you place your words this way... no reason. Adding a signature in
a different charset would in either case only destroy the signature not
the posting itself.
There is this issue with different encodings as Eduard pointed out. This
would destroy the signature because it places invalid characters in the
posting. But this is the same as adding a foreign signature to us-ascii:
everything above 127 is invalid there, too.
So, to be sure some other doesn't make an error always use multipart and
if you don't care (because it's HIS fault) never?
> Believe me or not, but the original intention was not to protect mails
> from evil gateways or mailinglists, it had to do with mailservers not
> being 8 bit aware.
If you say so. But can't QP declared in the header for the complete
message?
By[t]e,
Vitus Jensen
> On Tue, 25 Sep 2007, Adam Funk wrote:
>> On 2007-09-24, Peter J Ross wrote:
>>
>>> Once again, here's an "é". I want to know what happens.
>>
>> Using the luit + slrn thing, I see e+acute.
>
> Did someone try to pipe that (or probably this) mail to cat/less using
> pine? The dump stops at the é!
To be precise: dumping the RAW text of the mail doesn't work. Dumping it
as shown works,
Dan C
>>> The good news in all of this is that USENET is dying rapidly and in a few
>>> years nobody will care.
>> How is that "good news"?
> Because in a few years, nobody will care.
I don't think that's true. I hope I'm right.
> It is jaw-dropping to me that, something like 17 years after MIME was
> defined, that there are still a few Luddites who get bent out of shape
> over MIME appearing in USENET. Such people are badly in need of a life.
>
> Between the Luddites and Hipcrime, I won't miss USENET.
Well, I will. However, see above. I don't think it's going anywhere.
--
"Ubuntu" - an African word meaning "Slackware is too hard for me".
Rob van der Putten
Vitus Jensen wrote:
> To be precise: dumping the RAW text of the mail doesn't work. Dumping
> it as shown works,
What do you mean bij dump?
Save works. So does Export.
Regards,
Rob
--
Lifestyle sux
Vitus Jensen
> Vitus Jensen wrote:
>
>> To be precise: dumping the RAW text of the mail doesn't work. Dumping it
>> as shown works,
>
> What do you mean bij dump?
> Save works. So does Export.
As I wrote in the part you didn't cite:
"Did someone try to pipe that (or probably this) mail to cat/less using
pine? The dump stops at the é!"
Press "|" to select the pipe function, press "^W" to switch to raw mode
and enter "cat" as the program to pipe through.
Bye,
Vitus
Thomas Wiegner
This has always been clear to me. I never said, it would not protect the
message. My argument was, that this also applies to plain ascii. OK, now
with your QP example I see the difference.
Adding text to a QP encoded mail/post may break the message in a very
bad way.
But adding text to a plain ascii message may also break the message.
So with your argument you should also put plain ascii messages into a
multipart protection.
Anyway, while pine's behaviour might be a good solution for Email it is
IMHO not a good behaviour for news.
Cheers,
Thomas
Rob van der Putten
Vitus Jensen wrote:
> As I wrote in the part you didn't cite:
>
> "Did someone try to pipe that (or probably this) mail to cat/less using
> pine? The dump stops at the é!"
>
> Press "|" to select the pipe function, press "^W" to switch to raw mode
> and enter "cat" as the program to pipe through.
Sorry. I never used pipe before.
So what does 'raw' do. It seams to works without raw.
Jeffrey Goldberg
In <alpine.DEB.0.999.0709260735150.5696@localhost>, Vitus Jensen wrote:
> "Did someone try to pipe that (or probably this) mail to cat/less using pine?
> The dump stops at the é!"
>
> Press "|" to select the pipe function, press "^W" to switch to raw mode and
> enter "cat" as the program to pipe through.
I see the same problem with .9999 on OS X (PPC) 10.4 in Terminal.
-j
--
Jeffrey Goldberg http://www.goldmark.org/jeff/
I rarely read top-posted, over-quoting or HTML postings.
http://improve-usenet.org/
Eduardo Chappa
:) But adding text to a plain ascii message may also break the message.
True. I agree. I guess we need to create multipart messages for every
thing.
:) So with your argument you should also put plain ascii messages into a
:) multipart protection.
I hope we'll not get there eventually, but I can see easily how we may get
there.
:) Anyway, while pine's behaviour might be a good solution for Email it is
:) IMHO not a good behaviour for news.
I can see why you think that way.
--
Eduardo
http://staff.washington.edu/chappa/pine/
Jeffrey Goldberg
> Adding text to a QP encoded mail/post may break the message in a very
> bad way.
> Anyway, while pine's behaviour might be a good solution for Email it is
> IMHO not a good behaviour for news.
Don't most newsreaders also do SMTP submission in case you wish to mail a
reply to a news post? Does slrn have this ability? If so, shouldn't
those newsreaders use QP when sending such a message? And shouldn't they
encapsulate the QP for the same reason (al)pine does?
Several people have suggested that the problem is that Pine tries to do
both mail and news. But most pure newsreaders do SMTP submission as well
as doing their news thing. So if you think that pine's approach is
correct for mail, then shouldn't newsreaders when sending mail do the
same?
You say that pine's solution to the QP problem is a good solution for
Email but not good behavior for news. But pine's behavior should be good
for mail and harmless for news if newsreaders would implement message
standards properly.
Jeffrey Goldberg
In <46fa38e8$0$242$e4fe...@news.xs4all.nl>, Rob van der Putten wrote:
> So what does 'raw' do. It seams to works without raw.
raw doesn't "render" the message. That is if the message (or parts) are
in quoted-printable than you will see all that encoding. Also you will
see the MIME boundaries and headers for parts (which is what we were after
as a quick way to see whether pine encapsulated the message).
Peter J Ross
<no....@box.invalid> wrote:
> Thomas Wiegner wrote:
>
>> I've never seen newsservers adding ads to postings. I've seen that on
>> mailing lists.
>
> It's common, Thomas. I see it all the time -- three- or four-line
> server ad sigs below what the poster has posted.
For example, see any post sent through TeraNews's "free" server.
What I don't recall ever seeing is such an addition that used
non-US-ASCII characters.
If the PINE people can provide examples of the problem they're trying
to avoid, I'll be more sympathetic to what they do.
--
PJR :-)
Jeffrey Goldberg
> On Tue, 25 Sep 2007, Jeffrey Goldberg <nob...@goldmark.org> wrote:
>>> Since when pine was able to to threading?
>>
>> Someone can dig through revision history, but I think that it's been at
>> least eight years.
>
> I just dug a little bit, it's been introduced 5 years ago with version
> 4.50 but IMHO at this time the threading did not work very well. This
> came later (I'm not sure if this was with version 4.60).
Thanks for checking up on that. I guess I'm not a good judge of the
passage of time. I thought that I used pine for news before 2000, but I
can't imagine using something without threading, so I guess I used slrn or
tin. I'll have to dig through old postings.
I do recall that when threading was first introduced it was excruciatingly
slow.
Jeffrey Goldberg
In <Xns99B69D9...@213.186.42.107>, Patrick Lamaizière wrote:
> If an article does not need more than one part, this is a non-sense to send
> it as a MULTIPART article.
The rationale for this was explained MRC's message. Here is a summary.
Pine also sends messages by SMTP. Some SMTP servers don't like 8 bit.
So pine uses Quoted-printable to encode those message. Some system or
servers add advertising or signature text to message. Bad things happen
if you add plain ASCII into something that is quoted-printable. So pine
encapsulates the QP message into a "part".
I would also like to add that although most newsreaders are seen as
newsreaders only, they do have the capability of submitting SMTP. As such
they are subject to the same concerns that pine addresses, and so the
safest thing for them to do (at least while submitting SMTP) is to do what
pine does.
Because the MIME standards have been around for so long and we are still
only talking about text/plain parts, it is perplexing in my opinion for
people to get so upset at pine's behavior. But of course, I am certainly
already in their killfile, so I can only talk to those who are willing to
accept the possibility that slrn isn't necessarily correct in its
treatment of multipart messages.
Jeffrey Goldberg
> Software should be charset aware. It appears to me that this mime trick is
> designed to work around somebody else's bugs.
> Then again, maybe I'm a bit BOFH.
That is true. But avoiding the trick is also something to work around a
different somebody else's bugs.
> --
> Terry Gilliam's Brazil is here and now
"Don't suspect a friend. Report him."
Rob van der Putten
Jeffrey Goldberg wrote:
> raw doesn't "render" the message. That is if the message (or parts) are
> in quoted-printable than you will see all that encoding. Also you will
> see the MIME boundaries and headers for parts (which is what we were
> after as a quick way to see whether pine encapsulated the message).
That's what 'h' / HdrMode / full-header does. Which just works.
Raw appears (I'm not very good at this) to strip the high bit. Which is
the opposite of what one aspects.
In ISO-8859-1 and ISO-8859-15 'é' is 0xE9 (0xC3 0xA9 in UTF-8).
Clearing the high bit in bytes >= 0xA0 does not generate a control char.
Raw also seams to do something with the terminal settings. I have no
idea why.
If you want a raw dump, just use 'h' (enable-full-header-cmd first).
Peter J Ross
Goldberg <nob...@goldmark.org> wrote:
> In <slrnffgke...@pjr.gotdns.org>, Peter J Ross wrote:
>
>> Am I the only one who thinks that (a) pine is broken and (b) some
>> comp.mail.pine posters are in danger of disappearing up their own
>> arses?
>
> The rational for (al)pine using multipart/mixed was explained in the
> material Eduardo posted. Do you have an argument with that rationale?
Yes. The solution to a potential problem, which is more likely to
exist in mail than in news, causes practical problems for peeople
whose newsreaders expect plain text to be sent to text-only
newsgroups.
Pine's solution seems to me to be worse than the problems it's
intended to solve.
> If so, don't just bitch about it among yourselves, tell it to the pine
> people.
I didn't want an inter-newsgroup flame war, but I'd have done better
not to post my exasperated thoughts at all.
Let me say something nice about Pine: Pine, like the tin newsreader,
provides an interactive congiguration menu for basic options, and
creates important files without their having to be "touch"ed first. I
wish slrn had that functionality too.
In that way at least, your newsreader is better than mine.
Will that do in lieu of an apology?
>> Pine is sending "multipart/mixed" articles, and they think that's
>> *good*.
>
> Apparently slrn only implements MIME standards in a half-assed way, and
> they think that that is good. Furthermore those users want the rest of
> the world to adjust slrn's non-standard implementation.
slrn implements MIME insofar as it's useful for text newsgroups. I
have no problem reading single-part MIME posts in slrn, as long as the
character set is supported by libiconv and the individual characters
are present in my chosen font.
It's true that slrn's MIME support still needs some work, but I don't
think slrn (or any other newsreader used for text newsgroups) needs to
support "multipart/mixed" posts. If I were in charge of slrn, I'd even
go so far as to remove its very limited support for binaries. There
are other tools for such tasks.
>> (I've snecked the crosspost, because I'm talking about them, not to
>> them.)
>
> Ooops. I put it back in because now I'm talking about slrn users who like
> to lecture others about standards and correctly say that people shouldn't
> "break" their own software to adjust to others' non-standard
> implementations. We like talking *about* such things on comp.mail.pine.
Well, my regrettable secret flame doesn't seem to have stopped the
discussion continuing quite politely..
--
PJR :-)
Blinky the Shark
> In news.software.readers on 25 Sep 2007 07:57:01 GMT, Blinky the Shark
><no....@box.invalid> wrote:
>
>> Thomas Wiegner wrote:
>>
>>> I've never seen newsservers adding ads to postings. I've seen that on
>>> mailing lists.
>>
>> It's common, Thomas. I see it all the time -- three- or four-line
>> server ad sigs below what the poster has posted.
>
> For example, see any post sent through TeraNews's "free" server.
>
> What I don't recall ever seeing is such an addition that used
> non-US-ASCII characters.
I'm not sure if I have, either. But since TW said he'd never seen *any*
ads, I thought I'd provide a couple examples even though they looked
like ASCII.
Peter J Ross
Chappa <cha...@u.washington.edu> wrote:
> On Tue, 25 Sep 2007, Thomas Wiegner wrote:
>
>:) But the thing is, usenet is a text only medium, there is no need for
>:) multipart/mixed, except for binary groups.
>
> Aha!, that's your point. No wonder Mark is predicting the end of usenet. A
> text only medium in this age?
Yes, it's what makes Usenet not only distinctive but also truly
international. You don't need a Northern-American or Western-European
income to read Usenet affordably, and that's because it's text-only.
If you have the courage of your convictions, you should be posting
text/html - or perhaps, "in this day and age", application/xhtml+xml.
Only we Luddites could possibly object.
>:) Since when pine was able to to threading?
>
> I understand, but USENET is not about threading or scoring. Threading and
> scoring exists because users want to be able to read news more
> conveniently, and programs like Pine support such features. Similarly,
> MIME exists so that users can exchange information. Some people are being
> hurt for the lack of a feature of a program and blame the people that
> point that out to them for their grief. I am sure that slrn must be a very
> good program. It just needs an update to deal with some already old
> technology.
slrn is good, and if you agree to try it I'll agree to try pine. In
both cases, newbies who aren't clueless could help the developers to
improve the software. Deal?
--
PJR :-)
Rob van der Putten
Jeffrey Goldberg wrote:
> "Don't suspect a friend. Report him."
Suspicion breeds confidence.
Peter J Ross
<fe...@bestweb.spam> wrote:
> On Tue, 25 Sep 2007 01:04:28 -0700, Eduardo Chappa wrote:
>
>> On Tue, 25 Sep 2007, Thomas Wiegner wrote:
>>
>> :) But the thing is, usenet is a text only medium, there is no need for
>> :) multipart/mixed, except for binary groups.
>
> Please use a standard quote marker.
I.e. ">" or preferably "> ".
":" has a long and valuable history, but is more or less obsolete.
":)" has no history at all, and is on the same level of usefulness as
witty attribution lines and long ascii-art .sigs. If one does any of
these things, one has to work harder to be taken seriously - which is
why I stopped doing them..
--
PJR :-)
Peter J Ross
der Putten <r...@sput.nl> wrote:
> Hi there
>
>
> On Tue, 25 Sep 2007, Peter J Ross wrote:
>
>> Let me put it this way:
>>
>> "Content-Type: multipart/mixed" has no place in Usenet outside
>> alt.binaries, with the sole exception of PGP/MIME signatures, and even
>> they're generally disliked and are likely to result in the poster
>> being widely killfiled.
>>
>> Please encourage the pine developers to fix the bug in their software
>> that prevents pine users from sending anything other than US-ASCII
>> without perpetrating an approximate equivalent to text/html.
I still haven't seen a reason to change that opinion.
> So, if I put something like '£ € ¥ ⅟₁₆' here, this post becomes
> multipart?
No, it doesn't. It's an ordinary single-part post with UTF-8 as its
character set.
> Or did I miss something?
Assuming that you're using pine or alpine, it seems that not all
versions and/or configurations cause problems.
--
PJR :-)
Peter J Ross
Jensen <vi...@alter-schwede.de> wrote:
> Hi Rob!
>
> On Tue, 25 Sep 2007, Rob van der Putten wrote:
>
>> Rob van der Putten wrote:
>>
>>> So, if I put something like '£ € ¥ ⅟₁₆' here, this post becomes multipart?
>>> Or did I miss something?
>>
>> Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
>> Content-Transfer-Encoding: 8BIT
>> Message-ID: <alpine.DEB.0.9999....@sput.int.sput.nl>
>
> As already explained in another post for safety it *should* become
> multipart to guard against newsserver, news/mail-gateways, mailinglists
> via news which add a signature which doesn't use the same character set as
> you do.
Few news servers add such a signature. The ones that do are generally
despised for creating "double sigs". None that I've seen add a
.signature that isn't US-ASCII.
> You have enabled a feature which removes the "multipart" if there is only
> one part and rely therefore on that nobody ever will add something to your
> post. I've enabled it, too but seriously consider disabling that feature
> as I think the rationale about multipart is correct.
>
> Anybody else: please killfile me if you don't want to read those
> mimemultiparts.
I have no reason to killfile you, but one of the first things I did
when I ran a news server was to filter out all "multipart/mixed"
posts, in order to spare my users the nuisance of binaries in text
groups.
I suspect that much bigger news admins do something similar.
Quite apart from standards issues, this behaviour of pine may be
harming the propagation of harmless posts.
--
PJR :-)
Peter J Ross
<a24...@ducksburg.com> wrote:
> On 2007-09-24, Peter J Ross wrote:
>
>> Once again, here's an "é". I want to know what happens.
>
> Using the luit + slrn thing, I see e+acute.
Good, but TW's patches have obsoleted my clunky workaround.
--
PJR :-)
Peter J Ross
Goldberg <nob...@goldmark.org> wrote:
> [n.s.readers removed from follow-up as this is just an (al)pine issue]
>
> In <46fa38e8$0$242$e4fe...@news.xs4all.nl>, Rob van der Putten wrote:
>
>> So what does 'raw' do. It seams to works without raw.
>
> raw doesn't "render" the message. That is if the message (or parts) are
> in quoted-printable than you will see all that encoding. Also you will
> see the MIME boundaries and headers for parts (which is what we were after
> as a quick way to see whether pine encapsulated the message).
For slrn users who want to play with raw text too, I wrote this
primitive macro a while ago.
#v+
% Save this as show_raw.sl in your macro directory.
% Add "interpret show_raw.sl" to .slrnrc.
% Change the last line to a different keybinding if you prefer.
%
% This macro may help to troubleshoot problems with QP or Base64 in
% other people's headers and bodies.
%
% Possible bug: you may be offered a filename as default in other slrn
% prompts. But this may be a bug in another macro I use; it doesn't
% bother me enough to test it.
define show_raw ()
{
variable state = get_header_flags ();
set_input_string ("/tmp/slrn_raw");
call ("save");
% If necessary, edit next line to use a different pager.
system ("less /tmp/slrn_raw && rm /tmp/slrn_raw");
set_header_flags (state);
set_input_string ("");
}
definekey ("show_raw", "e", "article");
#v-
--
PJR :-)
Blinky the Shark
Awright, you guys -- there you go. Two-man group hug. Now start
compiling! :)
Blinky the Shark
>
> Jeffrey Goldberg wrote:
>
>> "Don't suspect a friend. Report him."
>
> Suspicion breeds confidence.
"Keep your friends close, and your enemies closer." - Sun-Tzu
Jeffrey Goldberg
> Good, but TW's patches have obsoleted my clunky workaround.
I was pleased to learn that there were patches that enabled slrn to cope
with fully standard compliant text/plain parts.
I'm glad you are using that patch. Likewise I am now using the alpine
configuration feature to avoid multipart/mixed.
Cheers,
-j
PS: If I seem to be responding to message grossly out of sequence, I
either have a problem with alpine managing my .newsrc or something strange
is going on with my feed. I'm seeing messages I've "deleted" multiple
times, and I'm seeing other messages strangely late.
Blinky the Shark
> I suspect that much bigger news admins do something similar.
I new one once that was six feet seven.
Rob van der Putten
Blinky the Shark wrote:
> Rob van der Putten wrote:
>> Jeffrey Goldberg wrote:
>>
>>> "Don't suspect a friend. Report him."
>> Suspicion breeds confidence.
>
> "Keep your friends close, and your enemies closer." - Sun-Tzu
Does that include voting your enemies into power?
We where quoting Brazil;
http://en.wikipedia.org/wiki/Brazil_%28film%29
Jeffrey Goldberg
> Jeffrey Goldberg wrote:
>
>> raw doesn't "render" the message. That is if the message (or parts) are in
>> quoted-printable than you will see all that encoding. Also you will see
>> the MIME boundaries and headers for parts (which is what we were after as a
>> quick way to see whether pine encapsulated the message).
>
> That's what 'h' / HdrMode / full-header does. Which just works.
Of course. I use 'h' all the time, and I don't think that I ever used
"raw" mode prior to this discussion.
> Raw appears (I'm not very good at this) to strip the high bit. Which is the
> opposite of what one aspects.
OK, thanks.
Eduardo Chappa
:) >> :) But the thing is, usenet is a text only medium, there is no need
:) >> :) for multipart/mixed, except for binary groups.
:) >
:) > Please use a standard quote marker.
:)
:) I.e. ">" or preferably "> ".
:)
:) ":" has a long and valuable history, but is more or less obsolete. ":)"
:) has no history at all, and is on the same level of usefulness as witty
:) attribution lines and long ascii-art .sigs. If one does any of these
:) things, one has to work harder to be taken seriously - which is why I
:) stopped doing them..
Depends on your definition of history, but I have been using that quote
character for about 10 years already. Not much history, but long enough to
see that it is not about to change either.
On the other hand, if someone does not take me seriously because of my
quote string, that's their choice. I believe in freedom, even when that
freedom plays against me.
Do a search in google groups to see that I've discussed this before also,
so you don't waste your time trying to argue this minor point.
--
Eduardo
http://staff.washington.edu/chappa/pine/
Rob van der Putten
Peter J Ross wrote:
> Few news servers add such a signature. The ones that do are generally
> despised for creating "double sigs". None that I've seen add a
> .signature that isn't US-ASCII.
> I have no reason to killfile you, but one of the first things I did
> when I ran a news server was to filter out all "multipart/mixed"
> posts, in order to spare my users the nuisance of binaries in text
> groups.
My provider blocks binaries on their text servers, but not in this way.
> I suspect that much bigger news admins do something similar.
>
> Quite apart from standards issues, this behaviour of pine may be
> harming the propagation of harmless posts.
Blinky the Shark
> Hi there
>
>
> Blinky the Shark wrote:
>
>> Rob van der Putten wrote:
>>> Jeffrey Goldberg wrote:
>>>
>>>> "Don't suspect a friend. Report him."
>>> Suspicion breeds confidence.
>>
>> "Keep your friends close, and your enemies closer." - Sun-Tzu
>
> Does that include voting your enemies into power? We where quoting
> Brazil; http://en.wikipedia.org/wiki/Brazil_%28film%29
I don't do politics. But I do history. So what I'm wondering now is if
Sun-Tzu would've known of the concept of "voting" for leaders.
Philip
Blinky the Shark say:
> I don't do politics. But I do history. So what I'm wondering now is
> if Sun-Tzu would've known of the concept of "voting" for leaders.
Oh, he welcomed the idea. As he wrote in The Art of War:
"Embrace democracy. Campaigning candidates make easier targets than
encastled emperors."
--
Bye,
Philip
Blinky the Shark
Not having a copy at hand, and not finding the keyphrase
encastled emperors
in a Google Search, I'll have to reserve my thanks until I see that
somewhere.
Rob van der Putten
Blinky the Shark wrote:
> I don't do politics. But I do history.
Brazil used to be a bit of cultural history. Now it's political present.
> So what I'm wondering now is if
> Sun-Tzu would've known of the concept of "voting" for leaders.
And you don't do politics?
Athens had a direct democracy, so probably not.
Peter J Ross
<no....@box.invalid> wrote:
> Peter J Ross wrote:
>
>> I suspect that much bigger news admins do something similar.
>
> I new one once that was six feet seven.
"On the Internet, nobody knows you're 4'3"."
--
PJ "5'10" in real life" R :-)
Peter J Ross
der Putten <r...@sput.nl> wrote:
> Peter J Ross wrote:
>
>> I have no reason to killfile you, but one of the first things I did
>> when I ran a news server was to filter out all "multipart/mixed"
>> posts, in order to spare my users the nuisance of binaries in text
>> groups.
>
> My provider blocks binaries on their text servers, but not in this way.
How do they block them?
>> I suspect that much bigger news admins do something similar.
>>
>> Quite apart from standards issues, this behaviour of pine may be
>> harming the propagation of harmless posts.
Does pine allow you to snip text you're not going to reply to?
--
PJR :-)
Vitus Jensen
> Vitus Jensen wrote:
>
>> As I wrote in the part you didn't cite:
>>
>> "Did someone try to pipe that (or probably this) mail to cat/less using
>> pine? The dump stops at the é!"
>>
>> Press "|" to select the pipe function, press "^W" to switch to raw mode and
>> enter "cat" as the program to pipe through.
>
> Sorry. I never used pipe before.
>
> So what does 'raw' do. It seams to works without raw.
It shows you the complete story, the headers of mime sections, the QP
codes and the full header. Pressing "h" will only show you that header.
The raw piping problem doesn't exist if the message is utf-8, 7 bit or qp.
piping stops when iso-8859-1 is used. As least on my system, I'm running
Kubuntu 6.06 which is utf-8 at terminal level.
By[t]e,
Vitus
--
Vitus Jensen, Hannover, Germany, Earth, Universe (current)
Rob van der Putten
Peter J Ross wrote:
> How do they block them?
They just remove the binary bits.
So the posts are still multipart, but some parts are empty.
> Does pine allow you to snip text you're not going to reply to?
Sure. So does Iceape. But only if I'm not too lazy.
Some people actually object to not quoting the bits one doesn't reply
to. I'm glad you're not one of those.
Rob van der Putten
Vitus Jensen wrote:
> It shows you the complete story, the headers of mime sections, the QP
> codes and the full header. Pressing "h" will only show you that header.
'h' does show all the mime parts. It also shows QP as QP. As if one
would use vi to read mail.
Maybe I have got a weird config.
> The raw piping problem doesn't exist if the message is utf-8, 7 bit or
> qp. piping stops when iso-8859-1 is used. As least on my system, I'm
> running Kubuntu 6.06 which is utf-8 at terminal level.
Everything is UTF-8 over here. Even the console. And plain text files
(except sources, which are ASCII).
I just send myself a few test mails. No problem with raw pipe.
I have seen a lot of bugs on the alpine mailing list which didn't bother
me. They were all related to non UTF-8 setups.
Blinky the Shark
Rob van der Putten wrote:
>
>
> Blinky the Shark wrote:
>
>> I don't do politics. But I do history.
>
> Brazil used to be a bit of cultural history. Now it's political present.
>
>> So what I'm wondering now is if
>> Sun-Tzu would've known of the concept of "voting" for leaders.
>
> And you don't do politics?
Knowing various forms of government is not doing politics.
Similarly, one can know the history of a sport without playing it.
> Athens had a direct democracy, so probably not.
I'm not convinced that Sun-Tzu knew much about Grecian government.
I'd think his knowledge would be of other eastern Asian cultures, and
while I'd guess that they all had tribal/ancestral leadership form, I
can't state that unquivocally.
Jeffrey Goldberg
[big snip]
> Does pine allow you to snip text you're not going to reply to?
No. You have to quote the entire message. Furthermore, pine requires
that you attach an uncompressed TIFF of Pamela Anderson for which you do
not have the right to redistributed. And the TIFF must be given the
content-type of
application/octet-stream
and a filename ending in .BIN. Though in keeping with pine's text roots,
an EBCDIC art alternative is also attached.
There is a configuration option to wrap both alternatives in MS-TNEF.
I'll be happy to answer any other questions you have about pine. I
wouldn't want you to have any misapprehensions about how it works.
Now I do have a question about using slrn on OS X. Do I get to be doubly
smug, or do the two smugnesses cancel each other out?
Cheers,
-j
Mark Crispin
> Quite apart from standards issues, this behaviour of pine may be
> harming the propagation of harmless posts.
Pine (and Alpine) are fully compliant with all published RFCs.
Furthermore, the upcoming Netnews Article Format RFC (in the RFC editor
queue as of July) *requires* MIME conformance in netnews clients. If your
netnews client is not MIME compliant, it is obsolete.
You can get a copy of the final, approved for publication, draft as:
draft-ietf-usefor-usefor-12.txt
I understand that all this may not be compliant with what you feel should
be "standard". If you want your opinions to be part of the standard,
you're a bit late.
Since you object to MIME being used in USENET articles, I suggest that you
contact the IESG at ie...@iesg.org, state your objections, and request that
they withdraw approval for publication as an RFC.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Eduardo Chappa
:) If the PINE people can provide examples of the problem they're trying
:) to avoid, I'll be more sympathetic to what they do.
I will show you one. This one came from a mailing list and I modified it
to obfuscate e-mail addresses, but you can probably track it back to the
list because there is enough information in it. This was one of the
messages that I used to test a patch to ignore the error in QP encoding
(FYI, it used to be that if there was one error in QP encoding, Pine would
not display the message at all, so I wrote a patch to make it display the
message anyway when the error could be ignored). Upon popular request
eventually the Pine team decided to code their own work around.
I once tried to code a work around for errors in BASE64 encoding, which
Pine also refuses to display if it finds errors. My analysis at that time
showed me that Pine was taking the right decision, that is, it should not
show the message in that instance. I do not know if today I would conclude
the same, because I forgot what led me to that conclusion, and I do not
have an example of a wrongly encoded BASE64 message, so I can not tell you
up the top of my head why that was correct, what remained with me was the
conviction that Pine was right.
Anyway, the message is at
http://staff.washington.edu/chappa/pine/wronghex
--
Eduardo
http://staff.washington.edu/chappa/pine/
Vitus Jensen
> Vitus Jensen wrote:
>
>> It shows you the complete story, the headers of mime sections, the QP codes
>> and the full header. Pressing "h" will only show you that header.
>
> 'h' does show all the mime parts. It also shows QP as QP. As if one would use
> vi to read mail.
> Maybe I have got a weird config.
You see "------=_Part_5" headers of the mime parts? I don't 8-o
>> The raw piping problem doesn't exist if the message is utf-8, 7 bit or qp.
>> piping stops when iso-8859-1 is used. As least on my system, I'm running
>> Kubuntu 6.06 which is utf-8 at terminal level.
>
> Everything is UTF-8 over here. Even the console. And plain text files (except
> sources, which are ASCII).
> I just send myself a few test mails. No problem with raw pipe.
>
> I have seen a lot of bugs on the alpine mailing list which didn't bother me.
> They were all related to non UTF-8 setups.
Strange, I'm UTF-8.
OK, it's not that important. And it's not a problem of the output to pipe
as "cat > ~/tmp.dat" works.
Rob van der Putten
Vitus Jensen wrote:
> You see "------=_Part_5" headers of the mime parts? I don't 8-o
Which message?
In alpine.OSX.0.9999...@hagrid.ewd.goldmark.org I can see
Content-Type: MULTIPART/MIXED; BOUNDARY="0-308207451-1190661311=:468"
--0-308207451-1190661311=:468
Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
--0-308207451-1190661311=:468--
It's all done with 'h'.
> Strange, I'm UTF-8.
My feature list;
feature-list=enable-8bit-esmtp-negotiation,
enable-8bit-nntp-posting,
allow-talk,
enable-bounce-cmd,
enable-full-header-cmd,
include-header-in-reply,
signature-at-bottom,
include-attachments-in-reply,
include-text-in-reply,
enable-suspend,
enable-aggregate-command-set,
enable-alternate-editor-cmd,
no-enable-alternate-editor-implicitly,
downgrade-multipart-to-text,
enable-full-header-and-text,
quell-full-header-auto-reset,
pass-c1-control-characters-as-is,
prefer-plain-text,
enable-print-via-y-command,
enable-newmail-in-xterm-icon,
enable-msg-view-urls,
no-enable-msg-view-web-hostnames,
convert-dates-to-localtime,
no-preserve-start-stop-characters
It evolved over the years. So I can't recall immediately what every
feature does.
> OK, it's not that important. And it's not a problem of the output to
> pipe as "cat > ~/tmp.dat" works.
Maybe alpine checks if the output is a tty.
Thomas Wiegner
On 2007-09-26, Eduardo Chappa <cha...@u.washington.edu> wrote:
[ quote string ":)" ]
> On the other hand, if someone does not take me seriously because of my
> quote string, that's their choice. I believe in freedom, even when that
> freedom plays against me.
It might look to a thunderbird user with ascii-smiley -> png-smiley
conversion turned on indeed look not very seriously.
But I think that's the problem of the thunderbird user.
;-)
Thomas
Jeffrey Goldberg
> On Thu, 27 Sep 2007, Rob van der Putten wrote:
>> 'h' does show all the mime parts. It also shows QP as QP. As if one would
>> use vi to read mail.
>> Maybe I have got a weird config.
>
> You see "------=_Part_5" headers of the mime parts? I don't 8-o
Rob obviously has set "Enable Full Header and Text" while you haven't.
From the help:
FEATURE: Enable Full Header and Text
This feature affects how the "H Full Headers" command displays message
text. If set, the raw message text will be displayed. This especially
affects MIME formatted email, where the entire MIME format will be
displayed. This feature similarly affects how messages are included for
the Export, Pipe, Print, Forward, and Reply functions.
When viewing a raw message that has attachments with this feature set,
you will not be able to view attachments without first leaving full
headers mode. This is because MIME parsing is not done on the raw
message.
Jeffrey Goldberg
> It's all done with 'h'.
> My feature list;
> feature-list=[...]
> enable-full-header-cmd,
[...]
> enable-full-header-and-text,
That's the one that makes the difference.