headers
Phil Pennock | 1 Aug 2011 13:18

[patch] Send TLS SNI when setting up TLS

TLS supports sending the expected server hostname during the handshake,
via the SNI extension.  This can be used to select a server certificate
to issue to the client, permitting virtual-hosting without requiring
multiple IP addresses.

I had this lying around in my hg checkout for, uhm, a couple of years; I
never tested it, because I don't know of any IMAP servers which actually
use this, but it's hopefully correct-by-inspection.  I made similar
changes back then to a number of other pieces of software, so this was
one of a set and all the others worked fine.

FWIW, this was part of the binary I used for testing the next patch I'll
post, which was tested in connecting to Gmail with IMAPS, so it didn't
break connecting to Gmail.

At some point (far down my todo list), I'm likely to add SNI server-side
support to Exim as an MTA, so I'll be happy to have mutt as a client for
the SMTP/TLS side of that.

Regards,
-Phil
Attachment (mutt-tlssni.patch): text/x-diff, 3036 bytes
Permalink | Reply | 3 comments |
headers
Phil Pennock | 1 Aug 2011 13:39

Gmail custom search support

Gmail's IMAP support has an extension, described at:
  http://code.google.com/apis/gmail/imap/
which lets you use the "X-GM-RAW" search attribute.  This will
interpret its string as a Gmail search, exposing (most of) the advanced
search operators via IMAP.

[disclosure: I am a former Google employee; I get nothing for adding
 this support to mutt, it's purely for personal convenience]

This patch adds the =/ operator to invoke this.  Mnemonic: '=' for
server-side search, '/' for the Gmail keyboard shortcut to move to the
search box.  And it was one of the few options still available. :)

Note that to get the nearest equivalence to typing into the search box,
you first need to navigate to the "[Gmail]/All Mail" folder; by default,
the IMAP server-side implementation seems to add folder constraints,
which is obviously correct for IMAP -- you can't return message
references that don't make sense in a given context.

I've tested it against my Gmail account, seems to work for me.

So:
  =/ "some arbitrary search string"
  =/ "has:attachment from:spodhuis.org"
etc etc etc.  See also:
  http://mail.google.com/support/bin/answer.py?answer=7190
It appears that chats are not integrated into IMAP, so is:chat returns
no results.  "is:starred" works, "has:<colour>-<startype>" does not.
Doubtless there are other differences, but that's not mutt's problem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brendan Cully | 1 Aug 2011 19:53
Gravatar

Re: [patch] Send TLS SNI when setting up TLS

