Re: [Mutt] #3897: Can't compile mutt 1.7.1 on an embedded NAS

[Mutt]

#3897: Can't compile mutt 1.7.1 on an embedded NAS
-+--
  Reporter:  mrdini  |  Owner:  mutt-dev
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:
 Component:  build   |Version:  1.7.1
Resolution:  |   Keywords:
-+--
Changes (by mrdini):

 * owner:  brendan => mutt-dev
 * component:  IMAP => build


--
Ticket URL: 
Mutt 
The Mutt mail user agent

[Mutt] #3897: Can't compile mutt 1.7.1 on an embedded NAS

[Mutt]

#3897: Can't compile mutt 1.7.1 on an embedded NAS
+-
 Reporter:  mrdini  |  Owner:  brendan
 Type:  defect  | Status:  new
 Priority:  major   |  Milestone:
Component:  IMAP|Version:  1.7.1
 Keywords:  |
+-
 Hi!

 I tried to compile the latest (1.7.1) mutt to my ARMv5 NAS, which has
 linux 2.6.31.8 kernel. The 1.4.* works nice...

 Here is the error message:


 {{{
 checking whether your system's regexp library is completely broken... no
 checking where new mail is stored... no
 configure: error: "Could not determine where new mail is stored."
 }}}

 What's wrong?

 Thanks!

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Legal values for a message-id, and references header

[Kevin J. McCarthy]

On #mutt, andrey_utkin_ reported getting a bounce trying to reply to a
linux-kernel mailing list email.  When he replied, vger.kernel.org
bounced it because of raw utf-8 in a header.

He posted a gist at


I don't know how long those hang around, but the problem is in the
References header: <201611170549.Q3WTfoMBþngguang...@intel.com>
contains the utf-8 character "þ".

Are any of you familiar with the rules for Mesage-ID and References
headers?  Should mutt be rfc-2047 encoding/decoding the references
header?  What about the domain part - should we be idn encoding that
part if $idn_encode is set?

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: [Mutt] #3897: Can't compile mutt 1.7.1 on an embedded NAS

[Mutt]

#3897: Can't compile mutt 1.7.1 on an embedded NAS
-+--
  Reporter:  mrdini  |  Owner:  mutt-dev
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:
 Component:  build   |Version:  1.7.1
Resolution:  |   Keywords:
-+--

Comment (by kevin8t8):

 By default, configure will look for /var/mail, /var/spool/mail,
 /usr/spool/mail, and /usr/mail.  If your spool mailboxes are not in one of
 those, you can specify it with the --with-mailpath argument.

 If mail is delivered to the home directory, you can specify the default
 place for delivery using --with-homespool instead.

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3897: Can't compile mutt 1.7.1 on an embedded NAS

[Mutt]

#3897: Can't compile mutt 1.7.1 on an embedded NAS
-+--
  Reporter:  mrdini  |  Owner:  mutt-dev
  Type:  defect  | Status:  closed
  Priority:  major   |  Milestone:
 Component:  build   |Version:  1.7.1
Resolution:  fixed   |   Keywords:
-+--
Changes (by mrdini):

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


Comment:

 Many thanks, the manual specify worked! :)

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: Legal values for a message-id, and references header

[Cameron Simpson]

On 19Nov2016 13:13, Kevin J. McCarthy  wrote:

On #mutt, andrey_utkin_ reported getting a bounce trying to reply to a
linux-kernel mailing list email.  When he replied, vger.kernel.org
bounced it because of raw utf-8 in a header.

He posted a gist at


I don't know how long those hang around, but the problem is in the
References header: <201611170549.Q3WTfoMBþngguang...@intel.com>
contains the utf-8 character "þ".

Are any of you familiar with the rules for Mesage-ID and References
headers?


Somewhat. Reviewing RFC 5322 right now to see how dated my knowledge is ...

 https://tools.ietf.org/rfcmarkup/5322


Should mutt be rfc-2047 encoding/decoding the references
header?


No. RFC2047 tokens need to be whitespace delimited from the surrounding text.  
No whitespace is permitted inside the "<" and ">" markers which enclose a 
message-id:


 https://tools.ietf.org/rfcmarkup/5322#section-3.6.4

The whitespace padding requirement is discussed in RFC2047 section 5:

 https://tools.ietf.org/rfcmarkup?doc=2047#section-5

