-={ 2017-02-27 19:06:20.358028540+00:00 }=-

Hey Konstantin!

I put in a CHRS kludge just for you. Unfortunetly it can be bogus just like the FTN 'standard' it is based on.

Life is good,
Maurice

... �� ��妬��� ��� ������椠 ���
--- GNU bash, version 4.4.12(1)-release (x86_64-atom-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

-={ 2017-02-27 11:21:51.415124894-08:00 }=-

Hey Maurice!

Just for the record and to demonstrate that it wasn't a bogus tagline I am taking the liberty of posting the solution to the bogus CP866 message you so thoughtfully constructed. :-)

Totally ignoring the CHRS kludge and running it through iconv like such;

iconv -f cp737 -t utf8

yields;

... Έχω σκίουροι στο παντελόνι μου

which is Greek for "I've got squirrels in my pants", ehich nicely sums up the state of the FTSC documentation.

Life is good,
Maurice

... Wide ne biþ wel, cwæþ se þe gehyrde on helle hriman.
Things are bad everywhere, said the man who heard wailing in hell.
--- GNU bash, version 4.4.12(1)-release (x86_64-atom-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Greetings, Maurice

MK Just for the record and to demonstrate that it wasn't a bogus tagline

Ehm... Good job crafting the message with not matching CHRS kludge and used codepage. And what is the point of that? Why don't you setup a homepage which serves pages in one codepage but provide different Content-Type? Or made the same with Content-Type/Mime encodings in your emails? Are internet RFC's working any better against ruining messages on purpose?

MK I am taking the liberty of posting the solution to the bogus CP866
MK message you so thoughtfully constructed. :-)

Why is my CP866 message bogus? It was written in CP866 codepage and so it advertise it. Heck, it even have CP866 cyrilic characters...

MK Totally ignoring the CHRS kludge and running it through iconv like such; >MK iconv -f cp737 -t utf8

Or if you have just specified "CHRS: CP737 2" then all "magically" worked as is...

--- Claws Mail 3.14.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu)
* Origin: Via 2:5019/40 NNTP (GaNJaNET STaTi0N, Smolensk) (2:5019/40.1)

-={ 2017-02-28 14:07:09.181375383+00:00 }=-

Hey Konstantin!

Good job crafting the message with not matching CHRS kludge and
used codepage.

Thank you. Actually it was easy and did no harm to anything that really matters. I just slightly modified a bit of abandoware code I happen to have handy. I used that same code to generate all the goofy 'demonstrate' messages. The only one I missed was a CP437 one which the sysops here in North America have been deluded into thinking is the norm, although some call it IBMPC.

Or if you have just specified "CHRS: CP737 2" then all "magically"
worked as is...

Really? I seriously doubt that given that it isn't a supported encoding. Mind you that doesn't REALLY matter ... does it? ;-)

Life is good,
Maurice

... On ælcere ea swa wyrse fordes, swa betere fisces.
In every river, the worse the ford the better the fish.
--- GNU bash, version 4.4.12(1)-release (x86_64-atom-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Greetings, Maurice!

Thank you. Actually it was easy and did no harm to anything that really matters. I just slightly modified a bit of abandoware code I happen to have handy. I used that same code to generate all the goofy
'demonstrate' messages.

All those 'demonstrate' messages do are demonstrating your ignorance and nothing else.

The only one I missed was a CP437 one which the sysops here in
North America have been deluded into thinking is the norm,

And why it isn't?

although some call it IBMPC.

Yes, technically IBMPC is CP437 if there are no CODEPAGE kludge. In reality on contrary even in Russian echoes there are messages with CHRS IBMPC but without CODEPAGE whose actually written in CP866.
But that's all just a legacy stuff and must not be presented in new messages for at least a few decades. Today all that legacy can be just ignored by editors as it is most likely not represent actually used codepage anyway.

Or if you have just specified "CHRS: CP737 2" then all "magically"
worked as is...

Really? I seriously doubt that given that it isn't a supported
encoding. Mind you that doesn't REALLY matter ... does it? ;-)

Supported by what? For example it is supported on my end, actually my current client supports all encodings whose iconv understand.
If you mean that it isn't specified in FTSC-5003 then you are wrong. FTSC-5003 just specify most commonly used codepages and not restrict you to only specified codepages. You can write you messages in whatever codepage you want, but you must supply CHRS kludge to indicate what codepage was used. It just a common sense to don't use anything rare because there are no guarantee that it can be read and understood by receivers.

--- Claws Mail 3.14.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu)
* Origin: Via 2:5019/40 NNTP (GaNJaNET STaTi0N, Smolensk) (2:5019/40.1)