Hello, On Fri, Aug 12, 2011 at 12:01:12PM +0000, Camaleón wrote: > What puzzles me is that raw splitted files > stored in my disk all look the same. I mean, > "file" returns the same information for all of > them but then, when I review my Gmail's sent > folder I see 3 or 4 of the attachments were bad > encoded while the rest (20 or 25) are fine :-?
So this is how attachments look on the receiving end: On Thu, Aug 11, 2011 at 03:30:56PM +0000, Camaleón wrote: > For instance, I've noted that properly encoded > attachments appear as follows: > > *** > Content-Type: application/octet-stream > Content-Disposition: attachment; filename=test0014 > Content-Transfer-Encoding: base64 > *** > > And bad ones are like this: > > *** > Content-Type: text/plain; charset=utf-8 > Content-Disposition: attachment; filename=test0015 > Content-Transfer-Encoding: quoted-printable > *** ? And in your local ~/sent file they are all application/octet-stream/base64? > So I tried to deal with this in two ways: > > 1. Enforcing Mutt to use "Content-Type: > application/octet-stream" when I call it using > the script (that is, "mutt -e 'set > content_type=application/ octet-stream' [...]) > > This works (I can see the body of the messages > are encoded in that way) but there are still > some messages that encode the attachments as > "text/ plain". Probably this sets encoding for the message text, not for attachments? In past gmail refused to deliver mails with executable attachments (I don't remember did it contain viruses or not), and it even looked inside archives and it even autodetected archives with spoofed filename extensions (probably gmail do run some sortg of home-brewn 'file' utility on all attachments regardless of their extensions and/or content-type's). I was forced to use openssl enc -aes to get my message pass through gmail. -- With best regards, xrgtn