The RFC5322 message-id syntax prevents using RFC2047.

I think the cited message-id is simply illegal and unfixable. Mutt should 
perhaps support it for stitching threads together, but arguably _not_ release 
such a thing into the wild in new References: or In-Reply-To: headers.



What about the domain part - should we be idn encoding that
part if $idn_encode is set?


Perhaps, if required. It looks like RFC3490's encoding is legal dot-text for 
RFC5322 (based on my reading of the Wikipedia article). The RFC is here:


 https://tools.ietf.org/rfcmarkup?doc=3490

and the article I've consulted has the relevant section here:

 
https://en.wikipedia.org/wiki/Internationalized_domain_name#ToASCII_and_ToUnicode

Cheers,
Cameron Simpson 

mutt: Updated French translation.

[Brendan Cully]

changeset: 6868:d14ffd58d976
user:  Vincent Lefevre 
date:  Sun Nov 20 01:41:49 2016 +0100
link:  http://dev.mutt.org/hg/mutt/rev/d14ffd58d976

Updated French translation.

diffs (124 lines):

diff -r 4bed0172c27b -r d14ffd58d976 po/fr.po
--- a/po/fr.po  Fri Nov 18 15:54:27 2016 -0800
+++ b/po/fr.po  Sun Nov 20 01:41:49 2016 +0100
@@ -21,8 +21,8 @@
 msgstr ""
 "Project-Id-Version: Mutt 1.7.1\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2016-11-18 18:09+0100\n"
-"PO-Revision-Date: 2016-11-18 18:15+0100\n"
+"POT-Creation-Date: 2016-11-20 01:32+0100\n"
+"PO-Revision-Date: 2016-11-20 01:40+0100\n"
 "Last-Translator: Vincent Lefevre \n"
 "Language-Team: Vincent Lefevre \n"
 "Language: fr\n"
@@ -130,8 +130,8 @@
 msgid "Mailcap compose entry requires %%s"
 msgstr "L'entrée compose du fichier mailcap nécessite %%s"
 
-#: attach.c:134 attach.c:266 commands.c:223 compose.c:1233 curs_lib.c:205
-#: curs_lib.c:724
+#: attach.c:134 attach.c:266 commands.c:223 compose.c:1233 compress.c:444
+#: curs_lib.c:205 curs_lib.c:724
 #, c-format
 msgid "Error running \"%s\"!"
 msgstr "Erreur en exécutant \"%s\" !"
@@ -822,11 +822,6 @@
 msgid "PGP already selected. Clear & continue ? "
 msgstr "PGP déjà sélectionné. Effacer & continuer ? "
 
-#: compress.c:444
-#, c-format
-msgid "Error executing: %s\n"
-msgstr "Erreur à l'exécution de : %s\n"
-
 #: compress.c:481 compress.c:551 compress.c:706 compress.c:895 mbox.c:847
 msgid "Unable to lock mailbox!"
 msgstr "Impossible de verrouiller la boîte aux lettres !"
@@ -872,10 +867,10 @@
 msgid "Compressing %s..."
 msgstr "Compression de %s..."
 
-#: compress.c:660
-#, c-format
-msgid " %s: Error compressing mailbox!  Uncompressed one kept!\n"
-msgstr " %s: Erreur en compressant la BAL ! BAL décompressée gardée !\n"
+#: compress.c:660 editmsg.c:210
+#, c-format
+msgid "Error. Preserving temporary file: %s"
+msgstr "Erreur. Préservation du fichier temporaire : %s"
 
 #: compress.c:885
 msgid "Can't sync a compressed file without a close-hook"
@@ -1818,7 +1813,7 @@
 msgstr "Marquer les messages correspondant à : "
 
 #. L10N: CHECK_ACL
-#: curs_main.c:1061 curs_main.c:2339 pager.c:2772
+#: curs_main.c:1061 curs_main.c:2349 pager.c:2772
 msgid "Cannot undelete message(s)"
 msgstr "Impossible de récupérer le(s) message(s)"
 
@@ -1966,21 +1961,35 @@
 msgstr "Impossible de marquer le(s) message(s) comme lu(s)"
 
 # , c-format
