headers
Mutt | 2 Sep 23:17

[Mutt] #3322: no longer parses port for pop3/localhost

#3322: no longer parses port for pop3/localhost
------------------------------+---------------------------------------------
 Reporter:  antonio <at> dyne.org  |       Owner:  mutt-dev
     Type:  defect            |      Status:  new     
 Priority:  minor             |   Milestone:          
Component:  mutt              |     Version:  1.5.20  
 Keywords:                    |  
------------------------------+---------------------------------------------
 Forwarding from http://bugs.debian.org/535096

 {{{
 Hello,
 With Mutt 1.5.20-1 and -2, Mutt fails to connect to my tunneled pop3
 connection.  The relevant line in my muttrc:

 set pop_host="pop://my_user <at> localhost:1235/"

 Output from .muttdebug0 / "mutt -d3":

 user <at> host:~$ tail .muttdebug0
 <snip>
 [2009-06-29 12:56:25] Connection failed. errno: 111...
 [2009-06-29 12:56:25] Could not connect to localhost (Connection refused).
 [2009-06-29 12:56:27] Connected to localhost:110 on fd=-1
 [2009-06-29 12:56:27] Error connecting to server: localhost

 This doesn't happen with the older Debian Mutt package, mutt_1.5.19-4.

 }}}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 2 Sep 23:24

[Mutt] #3323: Sending postponed messages doesn't save a copy in $record

#3323: Sending postponed messages doesn't save a copy in $record
------------------------------+---------------------------------------------
 Reporter:  antonio <at> dyne.org  |       Owner:  mutt-dev
     Type:  defect            |      Status:  new     
 Priority:  minor             |   Milestone:          
Component:  mutt              |     Version:  1.5.20  
 Keywords:                    |  
------------------------------+---------------------------------------------
 Fowarding from http://bugs.debian.org/540540

 {{{
 It appears that when sending postponed messages, mutt doesn't save a
 copy in $record.  Twice recently I used "git imap-send" to put a Git
 patch in my =Drafts folder, and then used mutt to send it ('m', yes use
 postponed, edit, send).  These messages did not end up in my $record
 folder (=Sent).

 All other messages I send end up in $record as expected.

 }}}

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3323>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 6 comments |
headers
Mutt | 3 Sep 02:06

[Mutt] #3324: mutt: smime_keys fails if tmpdir is set

#3324: mutt: smime_keys fails if tmpdir is set
------------------------------+---------------------------------------------
 Reporter:  antonio <at> dyne.org  |       Owner:  mutt-dev
     Type:  defect            |      Status:  new     
 Priority:  trivial           |   Milestone:          
Component:  mutt              |     Version:  1.5.20  
 Keywords:                    |  
