waldo kitty wrote

On 12/15/2013 3:06 PM, Johannes W. Dietrich wrote:

.
.

As already suggested by Jonas, responding to fpc-other.

Sorry, but I believe that you should indeed check the respective RFCs first (and possibly also search some information about what mail servers may do when receiving an e-mail with message encoding not supported by their configuration in order to understand what may cause differences with different recipients).

In any case:

1) RFC 2045 states that 7-bit "encoding" (i.e. no encoding necessary due to using only lower part of ASCII table aka us-ascii character set) is the default assumed if no other information about content encoding is provided (i.e. encoding the message using base64 without specifying this explicitly is invalid and any client doing this based on some heuristic methods of guessing the encoding would be breaking the RFC defined behaviour).

2) As also mentioned in the RFC mentioned above, the SMTP message format (RFC 821) requires all messages to be in us-ascii. Many e-mail clients provide possibility to allow 8-bit messages in their configuration (and some others might even do it silently by default). Even worse, some e-mail clients allow including non-encoded characters outside of us-ascii without signalizing that the encoding is in fact 8-bit (i.e. not conforming to the original SMTP message format). However, anybody allowing these 8-bit characters without encoding outside his own controlled environment (e.g. within a company) is in a risk that any of SMTP servers encountering such messages might enforce the strict rules of RFC 821 format and encode the message differently according to their own selection. This means that different recipients may receive the same message in different format. Obviously, proper headers should be added during this encoding - Jonas suggested that this might have worked wrongly in this case.

Tomas

In any event, this isn't really an issue about MIME types etc. The real issue is that if somebody wants to get an announcement (or an urgent request for help, or an urgent reply, or in fact /anything/) read by the maximum number of people, then it's good practice to use plain text and to leave off any attachments etc. that could possibly be misinterpreted or cause the entire message to be misrouted as spam.

The upside of the Internet is that there's a vast number of supported data formats and protocols. The downside is that there's a vast number of RFCs and informal conventions describing them. On occasion, for everybody's sake, it's best to keep things as simple as possible.

While I agree to your statement personally (regardless of my own experience from a corporate environment ;-) - see below), the issue discussed here may be triggered with plain text messages without any attachments very easily (especially for posters coming from areas where us-ascii is simply not enough) - one accented character (e.g. German "umlaut" / diaeresis) in name or organization (e.g. included in e-mail signature) may be sufficient (if "supported" by the e-mail client configuration as described in my previous post).

Now the promised bit regarding the corporate environment - some time ago, I was requested by a colleague not to use plain text mails by default because they were difficult to read (potentially causing recipients not to read them fully). It turned out that his view was primarily influenced by the default configuration of MS Outlook using font Courier for displaying plain text messages and that font being less readable than some others due to its non-proportional nature. Not even mentioning that not using top-posting also results in some people not reading responses because they do not realize the need to scroll to the bottom (obviously, this is also supported by the treatment of such messages in MS Outlook). :-( OK, let's get back to the slightly more educated Internet environment. ;-)

Tomas