Re: file corruption after transmission over email
On Sun, May 29, 2022 at 01:15:51PM -0300, Marcelo Laia wrote: tee >(lbdb-fetchaddr -a)|/usr/bin/msmtp -a gmail $@ Perhaps lbdb-fetchaddr is closing input before the end of the message, and tee is exiting on a SIGPIPE? Mutt 2.2 had a fix to properly reset signals (specifically SIGPIPE) on exec(). Child processes previously inherited Mutt's ignore setting, but this caused other incorrect behavior. Maybe adding '--output-error=exit-nopipe' to the tee command will help? Alternatively maybe capture stdin to a temp file and the perform the lbdb-fetchaddr msmtp separately? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: file corruption after transmission over email
On 2022/06/01 12:17, Marcelo Laia wrote: tee >(lbdb-fetchaddr -a)|/usr/bin/msmtp -a gmail $@ ... 1. http://www.jukie.net/bart/blog/lbdb-and-mutt Ah, bash's "process substitution". I forgot about that.
Re: file corruption after transmission over email
* Marcelo Laia [06-01-22 12:17]: > On 29/05/22 at 12:49, Kurt Hackenberg wrote: > > On 2022/05/29 12:15, Marcelo Laia wrote: > > > > > If I send a message using > > > > > > tee >(lbdb-fetchaddr -a)|/usr/bin/msmtp -a gmail $@ > > > > > > the attached file with embedded image got corrupted > > > > What is that line intended to do? > > Hi Kurt! > > I'm so sorry for don't had been do a complete explanation about that. > Sorry! > > Here [1] is a configuration that could bee explanation how to use LBDB > with mutt and msmtp. > > In this mean time, I migrate to abook and all work nice, now. > > I use abook in this way: > > set query_command = "abook --mutt-query '%s'" > set display_filter = "pee 'abook --add-email-quiet' 'cat -'" # all > opened messages have senders address added to abook database. > > I uninstalled lbdb from my machine. why uninstall lbdb? you can query it directly, ie: lbdbq Marcelo\ Laia lbdbq: 1 matches marcelol...@gmail.com Marcelo Laia then only add addresses to abook that you really need. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Re: file corruption after transmission over email
On 29/05/22 at 12:49, Kurt Hackenberg wrote: > On 2022/05/29 12:15, Marcelo Laia wrote: > > > If I send a message using > > > > tee >(lbdb-fetchaddr -a)|/usr/bin/msmtp -a gmail $@ > > > > the attached file with embedded image got corrupted > > What is that line intended to do? Hi Kurt! I'm so sorry for don't had been do a complete explanation about that. Sorry! Here [1] is a configuration that could bee explanation how to use LBDB with mutt and msmtp. In this mean time, I migrate to abook and all work nice, now. I use abook in this way: set query_command = "abook --mutt-query '%s'" set display_filter = "pee 'abook --add-email-quiet' 'cat -'" # all opened messages have senders address added to abook database. I uninstalled lbdb from my machine. Thanks! 1. http://www.jukie.net/bart/blog/lbdb-and-mutt -- Marcelo
Re: file corruption after transmission over email
On 2022/05/29 12:15, Marcelo Laia wrote: If I send a message using tee >(lbdb-fetchaddr -a)|/usr/bin/msmtp -a gmail $@ the attached file with embedded image got corrupted What is that line intended to do? Is the message intended to be on tee's standard input? If so, how does it get there? That line redirects tee's standard output to -- where? What will go through the pipe to msmtp? What is lbdb-fetchaddr? Putting it in () runs it in a subshell; that does not return a string. If you're trying to pass the message to be sent through tee (standard input to standard output), through a pipe to the standard input of msmtp, I don't think that command does that.
Re: file corruption after transmission over email
On 22/05/22 at 03:27, Marcelo Laia wrote: > On 18/05/22 at 01:17, Marcelo Laia wrote: > > > > Nowadays, senders have a feedback that attach files that I sent was > > corrupted. > > > > > After more tests, I found that if I use the mutt native smtp, attach is > properly transmitted. I could open it very well! > > So, I think there is a problem with msmtp or its configuration. No. Isn't msmtp problems. > This is only changes I do to get all works very well! I did more tests and found: If I send a message using tee >(lbdb-fetchaddr -a)|/usr/bin/msmtp -a gmail $@ the attached file with embedded image got corrupted The same result is got with tee >(lbdb-fetchaddr -a -c utf8) If I send a message using /usr/bin/msmtp -a gmail $@ the attached file with embedded image got loaded correctly. Have you some clue, here? Thank you so much! -- Marcelo
Re: file corruption after transmission over email
On 18/05/22 at 01:17, Marcelo Laia wrote: > > Nowadays, senders have a feedback that attach files that I sent was > corrupted. > After more tests, I found that if I use the mutt native smtp, attach is properly transmitted. I could open it very well! So, I think there is a problem with msmtp or its configuration. MSMTP config (msmtprc) defaults tls_trust_file /etc/ssl/certs/ca-certificates.crt logfile ~/.msmtp.log account gmail auth oauthbearer host smtp.gmail.com port 587 protocol smtp tls on from mylo...@gmail.com user mylo...@gmail.com passwordeval /path/to/scripts/OAuth2/get_teteraorg_token_gmail.sh MUTT native smtp relevant config (muttrc) set smtp_oauth_refresh_command="/path/to/scripts/OAuth2/get_teteraorg_token_gmail.sh" set smtp_authenticators="oauthbearer" set smtp_url = "smtp://mylo...@gmail.com@smtp.gmail.com:587/" set from = "mylo...@gmail.com" set use_from = yes set realname = "My Real Name" -- Marcelo
Re: file corruption after transmission over email
On 22/05/22 at 09:06, Marcelo Laia wrote: > On 18/05/22 at 01:17, Marcelo Laia wrote: > > > > Nowadays, senders have a feedback that attach files that I sent was > > corrupted. > > > > After a lot of tests, I found: > > 1. Files with image/figure was damaged > > 2. If images are remove from files, they are transferred by mutt intact. > > Could you do a test for me? If so, please, download the next files and > send it to me, one per message, using GMail. Send direct to my private > e-mail. > > pdf with image/figure > https://www.dropbox.com/s/y11l265wjt4dbbz/Mutt-test-estagio_assinado.pdf?dl=0 > > docx with image/figure > https://www.dropbox.com/s/ifu7qf1xnp2ev97/Mutt-test-figure.docx?dl=0 > > docx without image/figure > https://www.dropbox.com/s/q4c0t7vb8tu6ikp/Mutt-test.docx?dl=0 > Patrick Shanahan tell me that all three files was opened properly in their openSuse Box. He sent me all three files attached and all of then was properly opened in my Debian Box. I forwarded Patrick's message to he self. All three files was attached to that message automatically. Patrick report me that only two files arrived to his mail box: the pdf (attached) is corrupt. the docx (w/o image) was fine. The docx with image/figure was not transmitted to Patrick. Well, this is another problem I'm had having: when I sent more than one attachment, only the ones that "pass" are sent. When I forward to Patrick, I thought that only one, that one without image, would be sent. To my surprise, the pdf was too. I do not know what is happening. However, I don't have ideia how figure out that problem! Have you some idea? Thank you! -- Marcelo
Re: file corruption after transmission over email
On 18/05/22 at 01:17, Marcelo Laia wrote: > > Nowadays, senders have a feedback that attach files that I sent was > corrupted. > After a lot of tests, I found: 1. Files with image/figure was damaged 2. If images are remove from files, they are transferred by mutt intact. Could you do a test for me? If so, please, download the next files and send it to me, one per message, using GMail. Send direct to my private e-mail. pdf with image/figure https://www.dropbox.com/s/y11l265wjt4dbbz/Mutt-test-estagio_assinado.pdf?dl=0 docx with image/figure https://www.dropbox.com/s/ifu7qf1xnp2ev97/Mutt-test-figure.docx?dl=0 docx without image/figure https://www.dropbox.com/s/q4c0t7vb8tu6ikp/Mutt-test.docx?dl=0 Please, before send, inspect it if they are opened very well in your machine. Tell me what system are you using. I use Debian testing (Debian 5.17.3-1 (2022-04-18) x86_64) Thank you so much! -- Marcelo
Re: file corruption after transmission over email
* Marcelo Laia [05-21-22 15:24]: > On 20/05/22 at 01:30, Marcelo Laia wrote: > > On 20/05/22 at 01:22, Marcelo Laia wrote: > > > On 18/05/22 at 01:17, Marcelo Laia wrote: > > > > > > > > Nowadays, senders have a feedback that attach files that I sent was > > > > corrupted. > > > > > > > > Have a someone similar issue? > > > So, there are some issue with GMail to bypass! > > > > > > Have you using GMail? If so, could you do a test for me? > > > Please, note that there is a file size difference. It looks like GMail > > is cutting the file or removing a part of it. > > I was wrong! > > Yesterday, when I sent the message through the Yahoo server, mutt saved > it in the outbox, before sending it. For that reason, I thought the > Yahoo upload was ok. However, this morning, I found that the message had > not been sent. It was jammed in the msmtpq queue (msmtp.queue). When I > sent the message earlier, the file got corrupted. So, it doesn't be > relevant if you send by Yahoo or GMail: the file is corrupted in anyway. > I'm sorry for being wrong. > > Problem persist! > > Have you using GMail? If so, could you do a test for me? I have had no problems sending an included file via gmail or mail.yahoo.com using mutt. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Re: file corruption after transmission over email
On 20/05/22 at 01:30, Marcelo Laia wrote: > On 20/05/22 at 01:22, Marcelo Laia wrote: > > On 18/05/22 at 01:17, Marcelo Laia wrote: > > > > > > Nowadays, senders have a feedback that attach files that I sent was > > > corrupted. > > > > > > Have a someone similar issue? > > So, there are some issue with GMail to bypass! > > > > Have you using GMail? If so, could you do a test for me? > Please, note that there is a file size difference. It looks like GMail > is cutting the file or removing a part of it. I was wrong! Yesterday, when I sent the message through the Yahoo server, mutt saved it in the outbox, before sending it. For that reason, I thought the Yahoo upload was ok. However, this morning, I found that the message had not been sent. It was jammed in the msmtpq queue (msmtp.queue). When I sent the message earlier, the file got corrupted. So, it doesn't be relevant if you send by Yahoo or GMail: the file is corrupted in anyway. I'm sorry for being wrong. Problem persist! Have you using GMail? If so, could you do a test for me? -- Marcelo
Re: file corruption after transmission over email
* Marcelo Laia [05-20-22 12:32]: > On 20/05/22 at 01:22, Marcelo Laia wrote: > > On 18/05/22 at 01:17, Marcelo Laia wrote: > > > > > > Nowadays, senders have a feedback that attach files that I sent was > > > corrupted. > > > > > > Have a someone similar issue? > > > > > > > > > I found that issue is related to GMail. > > > > I sent the same attach from a Yahoo account and I got it open normally, > > like a charm! > > > > Here is the headers: > > > > > > From: Marcelo > > To: echo > > Date: Fri, 20 May 2022 13:10:42 -0300 > > Subject: Test Yahoo > > > > [-- Anexo No.1 --] > > [-- Tipo: text/plain, Codificação: 7bit, Tamanho: 0,1K --] > > > > -- > > Marcelo > > > > [-- Anexo No.2: TCC Lúnia-Vieira-v3.docx --] > > [-- Tipo: > > application/vnd.openxmlformats-officedocument.wordprocessingml.document, > > Codificação: > > base64, Tamanho: 6,0M --] > > > > [-- application/vnd.openxmlformats-officedocument.wordprocessingml.document > > não é aceito (use > > 'v' para ver esta parte) --] > > > > > > Attach view (after C-v) > > > > I 1 [text/plain, > > 7bit, us-ascii, 0,1K] > > A 2 TCC Lúnia-Vieira-v3.docx > > [applica/vnd.openxm, base64, 6,0M] > > > > > > So, there are some issue with GMail to bypass! > > > > Have you using GMail? If so, could you do a test for me? > > > > Plus: > > > GMail > > From: Marcelo > To: echo > Date: Fri, 20 May 2022 12:50:17 -0300 > Subject: Test 8 emacs > > [-- Anexo No.1 --] > [-- Tipo: text/plain, Codificação: 7bit, Tamanho: 0K --] > > > [-- Anexo No.2: TCC Lúnia-Vieira-v3.docx --] > [-- Tipo: > application/vnd.openxmlformats-officedocument.wordprocessingml.document, > Codificação: > base64, Tamanho: 71K --] > > [-- application/vnd.openxmlformats-officedocument.wordprocessingml.document > não é aceito (use > 'v' para ver esta parte) --] > > > Yahoo > > From: Marcelo > To: echo > Date: Fri, 20 May 2022 13:10:42 -0300 > Subject: Test Yahoo > > [-- Anexo No.1 --] > [-- Tipo: text/plain, Codificação: 7bit, Tamanho: 0,1K --] > > -- > Marcelo > > [-- Anexo No.2: TCC Lúnia-Vieira-v3.docx --] > [-- Tipo: > application/vnd.openxmlformats-officedocument.wordprocessingml.document, > Codificação: > base64, Tamanho: 6,0M --] > > [-- application/vnd.openxmlformats-officedocument.wordprocessingml.document > não é aceito (use > 'v' para ver esta parte) --] > > > Attach View (after C-v) > > GMail > > I 1 [text/plain, 7bit, us-ascii, 0K] > A 2 TCC Lúnia-Vieira-v3.docx [applica/vnd.openxm, base64, 71K] > > > Yahoo > > I 1 [text/plain, 7bit, us-ascii, 0,1K] > A 2 TCC Lúnia-Vieira-v3.docx [applica/vnd.openxm, base64, 6,0M] > > > Please, note that there is a file size difference. It looks like GMail > is cutting the file or removing a part of it. > > -- > Marcelo I have not ever had that happen to me, that I can recall. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Re: file corruption after transmission over email
On 20/05/22 at 01:22, Marcelo Laia wrote: > On 18/05/22 at 01:17, Marcelo Laia wrote: > > > > Nowadays, senders have a feedback that attach files that I sent was > > corrupted. > > > > Have a someone similar issue? > > > > > I found that issue is related to GMail. > > I sent the same attach from a Yahoo account and I got it open normally, > like a charm! > > Here is the headers: > > > From: Marcelo > To: echo > Date: Fri, 20 May 2022 13:10:42 -0300 > Subject: Test Yahoo > > [-- Anexo No.1 --] > [-- Tipo: text/plain, Codificação: 7bit, Tamanho: 0,1K --] > > -- > Marcelo > > [-- Anexo No.2: TCC Lúnia-Vieira-v3.docx --] > [-- Tipo: > application/vnd.openxmlformats-officedocument.wordprocessingml.document, > Codificação: > base64, Tamanho: 6,0M --] > > [-- application/vnd.openxmlformats-officedocument.wordprocessingml.document > não é aceito (use > 'v' para ver esta parte) --] > > > Attach view (after C-v) > > I 1 [text/plain, 7bit, > us-ascii, 0,1K] > A 2 TCC Lúnia-Vieira-v3.docx > [applica/vnd.openxm, base64, 6,0M] > > > So, there are some issue with GMail to bypass! > > Have you using GMail? If so, could you do a test for me? > Plus: GMail From: Marcelo To: echo Date: Fri, 20 May 2022 12:50:17 -0300 Subject: Test 8 emacs [-- Anexo No.1 --] [-- Tipo: text/plain, Codificação: 7bit, Tamanho: 0K --] [-- Anexo No.2: TCC Lúnia-Vieira-v3.docx --] [-- Tipo: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Codificação: base64, Tamanho: 71K --] [-- application/vnd.openxmlformats-officedocument.wordprocessingml.document não é aceito (use 'v' para ver esta parte) --] Yahoo From: Marcelo To: echo Date: Fri, 20 May 2022 13:10:42 -0300 Subject: Test Yahoo [-- Anexo No.1 --] [-- Tipo: text/plain, Codificação: 7bit, Tamanho: 0,1K --] -- Marcelo [-- Anexo No.2: TCC Lúnia-Vieira-v3.docx --] [-- Tipo: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Codificação: base64, Tamanho: 6,0M --] [-- application/vnd.openxmlformats-officedocument.wordprocessingml.document não é aceito (use 'v' para ver esta parte) --] Attach View (after C-v) GMail I 1 [text/plain, 7bit, us-ascii, 0K] A 2 TCC Lúnia-Vieira-v3.docx [applica/vnd.openxm, base64, 71K] Yahoo I 1 [text/plain, 7bit, us-ascii, 0,1K] A 2 TCC Lúnia-Vieira-v3.docx [applica/vnd.openxm, base64, 6,0M] Please, note that there is a file size difference. It looks like GMail is cutting the file or removing a part of it. -- Marcelo
Re: file corruption after transmission over email
On 18/05/22 at 01:17, Marcelo Laia wrote: > > Nowadays, senders have a feedback that attach files that I sent was > corrupted. > > Have a someone similar issue? > I found that issue is related to GMail. I sent the same attach from a Yahoo account and I got it open normally, like a charm! Here is the headers: From: Marcelo To: echo Date: Fri, 20 May 2022 13:10:42 -0300 Subject: Test Yahoo [-- Anexo No.1 --] [-- Tipo: text/plain, Codificação: 7bit, Tamanho: 0,1K --] -- Marcelo [-- Anexo No.2: TCC Lúnia-Vieira-v3.docx --] [-- Tipo: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Codificação: base64, Tamanho: 6,0M --] [-- application/vnd.openxmlformats-officedocument.wordprocessingml.document não é aceito (use 'v' para ver esta parte) --] Attach view (after C-v) I 1 [text/plain, 7bit, us-ascii, 0,1K] A 2 TCC Lúnia-Vieira-v3.docx [applica/vnd.openxm, base64, 6,0M] So, there are some issue with GMail to bypass! Have you using GMail? If so, could you do a test for me? -- Marcelo
Re: file corruption after transmission over email
On 20/05/22 at 11:09, Patrick Shanahan wrote: > I have for many years w/o problem: > set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:utf-8" Not solved! -- Marcelo
Re: file corruption after transmission over email
* Marcelo Laia [05-20-22 11:02]: > On 18/05/22 at 10:42, Paul Gilmartin via Mutt-users wrote: > > On May 18, 2022, at 10:17:56, Marcelo Laia wrote: > > > > > > Nowadays, senders have a feedback that attach files that I sent was > > > corrupted. > > > > > > Have a someone similar issue? > > > > > Do you know (Orr can thee recipients tell you): > > Content-Type: and Content-Transfer-Encoding: 7bit > > > > > I did some tests and neither solved the issue. > > Here is what I did. > > set send_charset="utf-8" > > or > > set send_charset="us-ascii:utf-8" > > or > > set use_8bitmime > > or > > set use_8bitmime = yes > > This is what I receive form server: > > Test 1 > > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > Content-Type: > application/vnd.openxmlformats-officedocument.wordprocessingml.document > Content-Disposition: attachment; > filename*=iso-8859-1''TCC%20L%FAnia-Vieira-v3%2Edocx > Content-Transfer-Encoding: base64 > > > Test 2 > > Content-Type: text/plain; charset=utf-8 > Content-Disposition: inline > > Content-Type: > application/vnd.openxmlformats-officedocument.wordprocessingml.document > Content-Disposition: attachment; > filename*=utf-8''TCC%20L%C3%BAnia-Vieira-v3%2Edocx > Content-Transfer-Encoding: base64 > > > On the Sent Box, I got, for all messages sent: > > From: Marcelo > To: echo > Date: Fri, 20 May 2022 11:19:12 -0300 > Subject: Test 6 > > [-- Anexo No.1 --] > [-- Tipo: text/plain, Codificação: 7bit, Tamanho: 0K --] > > > [-- Anexo No.2: TCC Lúnia-Vieira-v3.docx --] > [-- Tipo: > application/vnd.openxmlformats-officedocument.wordprocessingml.document, > Codificação: > base64, Tamanho: 71K --] > > [-- application/vnd.openxmlformats-officedocument.wordprocessingml.document > não é aceito (use > 'v' para ver esta parte) --] > > Please, someone could help me? I have for many years w/o problem: set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:utf-8" -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Re: file corruption after transmission over email
On 18/05/22 at 10:42, Paul Gilmartin via Mutt-users wrote: > On May 18, 2022, at 10:17:56, Marcelo Laia wrote: > > > > Nowadays, senders have a feedback that attach files that I sent was > > corrupted. > > > > Have a someone similar issue? > > > Do you know (Orr can thee recipients tell you): > Content-Type: and Content-Transfer-Encoding: 7bit > I did some tests and neither solved the issue. Here is what I did. set send_charset="utf-8" or set send_charset="us-ascii:utf-8" or set use_8bitmime or set use_8bitmime = yes This is what I receive form server: Test 1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Content-Disposition: attachment; filename*=iso-8859-1''TCC%20L%FAnia-Vieira-v3%2Edocx Content-Transfer-Encoding: base64 Test 2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Content-Disposition: attachment; filename*=utf-8''TCC%20L%C3%BAnia-Vieira-v3%2Edocx Content-Transfer-Encoding: base64 On the Sent Box, I got, for all messages sent: From: Marcelo To: echo Date: Fri, 20 May 2022 11:19:12 -0300 Subject: Test 6 [-- Anexo No.1 --] [-- Tipo: text/plain, Codificação: 7bit, Tamanho: 0K --] [-- Anexo No.2: TCC Lúnia-Vieira-v3.docx --] [-- Tipo: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Codificação: base64, Tamanho: 71K --] [-- application/vnd.openxmlformats-officedocument.wordprocessingml.document não é aceito (use 'v' para ver esta parte) --] Please, someone could help me? Thank you -- Marcelo
Re: file corruption after transmission over email
On 18/05/22 at 10:42, Paul Gilmartin via Mutt-users wrote: > > Can you test by sending a message with only small > attachments to: e...@univie.ac.at > ??? > OK, I do that. But, I don't known what I need to search inside the echo response. Could you point me out? -- Marcelo
Re: file corruption after transmission over email
On May 18, 2022, at 10:17:56, Marcelo Laia wrote: > > Nowadays, senders have a feedback that attach files that I sent was > corrupted. > > Have a someone similar issue? > Do you know (Orr can thee recipients tell you): Content-Type: and Content-Transfer-Encoding: 7bit Can you test by sending a message with only small attachments to: e...@univie.ac.at ??? -- gil
file corruption after transmission over email
Nowadays, senders have a feedback that attach files that I sent was corrupted. Have a someone similar issue? Thank you so much! -- Marcelo
Re: utf8 file corruption after transmission over email
Hi, * Jussi Peltola wrote: On Fri, May 08, 2009 at 06:23:15PM -0700, zion wrote: if LC_CTYPE is unset, file doesn't get corrupted. In that case, what does ':set ?charset' in mutt report? I think mutt is reading your file, assuming it's KOI8-R as stated in your locale, and converting it to UTF-8 for sending. It has to do that; plain text won't tell it what charset it's in and it has to guess. Yes. If mutt is recent enough, $attach_charset can help (it specifies the charsets to use for guessing for text media type attachments). Rocco
Re: utf8 file corruption after transmission over email
On Fri, May 08, 2009 at 06:23:15PM -0700, zion wrote:
On Fri, May 08, 2009 at 04:34:14PM -0700, zion wrote:
Well, I just captured smtp session of loopback interface (same box where
mutt is running). Here is the relevant part:
03d0: 746f 3e38 353c 2f74 6f3e 0d0a 0909 093c to85/to.
03e0: 7265 6164 3e21 d091 e288 9ae2 9591 3c2f read!п.Б..Б../
03f0: 7265 6164 3e0d 0a09 0909 3c77 7269 7465 read.write
As you can see, this character is already messed up before reaching
server. So, @gmail is not guilty here ;-).
Turns out it's my locale. having this causes the problem:
LC_CTYPE=ru_RU.KOI8-R
if LC_CTYPE is unset, file doesn't get corrupted.
I think mutt is reading your file, assuming it's KOI8-R as stated in
your locale, and converting it to UTF-8 for sending.
It has to do that; plain text won't tell it what charset it's in and it
has to guess. If you want to send files over email byte-per-byte, renaming
them to .bin or something else that has the mime type of
application/octet-stream should work better.
--
Jussi Peltola
utf8 file corruption after transmission over email
Hello, I have a mystery that I'm trying to solve to no avail. mutt-1.5.19 is running on OpenBSD 4.5, --with-idn. I got a little sample XML (utf-8) encoded file that I'm trying to send as attachment. When I attach it, mutt correctly identifies it: [text/plain, 8bit, utf-8, 0.3K], since there are non-ASCII characters, in this case there is only 1 such character. After I send it, this attached file becomes currupt. before I send it: MD5 (hw2.jff) = 9a14b9ac1a12deb07d262b6658d7b9b2 after: MD5 (hw2.jff-corrupted) = 718597b09e7544f89cd255a5d4c8e301 this file contains a 'WHITE SQUARE' character, see http://www.fileformat.info/info/unicode/char/25a1/index.htm after examining both files here is what gets changed: 0xE2 0x96 0xA1 becomes 0xD0 0x91 0xE2 0x88 0x9A 0xE2 0x95 0x91 Both files are available for your inspection at: http://www.x96.org/files/hw2.jff http://www.x96.org/files/hw2.jff-corrupted I appreciate your help.
Re: utf8 file corruption after transmission over email
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Friday, May 8 at 03:00 PM, quoth Aaron S.: I have a mystery that I'm trying to solve to no avail. Hopefully we can help! I got a little sample XML (utf-8) encoded file that I'm trying to send as attachment. When I attach it, mutt correctly identifies it: [text/plain, 8bit, utf-8, 0.3K], since there are non-ASCII characters, in this case there is only 1 such character. Well, actually, that's an incorrect identification. It's NOT a text/plain file, it's an xml file. According to RFC 3023, it should either be sent as application/xml or as text/xml. Now, that misidentification shouldn't cause the problem you're having, but correcting it *probably* will fix the problem. I bet that if you add the following to your ~/.mime.types file, the problem goes away: application/xml jff After I send it, this attached file becomes currupt. I tried sending your file to myself, both with and without that line in my mime.types file, and the file didn't get corrupted either way. My guess is that this is ACTUALLY your mail server's fault (did you send it through an MSFT Exchange server maybe? They're really bad about this). Here's what I think happened: you have configured mutt to send things in 8-bit mode (i.e. $allow_8bit). Thus, when sending a utf-8 file attachment with an unusual character in it, mutt sent it completely unmodified, because that's supposed to be safe to do when sending in 8-bit mode. But some servers (and I've had this happen more often than not with Exchange servers) attempt to convert all messages into 7-bit form. Unfortunately, they're often very bad at it. I've had several messages corrupted by Exchange servers simply because they couldn't handle curly-quotes correctly. It's happened often enough that I finally just unset allow_8bit so that mutt would always take care of encoding my messages in a 7-bit safe manner, because mutt is so much better at it than they are. Anyway, does that help? ~Kyle - -- Anyway, have fun. And don't bother reporting any bugs for the next few days. I won't care anyway. -- Linus Torvalds, when kernel 2.4 came out -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKBLqJAAoJECuveozR/AWeBBQP/j1tOe19BTFKo/AN4gzcDhTS 72ug8j7pY3M75W7DJ33Bx3p6gafGEwaiHh6mePt/0L4YuHzGpZxhog9FmmzptJmG 1ROfdmkJ4DYH7zrXTHvLBufrp1I/hlAGqsogncrs+N/gLV6QNzJno3FnY9xkVbxe DNm3MgkksZ1U9uMXyhrHsoJ+NQ01zuzP6BtEp1uVQKOHnluEd8jzyR9Dow5j5/8A zp84PLMCvHn5UIQl1cf8qoUGFSfznBmK6xMgBDXCy/bghjwliGdPsy8n3Y0VhD6V 16vqx3qcTwoSbbTaQcyqY++v82TvQAz8izat23C1OWxWnYoAiy5lEjMv5FBh5UkO dyDZKAWM4XmM05c1GexEcmhfvAHOQ2Il93hluKA7ZIFGeDfyz4Hl+dkeY7aSX2ek 6caHXz+jQnRz6hgBnwk1GcoTDwdmAdtU8XZYCjYHo+1BotMyKzMcE7c/483pj4Kb dOpluhcPXsjnHKJK3wvRzT9lQqfGy4XFU6SuxXIH8TIxucAvlw+ZWrwUdpx1btIm tH1ESVyIr4RoAm8viVl/OUdZ2apF8an9faxMwa80YBVGog9TxfoCy0jYOxs0g9YW KLhPmaeeHaBaFpeha//MN8zcMxNknx7WsFvg2eL7XyMoUj3s2LhlWE6eQu0Luijc 3NWylNKI3jMswtfFtUyQ =Hbvl -END PGP SIGNATURE-
Re: utf8 file corruption after transmission over email
On Fri, May 08, 2009 at 06:04:42PM -0500, Kyle Wheeler wrote: On Friday, May 8 at 03:00 PM, quoth Aaron S.: I have a mystery that I'm trying to solve to no avail. Hopefully we can help! I got a little sample XML (utf-8) encoded file that I'm trying to send as attachment. When I attach it, mutt correctly identifies it: [text/plain, 8bit, utf-8, 0.3K], since there are non-ASCII characters, in this case there is only 1 such character. Well, actually, that's an incorrect identification. It's NOT a text/plain file, it's an xml file. According to RFC 3023, it should either be sent as application/xml or as text/xml. Now, that misidentification shouldn't cause the problem you're having, but correcting it *probably* will fix the problem. I bet that if you add the following to your ~/.mime.types file, the problem goes away: application/xml jff After I send it, this attached file becomes currupt. I tried sending your file to myself, both with and without that line in my mime.types file, and the file didn't get corrupted either way. My guess is that this is ACTUALLY your mail server's fault (did you send it through an MSFT Exchange server maybe? They're really bad about this). Here's what I think happened: you have configured mutt to send things in 8-bit mode (i.e. $allow_8bit). Thus, when sending a utf-8 file attachment with an unusual character in it, mutt sent it completely unmodified, because that's supposed to be safe to do when sending in 8-bit mode. But some servers (and I've had this happen more often than not with Exchange servers) attempt to convert all messages into 7-bit form. Unfortunately, they're often very bad at it. I've had several messages corrupted by Exchange servers simply because they couldn't handle curly-quotes correctly. It's happened often enough that I finally just unset allow_8bit so that mutt would always take care of encoding my messages in a 7-bit safe manner, because mutt is so much better at it than they are. Anyway, does that help? Hello, Well, it was sent from @gmail to another @gmail account. I have no idea what they run there at google. I thought about adding that to mime.types and it does work. What bothers me is that now I have to pay much closer attention as to when I'm attaching strange files. I'm gonna have to think of a way to intercept whatever mutt is sending out to make sure it's not mutt that messes up this 3byte UTF-8 character. In any case, thanks for your pointers.
Re: utf8 file corruption after transmission over email
Well, I just captured smtp session of loopback interface (same box where
mutt is running). Here is the relevant part:
03d0: 746f 3e38 353c 2f74 6f3e 0d0a 0909 093c to85/to.
03e0: 7265 6164 3e21 d091 e288 9ae2 9591 3c2f read!п.Б..Б../
03f0: 7265 6164 3e0d 0a09 0909 3c77 7269 7465 read.write
As you can see, this character is already messed up before reaching
server. So, @gmail is not guilty here ;-).
Re: utf8 file corruption after transmission over email
On Fri, May 08, 2009 at 04:34:14PM -0700, zion wrote: Well, I just captured smtp session of loopback interface (same box where mutt is running). Here is the relevant part: 03d0: 746f 3e38 353c 2f74 6f3e 0d0a 0909 093c to85/to. 03e0: 7265 6164 3e21 d091 e288 9ae2 9591 3c2f read!п.Б..Б../ 03f0: 7265 6164 3e0d 0a09 0909 3c77 7269 7465 read.write As you can see, this character is already messed up before reaching server. So, @gmail is not guilty here ;-). Turns out it's my locale. having this causes the problem: LC_CTYPE=ru_RU.KOI8-R if LC_CTYPE is unset, file doesn't get corrupted.
