headers
aitor | 1 Mar 2012 07:26
Picon

Saving attachments to disk

Hi,

I sent this mail to mutt-users some days ago. In the past couple of days
I've been hit by this behaviour (using mutt 1.5.21 compiled from
scratch). Suppose that I receive a mail with several attachments:

I     1 <no description>      [multipa/alternativ, 7bit, 7.2K]
I     2 ├─><no description>   [text/plain, 7bit, iso-8859-1, 0.7K]
I     3 └─><no description>   [text/html, 7bit, iso-8859-1, 6.3K]
A     4 file.txt              [text/plain, 8bit, us-ascii, 2.3K]
A     5 file.xml              [text/xml, 8bit, us-ascii, 0.1K]
A     6 file.pdf 	      [text/x-unknown-, base64, us-ascii, 66K]

The message has 3 attachments, one text file, one xml document and one
pdf document (this is a real example,the sender MUA being Thuderbird
3.1.18). It turns out that the sender MUA got it wrong, and the
character encoding is wrongly set (us-ascii), but:

- file.txt is utf-8 encoded

- file.xml is also utf-8 encoded.

- file.pdf is a pdf document.

The problem is that there is no way to save these attachment
properly. For instance, when saving file.xml all the non ascii
characters are replaced with "?". So if file.xml originally was:

<?xml version="1.0" encoding="utf-8"?>
<a>©Áéñio</a>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Fandrich | 1 Mar 2012 09:14
Favicon

Re: Saving attachments to disk

On Thu, Mar 01, 2012 at 07:26:41AM +0100, aitor wrote:
> The problem is that there is no way to save these attachment
> properly. For instance, when saving file.xml all the non ascii
> characters are replaced with "?". So if file.xml originally was:

I've been hit by this problem as well. I've also found that piping the
attachment to an external program changes this behaviour. So using
"| cat > uncorrupted_file" actually works. At the least, this behaviour
is inconsistent. The automatic conversion on save was certainly
surprising to me.

>>> Dan
Permalink | Reply | 0 comments |
headers
Mutt | 9 Mar 2012 17:35

[Mutt] #3567: folder-hook interference of settings

#3567: folder-hook interference of settings
-------------------------+--------------------------------------------------
 Reporter:  mutt_usr1    |       Owner:  mutt-dev
     Type:  defect       |      Status:  new     
 Priority:  major        |   Milestone:          
Component:  mutt         |     Version:  1.5.21  
 Keywords:  folder-hook  |  
-------------------------+--------------------------------------------------
 I have 2 mail accounts for which i have separate config files, which are
 sourced by muttrc, using folder-hook.

 In profile1 i have set

 my_hdr Bcc:abc <at> xyz.com

 When i change to the mailbox of profile2 and try to compose a mail, it too
 shows Bcc:abc <at> xyz.com, even though i have not set bcc for profile2 and
 it's not in ~/.muttrc either.

 So the setting of profile1 is interfering with profile2. To work around
 this i have this in profile2,

 unmy_hdr Bcc:

 I have tested that at least the "set from = " option also behaves like
 this, i.e., if i have not explicitly specified "from" for profile2, then
 the one from profile1 gets used, even though there is no "from" in muttrc.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3567>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mutt | 9 Mar 2012 17:41

Re: [Mutt] #3567: folder-hook interference of settings

#3567: folder-hook interference of settings
------------------------+---------------------------------------------------
  Reporter:  mutt_usr1  |       Owner:  mutt-dev   
      Type:  defect     |      Status:  closed     
  Priority:  major      |   Milestone:             
 Component:  mutt       |     Version:  1.5.21     
Resolution:  wontfix    |    Keywords:  folder-hook
------------------------+---------------------------------------------------
Changes (by brendan):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 This has been in the design of mutt for as long as I remember. It's even
 documented: http://dev.mutt.org/doc/manual.html#hooks :)

 It would cause too much compatibility pain to consider changing it now.
 Your "workaround" is the recommended technique in the docs.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3567#comment:1>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 0 comments |
headers
Mutt | 9 Mar 2012 18:37

