Forced MIME text/plain for non-ascii letters

["ListMan" <LISTMAN@cpr.cor.neva.ru>]

Hello All The Zmailer Guru's!

The well-known problem of Cyrillic Internet is transport charset (KOI-
8) being different from both DOS (IBM-866) and Windows (ANSI-1251)
charsets. Most of standard modern Windows e-mail packages assume
that incoming messages are either IBM437, IBM866 (if properly using
OemToAnsi) or ISO8859-1. And reader sees some shit.

However, if message encoding is shown directly in header, as:

==================
MIME-Version: 1.0
Content-type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8BIT
=====================

any e-mail package equipped with proper translation tables processes it
well.

The solution choosen by me in our Internet site since September 1996 is
based on the following ideas:

1. Any message containing 8-bit non-ascii text MUST be marked as "MIME
text/plain" in header. (my understanding RFC1341 ?)

2. For our national environment, any 8-bit message without shown
charset MUST be interpreted by recepient as "koi8-r" text.

So, I may (or must?) insert the lines given above in any message
passing my postoffice, IF respective field was not given before by
sender. This insertion is absolutely safe and does not violate RFC.

To provide this behavior, Zmailer was patched in three modules:
(line numbers for 2.99.49p5)

======transports/sm/sm.c after line 659
        if (!has_header(startrp,"MIME-version:"))
          append_header(startrp,"MIME-version: 1.0");
        if (!has_header(startrp,"Content-Type:"))
          append_header(startrp,"Content-Type: text/plain; charset=koi8-r");
        if (!has_header(startrp,"Content-Transfer-Encoding:"))
          append_header(startrp,"Content-Transfer-Encoding: 8bit");

======transport/smtp.c, after line 1025
       if (!has_header(startrp,"MIME-version:"))
          append_header(startrp,"MIME-version: 1.0");
        if (!has_header(startrp,"Content-Type:"))
          append_header(startrp,"Content-Type: text/plain; charset=koi8-r");
        if (!has_header(startrp,"Content-Transfer-Encoding:"))
          append_header(startrp,"Content-Transfer-Encoding: 8bit");

======transport/mailbox.c, after line 1496
        if (!has_header(rp,"MIME-version:"))
          append_header(rp,"MIME-version: 1.0");
        if (!has_header(rp,"Content-Type:"))
          append_header(rp,"Content-Type: text/plain; charset=koi8-r");
        if (!has_header(rp,"Content-Transfer-Encoding:"))
          append_header(rp,"Content-Transfer-Encoding: 8bit");

The patch vas tested since September 1996 on 2.99.37 and since 16.09.97
on 2.99.49p5.

All the agents are run with -8 key, to prevent unnecessary QPing of 
message body: all the channels must be 8-bit clean here.

In v.37, libta.c was also patched to replace UNKNOWN-8BIT by koi8-r.
In v.49, it is already done by DEFCHARSET. Thanks.

I know that below these insertions, all the modules scan message body
for "real 8BITness" and replace "koi8-r" with "us-ascii" if no bad
characters found. Such behavoir seems to be fine too: this message
should bee processed just in this way.

This patch is fast'n'durty: first, I am not sure in it's optimal
position; 2nd, it must be controlled by commandline key and DEFCHARSET.
However, it works reliably, and I feel no power to make better now :-(

The primary e-mail editor of our site is Pegasus Mail. Users run DOS
and Win16 versions in NW312/Mercury environment; Win32 and Win16 as
dial-up or remote POP3 clients; DOS, Win16 and Win32 as UUCP clients. 
Cyrillic messages in koi8-r, ANSI-1251, IBM-866 and (hope) ISO8859-5 
are accepted fine and transparently for reader, if sender says truth 
about his encoding, or says nothing about koi8-r. Our correspondents 
also see no any problems reading our mail.

Feel free to test ns.cor.neva.ru running this patch as mail relay.
Until smtp-policy is not compiled ;-).