At 15:49 +0100 05 Dec 2000, Anand Buddhdev <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 05, 2000 at 08:31:43AM -0500, Sam Varshavchik wrote:
> > Note that the second MIME section does not specify its content transfer
> > encoding. Neither is the default transfer encoding specified in the top
> > level MIME header. As I mentioned, if a MIME section that does explicitly
> > specify its transfer encoding, Courier will calculate one.
The default transfer encoding is never specified in the top level
header, it's specified in RFC (2045, section 6.1):
"Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
Please point out where it is stated that the top level encoding is
supposed to be the default for lower levels? The only mentions of a
default encoding that I can find in either RFC 2045 or 2046 is the one
quoted below and a couple in 2046 about the message/partial and
message/external-body types which also state that 7BIT is the default.
> So the problem boils down to the MUA not generating full and correct MIME
> headers. In this case, mutt isn't inserting all the headers that courier
> expects (it assumes that the relevant information will be infered according
> to RFC 1847). I suppose mutt's interpretation of the RFC is understandable.
Mutt's MIME headers *are* correct and as full as necessary. I don't see
any reason (other than broken software) for mutt to explicitly state
that a default value is to be used. So as far as can see mutt's
interpretation is not only understandable, it is correct.
> of the MUA. Do you have any suggestions for alternative mail clients that
> have better MIME support? Alternatively, do the mutt users have any ideas
> on making mutt generate the headers as Sam suggests?
I'm not aware of mail clients with better MIME support (other than
possibly having builtin support for more types). I don't think it's
really even possible, since mutt's support is excellent.
But, I suppose you could use the attached patch to work around courier's
bad behaviour, it will cause mutt to always generate a
Content-Transfer-Encoding header for multipart/signed messages. The
same shouldn't be necessary for multipart/encrypted, since the relevant
headers are encrypted and therefore safe from courier. This patch is
against the CVS version, but I expect it will work for pretty much any
version.
--
Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/
Life is like sendmail: It's complicated and hard to understand,
but it sure beats the alternative. -- Paul Tomblin
--- sendlib.c.dist Tue Dec 5 12:31:21 2000
+++ sendlib.c Tue Dec 5 14:32:25 2000
@@ -433,7 +433,10 @@
fputc ('\n', f);
- if (a->encoding != ENC7BIT)
+ /* Courier MTA will rewrite messages that don't contain an explicit
+ * Content-Transfer-Encoding, breaking PGP/MIME signatures. */
+ if (a->encoding != ENC7BIT
+ || (a->type == TYPEMULTIPART && mutt_strcmp(a->subtype, "signed") == 0) )
fprintf(f, "Content-Transfer-Encoding: %s\n", ENCODING (a->encoding));
/* Do NOT add the terminator here!!! */