------------------------------+---------------------------------------------
 Forwarding from http://bugs.debian.org/542817

 {{{
 Hi!

         In my .muttrc I have set tmpdir with the following entry away
 from /tmp (causes mail loss if suspend fails while a message is in the
 pipe). This setting seems to confise smime_keys.

 <=====
 set tmpdir="$HOME/Mail/tmp"
 ====>

 <=====
 LANG="C" smime_keys add_p12 christoph.p12

 NOTE: This will ask you for two passphrases:
        1. The passphrase you used for exporting
        2. The passphrase you wish to secure your private key with.

 Enter Import Password:
 MAC verified OK
(Continue reading)

Permalink | Reply | 0 comments |
headers
Louis-David Mitterrand | 3 Sep 15:09

http://dev.mutt.org/trac/prefs/account

Hi,

I can't login to http://dev.mutt.org/trac/prefs/account with either
firefox or w3m: 

"Iceweasel has detected that the server is redirecting the request for
this address in a way that will never complete."
Permalink | Reply | 0 comments |
headers
Mutt | 4 Sep 01:29

[Mutt] #3325: attachment type misdetection for small .tar.gz

#3325: attachment type misdetection for small .tar.gz
------------------------------+---------------------------------------------
 Reporter:  antonio <at> dyne.org  |       Owner:  mutt-dev
     Type:  defect            |      Status:  new     
 Priority:  minor             |   Milestone:          
Component:  mutt              |     Version:  1.5.20  
 Keywords:                    |  
------------------------------+---------------------------------------------
 Hi,
 we have found that there is an attachment type misdetection for a small
 .tar.gz file, you can see the complete bug report on
 http://bugs.debian.org/541241.

 I had a look at your code and in sendlib.c the mutt_make_file_attach
 function will take care of looking up the mime type, it will use
 'mutt_lookup_mime_type', then based on the extension it will report the
 mimetype back to mutt. Unfortunately .gz, .bz2 and other compressed
 formats are not classified as mime types because they are 'encodings, so
 you won't find anything in /etc/mime.types

 In that case (i.e.: no content-type found in mime-type) you're trying to
 guess if it's a binary file or not with this check

 {{{
     if (info->lobin == 0 || (info->lobin + info->hibin + info->ascii)/
 info->lobin >= 10)
     {
       /*
        * Statistically speaking, there should be more than 10% "lobin"
        * chars if this is really a binary file...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 4 Sep 18:24

Re: [Mutt] #3325: attachment type misdetection for small .tar.gz

#3325: attachment type misdetection for small .tar.gz
-------------------------------+--------------------------------------------
  Reporter:  antonio <at> dyne.org  |       Owner:  mutt-dev
      Type:  defect            |      Status:  new     
  Priority:  minor             |   Milestone:          
 Component:  mutt              |     Version:  1.5.20  
Resolution:                    |    Keywords:          
-------------------------------+--------------------------------------------

Comment(by Derek Martin):

 {{{
 On Thu, Sep 03, 2009 at 11:29:55PM -0000, Mutt wrote:

 Who said they're encodings?  I don't see them listed in the
 Content-Transfer-Encodings section of the MIME RFCs, nor do I see them
 mentioned anywhere pertaining to "encoded words", and I don't see any
 other part of the RFCs that might suggest they should be classified as
 encodings.

 Classifying these as encodings seems impractically pedantic at best,
 but more likely just plain wrong.  They are application data, specific
 to their respective compression applications.  Note also that while
 not an officially recognized IANA MIME type, on platforms other than
 debian and derivatives, gzip does indeed appear in the MIME type
 listings.  This makes sense: once the e-mail is "decoded" and the
 attachment saved to a file, the data is still gzipped.  It is in fact
 a non-text attachment, as was intended to be hanled by MIME.  It
 requires an "application" to use the data.  It's no more an encoding
 than HTML and MP3 are encodings (which, in fact, they are, though not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 4 Sep 19:54

Re: [Mutt] #3325: attachment type misdetection for small .tar.gz

#3325: attachment type misdetection for small .tar.gz
-------------------------------+--------------------------------------------
  Reporter:  antonio <at> dyne.org  |       Owner:  mutt-dev
      Type:  defect            |      Status:  closed  
  Priority:  minor             |   Milestone:          
 Component:  mutt              |     Version:  1.5.20  
Resolution:  invalid           |    Keywords:          
-------------------------------+--------------------------------------------
Changes (by antonio <at> dyne.org):

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

Comment:

 Hi Derek,
 thanks for your clear explanation; I will resolve this bug because it's
 clear that it is not a mutt bug and I will follow-up this on the Debian
 side.

 Cheers
 Antonio

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3325#comment:2>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 0 comments |
headers
Mutt | 5 Sep 18:20

[Mutt] #3326: mutt segfaults if a charset is empty in .muttrc

#3326: mutt segfaults if a charset is empty in .muttrc
------------------------------+---------------------------------------------
 Reporter:  antonio <at> dyne.org  |       Owner:  mutt-dev
     Type:  defect            |      Status:  new     
 Priority:  trivial           |   Milestone:          
Component:  mutt              |     Version:  1.5.20  
 Keywords:  patch             |  
------------------------------+---------------------------------------------
 Related to bug http://bugs.debian.org/537818

 {{{
 To reproduce:
 1) create a .muttrc-minimal that contains a parameter with 'charset' in
 the name and no definition, for example
 set attach_charset=""
 or
 set attach_charset=
 }}}

 This will lead to a segfault, the cause is an improper validation in
 init.c:check_charset, the attached patch fixes the problem

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3326>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 1 comment |
headers
Mutt | 6 Sep 21:07

[Mutt] #3327: make tag-prefix available in the pager

#3327: make tag-prefix available in the pager
------------------------------+---------------------------------------------
 Reporter:  antonio <at> dyne.org  |       Owner:  mutt-dev
     Type:  enhancement       |      Status:  new     
 Priority:  trivial           |   Milestone:          
Component:  mutt              |     Version:  1.5.20  
 Keywords:                    |  
------------------------------+---------------------------------------------
 Forwarding from http://bugs.debian.org/539675

 {{{
 Hi,

 The tag-prefix function works fine in the index, but it does not
 work at all in the pager.  I tried using a macro, key binding,
 and the push and exec commands in the pager - none of them work.

 For example,

     :exec tag-prefix

 gives the error message,

     tag-prefix: no such function

 Here is how I would like to use tag-prefix in the pager,

     1. I make a first pass over incoming mail in the index.  I tag all
     spam, and then at the end of the first pass, I use tag-prefix to
     dispose of the spam.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 6 Sep 22:00

[Mutt] #3328: mutt should handle unencoded whitespace in Q-coded strings

#3328: mutt should handle unencoded whitespace in Q-coded strings
------------------------------+---------------------------------------------
 Reporter:  antonio <at> dyne.org  |       Owner:  mutt-dev
     Type:  enhancement       |      Status:  new     
 Priority:  trivial           |   Milestone:          
Component:  mutt              |     Version:  1.5.20  
 Keywords:                    |  
------------------------------+---------------------------------------------
 Forwarding from http://bugs.debian.org/497171

 {{{

 Hi,

 a Mail with

 Subject: =?us-ascii?Q?Ein neuer?=

 gets displayed as "=?us-ascii?Q?Ein neuer?=" in mutt. While this is
 technicall correct (unencoded spaces are not allowed in Q-encoded
 strings), mutt should be a little more tolerant here since a lot of
 software generates that kind of <censored>.

 I'd love to see

 Subject: Ein neuer

 on such input.

 Greetings
(Continue reading)

Permalink | Reply | 0 comments |

Gmane