Talk:8BITMIME

This is the talk page for discussing improvements to the 8BITMIME redirect.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Untitled

Prior to the availability of 8BITMIME implementations, mail user agents employed several techniques to cope with the seven-bit limitation, including binary to text encodings and UTF-7.

Following the given RFC's, UTF-7 was standardized at the same time (July 1994) as 8BITMIME, therefore UTF-7 cannot be used before 8BITMIME, as I would say. --Abdull 14:48, 1 January 2006 (UTC)[reply]

I think one would have to figure out when 8BITMIME implementations became available (and UTF-7 implementations, for that matter), and not just when the standards were published… —Fleminra 20:06, 1 January 2006 (UTC)[reply]

If exim has the same level of 8bitmime support when enabled with a single line in the config file as qmail does, why is it listed under "non-supporting" clients instead of the "supporting" section above? That seems wrong. —The preceding unsigned comment was added by 71.113.119.162 (talk • contribs) 08:45, April 12, 2006.

The documentation shipped with Exim 3.36-18 for Debian says:

accept_8bitmime                 Type: boolean                  Default: false

    This option causes Exim to send 8BITMIME in its response to an SMTP EHLO
    command, and to accept the BODY= parameter on MAIL commands. However,
    though Exim is 8-bit clean, it is not a protocol converter, and it takes
    no steps to do anything special with messages received by this route.
    Consequently, this option is turned off by default.

Which seems to mean that Exim does not implement 8BITMIME. This could be outdated though… —Fleminra 18:39, 12 April 2006 (UTC)[reply]

exmi and qmail not conforming?

Could anybody pin down the statement made in the article? I find the following in RFC1652:

If a server SMTP does not support the 8-bit MIME transport extension (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value 8BITMIME in its response), then the client SMTP must not, under any circumstances, attempt to transfer a content which contains characters outside the US-ASCII octet range (hex 00-7F).

A client SMTP has two options in this case: first, it may implement a gateway transformation to convert the message into valid 7bit MIME, or second, or may treat this as a permanent error and handle it in the usual manner for delivery failures.

Thus not being able to translate an accepted 8bit message to a non-8bit next hop does not imply lack of conformance, right? Where in RFC1652 do you find the contrary as claimed in the text?195.227.74.194 (talk) 08:51, 28 February 2008 (UTC)[reply]

It's been a while since I wrote it, but I suppose the determination of conformance would depend on how qmail and EXIM behave when attempting to relay an 8-bit message to a non-8BITMIME peer. Do they detect that the peer is non-8BITMIME, and properly report a delivery error, or do they just pass the 8-bit message along? FWIW, presently the article doesn't use the word "non-conformance," which would imply a defect. I guess you could say that they choose to not implement this certain feature described the spec. —Fleminra (talk) 19:39, 28 February 2008 (UTC)[reply]