Kris Kelley writes:
Alexei Batyr' wrote:
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.
Actually, the usual argument is that if you start sending blind 8-bit
without proper MIME encoding, you lose other vital information, including
what character set to use. Since there is no single all-encompassing 8-bit
character set, MIME encoding is essential in letting the email client know
how to display 8-bit messages. For example, if a person in Russia sends
8-bit characters without MIME encoding to somebody in Korea, the email
client in Korea will render the 8-bit characters using its local character
set instead of the Russian set, potentially making the message unreadable.
To which the answer would be "but at least I can read the messages that my
buggy mail client *can* make sense of."
I wonder if the following would be acceptable to Sam.
* As an option to configure,
* mailserver will accept messages without a required mime header.
* mailserver will forward message to desired destination.
* mailserver will send phoney "bounce" message to sender, containing
details of why.
Then, people who need to be able to accept faulty 8-bit messages can do so,
people who don't want them (perhaps because the local character set doesn't
need the extra characters) can continue to bounce them, and people who send
non-RFC-compliant messages will find their mailbox filling up with nagging
messages telling them to get their client fixed, and why it is important.
16 messages in net.sourceforge.lists.courier-users[courier-users] Re: 8bit Again
