On Fri, 12 Aug 2011 15:53:31 +0300, Alexander Gattin wrote: > 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 >> *** > > ?
Yes, that was extracted from two e-mail messages I sent. The former is encoded okay and the latter is the one the user has problems when tries to reconstruct the original file. I have to manually resend the original splitted file so he can proceed with no errors. > And in your local ~/sent file they are all > application/octet-stream/base64? I drop the files under a folder in my /home/user/Desktop. Once I run the "split" command, files in there (i.e., test0001, test0002, test0003, file0004, file0005...) are like this: sm01@stt008:~$ file Desktop/enviar/test0001 Desktop/enviar/test0001: data The problem comes when I send that files via e-mail. I have configured Mutt to directly contact Gmail smtp server (smtp_url = "smtp:// u...@smtp.gmail.com:587/"), so I have no local "~/sent" folder, sent messages are stored remotely, in Gmail's servers. >> 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? I think it should set all of the mime parts of the message :-? In fact, there are only a few e-mails that fail, the rest are encoded fine. > 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. That was another thing I was thinking about: using PGP/GPG and sign the messages to force encoding and will be the next to try if I still encounter problems when sending the attachments. Greetings, -- Camaleón
