[Mutt] #3565: Use last used folder as default suggestion when using save-message

#3565: Use last used folder as default suggestion when using save-message
-------------------------+--------------------------------------------------
 Reporter:  idl0r        |       Owner:  mutt-dev
     Type:  enhancement  |      Status:  new     
 Priority:  minor        |   Milestone:          
Component:  mutt         |     Version:          
 Keywords:               |  
-------------------------+--------------------------------------------------
 See $Summary.

 At least in *my* case I can say that using the last folder used for save-
 message was in almost all cases more useful than the current one.
 I guess others may think the same.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3565>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

[PATCH] add real prototype for re_match_2_internal in regex.c

# HG changeset patch
# User Olaf Hering <olaf <at> aepfle.de>
# Date 1328299312 -3600
# Branch HEAD
# Node ID 8743a4a6bd37bd5c1b873c7758046fdbc47f4021
# Parent  c26dbc7021f4ec56c0e41d43019e43dd0be666de
add real prototype for re_match_2_internal in regex.c

regex.c: In function 're_search_2':
regex.c:3584:6: warning: call to function 're_match_2_internal' without a real prototype [-Wunprototyped-calls]
regex.c:384:12: note: 're_match_2_internal' was declared here
regex.c: In function 're_match':
regex.c:3706:9: warning: call to function 're_match_2_internal' without a real prototype [-Wunprototyped-calls]
regex.c:384:12: note: 're_match_2_internal' was declared here
regex.c: In function 're_match_2':
regex.c:3751:9: warning: call to function 're_match_2_internal' without a real prototype [-Wunprototyped-calls]
regex.c:384:12: note: 're_match_2_internal' was declared here

Signed-off-by: Olaf Hering <olaf <at> aepfle.de>

diff -r c26dbc7021f4 -r 8743a4a6bd37 regex.c
--- a/regex.c
+++ b/regex.c
@@ -381,7 +381,9 @@ typedef char boolean;
 #define false 0
 #define true 1