-#: curs_main.c:2218
+#. L10N: This is the prompt for .  Whatever they
+#. enter will be prefixed by $mark_macro_prefix and will become
+#. a macro hotkey to jump to the currently selected message.
+#: curs_main.c:2221
 msgid "Enter macro stroke: "
 msgstr "Entrez les touches de la macro : "
 
-#: curs_main.c:2226
+#. L10N: "message hotkey" is the key bindings menu description of a
+#. macro created by .
+#: curs_main.c:2229
+msgid "message hotkey"
+msgstr "hotkey (marque-page)"
+
+#. L10N: This is echoed after  creates a new hotkey
+#. macro.  %s is the hotkey string ($mark_macro_prefix followed
+#. by whatever they typed at the prompt.)
+#: curs_main.c:2234
 #, c-format
 msgid "Message bound to %s."
 msgstr "Message lié à %s."
 
-#: curs_main.c:2232
+#. L10N: This error is printed if  cannot find a
+#. Message-ID for the currently selected message in the index.
+#: curs_main.c:2242
 msgid "No message ID to macro."
 msgstr "Pas de Message-ID pour la macro."
 
 #. L10N: CHECK_ACL
-#: curs_main.c:2309 pager.c:2755
+#: curs_main.c:2319 pager.c:2755
 msgid "Cannot undelete message"
 msgstr "Impossible de récupérer le message"
 
@@ -2110,11 +2119,6 @@
 msgid "Can't append to folder: %s"
 msgstr "Impossible d'ajouter au dossier : %s"
 
-#: editmsg.c:210
-#, c-format
-msgid "Error. Preserving temporary file: %s"
-msgstr "Erreur. On préserve le fichier temporaire : %s"
-
 # , c-format
 #: flags.c:346
 msgid "Set flag"
@@ -5353,8 +5357,8 @@
 msgstr "démarquer les messages correspondant à un motif"
 
 #: ../keymap_alldefs.h:138
-msgid "create a hot-key macro for the current message"
-msgstr "créer un marque-page (hot-key macro) pour le message courant"
+msgid "create a hotkey macro for the current message"
+msgstr "créer une macro hotkey (marque-page) pour le message courant"
 
 #: ../keymap_alldefs.h:139
 msgid "move to the middle of the page"

Re: mutt: Adds binding to create "hotkeys" for messages.

[Vincent Lefevre]

On 2016-11-18 09:57:33 -0800, Kevin J. McCarthy wrote:
> Answering my own question: no.  Inside the pager, the  operation
> searches for text in the message.  I suppose we could have it  in
> the pager version, but I think that might be more likely to confuse
> someone.

I agree. And the macro can be added by the user if he really wants
that.

> So I think the fix here is just to change MENU_GENERIC to MENU_MAIN.
> 
> I'll fix that and the translation messages and push a fix later today.

Thanks. I confirm that this works.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [Mutt] #3870: openssl 1.1

[Mutt]

#3870: openssl 1.1
--+--
  Reporter:  tamo |  Owner:  mutt-dev
  Type:  task | Status:  reopened
  Priority:  trivial  |  Milestone:
 Component:  build|Version:  1.7.0
Resolution:   |   Keywords:  ssl
--+--

Comment (by kevin8t8):

 X509->name appears to have been a shortcut for
 X509_NAME_oneline(X509_get_subject_name (cert))

 This is only used in debugging.  I've moved printing this out into
 ssl_check_certificate() and pulled it out of the other places.

--
Ticket URL: 
Mutt 
The Mutt mail user agent

mutt: More openssl1.1 fixes: remove uses of X509->name in debugg...

[Brendan Cully]

changeset: 6869:695243ba6374
user:  Kevin McCarthy 
date:  Sat Nov 19 19:35:07 2016 -0800
link:  http://dev.mutt.org/hg/mutt/rev/695243ba6374

More openssl1.1 fixes: remove uses of X509->name in debugging. (closes #3870)

X509->name was a shortcut for the longer
  name = X509_NAME_oneline (X509_get_subject_name (cert),
buf, sizeof (buf));
invocation.  Change the debugging to print the cert name and chain
names in the ssl_check_certificate() loop instead.

diffs (62 lines):

diff -r d14ffd58d976 -r 695243ba6374 mutt_ssl.c
--- a/mutt_ssl.cSun Nov 20 01:41:49 2016 +0100
+++ b/mutt_ssl.cSat Nov 19 19:35:07 2016 -0800
@@ -666,7 +666,6 @@
 snprintf (buf, sizeof (buf), "%s (%d)",
X509_verify_cert_error_string(err), err);
 dprint (2, (debugfile, "X509_verify_cert: %s\n", buf));
-dprint (2, (debugfile, " [%s]\n", peercert->name));
   }
 #endif
   X509_STORE_CTX_free (xsc);