[Mutt] #3568: Saving attachments to disk

#3568: Saving attachments to disk
--------------------+-------------------------------------------------------
 Reporter:  aitor   |       Owner:  mutt-dev
     Type:  defect  |      Status:  new     
 Priority:  major   |   Milestone:  1.6     
Component:  mutt    |     Version:  1.5.21  
 Keywords:          |  
--------------------+-------------------------------------------------------
 Hi,

 I sent this mail to mutt-users some days ago. In the past couple of days
 I've been hit by this behaviour (using mutt 1.5.21 compiled from scratch).
 Suppose that I receive a mail with several attachments:

 I     1 <no description>      [multipa/alternativ, 7bit, 7.2K][[BR]]

 I     2 ├─><no description>   [text/plain, 7bit, iso-8859-1, 0.7K][[BR]]

 I     3 └─><no description>   [text/html, 7bit, iso-8859-1, 6.3K][[BR]]

 A     4 file.txt              [text/plain, 8bit, us-ascii, 2.3K][[BR]]

 A     5 file.xml              [text/xml, 8bit, us-ascii, 0.1K][[BR]]

 A     6 file.pdf              [text/x-unknown-, base64, us-ascii,
 66K][[BR]]

 The message has 3 attachments, one text file, one xml document and one pdf
 document (this is a real example,the sender MUA being Thuderbird 3.1.18).
 It turns out that the sender MUA got it wrong, and the character encoding
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mutt | 27 Mar 2012 10:14

[Mutt] #3569: Segmentation fault in sync_helper

#3569: Segmentation fault in sync_helper
--------------------+-------------------------------------------------------
 Reporter:  hhorak  |       Owner:  mutt-dev
     Type:  defect  |      Status:  new     
 Priority:  major   |   Milestone:          
Component:  mutt    |     Version:  1.5.21  
 Keywords:          |  