On Monday, 01 August 2011 at 07:18, Phil Pennock wrote:
> TLS supports sending the expected server hostname during the handshake,
> via the SNI extension.  This can be used to select a server certificate
> to issue to the client, permitting virtual-hosting without requiring
> multiple IP addresses.
> 
> I had this lying around in my hg checkout for, uhm, a couple of years; I
> never tested it, because I don't know of any IMAP servers which actually
> use this, but it's hopefully correct-by-inspection.  I made similar
> changes back then to a number of other pieces of software, so this was
> one of a set and all the others worked fine.
> 
> FWIW, this was part of the binary I used for testing the next patch I'll
> post, which was tested in connecting to Gmail with IMAPS, so it didn't
> break connecting to Gmail.
> 
> At some point (far down my todo list), I'm likely to add SNI server-side
> support to Exim as an MTA, so I'll be happy to have mutt as a client for
> the SMTP/TLS side of that.
> 
> Regards,
> -Phil
> diff --git a/mutt_ssl.c b/mutt_ssl.c 
> +++ b/mutt_ssl.c
>  <at>  <at>  -344,6 +344,20  <at>  <at>  static int ssl_negotiate (CONNECTION *co
>    SSL_set_mode (ssldata->ssl, SSL_MODE_AUTO_RETRY);
>  #endif
>  
> +#if OPENSSL_VERSION_NUMBER >= 0x0090806fL && !defined(OPENSSL_NO_TLSEXT)
> +  /* TLS Virtual-hosting requires that the server present the correct
(Continue reading)

Permalink | Reply | 2 comments |
headers
Phil Pennock | 2 Aug 2011 01:02

Re: [patch] Send TLS SNI when setting up TLS

On 2011-08-01 at 10:53 -0700, Brendan Cully wrote:
> On Monday, 01 August 2011 at 07:18, Phil Pennock wrote:
> > +#if OPENSSL_VERSION_NUMBER >= 0x0090806fL && !defined(OPENSSL_NO_TLSEXT)

> I'd prefer an autoconf test for SSL_set_tlsext_host_name instead of
> the version check above. I think it's more reliable.

Hrm, it's not a cross-vendor issue of testing for availability, since
there's only one origin piece of software and they document its origin.

Life's too short to willingly deal with autoconf, so I'll let this one
drop.  Ah well.

-Phil
Permalink | Reply | 1 comment |
headers
Bernard Lang | 1 Aug 2011 13:34

an email crashed my mutt


Hi,

I have been a long time user of mutt, and I just received an email
that crashes it.

I did not understand how to report in the bug tracking system.

So I am just sending the faulty email as attachement, after gzipping
it to prevent any problem.

Technical info about my version, from mutt -v :

Mutt 1.5.21 (2010-09-15)
Copyright (C) 1996-2009 Michael R. Elkins et autres.

System: Linux 2.6.38.8-server-4.mga (i686)
ncurses: ncurses 5.7.20100925 (compiled with 5.7)
hcache backend: Berkeley DB 4.8.30: (March 25, 2011)
Options de compilation :
-DOMAIN
-DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_NNTP  +USE_IMAP  +USE_SMTP  
+USE_SSL_OPENSSL  -USE_SSL_GNUTLS  +USE_SASL  -USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  +COMPRESSED  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  -CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brendan Cully | 3 Aug 2011 01:04
Gravatar

Re: [patch] Send TLS SNI when setting up TLS

On Monday, 01 August 2011 at 19:02, Phil Pennock wrote:
> On 2011-08-01 at 10:53 -0700, Brendan Cully wrote:
> > On Monday, 01 August 2011 at 07:18, Phil Pennock wrote:
> > > +#if OPENSSL_VERSION_NUMBER >= 0x0090806fL && !defined(OPENSSL_NO_TLSEXT)
> 
> > I'd prefer an autoconf test for SSL_set_tlsext_host_name instead of
> > the version check above. I think it's more reliable.
> 
> Hrm, it's not a cross-vendor issue of testing for availability, since
> there's only one origin piece of software and they document its origin.

It's still better to test for functionality directly, instead of going
by a version number (the additional OPENSSL_NO_TSLEXT hints at
this).

> Life's too short to willingly deal with autoconf, so I'll let this one
> drop.  Ah well.

AC_CHECK_FUNCS would have done the job pretty easily. Ah well.
Permalink | Reply | 0 comments |
headers
Vincent Lefevre | 3 Aug 2011 11:12

Re: an email crashed my mutt

Hi,

On 2011-08-01 13:34:59 +0200, Bernard Lang wrote:
> I have been a long time user of mutt, and I just received an email
> that crashes it.
> 
> I did not understand how to report in the bug tracking system.
> 
> So I am just sending the faulty email as attachement, after gzipping
> it to prevent any problem.

With my own version of Mutt (based on the hg rev 6194), I don't have
any problem with it.

Can you reproduce the crash? If yes, you can try to rebuild Mutt from
the hg repository.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Permalink | Reply | 1 comment |
headers
Bernard Lang | 3 Aug 2011 16:18

Re: an email crashed my mutt

Bonjour,

Thank you for the fast reply.

It is not a major problem for me. I only thought I should mention the
problem to the team.

And rebuilding a mutt is going to tax my long lost competence on
rebuilding anything ... other than Lego towers for my grand son.

This mail still crashes my mutt when I try to open it : a long wait
followed by a crash - segmentation error.  (I have been rebooting the
system since I wrote to you).

I remember I had problem before with some mails from china, on a
previous version of mutt and of linux. They seemed related to the
character set used.  But I would not swear it.

If you do not think this is important ... please just ignore my mail.

amicalement,

Bernard

PS je réponds en anglais pour le principe ... je suppose qu'il y a
d'autres lecteurs.

* Vincent Lefevre <vincent <at> vinc17.org>, le 03-08-11, a écrit:
> Hi,
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 6 Aug 2011 13:05

Re: [Mutt] #3522: Can't open mailbox with spaces in name

#3522: Can't open mailbox with spaces in name
----------------------+-----------------------------------------------------
  Reporter:  strk     |       Owner:  mutt-dev
      Type:  defect   |      Status:  closed  
  Priority:  major    |   Milestone:          
 Component:  mutt     |     Version:  1.5.20  
Resolution:  invalid  |    Keywords:          
----------------------+-----------------------------------------------------
Changes (by dirkwallenstein):

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

Comment:

 Ah, forgot that. It works like this:

 {{{
 macro index ZZZ <change-folder>=with<quote-char><space>inside
 }}}

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3522#comment:4>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 0 comments |
headers
Mutt | 15 Aug 2011 00:31

[Mutt] #3534: set record doesn't update when in compose dialog

#3534: set record doesn't update when in compose dialog
----------------------+-----------------------------------------------------
 Reporter:  Erulisse  |       Owner:  mutt-dev
     Type:  defect    |      Status:  new     
 Priority:  minor     |   Milestone:          
Component:  mutt      |     Version:          
 Keywords:            |  
----------------------+-----------------------------------------------------
 Here is my sample macro.
 macro compose Y "<enter-command>unset record<enter><enter-command>set
 record="+Waiting Response"<enter><send-message>"

 the macro seems to work correctly, it sets record to +Waiting and then
 sends the message, However when the email is sent the old record variable
 is used. The new record variable is not used until a Second email is
 composed.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3534>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
Permalink | Reply | 2 comments |

Gmane