Pine does not decode encoded Subjects that are longer than 75 bytes
Andreas Prilop
This problem has been addressed earlier, for example:
http://groups.google.com/groups?th=b8604ae4b9eb5c5b
Allegedly, RFCs prohibit the decoding of long encoded words.
But I do not understand why. Could someone please explain it to me?
Pine seems to be the *only* mail or news program that refuses
to decode. All others are more liberal in what they accept.
Should not Pine also be liberal in what it accepts?
Perhaps the (anglophone) developers don't see a need to show
Subjects in a user-friendly way. But in French- or German-speaking
newsgroups, for example, one often finds long encoded words.
It it really annoying that Pine does not show them in a readable
way to the user.
Pine is user-hostile in this respect!
Mark Crispin
> Pine refuses to /decode/ encoded Subjects that are longer than 75 bytes.
Not allegedly. Explicitly. From RFC 2047 (the specification for
encoded-words), page 4:
An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.
While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
'encoded-word's is limited to 76 characters.
> But I do not understand why. Could someone please explain it to me?
Some MTAs and mailing list processors insert line breaks in lines that are
longer than that, which renders the encoded word undecodable.
Consequently, instead of using a single encoded-word for a long subject,
software is supposed to use multiple words.
> Pine seems to be the *only* mail or news program that refuses
> to decode. All others are more liberal in what they accept.
> Should not Pine also be liberal in what it accepts?
This statement is based upon a terrible misunderstand of Postel's
robustness principle. I knew Jon Postel. He was quite unhappy with
how his robustness principle was abused to cover up non-compliant
behavior, and to criticize compliant software.
Jon's principle could perhaps be more accurately stated as "in general,
only a subset of a protocol is actually used in real life. So, you should
be conservative and only generate that subset. However, you should also
be liberal and accept everything that the protocol permits, even if it
appears that nobody will ever use it."
> Perhaps the (anglophone) developers don't see a need to show
> Subjects in a user-friendly way. But in French- or German-speaking
> newsgroups, for example, one often finds long encoded words.
The problem with pulling the "differences" card (be it nation, race,
gender, sexual habits, religion, whatever) to win a concession is that it
implicitly states one's own inferiority: "we're not as as good as you,
therefore you must give us such-and-such."
I reject such arguments utterly; anyone capable of implementing newsgroup
software is capable of following the specifications properly.
In no way does this say "you can't have long subjects in European
languages." All it does is require that long subjects be in the correct
form for long subjects, which all MIME-capable software throughout the
world will recognize and handle properly.
Here is the proper thing to do. Suppose you are discussing Goethe, and
the subject of your message is a quote. Instead of generating:
?=ISO-8851-1?q?Das_sc=E4dlichste_Vorurteil_ist=2C_da=DF_irgend_eine_Art_Naturuntersuchung_mit_dem_Bann_belegt_werden_k=F6nne?=
your software should generate this:
?=ISO-8851-1?q?Das_sc=E4dlichste_Vorurteil_ist=2C_da=DF_irgend_eine_?=
?=ISO-8851-1?q?Art_Naturuntersuchung_mit_dem_Bann_belegt_werden_k=F6nne?=
[I think that I got this example right. I generated it manually, and the
quote is from memory. So please don't flame me if there's a mistake;
it's the principle in the example that counts.]
Also, software which fails to enforce the specifications is also
vulnerable to all types of security attacks.
It seems that there *is* concern about this in Europe.
Not long ago, a European government released a test suite which exploited
various security holes caused by mishandling of specification violations.
We were asked by that government to put Pine and imapd through that test
suite. Pine and imapd passed with flying colors.
Sadly, nothing else did. This included some rather expensive commercial
products. They all passed and/or installed the hidden virus (fortunately
killed) in the suite. Most caught some of the attempts, but Pine was the
only one that caught all.
It may not be "user-friendly" to show a phish scam as a bunch of
meaningless HTML instead of rendering it (because it didn't follow
specifications for how HTML mail is sent), but I prefer that behavior.
That way, I immediately know that it is a phish (almost all phishes
violate the specifications) and don't have to waste my time looking at it
more closely to see if it is really something from my bank.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Andreas Prilop
>> Pine refuses to /decode/ encoded Subjects that are longer than 75 bytes.
>> Allegedly, RFCs prohibit the decoding of long encoded words.
>
> Not allegedly. Explicitly. From RFC 2047 (the specification for
> encoded-words), page 4:
> [......]
Sorry, no! This is all about *en*coding. But I'm asking about *de*coding,
that is, showing the Subject to the reader. Where does RFC 2047 say
that the Subject of this thread _may not_ be shown as
Pine does not decode encoded Subjects that are longer than 75 bytes
to the reader? Please look at this thread in other newsreaders. I bet
they all show the Subject in this way. Are the other newsreaders wrong?
> Some MTAs and mailing list processors insert line breaks in lines that are
> longer than that, which renders the encoded word undecodable.
> Consequently, instead of using a single encoded-word for a long subject,
> software is supposed to use multiple words.
I agree completely with you. But this was not my point.
> Here is the proper thing to do. Suppose you are discussing Goethe, and
> the subject of your message is a quote. Instead of generating:
> ?=ISO-8851-1?q?Das_sc=E4dlichste_Vorurteil_ist=2C_da=DF_irgend_eine_Art_Naturuntersuchung_mit_dem_Bann_belegt_werden_k=F6nne?=
> your software should generate this:
> ?=ISO-8851-1?q?Das_sc=E4dlichste_Vorurteil_ist=2C_da=DF_irgend_eine_?=
> ?=ISO-8851-1?q?Art_Naturuntersuchung_mit_dem_Bann_belegt_werden_k=F6nne?=
This is all fine and there is no point to argue because I agree with you
completely. However, I did not write about *generating* or sending any
Subject but only about *displaying* an *incoming* long Subject.
(Actually, _you_ argue against Pine's behaviour. By your argument, Pine
should break the Subject of this thread in the reply. But it does not
do this currently!)
I ask again: Which RFC (and why) prohibits to *show* the Subject of
this thread as
Pine does not decode encoded Subjects that are longer than 75 bytes
to the reader? I do not address the question what you should happen
with a long encoded word in *replying*. Currently, Pine leaves the
Subject as it is - contrary to your arguments. But this is not my point.
[I thank you for your detailed answer - but I'm afraid you missed
my point. Is my English unclear?]
Alan J. Flavell
> On Wed, 21 Sep 2005, Mark Crispin wrote:
>
> >> Pine refuses to /decode/ encoded Subjects that are longer than 75 bytes.
> >> Allegedly, RFCs prohibit the decoding of long encoded words.
> >
> > Not allegedly. Explicitly. From RFC 2047 (the specification for
> > encoded-words), page 4:
> > [......]
>
> Sorry, no! This is all about *en*coding. But I'm asking about *de*coding,
See RFC2047 section 6.1 item (1):
'encoded-word's are to be recognized as follows:
(1) Any message or body part header field defined as '*text', or any
user-defined header field, should be parsed as follows: Beginning
at the start of the field-body and immediately following each
occurrence of 'linear-white-space', each sequence of up to 75
^^^^^^^^^^^^^^^^^^^^^^^^^
printable characters (not containing any 'linear-white-space')
should be examined to see if it is an 'encoded-word' according to
the syntax rules in section 2. Any other sequence of printable
^^^^^^^^^^^^^^^^^^
characters should be treated as ordinary ASCII text.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Seems to me that PINE is doing just what it says on the tin (no
pun intended).
> Please look at this thread in other newsreaders. I bet
> they all show the Subject in this way. Are the other newsreaders wrong?
They would presumably need to explain themselves as to why they are
violating this SHOULD condition of the RFC.
Mark Crispin
> Sorry, no! This is all about *en*coding. But I'm asking about *de*coding,
> that is, showing the Subject to the reader.
False dichotomy. An encoded-word of longer than 75 octets does not exist.
You are arguing that this token of longer than 75 octets, which is not an
encoded-word by definition, should nonetheless be treated as an
encoded-word.
There is nothing in any specification which stays that tokens longer than
75 octets must be treated as a quoted-word. If you think that a 100 octet
token must be treated as a quoted-word, what about a 1MB token? What
about a 2GB token?
The moment that you say that such a long token does not need to be
decoded, you conceed that there is a maximum size.
That size is in the RFC. It is 75.
> Please look at this thread in other newsreaders. I bet
> they all show the Subject in this way. Are the other newsreaders wrong?
Yes. They are broken. Those programs are failing to validate their input
according to the specification.
There is a security risk to this; failure to validate input is a potential
path for a virus. As I mentioned in my previous message, there is concern
about this in Europe, and a European government recently issued a MIME
test suite (which Pine and imapd passed) that specifically looked for
input validation failures. Given that your governments are seeking to
have such bugs fixed, it would be a step backwards to introduce this sort
of bug into Pine.
> This is all fine and there is no point to argue because I agree with you
> completely. However, I did not write about *generating* or sending any
> Subject but only about *displaying* an *incoming* long Subject.
Outlook goes to great efforts to display what the sender intended, rather
than enforce the specification. Outlook fully render all those malformed
phish spams in convincing detail, instead of Pine's behavior of showing
you the raw HTML because of the malformation.
Perhaps you consider this to be a feature. I consider it to be a bug.
> (Actually, _you_ argue against Pine's behaviour. By your argument, Pine
> should break the Subject of this thread in the reply. But it does not
> do this currently!)
No. It is just one big word, with nothing special about it (it's too big
to be an encoded-word). You're allowed lines of up to 1000 octets in
SMTP. There is no requirement that it be line-broken into smaller lines.
Now, some mail gateway or list processor might break it into a smaller
line. But that's its perogative. It's not a mandate for Pine.
> I ask again: Which RFC (and why) prohibits to *show* the Subject of
> this thread as
> Pine does not decode encoded Subjects that are longer than 75 bytes
> to the reader?
Which RFC (and why) prohibits a program from showing a malformed phish
spam as fully-rendered HTML?
Your question is just as silly. You argue that if something is not
explicitly prohibited by an RFC, it is therefore mandatory.
I to enjoy the fact that Pine does not render HTML in malformed messages.
Almost all the phish spams that I receive are malformed. This makes it
possible for me to recognize a phish immediately. It's the few
non-malformed phishes that render that waste my time; as I have to examine
them to see if they are phish or legitimate.
Similarly, an overlong encoded-word is another useful indicator that the
message is probably spam. I regularly correspond with people in a
non-English language, but most MUAs in that country seem to follow the
specification and do not generate overlong encoded-words. The main
exception is spam engines; that falls into the category of "feature, not a
bug."
Last but not least, I don't think that "it works in Pine [or imapd]!" to
be used as an argument to browbeat some other MUA author into violating
the specification, or into handling something that does not comply with
the specification.
For the people who want their spams, phishes, and viruses rendered in
spite of malformation, there is always Outlook.
Mark Crispin
> See RFC2047 section 6.1 item (1):
Thanks for pointing that out. It's amazing that we need explicit text for
the interpretation procedure; interpretation is (after all) nothing more
than the inverse of the generation procedure.
But I guess that the current argument, based upon an abuse of Postel's
robustness principles, is what makes it necessary.
Then we end up with "nobody reads RFCs because they are too bloated."
Can't win. Can't break even. Can't quit the game. :-)
Alan J. Flavell
> On Thu, 22 Sep 2005, Alan J. Flavell wrote:
> > See RFC2047 section 6.1 item (1):
>
> Thanks for pointing that out. It's amazing that we need explicit
> text for the interpretation procedure; interpretation is (after all)
> nothing more than the inverse of the generation procedure.
With respect: "not always". There are sometimes permissive areas
between generation and acceptance. But in this case it seems to be
stated rather clearly.
For what it's worth, our departmental mailer runs the (excellent) exim
MTA software, which has quite a range of optional facilities to
validate various features of the SMTP protocol exchange; we have
chosen generally to reject mails whose headers fail syntax validation.
Almost all of our logged rejections can be rated as deliberate abuse;
I'm sorry to say that those few whose intentions are otherwise bona
fide, seem to have a habit of hassling us to accept their defective
mail (some by a proper route to our postmaster/abuse address, others
by libelling us on a public forum), and do not seem inclined to
understand that the fault lies more on their side than on ours.
The usual refrain is "*nobody* else refuses our mail, so there can't
be anything wrong with it". Sigh. One time I did helpfully cc: my
reply to a colleague at another site which I knew would reject their
subsequent reply for the same reason, and then waited for the bang.
The complainant was not well-pleased that he'd now found a second site
that rejected his illegal header, thus giving the lie to the claim
that it was only us. But he was still not inclined to correct his own
software. Apparently he felt that the fact that he was paying a
considerable sum of money for his mail software implied some kind of
compulsion on us to accept anything that it cared to extrude.
> Can't win. Can't break even. Can't quit the game. :-)
Indeed :-}
Mark Crispin
> I'm sorry to say that those few whose intentions are otherwise bona
> fide, seem to have a habit of hassling us to accept their defective
> mail (some by a proper route to our postmaster/abuse address, others
> by libelling us on a public forum), and do not seem inclined to
> understand that the fault lies more on their side than on ours.
If it makes you feel any better, the same thing has been going on in the
ARPAnet/Internet world for at least three decades; perhaps longer, but I
don't have first-hand knowledge.
> The usual refrain is "*nobody* else refuses our mail, so there can't
> be anything wrong with it".
I would go beyond the word "usual" by saying "invariable". Apparently,
there is a flaw in the mental wiring of our human species that allows peer
pressure to make us do stupid things. "Everybody else is doing it, so you
should too."
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Andreas Prilop
[......]
> For the people who want their spams, phishes, and viruses rendered in
> spite of malformation, there is always Outlook.
I do not understand why you write about spam, HTML e-mail, phishes,
and Outlook. (You mean /Outlook Express/, do you?)
I speak about *normal* Usenet messages. This is the message that
caused me to bring up the problem:
| Newsgroups: de.comp.os.unix.apps.kde
| Message-ID: <dgmmvh$mf9$05$1...@news.t-online.com>
<news:dgmmvh$mf9$05$1...@news.t-online.com>
A Subject as in our thread may be fun, but to see
=?UTF-8?B?R2Vyw6R0ZXN5bWJvbGUgbnVyIGFuemVpZ2VuLCB3ZW5uIEdlcsOkdCB2b3JoYW5kZW4=?=
is no fun! You say it is not an encoded word. What else is it?
Just a random string of letters and digits? You say it is a security
risk to decode it? How come that all other newsreaders show it as
Gerätesymbole nur anzeigen, wenn Gerät vorhanden
When I described the problem in <news:de.comm.software.newsreader> ,
the first reaction was astonishment that there exists a newsreader
that fails to decode the Subject. (Yes! I mean "fail".)
http://groups.google.com/groups?as_usubject=Codiertes.Subject.zu.lang
And *my* reasoning was that Pine is correct, being a long-time
Pine user. Please look at that thread where I actually tried to
defend Pine's position. However, I can tell you that Pine isn't
well received in German-speaking newsgroups because of its severe
limitations with non-ASCII text. One statement was "Drecksoftware"
(shitty software).
You should look through French- and German-language newsgroups.
Perhaps you will then understand why Pine is almost never used
outside the anglophone world. To show a Subject as
=?UTF-8?B?R2Vyw6R0ZXN5bWJvbGUgbnVyIGFuemVpZ2VuLCB3ZW5uIEdlcsOkdCB2b3JoYW5kZW4=?=
is what I called and still call user-hostile. Mozilla decodes it;
I do *not* speak of Microsoft's programs. Maybe you don't care
about this in your anglophone world.
Mr. Crispin:
I thought you might convince other people of Pine.
Instead, you piss off people who have already been using Pine!
I have always tried to back Pine's position. Now I'm pissed off
by you, Mr. Crispin.
Mark Crispin
> A Subject as in our thread may be fun, but to see
> =?UTF-8?B?R2Vyw6R0ZXN5bWJvbGUgbnVyIGFuemVpZ2VuLCB3ZW5uIEdlcsOkdCB2b3JoYW5kZW4=?=
> is no fun! You say it is not an encoded word. What else is it?
> Just a random string of letters and digits?
That is correct. It is not an encoded-word, because RFC 2047 (the
definition of encoded-word) explicit states that it is not.
> You say it is a security
> risk to decode it?
At least one European government thinks so. Limits-checking was one of
the things that their test suite checked.
> How come that all other newsreaders show it as
> Ger���齷轤闌�銛�瘤淏蜃緕���銕�賠�ぢ����鱶瘤粤�
壽闢�頏閾鱇逑�癇�碣闍緕���汝闕�卞�屋慣�
嚆笏蜿�穏
����綜�у釿閼繖∠闥筵�轣�鈿�矼�迴鱚��瘤�卦�竏癇痺�鴦�跫鈑��蜴竚�蜴�����湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎湎�����с葹鴦續К�у釿閼蜴腱��у釿閼繖∑纔���瘤�粤跚迚�鴦���膚�蜚�蜩
����粤皷鱇碎���緕竢粤�迴鱚�����瘤��跛�肅�蜴�瘤�у釿閼繖∠闥筵�閹
����卦�竏癇痺�鴦��逡踉蜷跂�у釿閼繖∠闥筵��辮癇癆繖�磔�智牝�嗤礎滴�轣�����矼��繖�
嚆笏蜿�峡浦
��������朞��縺竏�黼髟緕竇�閹�����卦
�������������������������������湎湎湎湎
��������頏蜴�碎�竏癇痺�鴦��阡�竢銓瘟鉗鈑�瘤�ъ蜴縺鬮�蜚絖齔痺紮�
��������鼈阨趙�矼�纔瘢蜴繖���黼�蜀�蜚�蜩�瘤�у釿閼繖∠闥筵�痺竢鰾蜴��
����������齷銓癢�鴣跂�蜴�黼笏蜿�荻��綜�阡蒹�黼髟緕竇�閹�頏蜴�碎���������竏癇痺�鴦�鼈阨趙�矼��縺��癈�闥粡釶鴒�喪檀����
�被��鬪��竅��跛�尞���癆�倡鈬�蜩逾���跛�鱚竇蝟繖�蜴�賠鴉瘤∮鞳瘠蜴�鈬�苒阨頌�矼竅��閹�蜚�黼�鱚
�跚迚��闔����鈿遶喪檀�������齡癆纃緕����鱚站齒胄�鱚���蓍��齒胄�鱚�
倥纈�頏纉齦鱚�│纐纈墲閼�繻黼�蜩�粹蜴�蜚〒��闥�矼蜴�竅跛繖���趺癇�
釶辣��蜩�鈿��鱚癈闔���粹�齒辣�蜴��癆�蜩��闔膸�纉鞳竕瘡踟��緕��纈�
蜩�纔韭蜒蜚����蜴�卞�屋慣��癆�黶崧��阡����粹�蜚�
�浴墲�尞��粹逾�竅鱚
�痰阨��蜩�蜴�尞��瘤芟關蓖鈬��鳰筮
令�闔瘡蜩�癇苺辣銓�癇�鈿�苡閼�癇苺辣銓�繪�纈�
�聽�齒���竏鉗竅�癇苺辣銓�蜀�尞���銓���竢鉚蜴竇���
卞�屋慣�頏阮蜆纉��辣瘤���鱚頏纉緕�跫鈑���鶤��烈辣鳫��蜴粡�糒瘡�
胙闕�燈鳫鞳��蜴竚�蜴�胙闕�賠鴉瘤∮鞳瘠蜴�竢��蜈鵺��鱚�辣轤纈�閹���
�鳬蜴�苒阨��癆�頏閼�繖���揺妖�齦蜚��釿跿粡鈑�卞�屋慣���囂辣�
齒胄�鱚�鴣銕蜴�蜴�燈鳫鞳��闌癆纉�卞�屋慣��瘤�艱鈬鱇��跫鈑����蜴��
粡聿纈緕�轣銕纈���壽癆�齒胄�鱚�鼈阨趙�矼�肅�篁�蜚�蜩�鈿遶竢逅跚瘤����
卞�屋慣���部�蜩�蜴瘰頏關鱸癆���粤轣鈔��癆�卞�屋慣�竢逅跚瘤�齒胄�鱚�
矼�碣闍緕���痺竢迴籬��碣闍緕�齒胄�鱚�
嚆�鱇�頏閼���闔���轣鳬續�癇�閹聽鱚�磔��鈔闥���粡齟繚癇��癆�
蜩��竏鉗竅跛�竢鴪繝�蜴�闥粤���瘰鞳癈�鞳纈≒鱚齠��瘤�釶�闔瘡蜩蹼�
壽�蜴粡�糒瘡���竏闖黼�齦竏�頏閼���癇��闢��鈔闥鵲�赱���頏纖��
�蒹�蜴粡�糒瘡�頏繙纈������鈔�頏閼�紿�頏閼����蜒�粹��癆�蜩�
�竏鉗竅跛�竢鴪繝��纐緕�蜀�蜚�蜩�鈿�鈬竇齠癇蛹�竟頤赱鬯
⑬�浴鳬�⑬
蔗�痕�瘤籬�闕�鱆
偵迴竰痺�蜩����踝纉�瘤��鼈繞�粤竕粡鈑��癆���縺�肬�跿釿莅
也矼鶯�蜩���跛〟鴉繖�鼈繞�竢銓纉�鈑������
andreas mrs d.t ch
>
> I thought you might convince other people of Pine.
>
> Instead, you piss off people who have already been using Pine!
>
> I have always tried to back Pine's position. Now I'm pissed off
> by you, Mr. Crispin.
>
Hmm, and what is pissing off a guy who sticks to the standard good for?
Why not ask the others to fix their software? Ok, perhaps you did and
I'm not aware of it. Perhaps they have a good argument to not to stick
to a standard.
Andreas
Harold Stevens
[Snip...]
> Hmm, and what is pissing off a guy who sticks to the standard good for?
Agree; it's kinda like yelling at Moses for delivering the Decalogue. :)
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Kids jumping ship? Looking to hire an old-school type? Email me.
Franz Haeuslschmid
[Some statements on security and privacy issues with e-Mail.]
> I speak about *normal* Usenet messages. This is the message that
> caused me to bring up the problem:
>
> | Newsgroups: de.comp.os.unix.apps.kde
> | Message-ID: <dgmmvh$mf9$05$1...@news.t-online.com>
> <news:dgmmvh$mf9$05$1...@news.t-online.com>
Oh, I followed the discussion so far and looked at the offending
message. I don't think that following standards or
recommendations (or even request for comments) is a bad thing for
any software in the field of Internet communication. And in this
case, Pine is perfectly correct.
But is it user-friendly? It is more user-friendly than the
software that was breaking standards as it produced invalid
encoded words. In the case of the message above, it is up to
`KNode' to produce correct headers. IMHO is it more appropriate to
submit a bug report to the developers of `KNode' than demanding
from Pine to relax their handling of standards.
[Elided for denastyfication.]
BTW, how did you create that subject line? That is, did you
manually set charset, encoding and delimiters? It actually
exceeds the limit of 75 characters for the encoded word. Would
it now make sense for Pine to ring the alarm and inform the
user? However, that would be out of scope of Pine's tasks, too.
Franz.
Alan J. Flavell
> I speak about *normal* Usenet messages.
In the time since you raised this topic, I've reviewed the subject
lines on a few "normal" German-language usenet groups. I had some
difficulty finding examples of the kind of defective subject line that
you're complaining about, but there /were/ just a few.
> This is the message that caused me to bring up the problem:
>
> | Newsgroups: de.comp.os.unix.apps.kde
> | Message-ID: <dgmmvh$mf9$05$1...@news.t-online.com>
> <news:dgmmvh$mf9$05$1...@news.t-online.com>
So it seems we're discussing a bug in KNode, no?
A search for KNode in conjunction with RFC2047 reveals that this bug
was reported in June this year, bug 37992 - as you now know, since
you've posted to that thread.
http://lists.kde.org/?t=111925744200003&r=1&w=2
> A Subject as in our thread may be fun, but to see
>
> =?UTF-8?B?R2Vyw6R0ZXN5bWJvbGUgbnVyIGFuemVpZ2VuLCB3ZW5uIEdlcsOkdCB2b3JoYW5kZW4=?=
>
> is no fun!
So put the complaint where it belongs (i.e in this instance on the
KNode bug list), as you've now done.
I found a specimen posted from "G2/0.2". This looks like yet another
Google Groups SNAFU, of which there are so many that I basically
killfile all postings via Google groups. G.G is a useful facility for
reviewing archived postings, OK, but their attempt to present Usenet
to the great unwashed as a new Google facility has been an unmitigated
disaster IMNSHO. However, that's a topic for another day.
There's also a fellow called Dax who apparently posts in
x-mac-croatian: at first I thought this was another specimen of the
same, see e.g message-id <dh1em0$665$2...@ss405.t-com.hr>
> However, I can tell you that Pine isn't well received in
> German-speaking newsgroups because of its severe limitations with
> non-ASCII text. One statement was "Drecksoftware" (shitty software).
Whatever they might think of it now, it won't be any better if it gets
changed ("verschlimmbessert") to violate specifications.
(PINE's most evident current problem IMHO when I'm doing German
language groups is dealing with display of messages posted in
iso-8859-15 when I'm configured for iso-8859-1. But I digress...)
I know why I use PINE, although I see it as a compromise rather than
an inevitable choice. It doesn't bother me if other users prefer
something else, just as long as they don't start posting RFC-violating
Dreck themselves and then complaining that RFC-conforming clients
won't tolerate it. Not that I'm accusing you of doing that directly,
but for a moment there you seemed to be doing it by proxy.
best
Andreas Prilop
> Why not ask the others to fix their software?
Oh yes - please do so!
http://bugs.kde.org/show_bug.cgi?id=37992
Andreas Prilop
> In the case of the message above, it is up to
> `KNode' to produce correct headers. IMHO is it more appropriate to
> submit a bug report to the developers of `KNode' than demanding
> from Pine to relax their handling of standards.
Do it then!
http://bugs.kde.org/show_bug.cgi?id=37992
Andreas Prilop
> A search for KNode in conjunction with RFC2047 reveals that this bug
> was reported in June this year, bug 37992
Sorry no! http://bugs.kde.org/show_bug.cgi?id=37992
was opened 2002-02-11.
^
I says "Status: RESOLVED" and "Resolution: FIXED".
Alan J. Flavell
> On Sat, 24 Sep 2005, Alan J. Flavell wrote:
>
> > A search for KNode in conjunction with RFC2047 reveals that this bug
> > was reported in June this year, bug 37992
Correction - see below.
> Sorry no! http://bugs.kde.org/show_bug.cgi?id=37992
> was opened 2002-02-11.
> ^
> I says "Status: RESOLVED" and "Resolution: FIXED".
Yes, I saw that. However, as I read the mailing list, it was claimed
in June this year that the problem was fixed, but then reported on
2005/07/08 that the problem was still present in 0.9.1 and the bug
should be re-opened:
http://lists.kde.org/?t=111925744200003&r=1&w=2
http://lists.kde.org/?l=knode-devel&m=112081544017240&w=2
That action however had still not been taken when you added to the
thread, last week.
Having looked (or rather, had some software look) though the subject
lines of cached postings on a few de.* groups, I have to report:
* I found just a few samples which could be blamed on KNode;
* I found a handful of specimens posted from "G2/0.2" -
I've already written Goo-groups off as a disaster area anyway,
as far as netiquette and RFCs are concerned.
* The other few examples I found, amongst tens of thousands of normal
postings, identified themselves as:
Freenet Webnews (1)
Unison/1.5.2 (2)
It seems to me that the complained-of effect is rather rare, at least
on the de.* groups which I happened to look at. Irritating when it
happens, for sure.
But anyway, we really should take this off the PINE group, as it's
evidently not PINE's problem.
All the best