Subj : squirrel and M├╕├╕se To : Nicholas Boel From : mark lewis Date : Fri Jul 28 2017 06:45:16 On 2017 Jul 24 15:22:54, you wrote to me: ml>> that was more likely jamnntpd... it doesn't apply the message body ml>> character set to the header data... nothing talks about doing that in ml>> FTN stuffs... it was probably done by jamnntpd during the creation of ml>> the article header... we won't mention that even on the 'net they ml>> don't apply the body settings to the header... on the 'net, they do ml>> it, in MIME, in the header field that's being special... we see it a ml>> lot in spams with the name and/or subject fields being the main ml>> ""targets""... NB> Either way, it shouldn't happen. When a message arrives with a UTF-8 NB> subject line, it should not be translated. Especially when I have NB> everything set here to translate to - keep - and reply all with UTF-8 as NB> well. NB> So what you're saying is the subject came in as UTF-8, but since the body NB> was us_ascii.. jamnntpd translated the subject to us_ascii as well? I have NB> nothing here in my configs that would tell it to do that. no, what i'm saying is that the subject wasn't translated at all... there's nothing anywhere to tell your news reader what character set to use in the header lines... the subject lines, at least, use base 64 mime in them if the character set is not plain 7bit ascii... NB> To be more specific, his message arrived here with a readable subject NB> line. I could read the UTF-8 subject just fine. When I replied in NB> Thunderbird, it still showed the subject as it was originally written. NB> When I saved it, it was then mangled. then your news reader mangled it... see above about the base 64 mime stuff... referring to my original quoted statement, the subject field is the ""target"" field in this instance... here's an example of what i'm talking about... i've grabbed this from my SMTP SPAM quarantine on my perimeter firewall... ----->8 snip 8<----- Subject: =?GB2312?B?t+HM77HquMu5pLOnvqvS5s/Ws6EsztLDx7+0tb3KssO0?= ----->8 snip 8<----- you can go here to decode it and see an additional example of how it is done... http://dogmamix.com/MimeHeadersDecoder/ see also RFC-2047... and if you really want to trip out, the message with the above subject header line also contains this shit... ----->8 snip 8<----- Content-Type: text/plain;charset="GB2312" ----->8 snip 8<----- https://en.wikipedia.org/wiki/GB_2312 text/plain, hunh?? riiiight... so anyway, the point is that without jamnntpd creating a mime subject line with the proper character set stuff, your news reader can do anything it likes to it... we won't even attempt to speculate what would happen if jamnntpd tried to eat one of those lines... NB> I think remember seeing something in jamnntpd's code that when an NB> ascii message comes in, not to translate it - even though it will NB> change your CHRS kludge to whatever your charset is. Something's odd NB> there, for sure. the whole thing was an attempt to shoehorn shit into shinola... good idea but the implementation was off... we won't even mention the well known problems with the last read pointers being held on the user's system instead of the server where they belong so they can be adjusted when the message areas are purged and renumbered... )\/(ark Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... .... Invalid COMMAND.COM, System Disobeying. --- * Origin: (1:3634/12.73) .