Hello Thomas, On Sun, 25 Jan 2004 г. 18:39:19 you wrote:
TF> Let me understand this. You explicitely tell TB to use: >> "Content-Type: text/plain; charset=koi8-r / >> Content-Transfer-Encoding: 8bit" TF> but TB changes it to >> "Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: 7bit" TF> just because it doesn't detect a high ASCII character? Yep. Looks exactly so. TF> That sounds wrong. For me too. However, based on the bug No. 2343 which I also mentioned, as well as on the Russian discussion I mentioned on the bugtraq, some people think this behaviour (completely unacceptable for me) is absolutely OK. TF> But let me ask you *how* you have set TB to the first setting to being TF> with. Well, there is that "Use Character set" in account templates, as well as "Message encoding" when composing a message... If I choose a charset in those 2 places, I think that means I want to be in the specified charset, and since it is an 8-bit charset, I think it also means I want it to be "Content-Transfer-Encoding: 8bit". (To be strict, I don't think I indicate "Content-Type: text/plain" directly anywhere, - I simply use a plain text message editor. but thanks God, The Bat! does not change that anyway :))) ). You may also want to have a look at the bugtraq link I provided, where I list in every detail the steps required to reproduce this. By the way, a fellow TBUDL subscriber has already added a note there saying it's the same with Latin-9 (ISO-8859-15) encoding. Of course, feel free to ask for any additional info. The following are thing s you may be not so interested in, but still. I will now quote some parts of those discussions here (in my English translation). Those are public discussions anyway, so I think that's OK. First, there was a discussion at http://www.forum.nobat.ru/index.php?board=5;action=display;threadid=1361 , from which I myself got first information on that problem. People complained about this sort of TB! behaviour, saying it is still the same with Windows-1251 charset, it is still the same if you include "%charset" in your templates, whatever. Alexandr Kiselev, administrator, Dec 02, 2003, 07:28:24 pm: -------------------------------------------------------------------------------- "If all characters in a message are us-ascii, then Bat has been always putting us-ascii in message headers, irrespective of the default encoding. This is by the way in complete accordance with the letter and spirit of RFCs. I would recommend to replace one of Latin "a"'s with a Russian "а" - this would be sufficient to cope with your problem. In general terms, this is a problem with Outglitch (=Outlook - M.K.)... (skipped - M.K.)" Sokol, Dec 03, 2003, 09:30:29 am: -------------------------------------------------------------------------------- Alexander Kiselev on Dec 02, 2003, 07:28:24 pm wrote: "If all characters in a message are us-ascii, then Bat has been always putting us-ascii in message headers, irrespective of the default encoding. This is by the way in complete accordance with the letter and spirit of RFCs." I don't seem to remember seeing such things there. Would you kindly remind me where exactly it says so?.. (skipped - M.K.)" Alexandr Kiselev, administrator, Dec 03, 2003, 08:15:47 pm: -------------------------------------------------------------------------------- RFC2045, see the definition of 7bit data and 8bit data. Yours are 7bit data, so they're encoded under RFC822, i.e. us-ascii. Moreover, I purposely check, and Pegasus for example uses exactly the same logic as The Bat!. Same for Becky. So don't tell me this is wrong. You can install some smtp-gateway like Xray, and change forcefully the respective header field. I cannot give any other advice. Oh well... If you have honestly purchased your Outglitch, then you can complain to Microsoft. Let them patch their mistake." Vadim, administrator, Dec 05, 2003, 10:54:21 am: -------------------------------------------------------------------------------- ...It is for this very reason that monsters like Microsoft write programs which do not correspond to standards that people like ypu appear... IMHO, there is a standard, so it must be complied with. And all clients comly with it, while Microsoft invents something of their own and most people comply with that for some [incomprehensible] reasons..." I got a feeling of all that being definitely a wrong approach, and started a new thread at http://www.forum.nobat.ru/index.php?board=3;action=display;threadid=1564 : Me on Jan 14, 2004, 03:42:05 pm : (arguments like those provided in the previous message, aa well as in my bugtraq message, skipped...) "...So this is a really illogical behaviour of The Bat!, and if Pegasus and Becky use the same logic... it doesn't mean the logic itself is correct. By the way, regarding Pegasus... Harris puts it in the help files: "Allow 8-bit MIME encodings" "If you check this control, Pegasus Mail will generate MIME messages using the MIME "8BIT" transfer encoding whenever you include 8-bit data in your mail. _8-bit data is illegal in Internet mail_ (sic! - M.K.), but is used in some countries. This is both a very technical, and potentially very dangerous option and should only be used if you know what you are doing. We recommend you do not check this control except on the advice of a properly qualified person." So, with all my respect for Pegasus and its author, I would not use it as a good example in terms of handling 8-bit data..." Wanderer, Jan 14, 2004, 05:38:35 pm: -------------------------------------------------------------------------------- "My answer will be short... To indicate 7-bit data as 8-bit for the convenience of ugly clients??? Don't you need to see a doctor, heh? And don't f*** Harris's brain..." Wanderer, Jan 14, 2004, 06:46:03 pm: -------------------------------------------------------------------------------- "Well, let's calm down a bit... <INTRO (offtop)> ...I don't like stupidity based on merely one's speculations around his own interpretation of RFCs and one's own wishes... </INTRO> No one RFC out of those mentioned does not mention 8-bit data even in terms of SHOULD, not to say MUST, so this is completely subject to the implementation decision. And it is a completely legal to make an assumption based on the above that any indication of an 8-bit charset is only relevant for cases where there might be an ambiguity in terms of the charset selection for 8-bit data, i.e., then, and only then, if there _are_ those 8-bit data, because for 7-bit data there is just one option, with no alternatives. So this is an interpretation of RFC which does not contradict to anything, creates fewer problems than the broad interpretation you proposed, and it is widely used therefore in any MUAs, which are aware of 8bit, but follow the Ockham' razor pinciple" That's the "mood" of the whole further discussion there. So thanks a lot Thomas, - now I know it's not necessarily me going crazy :). My apology for any inconvenience with the translated parts, - I did it very quickly (although accurately as I could in terms of keeping the meaning). Regards, Maksym. -- Maksym Kozub, MK881-UANIC mailto: [EMAIL PROTECTED] ________________________________________________ Current version is 2.02.3 CE | "Using TBUDL" information: http://www.silverstones.com/thebat/TBUDLInfo.html
