aitor | 1 Mar 07:26 2012
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)

Dan Fandrich | 1 Mar 09:14 2012

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

Mutt | 9 Mar 17:35 2012

[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)

Mutt | 9 Mar 17:41 2012

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

Mutt | 9 Mar 18:37 2012

[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)

Mutt | 27 Mar 10:14 2012

[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)

Chris Burdess | 27 Mar 10:20 2012

Support for BODYSTRUCTURE (message fetch on demand)

Hi all

As I'm sure you're aware, these days people tend to send really quite huge
messages, 2MB and upward. I'm forever just hitting Enter on new messages
without looking at their size beforehand and then being stuck waiting for
several seconds while Mutt downloads the entire RFC822 message, even though
I usually only want to read the text MIME part and then potentially save
some other part to disk or open it separately.

It seems to me that it would probably not be a huge amount of work to get
Mutt to support BODYSTRUCTURE in imap/message.c, i.e. in imap_fetch_message:

- first issue UID FETCH <uid> BODYSTRUCTURE
- parse the BODYSTRUCTURE response and discover the MIME part number
  corresponding to the text part, respecting multipart/alternative etc
- issue UID FETCH BODY[<part>]
- populate the MESSAGE with just that part of the result.

So as far as displaying the message normally is concerned, we would just be
showing the text part (although we could indicate the presence of other
parts if desired).

This would mean making some changes to the MESSAGE structure to get it to
be aware that not all MIME parts are yet loaded, and that subsequent calls
to UID FETCH BODY[<part>] are required to load in not-yet-loaded parts when
we're in Mutt's MIME-part outline view.

It would also mean doing a bit of BODYSTRUCTURE parsing (since imap_next_word
is not really up to the job for this) and integrating that result somehow with
the standard MIME parsing that Mutt does for messages.
(Continue reading)

Chris Burdess | 28 Mar 12:06 2012

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)

David Champion | 28 Mar 17:07 2012

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

Mutt | 28 Mar 17:36 2012

[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)


Gmane