On Tue, Dec 05, 2000 at 08:31:43AM -0500, Sam Varshavchik wrote:
Hi Sam,
Thank you very much for this detailed answer. I now understand what the
problem is. I just concluded a test, where I manually inserted a
Content-Transfer-Encoding: header into the main headers of the mail, and
used only 7bit content throughout. Indeed, courier did not touch the
message, and it came through just fine, and also verified correctly.
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.
Anyway, the result is that a user has to go to extra effort to make sure
that PGP/MIME messages are correctly encoded, to avoid changes along the
way. I just don't want to go to such extra effort every time. It's hard to
remember and make sure the headers are correct everytime - that's the job
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?
> Here are just the MIME headers from your test message:
>
> Mime-Version: 1.0
> Content-Type: multipart/signed; micalg=pgp-md5;
> protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE"
> Content-Disposition: inline
>
>
> Here's the first MIME section:
>
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Here's the second MIME section:
>
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
>
> 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.
>
> I believe that if you had a "Content-Transfer-Encoding: 7bit" *either* in
> the top level MIME headers, which will set a default for the whole
> message, or in the application/pgp-signature MIME section, Courier will
> not rewrite it.
>
> If you notice, when Courier rewrites the message, it regenerates all the
> MIME headers. The top level MIME headers will set a default
> "Content-Transfer-Encoding: 7bit", header. Because that's also the
> encoding for the second MIME section, it doesn't have to specify it
> explicitly. Basically, the message is rewritten and the MIME headers are
> regenerated. It just so happens that when the headers are regenerated,
> the order of the headers in the second MIME section is reversed.
>
> But, having "Content-Transfer-Encoding: 7bit" specified either in the
> top level MIME header, or in the application/pgp-signature MIME section
> would avoid the need to provide a default encoding.
--
Anand