--------------------+-------------------------------------------------------
 Mutt sometimes crashes in sync_helper (imap.c:1131) because of a
 segmentation fault. Regarding the backtrace it fails because idata->ctx is
 NULL, which is not expected at this point, but seeing many similar
 failures in [1], [2] and [3], it really happens.

 What we know from bug reports, it usually happens after many changes in
 the imap folder or after imap server failure occurs. I suspect mutt to
 erased idata->ctx after it fails to communicate with imap server, but I
 don't know how to reproduce it.

 There are many checks of idata->ctx to be set before working with it in
 other places, so I'd suggest to add a check into sync_helper as well, for
 example as the following:

 {{{
 diff -up mutt-1.5.21/imap/imap.c.syncdebug mutt-1.5.21/imap/imap.c
 --- mutt-1.5.21/imap/imap.c.syncdebug   2012-03-27 10:05:44.978962551
 +0200
 +++ mutt-1.5.21/imap/imap.c     2012-03-27 10:05:54.223252267 +0200
  <at>  <at>  -1128,7 +1128,7  <at>  <at>  static int sync_helper (IMAP_DATA* idata

    char buf[LONG_STRING];
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Burdess | 28 Mar 2012 12:06
Favicon

Re: Support for BODYSTRUCTURE (message fetch on demand)

I attach a patch which implements a first pass at this work. I stripped out
all the makefile, etc diff stuff to make it readable.

What this does:

- issue BODYSTRUCTURE IMAP command instead of BODY.PEEK[]
- parses the BODYSTRUCTURE response into a MIME structure associated with
  the message
- issue FETCH (RFC822.HEADER BODY[n...]) to fetch only the text part of
  the message, parse the resulting literals into msg->fp

What it doesn't yet do:

- integrate with the rest of the MIME handling in mutt.
- free the MIME structure associated with the message

This means that when we go into the MIME structure page (default key 'v',
don't know what the screen is called) it will just parse the fetched part
of the message from msg->fp, it doesn't know anything about the new MIME
structure which we can use to fetch the missing parts on demand. I need
a bit of help with this as I'm not really familiar enough with the
internal details. Also when should the message be freed so I can free the
MIME structure?

Please let me know what you think and how best to proceed.

Cheers
--

-- 
Chris Burdess
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Champion | 28 Mar 2012 17:07
Favicon

Re: Support for BODYSTRUCTURE (message fetch on demand)

* On 28 Mar 2012, Chris Burdess wrote: 
> I attach a patch which implements a first pass at this work. I stripped out
> all the makefile, etc diff stuff to make it readable.

Thanks for the work.  If you could, it would make code review easier to
use Mercurial for the patch generation.

$ hg clone http://dev.mutt.org/hg/mutt
$ cd mutt
$ hg up -C HEAD
[apply your patches locally]
[resolve any conflicts resulting from version differences]
$ hg ci

You can then use 'hg diff' to make a patch, or 'hg email' to send the
patchset to the list.  For one thing this will automatically exclude
untracked/generated files.

--

-- 
David Champion • dgc <at> uchicago.edu • IT Services • University of Chicago
Permalink | Reply | 1 comment |
headers
Mutt | 28 Mar 2012 17:36

[Mutt] #3570: use of socat with "tunnel" hang forever

#3570: use of socat with "tunnel" hang forever
--------------------------+-------------------------------------------------
 Reporter:  pierrem       |       Owner:  mutt-dev
     Type:  defect        |      Status:  new     
 Priority:  major         |   Milestone:          
Component:  mutt          |     Version:  1.5.21  
 Keywords:  tunnel socat  |  
--------------------------+-------------------------------------------------
 Using debian wheezy package mutt 1.5.21-5, and getting the same result
 with /usr/bin/mutt and /usr/bin/mutt-org

 using set tunnel='socat STDIO
 SOCKS4A:tor.example.com:imap.gmail.com:imaps,socksport=9100'
 gives the following output when running mutt -d 5:

 Connecting with "socat STDIO
 SOCKS4A:tor.example.com:imap.gmail.com:imaps,socksport=9100"...

 Connected to imap.gmail.com:993 on fd=42

 imap_cmd_step: grew buffer to 512 bytes

 and wait forever until I kill the socat process.
 A direct connection to the imap server works fine.

 For the same kind of problematic, fetchmail uses the "plugin" parameter
 with the same "socat ..." argument and succeeds in establishing a
 connection through the tor node and fetching mails from the IMAP server.
 The difference I spot is that fetchmail uses one socketpair() where mutt
 uses two pipe().
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mutt | 28 Mar 2012 20:38

[Mutt] #3571: User should be able to disable TLSv1.1 and TLSv1.2

#3571: User should be able to disable TLSv1.1 and TLSv1.2
-------------------------+--------------------------------------------------
 Reporter:  hncaldwell   |       Owner:  mutt-dev
     Type:  enhancement  |      Status:  new     
 Priority:  minor        |   Milestone:          
Component:  mutt         |     Version:  1.5.21  
 Keywords:               |  
-------------------------+--------------------------------------------------
 I ran into a problem where I was unable to connect to an Exchange server
 over imaps with mutt after I had upgraded OpenSSL to version 1.0.1.

 After examining some pcaps, I realized that after the upgrade, mutt's TLS
 connection was using TLS version 1.2, which I guess resulted in the
 Exchange server not being able to negotiate the connection:

 {{{
 ...
 [2012-03-28 10:46:34] 4< * OK Microsoft Exchange Server 2003 IMAP4rev1
 server version 6.5.7638.1 (hq-es.FASTSOFT.COM) ready.
 [2012-03-28 10:46:34] IMAP queue drained
 [2012-03-28 10:46:34] Right before imap_check_capabilities call 1
 [2012-03-28 10:46:36] 4> a0000 CAPABILITY^M
 [2012-03-28 10:46:36] SSL error: error:1408F10B:SSL
 routines:SSL3_GET_RECORD:wrong version number
 [2012-03-28 10:46:36] imap_cmd_step: Error reading server response.
 ...
 }}}

 Looking at mutt's code, I realized that there were no options that allowed
 for the explicit selection of a TLS version.  I think that there should be
(Continue reading)

Permalink | Reply | 5 comments |

Gmane