Re: [PATCH] Add %F expando to $message_id_format to use from address.

[Kevin J. McCarthy]

On Mon, Aug 03, 2026 at 01:12:46PM +0200, Alejandro Colomar via Mutt-dev wrote:

From: "Kevin J. McCarthy" <ke...@8t8.us>
+static const char *ALLOWED_FROM_CHARS = "abcdefghijklmnopqrstuvwxyz"
+                                        "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
+                                        "1234567890-_.";

I suggest a more generic name for this, which documents the fact that
this is the POSIX Portable Filename Character Set.  Also, I suggest
using intermediate character sets that have a well-known name, to make
it easier to distinguish each character set.

        #define CTYPE_LOWER_C          "abcdefghijklmnopqrstuvwxyz"
        #define CTYPE_UPPER_C          "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
        #define CTYPE_DIGIT_C          "0123456789"
        #define CTYPE_ALPHA_C          CTYPE_LOWER_C CTYPE_UPPER_C
        #define CTYPE_ALNUM_C          CTYPE_ALPHA_C CTYPE_DIGIT_C
        #define CTYPE_PFCHAR_C         CTYPE_ALNUM_C "._-"  // portable 
filename character set

Thanks Alex. I'll add a pre-patch with this to the series and send it out later today for feedback.

+
+/* This function is much stricter than RFC5322 specifies, because we also want
+ * the message-id to be passed in a URL as a path segment or parameter without
+ * needing encoding.
+ */
+static void filter_from_addr(char *from)
+{
+  int has_at = 0;
+
+  if (!from)
+    return;
+
+  while (*from)
+  {
+    if (*from == '@' && !has_at)
+      has_at = 1;
+    else if (!strchr(ALLOWED_FROM_CHARS, *from))

And then here I suggest adding another API, inspired by isascii(3):

        // isascii_c - is [:ascii:] C-locale
        #define ispfchar_c(c)  (!streq(strchrnul(CTYPE_PFCHAR_C, c), ""))

        #define streq(s1, s2)  (!strcmp(s1, s2))

To be able to write it as

        else if (!ispfchar_c(*from))

I remember the earlier discussion on mutt-dev about this. I'm going to hold off on this suggestion, as I remember strchrnul() is not standardized, and the fallback suggestions relied on non-standard ?: operators, etc. The nul's are explicitly checked for in this case, so I don't think it's worth it to dig into that for this case. (But of course I'll swap out to use CTYPE_PFCHAR_C)

+      *from = '_';
+    from++;
+  }
+}

In any case, the above seems okay.

Thanks again!

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

signature.asc
Description: PGP signature