Re: [Advice needed] Best way to handle attachments?
Hello, On Thu, Aug 11, 2011 at 03:30:56PM +, Camaleón wrote: All the process works fine but some of the files are wrongly encoded which results in an error when the user tries to reconstruct the big file from the received attachments. becaue you split archive, pieces start with random data and e.g. 'file' utility may detect data type wrongly. I don't know how mutt performs data type autodetection, but if it involves the 'file' utility, you may want to try substituting system 'file' with your own shellscript, which always returns something like 'xxx: data' and resides in e.g. ~/bin directory. Then you could run mutt prefixed by PATH=$HOME/bin:$PATH to override system 'file' and force uniform type for al attachments. -- With best regards, xrgtn
Re: [Advice needed] Best way to handle attachments?
On Thu, 11 Aug 2011 13:20:51 -0400, Chris Brennan wrote: On 8/11/2011 1:14 PM, Camaleón wrote: On Thu, 11 Aug 2011 12:33:09 -0400, Chris Brennan wrote: zip -s SIZE should do the trick ... split the archive at your designated size at creation, not after the fact, that might be where zipsplit/zsplit is dropping the ball Thanks but I don't see -s as an available parameter for my zip (2.32) :- (. Anyway, if I try it: *** sm01@stt008:~/Desktop$ zip -s 512000 data *.pdf zip error: Invalid command arguments (no such option: s) *** From my Debian 6-stable box, I have the following (line 152 of the grep is where I got -s from) (...) 152: -s ssize create split archive with splits of size ssize, where ssize nm (...) I see, I'm running lenny here ;-( Anyway, I'm testing with the rest of the proposals and it seems (at least after running a small set of tests) that compressing the resulting files after they're splitted is doing the trick. Annoying and time consuming but at least the attachments (.zip) are being encoded in the right manner. Greetings, -- Camaleón
Re: [Advice needed] Best way to handle attachments?
On Fri, 12 Aug 2011 10:03:09 +0300, Alexander Gattin wrote: Hello, On Thu, Aug 11, 2011 at 03:30:56PM +, Camaleón wrote: All the process works fine but some of the files are wrongly encoded which results in an error when the user tries to reconstruct the big file from the received attachments. becaue you split archive, pieces start with random data and e.g. 'file' utility may detect data type wrongly. I don't know how mutt performs data type autodetection, but if it involves the 'file' utility, you may want to try substituting system 'file' with your own shellscript, which always returns something like 'xxx: data' and resides in e.g. ~/bin directory. Then you could run mutt prefixed by PATH=$HOME/bin:$PATH to override system 'file' and force uniform type for al attachments. 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 :-? Besides, enforcing Mutt to use set content_type=application/ octet-stream is not respected and I really doubt this is up to Mutt which seems to do it right but something that happens on the remote e- mail server that breaks the files. Greetings, -- Camaleón
Re: [Advice needed] Best way to handle attachments?
Hello, On Fri, Aug 12, 2011 at 12:01:12PM +, 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 +, 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
Re: [Advice needed] Best way to handle attachments?
On Fri, 12 Aug 2011 15:53:31 +0300, Alexander Gattin wrote: Hello, On Fri, Aug 12, 2011 at 12:01:12PM +, 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 +, 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
