Sam Varshavchik wrote:
>> Why did Courier attempt to alter the attachment encoding in the first place?
>> ("X-Mime-Autoconverted: from x-uuencode to 7bit by courier 0.42")
>
> Because ?x-uuencode? is not a valid MIME transfer encoding, as defined by
> RFC 2045.
>
>> Also, if it claims it "Autoconverted from x-uuencode to 7bit", why did
>> the rest of the attachment remain untouched, i.e. it's still there as
>> a uuencoded section? No actual conversion took place ...
>
> Because x-uuencode is not a valid transfer encoding. As such, analysis of
> MIME content determined that it only contains 7-bit data, so it is labeled
> as such.
>
>> How can I fix/stop this from happening? This is a real show-stopper for me.
>
> Have the sender reconfigure his mail program to generate a MIME-compliant
> message format.
Well, the problem here is that there are multiple "senders", not just one.
And some of the "senders" are from people external to my work.
More to the point, though, why the particularly an*l interpretation of
RFC 2045?
Section 6.3 of RFC 2045 states
"6.3 New Content-Transfer-Encodings
Implementors may, if necessary, define private Content-Transfer-Encoding
values, but must use an x-token, which is a name prefixed by "X-", to
indicate its non-standard status, e.g.,
"Content-Transfer-Encoding: x-my-new-encoding". Additional standardized
Content-Transfer-Encoding values must be specified by a standards-track RFC.
The requirements such specifications must meet are given in RFC 2048.
As such, all content-transfer-encoding namespace except that beginning with
"X-" is explicitly reserved to the IETF for future use."
For example, Mabry's MIME/X product mentions the following on this page:
http://www.mabry.com/mimex/part%20object%20contenttransferencoding%20property.h
tm
"The MIME standard also allows extensions to the ContentTransferEncoding
header. Such extensions are specified with the prefix 'x-'. For instance,
x-uuencode is often used to indicate UUencoding. Message parts with
ContentTransferEncoding x-uuencode and mac-binhex40 are sometimes received.
The mail control supports decoding and encoding message parts using these
formats in addition to the standard MIME encoding formats listed above."
Seems like a reasonable policy to me ...
Given the prevalence of "x-uuencode" and "mac-binhex40" encodings (the
latest version of Eudora 6 presents both of these as acceptable choices
for attachment encoding, for example), what about the notion of a
"BOFHBADMIMEENCODING" (perhaps tied to a "RFC2045_ERRBADENCODING"
flag) that would permit the pass-through (i.e., no rewrite) of these
particular Content-Transfer-Encoding types (perhaps user-defined) without
doing the X-Mime-Autoconverted conversion step?
I want to use this software, and I want my users to use this software.
But if people start telling me "Attachments from some people don't work"
(when they "used to work on the old POP server"), and it's a matter of
trying to change dozens of Eudora/Outlook Express users (not to mention
the ones that are external to my work that send my users files with
x-uuencode or mac-binhex40 encoded attachments) or changing the software,
I have little choice but to want to change the software. (Then again, the
old Jon Postel koan - see RFC 1122, Section 1.2.2 - about "Be liberal in
what you accept, and conservative in what you send [out]" always seemed
like a good idea to me.)
- Greg
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
