Professional Web Applications Themes

Force mutt to encode - SCO

Is there anyway to force mutt to base64 encode an attachment even if it thinks it doesn't need to? Thanks, Fabio ----------------------------------------- Fabio Giannotti (mailto:com) Phone: 314-428-2266 x214 Venmar Systems, Inc. 10803 Indian Head Industrial Blvd. St. Louis, MO 63132 Web: http://www.venmar.com Phone: 314-428-2266 Fax: 314-428-4747...

  1. #1

    Default Force mutt to encode



    Is there anyway to force mutt to base64 encode an attachment even if it
    thinks it doesn't need to?

    Thanks,
    Fabio


    -----------------------------------------
    Fabio Giannotti (mailto:com)
    Phone: 314-428-2266 x214

    Venmar Systems, Inc.
    10803 Indian Head Industrial Blvd.
    St. Louis, MO 63132
    Web: http://www.venmar.com
    Phone: 314-428-2266
    Fax: 314-428-4747

    Fabio Guest

  2. #2

    Default Re: Force mutt to encode

    Fabio Giannotti typed (on Sat, Nov 01, 2003 at 06:14:43PM +0000):
    |
    | Is there anyway to force mutt to base64 encode an attachment even if it
    | thinks it doesn't need to?

    Not that I can see. But ask on the mutt mailing lists.

    --
    JP
    Jean-Pierre Guest

  3. #3

    Default Re: Force mutt to encode

    Fabio Giannotti wrote:
     

    A default binding on the "compose" menu is:

    ^E edit-encoding edit attachment transfer-encoding
     
    Bela Guest

  4. #4

    Default RE: Force mutt to encode


     
    > attachment even if it 
    >
    > A default binding on the "compose" menu is:
    >
    > ^E edit-encoding edit attachment transfer-encoding
    > [/ref]

    Bela,

    Thanks for the response. Unfortunately, my question was not worded well. I
    should have added "from the command line" to it!

    That is, is there any way from the command line to force mutt to encode an
    attachment.

    If anyone is interested, I have found a bit of a problem with mutt. It
    decides that PDF files should be sent with a transfer encoding of
    quoted-printable instead of base64.

    If someone using Outlook or OE receives the attachment, they can view it
    from within the mail message. However, if they try to save it or forward
    it, the MS app is so nice as to add a ^M for them at the end of every line,
    thus corrupting the PDF.

    Thanks,
    Fabio

    Fabio Guest

  5. #5

    Default Re: Force mutt to encode

    Fabio Giannotti typed (on Sat, Nov 01, 2003 at 09:52:30PM +0000):
    | > From: on.ca [mailto:on.ca]On Behalf Of Bela Lubkin
    | > Fabio Giannotti wrote:
    | >
    | > > Is there anyway to force mutt to base64 encode an
    | > attachment even if it
    | > > thinks it doesn't need to?
    | >
    | > A default binding on the "compose" menu is:
    | >
    | > ^E edit-encoding edit attachment transfer-encoding
    |
    | Thanks for the response. Unfortunately, my question was not worded well. I
    | should have added "from the command line" to it!
    |
    | That is, is there any way from the command line to force mutt to encode an
    | attachment.
    |
    | If anyone is interested, I have found a bit of a problem with mutt. It
    | decides that PDF files should be sent with a transfer encoding of
    | quoted-printable instead of base64.

    Have you a ~/.mime.types files, or a system-wide one, which contains:

    application/pdf pdf

    ?

    See para. 5.2 of the Mutt help file for the possible paths to a
    system-wide mime.types file.

    --
    JP
    Jean-Pierre Guest

  6. #6

    Default RE: Force mutt to encode

     
    Yes, I have a mime.types file, and the attachement is correctly being
    identified as a PDF. The problem is that mutt has decided that PDFs should
    be quote-printable, not base64.

    Apparently, this is a well know mutt issue. However, the mutt folk have
    taken the stance that MS is mis-handling MIME attachments, and so it's an MS
    bug, not a mutt problem at all. There suggestion was to get MS to fix it's
    products. While I see their point, I don't think I'm going to have much
    luck getting MS to fix the problem, then get the hundreds of
    thousands/millions of Outlook/OE users to patch their readers. The sad fact
    is that a very large majority of non-technical users use MS mail readers,
    and this makes mutt pretty much unusable if you are trying to send PDFs.

    Ah well, time to search for another solution.

    Thanks,
    Fabio

    Fabio Guest

  7. #7

    Default Re: Force mutt to encode

    Fabio Giannotti typed (on Mon, Nov 03, 2003 at 02:47:56PM +0000):
    |
    | > From: on.ca [mailto:on.ca]On
    | > Behalf Of Jean-Pierre Radley
    | > Sent: Saturday, November 01, 2003 5:26 PM
    | > To: on.ca; com
    | > Subject: Re: Force mutt to encode
    | >
    | > Fabio Giannotti typed (on Sat, Nov 01, 2003 at 09:52:30PM +0000):
    | > | > From: on.ca
    | > [mailto:on.ca]On Behalf Of Bela Lubkin
    | > | > Fabio Giannotti wrote:
    | > | >
    | > | > > Is there anyway to force mutt to base64 encode an
    | > | > attachment even if it
    | > | > > thinks it doesn't need to?
    | > | >
    | > | > A default binding on the "compose" menu is:
    | > | >
    | > | > ^E edit-encoding edit attachment transfer-encoding
    | > |
    | > | Thanks for the response. Unfortunately, my question was
    | > not worded well. I
    | > | should have added "from the command line" to it!
    | > |
    | > | That is, is there any way from the command line to force
    | > mutt to encode an
    | > | attachment.
    | > |
    | > | If anyone is interested, I have found a bit of a problem
    | > with mutt. It
    | > | decides that PDF files should be sent with a transfer encoding of
    | > | quoted-printable instead of base64.
    | >
    | > Have you a ~/.mime.types files, or a system-wide one, which contains:
    | >
    | > application/pdf pdf
    | >
    | > ?
    | >
    | > See para. 5.2 of the Mutt help file for the possible paths to a
    | > system-wide mime.types file.
    | >
    | Yes, I have a mime.types file, and the attachement is correctly being
    | identified as a PDF. The problem is that mutt has decided that PDFs should
    | be quote-printable, not base64.

    Not here. I just sent myself a pdf file, and I clearly see:

    [-- Attachment #2: univ.pdf --]
    [-- Type: application/pdf, Encoding: base64, Size: 343K --]
    Content-Type: application/pdf
    Content-Disposition: attachment; filename="univ.pdf"
    Content-Transfer-Encoding: base64

    FWIW, I'm using Mutt 1.5.4i.

    | Apparently, this is a well know mutt issue. However, the mutt folk have
    | taken the stance that MS is mis-handling MIME attachments, and so it's an MS
    | bug, not a mutt problem at all. There suggestion was to get MS to fix it's
    | products. While I see their point, I don't think I'm going to have much
    | luck getting MS to fix the problem, then get the hundreds of
    | thousands/millions of Outlook/OE users to patch their readers. The sad fact
    | is that a very large majority of non-technical users use MS mail readers,
    | and this makes mutt pretty much unusable if you are trying to send PDFs.
    |
    | Ah well, time to search for another solution.
    |
    | Thanks,
    | Fabio

    --
    JP
    Jean-Pierre Guest

  8. #8

    Default Re: Force mutt to encode

    Jean-Pierre Radley <com> wrote in message news:<jpr.com>... 

    Ok, I've made a somewhat interesting discovery and thought I'd share
    it with the group.

    It seems that mutt guesses PDFs to be either base64 or
    quoted-printable depending on what it sees in the file.

    PDFs I create with ImageMagick all show up as quoted-printable, PDFs
    created with Adobe all get base64 encoded. Weird huh?

    In addtion to mutt problems, PDFs created with ImageMagick get garbled
    by Outlook and OE when forwarding even if they were manually base64
    encoded.

    That is, I changed the mutt source code to base64 encode everything,
    and then sent the IM PDF to myself. Got it fine, it was base64
    encoded. When I forwarded it using Outlook, Outlook un-base64 encoded
    it, garbled it, then sent it.

    So, I'm off to try the latest version of IM to see if it creates PDFs
    any differently.

    Fabio
    Fabio Guest

  9. #9

    Default Re: Force mutt to encode

    In article <google.com>,
    Fabio Giannotti <com> wrote: [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]
     [/ref]

    [I think I got the attribs right as at least one mailer wrapped
    weirdly - wjv]
     
     

    Guesses?

    What does 'file' show on the differing files.
    I don't know if mutt used the 'magic' files but I would think
    any well-behaved application would do so.

     

    And what does the first line of those files indicate.

    You should see PDF-1.2 or PDF-1.3 followed by others.
    Do the ImageMagick files look the same.
     

    Fits with the above.

    Just idle thoughts.

    Bill

    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  10. #10

    Default RE: Force mutt to encode


     
    > news:<jpr.com>... [/ref]
    > [mailto:on.ca]On [/ref]
    > 09:52:30PM +0000): [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > transfer-encoding
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    > [/ref]
    >
    > [I think I got the attribs right as at least one mailer wrapped
    > weirdly - wjv]


    >
    > Guesses?[/ref]

    Yes, it guesses. As far as I can tell, it tries to determine if the
    encoding is base64 or quoted-printable based on some algorithm that looks at
    the data in the file. It is correctly identifying both files as PDFs. (The
    mime header for each is "application/pdf".
     

    "file" on both shows them to be a PDF. MIME header on both show it to be
    "application/pdf".
     
    >
    > And what does the first line of those files indicate.
    >
    >
    > You should see PDF-1.2 or PDF-1.3 followed by others.
    > Do the ImageMagick files look the same.
    >[/ref]

    First line of both is %PDF-1.2

     
    > get garbled 
    >
    > Fits with the above.[/ref]

    Yup, apparently Mutt and Outlook are using a similar algorithm.
    Unfortunately, Outlook decides to mess with the contents instead of just
    leaving them alone like mutt does!
     

    Again, I say "Weird, huh?"

    Fabio

    Fabio Guest

  11. #11

    Default Re: Force mutt to encode

    In article <001101c3a3c9$116cc1c0$com>,
    Fabio Giannotti <com> wrote: 
    >> news:<jpr.com>... 
    >> [mailto:on.ca]On 
    >> 09:52:30PM +0000): 
    >> 
    >> 
    >> 
    >> transfer-encoding
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >>
    >> [I think I got the attribs right as at least one mailer wrapped
    >> weirdly - wjv]
    >> [/ref][/ref]
     [/ref][/ref]
     [/ref]
     

    That's not good.

     [/ref]
     
     [/ref][/ref]
     [/ref]

     [/ref]
     

    Shoots down that thought I had.

    Perhaps going to www.mutt.org might point you to something, or a
    link to someone who can answer this. Or comp.mail.mutt
     

    Another reason I tend to dislike and distrust MS products.
     

    Yup.

    Bill


    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  12. #12

    Default Re: Force mutt to encode

    Bill Vermillion wrote:
     
     [/ref]
    > [/ref]

    >
    > That's not good.[/ref]

    Actually it's fine. lookOut isn't having trouble with the encoding,
    it's garbling the contents. Fabio already said that even when he forced
    Mutt to use base64, the same garbling occurred.

    Mutt isn't _guessing_, it's _choosing_. A mailer chooses an encoding
    based on what standards it supports, and which encoding is most
    efficient for the particular thing being sent. An encoding of "7bit" is
    most efficient for pure ASCII text; "quoted-printable" is most efficient
    for nearly pure ASCII text with a few high bit characters; "base64" is
    most efficient for binary gibberish. As long as the _contents_ of the
    message come through cleanly, which encoding was used should make no
    difference to the receiving mailer. Which is exactly what Fabio's
    testing showed.
     [/ref][/ref]

    I suggest copying one each of these files to Windows using some
    completely different method (scp or ftp) and seeing whether they display
    correctly. Then mailing them somewhere else using lookOut and again
    testing whether they get garbled by that. It sounds more like lookOut
    just simply garbles ImageMagick PDFs, for unknown reasons. Nothing to
    do with Mutt.
     
    Bela Guest

Similar Threads

  1. mutt-ng
    By Claude in forum Ubuntu
    Replies: 2
    Last Post: September 14th, 03:12 PM
  2. Encode::Arabic, Encode::Korean and Encode::Mapper
    By Otakar Smrz in forum PERL Modules
    Replies: 0
    Last Post: August 26th, 01:39 PM
  3. Mutt and locale
    By Lonnie Sutton in forum Debian
    Replies: 2
    Last Post: August 1st, 01:50 AM
  4. Encode or not to encode, that is the question
    By fartsniff in forum PHP Development
    Replies: 1
    Last Post: July 14th, 12:15 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139