On Mon, Jan 24, 2000 at 12:18:50PM -0500, Brolley, Michael wrote:
>
> I would like for mutt to do the same for outgoing mail, but when mutt sends
> out an email with an attachment, let's say the same spreadsheet file, I get:
>
> --EVF5PPMfhYS0aIcm
> Content-Type: text/plain; charset=us-ascii
>
> Let mutt try sending out an attachment
>
> --EVF5PPMfhYS0aIcm
> Content-Type: application/excel
> Content-Disposition: attachment; filename="Timesheet-01-14-00.xls"
> Content-Transfer-Encoding: base64
>
> 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAA
> AAAAEAAA/v///wAAAAD+////AAAAACUAAAD/////////////////////////////////////
> ////////////////////////////////////////////////////////////////////////
>
> ...
>
> This is not good because I cannot extract this attached file back into its
> original form.
>
> How do I configure mutt to send out email attachments the way Exchange,
> Netscape, Eudora, and countless other MUA's do?
Mike,
It generally helps if you tell the version of mutt you are using. In this
case I have seen similar issues and should be able to explain. If I am wrong
many people will tell me.
The problem is that Exchange, Eudora, Netscape and countless other MUA's do
not interpret the MIME boundary correctly. Most of them took a shortcut and
decided that all boundaries (the --EVF5PPMfhYS0aIcm above) should be quoted.
Mutt correctly knows that boundaries containing only alphanumerics do not
need to be quoted and often constructs MIME boundaries of characters not
needing to be quoted. Since MS and much of the world does not respect the
appropriate RFCs here, mutt attachments of certain versions appear broken.
The only current workaround for mutt users is to upgrade to version 1.1.1 or
1.1.2 from the development branch which deliberately constructs quoted
boundaries.
/Duncan
--
Duncan Watson ||| Smith Rock Hit List - Pumpkin Patch 5.5, Northern
Unix Sysadmin at Large ||| Point - Basalt Rimrock
[EMAIL PROTECTED] |||
Portland, OR |||
PGP signature