@@ -914,7 +913,7 @@
 
 static int ssl_cache_trusted_cert (X509 *c)
 {
-  dprint (1, (debugfile, "trusted: %s\n", c->name));
+  dprint (1, (debugfile, "ssl_cache_trusted_cert: trusted\n"));
   if (!SslSessionCerts)
 SslSessionCerts = sk_X509_new_null();
   return (sk_X509_push (SslSessionCerts, X509_dup(c)));
@@ -967,6 +966,13 @@
   int i, preauthrc, chain_len;
   STACK_OF(X509) *chain;
   X509 *cert;
+#ifdef DEBUG
+  char buf[STRING];
+
+  dprint (1, (debugfile, "ssl_check_certificate: checking cert %s\n",
+  X509_NAME_oneline (X509_get_subject_name (data->cert),
+ buf, sizeof (buf;
+#endif
 
   if ((preauthrc = ssl_check_preauth (data->cert, conn->account.host)) > 0)
 return preauthrc;
@@ -983,6 +989,10 @@
   {
 cert = sk_X509_value (chain, i);
 
+dprint (1, (debugfile, "ssl_check_certificate: checking cert chain entry 
%s\n",
+X509_NAME_oneline (X509_get_subject_name (cert),
+   buf, sizeof (buf;
+
 /* if the certificate validates or is manually accepted, then add it to
  * the trusted set and recheck the peer certificate */
 if (ssl_check_preauth (cert, NULL)
@@ -1009,8 +1019,6 @@
   FILE *fp;
   char *name = NULL, *c;
 
-  dprint (2, (debugfile, "interactive_check_cert: %s\n", cert->name));
-
   menu->max = 19;
   menu->dialog = (char **) safe_calloc (1, menu->max * sizeof (char *));
   for (i = 0; i < menu->max; i++)
@@ -1021,7 +1029,6 @@
   row++;
   name = X509_NAME_oneline (X509_get_subject_name (cert),
buf, sizeof (buf));
-  dprint (2, (debugfile, "oneline: %s\n", name));
 
   for (i = 0; i < 5; i++)
   {

Re: [Mutt] #3870: openssl 1.1

[Mutt]

#3870: openssl 1.1
--+--
  Reporter:  tamo |  Owner:  mutt-dev
  Type:  task | Status:  closed
  Priority:  trivial  |  Milestone:
 Component:  build|Version:  1.7.0
Resolution:  fixed|   Keywords:  ssl
--+--
Changes (by Kevin McCarthy ):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"695243ba637465dc3822df1ff152091bc52b9ec8"
 6869:695243ba6374]:
 {{{
 #!CommitTicketReference repository=""
 revision="695243ba637465dc3822df1ff152091bc52b9ec8"
 More openssl1.1 fixes: remove uses of X509->name in debugging. (closes
 #3870)

 X509->name was a shortcut for the longer
   name = X509_NAME_oneline (X509_get_subject_name (cert),
 buf, sizeof (buf));
 invocation.  Change the debugging to print the cert name and chain
 names in the ssl_check_certificate() loop instead.
 }}}

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: Legal values for a message-id, and references header

[Kevin J. McCarthy]

On Sun, Nov 20, 2016 at 10:08:13AM +1100, Cameron Simpson wrote:
> On 19Nov2016 13:13, Kevin J. McCarthy  wrote:
> > Should mutt be rfc-2047 encoding/decoding the references
> > header?
> 
> No. RFC2047 tokens need to be whitespace delimited from the surrounding
> text.  No whitespace is permitted inside the "<" and ">" markers which
> enclose a message-id:

Thank you for your detailed analysis, Cameron.  I will take a deeper
look at this soon.  Another piece of information is that they sent a
reply through the Fastmail web interface, which sent this:

  References: =?utf-8?Q?=3C201611170549=2EQ3WT?=
=?utf-8?Q?foMB=C3=83=C2=BEngguang=2Ewu=40i?=
=?utf-8?Q?ntel=2Ecom=3E=20=3C1479410?= =?utf-8?Q?777-6702-1-git-sen?=
=?utf-8?Q?d-email-manuel=2Esch?= =?utf-8?Q?oelling=40gmx=2Ede=3E?=

  

If this is legal, then mutt needs to be decoding the References before
trying to parse out the ids, because I believe it will just choke on
this.

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Legal values for a message-id, and references header

[Cameron Simpson]

On 19Nov2016 19:58, Kevin J. McCarthy  wrote:

On Sun, Nov 20, 2016 at 10:08:13AM +1100, Cameron Simpson wrote:

On 19Nov2016 13:13, Kevin J. McCarthy  wrote:
> Should mutt be rfc-2047 encoding/decoding the references
> header?

No. RFC2047 tokens need to be whitespace delimited from the surrounding
text.  No whitespace is permitted inside the "<" and ">" markers which
enclose a message-id:


Thank you for your detailed analysis, Cameron.  I will take a deeper
look at this soon.  Another piece of information is that they sent a
reply through the Fastmail web interface, which sent this:

 References: =?utf-8?Q?=3C201611170549=2EQ3WT?=
   =?utf-8?Q?foMB=C3=83=C2=BEngguang=2Ewu=40i?=
   =?utf-8?Q?ntel=2Ecom=3E=20=3C1479410?= =?utf-8?Q?777-6702-1-git-sen?=
   =?utf-8?Q?d-email-manuel=2Esch?= =?utf-8?Q?oelling=40gmx=2Ede=3E?=

 

If this is legal, then mutt needs to be decoding the References before
trying to parse out the ids, because I believe it will just choke on
this.


Wow. I would have thought that was illegal.

Regarding the discussion below, the TL;DR is that I think that if it is 
feasible mutt should decode these, but write _unencoded_ versions of these 
headers and any headers derived from them. In particular, is it easy to make 
mutt's header ingestion code go "stict parse, but if that fails decode with 
RFC2047 and try a second time"? Probably on a specific header basis.


Regarding the standards:

RFC2047 doesn't actually enumerate specific headers, but second 5 has a list of 
permitted and forbidden places for "encoded-words" (which the above are). I'm 
going to quote the bits I think are pertinent but please read it to see if I'm 
missing anything:


An 'encoded-word' may appear in a message header or body part header according 
to the following rules:


(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822) in 
any Subject or Comments header field, any extension message header field, or 
any MIME body part field for which the field body is defined as '*text'.  An 
'encoded-word' may also appear in any user-defined ("X-") message or body part 
header field.


Message-IDs are not "text" in RFC822 and its modern form RFC5322. So I'd say 
(1) does not permit this. A 'text' token is defined as:


  text=   %d1-9 /; Characters excluding CR
  %d11 / ;  and LF
  %d12 /
  %d14-127

(1) _does_ say "any MIME body part field for which the field body is defined as 
'*text'". But '*text' means zero or more 'text' tokens, and Message-ID: et al 
are not MIME fields.


(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and ")", 
i.e., wherever a 'ctext' is allowed.  More precisely, the RFC 822 ABNF 
definition for 'comment' is amended as follows:


 comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"

This doesn't cover Message-IDs.

(3) As a replacement for a 'word' entity within a 'phrase', for example, one 
that precedes an address in a From, To, or Cc header.  The ABNF definition for 
'phrase' from RFC 822 thus becomes:


 phrase = 1*( encoded-word / word )

But a 'phrase' is just one of more 'word's and Message-IDs are not 'word's. The 
RFC2047 goes on to say that _any_ other use is forbidden, and tries to be 
really clear about that:


These are the ONLY locations where an 'encoded-word' may appear.  In 
particular:


+ An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.

+ An 'encoded-word' MUST NOT appear within a 'quoted-string'.

+ An 'encoded-word' MUST NOT be used in a Received header field.

+ An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or 
Content-Disposition field, or in any structured field body except within a 
'comment' or 'phrase'.


So I think fastmail are playing fast and loose, and while mutt should try to 
cope, it sure as hell should never _emit_ this nonsense!


Cheers,
Cameron Simpson