16 messages in net.sourceforge.lists.courier-users[courier-users] Re: 8bit Again| From | Sent On | Attachments |
|---|---|---|
| Papo Napolitano | Mar 9, 2001 1:53 pm | |
| Papo Napolitano | Mar 9, 2001 6:59 pm | |
| Roland Schneider | Mar 10, 2001 1:37 am | |
| Papo Napolitano | Mar 10, 2001 2:28 pm | |
| Alexei Batyr' | Mar 11, 2001 4:15 am | |
| Roland Schneider | Mar 11, 2001 7:57 am | |
| James.Duanmu | Mar 11, 2001 5:04 pm | |
| Alexei Batyr' | Mar 12, 2001 3:11 am | |
| Kris Kelley | Mar 12, 2001 7:43 am | |
| Kirill Pushkin | Mar 12, 2001 8:14 am | |
| Bill Michell | Mar 12, 2001 8:52 am | |
| Sam Varshavchik | Mar 12, 2001 4:02 pm | |
| Sam Varshavchik | Mar 12, 2001 4:03 pm | |
| Alexei Batyr' | Mar 13, 2001 1:24 am | |
| Bill Michell | Mar 13, 2001 2:30 am | |
| Kirill Pushkin | Mar 13, 2001 4:20 am |
| Subject: | [courier-users] Re: 8bit Again | |
|---|---|---|
| From: | Alexei Batyr' (leh...@pcmag.ru) | |
| Date: | Mar 12, 2001 3:11:09 am | |
| List: | net.sourceforge.lists.courier-users | |
Roland Schneider writes:
Why not define what such rules should be ? For a ISP-like scenario I want my MTA do do about the following: 8bit in the headers is a real no-no but this could be fixed in most cases, copy the bad header to X-Mimified-ISO-8859-1-... and then replace anything outside of US-ASCII with underscores to maintain some readability. This rewriting could be limited to the Subject, From:, To: and Date:, otherwise bounce the message or dont accept it at all if submitted across the network.
8bit in the body (without the correct MIME-headers) does not hurt the internet, but I dont see a problem adding text/plain, 8bit to the headers to make even cron and friends compatible. I also dont want the MTA to change a single bit in the body if not absolutely necessary, this data belongs to third parties and if the recipient cant read the mail he knows how to contact the sender.
Unfortunately it's not so simple for non-latin alphabet countries such as Russia. If you replace non-ascii characters with underscores Russian text in headers becomes totally unreadable. Moreover, placing Russian text to the headers without proper encoding is the very common practice here and we have to abide the circumstances.
IMO Internet in general is now 8-bit and I'm not sure that contemporary MTA should be so stick to the archaic ARPANET 7-bit world. Of course you can rise the objection that RFCs states otherwise but (I understand that I'm falling into heresy) RFCs themselves are subject to change.
In fact as shows our many years experience existence of 8-bit characters (at least with codes from 0x80 to 0xff) anywhere in the mail message (including headers) never break any transparent mail service (e.g. sendmail, UW IMAP and many others). Courier itself is actually 8bit-tolerant enough. The only trouble these characters could cause - unreadability of message by recipient's client - as you absolutely correctly mentioned could be solved by common efforts of sender and recipient.
Courier wants to make shure that everything is in accordance with RFC2045 and does a real great job with this as a (smart) relay for sending out mail, but I must be able to receive mail if its only a common, easy 'fixable' violation of the RFC.
As a postmaster I would be happy if Courier could properly rewrite 8-bit headers of messages it sending from local network to the Internet (e.g. based on default charset specified in sqwebmail configuration) assuming that message body is always 8bit and accept all messages from outside applying some kind of configurable filters to the messages which are now being simply bounced (it concerns not only to "RFC" bounces but to all other kinds of them, including "User unknown"). Doing so it would be the smartest MTA in the world.
Sorry for such a long posting, but these issues are very close to my heart.
Alexei.