-static int re_match_2_internal ();
+static int re_match_2_internal (struct re_pattern_buffer *bufp,
+	const char *string1, int size1, const char *string2, int size2, int pos,

[Mutt] #3564: can't choose certain public keys for encryption even when specifying the keyID

#3564: can't choose certain public keys for encryption even when specifying the
keyID
----------------------+-----------------------------------------------------
 Reporter:  likkk     |       Owner:  mutt-dev
     Type:  defect    |      Status:  new     
 Priority:  critical  |   Milestone:          
Component:  mutt      |     Version:  1.5.21  
 Keywords:            |  
----------------------+-----------------------------------------------------
 I get stuck when trying to send an encrypted mail after entering
 0xbc8002f3 as keyID... mutt keeps asking me for keyID. The key is in my
 keyring but it is not listed when entering nothing. You can fetch the key
 from the keyservers. Please help! Thank you!

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3564>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

[Mutt] #3563: NO Beep for New Messages, but "beep_new" is set

#3563: NO Beep for New Messages, but "beep_new" is set
-----------------------------------------+----------------------------------
 Reporter:  riderplus                    |       Owner:  mutt-dev
     Type:  defect                       |      Status:  new     
 Priority:  major                        |   Milestone:          
Component:  mutt                         |     Version:  1.5.21  
 Keywords:  beep; set beep_new; no beep  |  
-----------------------------------------+----------------------------------
 I use mutt on xterm, konsole and urxvt. I have "set beep_new=yes" in my
 ~/.muttrc, but there's no beep upon receiving new messages. I also have
 "set beep=yes", which works fine, as I get a beep when an error is
 encountered. I always get a notification "New message in inbox" when a new
 message is received, but no beep. It should have worked I think, since the
 variable is set. I have tried on a different computer with gnome-terminal,
 and no luck.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3563>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

Re: Trying to patch mutt to use gmail imap extension

On Sun, Jan 29, 2012 at 08:29:12PM +0900, Tamo wrote:
> Hi,
> 
> On Sun, Jan 29, 2012 at 5:28 PM, Todd Hoffmann <ddffnn <at> gmail.com> wrote:
> > I'm trying to patch mutt so that I can see each message's labels. The
> > gmail imap extension I want to use is described here:
> >
> > http://code.google.com/apis/gmail/imap/#x-gm-labels
> 
> Maybe you can use "spam", "$spam_separator" and "$imap_headers".
> 
> set imap_headers="X-GM-LABELS"
> spam "X-GM-LABELS:? \((.*)\)" "%1"
> set spam_separator=" "
> set index_format="%4C %Z %?H?[%H] ?%s"
> 
> (I haven't tested it yet)

The extension provides another attribute for the fetch command. The
X-GM-LABELS is not a header, so it can't be treated as such. 

> 
> 
> 
> > It seems like it would be easiest to just put the labels in the x-label
> > field. I started digging into the mutt code to implement this and
> > encountered some issues. The patch I've included does make the labels
> > appear in the message index if I include %y in the index_format setting,
> > but some seem to be encoded. I tried to figure out if I need to use
> > rfc2047_decode or something, but I haven't gotten anything to work so

Trying to patch mutt to use gmail imap extension

I'm trying to patch mutt so that I can see each message's labels. The
gmail imap extension I want to use is described here:

http://code.google.com/apis/gmail/imap/#x-gm-labels

It seems like it would be easiest to just put the labels in the x-label
field. I started digging into the mutt code to implement this and
encountered some issues. The patch I've included does make the labels
appear in the message index if I include %y in the index_format setting,
but some seem to be encoded. I tried to figure out if I need to use
rfc2047_decode or something, but I haven't gotten anything to work so
far. Worse still, it segfaults when changing from the inbox to some (not
all) other imap folders.

Can anyone give me some suggestions? Am I going about this the
completely wrong way?

diff -udprP mutt-1.5.21/imap/message.c mutt-1.5.21-patched/imap/message.c
--- mutt-1.5.21/imap/message.c	2010-08-24 09:34:21.000000000 -0700
+++ mutt-1.5.21-patched/imap/message.c	2012-01-29 00:05:29.000000000 -0700
@@ -242,7 +242,7 @@ int imap_read_headers (IMAP_DATA* idata,
       char *cmd;
 
       fetchlast = msgend + 1;
-      safe_asprintf (&cmd, "FETCH %d:%d (UID FLAGS INTERNALDATE RFC822.SIZE %s)",
+      safe_asprintf (&cmd, "FETCH %d:%d (UID FLAGS INTERNALDATE RFC822.SIZE X-GM-LABELS %s)",
                      msgno + 1, fetchlast, hdrreq);
       imap_cmd_start (idata, cmd);
       FREE (&cmd);

bug tracker issue

Folks, 

Not sure who's maintaining the bug tracker, but I sent a reply to
ticket #3561, and it seems as though the bug tracker is resubmitting
my response every hour or so.  I checked my logs to make sure my mail
server is not reposting the message, and indeed there is only one
record of it being sent, successfully, on Jan 20 11:13:33.  The mail
queue is empty.  Something's definitely out of whack on the bug
tracker...

--

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

[Mutt] #3562: with exchange 2010 IMAP -- tls_socket_read (A TLS packet with unexpected length was received)

#3562: with exchange 2010 IMAP  -- tls_socket_read (A TLS packet with unexpected
length was received)
---------------------------+------------------------------------------------
 Reporter:  jreidthompson  |       Owner:  mutt-dev
     Type:  defect         |      Status:  new     
 Priority:  major          |   Milestone:          
Component:  mutt           |     Version:          
 Keywords:                 |  
---------------------------+------------------------------------------------
 I get the subject error regularly which forces me to re-open the mailbox
 or, if i'm not paying close enough attention and hit the wrong keys, I end
 up *quitting* mutt and having to restart.

 $ mutt -v
 Mutt 1.5.21 (2010-09-15, Gentoo 1.5.21-r1)
 Copyright (C) 1996-2009 Michael R. Elkins and others.
 Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
 Mutt is free software, and you are welcome to redistribute it
 under certain conditions; type `mutt -vv' for details.

 System: Linux 2.6.39-gentoo-r3 (x86_64)
 ncurses: ncurses 5.9.20110404 (compiled with 5.9)
 hcache backend: GDBM version 1.8.3. 10/15/2002 (built Aug 11 2011
 08:15:46)
 Compile options:
 -DOMAIN
 +DEBUG
 -HOMESPOOL  -USE_SETGID  -USE_DOTLOCK  +DL_STANDALONE  -USE_FCNTL
 +USE_FLOCK
 +USE_POP  -USE_NNTP  +USE_IMAP  -USE_SMTP

[Mutt] #3561: Incorrect names of sent attachments with non-ascii characters

#3561: Incorrect names of sent attachments with non-ascii characters
--------------------+-------------------------------------------------------
 Reporter:  kolcon  |       Owner:  mutt-dev
     Type:  defect  |      Status:  new     
 Priority:  major   |   Milestone:          
Component:  mutt    |     Version:  1.5.21  
 Keywords:          |  
--------------------+-------------------------------------------------------
 When I send out email and add attachments, that contain non-ascii
 characters in the name (such as žluťoučký-kůň.txt),

 the name is not correctly viewed in some clients. For example Outlook
 2010+
 changes it into ATT-00185.txt or similar.

 When I send the same attachment from Thunderbird, the name is displayed on
 recipient side without problems.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3561>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

[Mutt] #3560: printf statement in mbox-hook

#3560: printf statement in mbox-hook
-----------------------------------+----------------------------------------
 Reporter:  kierun                 |       Owner:  mutt-dev
     Type:  enhancement            |      Status:  new     
 Priority:  major                  |   Milestone:          
Component:  mutt                   |     Version:          
 Keywords:  mbox-hook printf date  |  
-----------------------------------+----------------------------------------
 A while ago, there was a patch that allowed mbox-hook to have printf-liek
 statements.  This was really useful for archiving emails in different
 directories with a date in the directory name.

 Is this patch still around or has it been ported to the development
 version?

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3560>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

[Mutt] #3559: smime_keys.pl considers only first certificate of a chain

#3559: smime_keys.pl considers only first certificate of a chain
--------------------+-------------------------------------------------------
 Reporter:  andy    |       Owner:  mutt-dev
     Type:  defect  |      Status:  new     
 Priority:  minor   |   Milestone:          
Component:  crypto  |     Version:  1.5.21  
 Keywords:          |  
--------------------+-------------------------------------------------------
 When smime_keys.pl is used as smime_import_cert_command to add keys via
 the extract-keys function (Ctrl-K), it gets the whole certificate chain
 from the pkcs7 data (via smime_pk7out_command and smime_get_cert_command).
 Before 1.5.21, smime_keys.pl split the certificates and handled them as
 separate user certificates, which was wrong. Now it takes the chain as a
 whole, which is better (best would be automatically splitting it into leaf
 certificate and intermediate chain certificates, but that would be asking
 too much), but since it now calls openssl to extract information from the
 whole chain (e.g. "$opensslbin x509 -email" in line 469), it gets
 information for the first certificate in the chain, which may or may not
 be the user's certificate - mutt appends the intermediate certificates to
 the user certificate, other MUAs start the chain with the root CA, the
 user's certificate being last. This results in (at least) no .index entry
 if the root CA certificate has no associated email address, or even a
 wrong .index entry. A solution would require to split up the chain of
 certificates, to reconstruct the correct order and to apply the single-
 certificate-commands to the user's certificate - well, then we're almost
 at the aforementioned automatic handling of intermediate chain
 certificates.

 If you see this as a valid point, but are in need of someone to code it,
 I'd volunteer to give it a try...