Re: [PATCH 0/2] A couple IDNA related fixes
Arnt Gulbrandsen <[email protected]> Tue, 30 Jun 2026 13:29:34 +0000
| Newsgroups | gmane.mail.mutt.devel |
|---|---|
| Message-ID | <[email protected]> |
--da1535eb-6a0f-488c-aa1a-b45b12ac3e5a-1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I think this takes mutt further in the wrong direction. Using xn-- in = headers moves mutt further towards the walled-garden approach, where = users don't get to grep or awk their data, they access it through the UI. People and software are fairly good at handling UTF8-encoded strings. I = have a few subdirectory trees with MH and maildir format (yes, both, = long story). I can grep in those, not a problem, except when there's = Subject: =3D?b?abcd?=3D or From: [email protected]. Mutt seems to me the = kind of client that ought to facilitate grepping, not the kind that = should lean into =3D?b?...?=3D or xn--=E2=80=A6 encoding. xn-- is IMO even a tick worse than b64, since substring grepping is even = more difficult. Arnt May 21, 2026 at 3:40 AM, "Kevin J. McCarthy" <[email protected] mailto:kevin@8= t8.us?to=3D%22Kevin%20J.%20McCarthy%22%20%3Ckevin%408t8.us%3E > wrote: >=20 > On Fri, May 15, 2026 at 08:28:07PM +0800, Kevin J. McCarthy wrote: >=20 > >=20 > > The first patch does some cleanup in the send email path. It puts > > mutt_env_to_intl() before the mutt_prepare_envelope(), like everywher= e > > else in the codebase. This also plugs a theoretical issue where the > > Mail-Followup-To didn't come from an already IDNA encoded address, = such > > as mutt_default_from(). > >=20 > > The second one fixes a bug with gpg key lookups with intl domains. > >=20 > > On a related note, Mutt's IDNA handling is quite basic right now. > > Parsed addresses are stored in IDNA format, and only converted to = local > > when viewing or editing. I believe hooks, patterns, and regexps (e.g. > > subscribe/lists) need to be specified in IDNA to work. This is on my > > "future" list to look at. > >=20 > I pushed these up a few days ago, but forgot to mail the list. >=20 > --=20 > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA > --da1535eb-6a0f-488c-aa1a-b45b12ac3e5a-1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><head><meta http-equiv=3D"Content-Type" content=3D"t= ext/html; charset=3Dutf-8"></head><body><div>Hi,</div><div><br></div><div= >I think this takes mutt further in the wrong direction. Using xn-- in = headers moves mutt further towards the walled-garden approach, where = users don't get to grep or awk their data, they access it through the = UI.<br></div><div><br></div><div>People and software are fairly good at = handling UTF8-encoded strings. I have a few subdirectory trees with MH = and maildir format (yes, both, long story). I can grep in those, not a = problem, except when there's <span style=3D'font-family: "DejaVu Sans = Mono", "DejaVu LGC Sans Mono", "Bitstream Vera Sans Mono", "Lucida = Console", Monaco, monospace;'>Subject: =3D?b?abcd?=3D</span> or <span = style=3D'font-family: "DejaVu Sans Mono", "DejaVu LGC Sans Mono", = "Bitstream Vera Sans Mono", "Lucida Console", Monaco, monospace;'>From: = [email protected]</span>. Mutt seems to me the kind of client that ought = to facilitate grepping, not the kind that should lean into =3D?b?...?=3D = or xn--=E2=80=A6 encoding.</div><div><br></div><div>xn-- is IMO even a = tick worse than b64, since substring grepping is even more difficult.</di= v><div><br></div><div>Arnt</div><div><br></div><p>May 21, 2026 at 3:40 = AM, "Kevin J. McCarthy" <<a href=3D"mailto:[email protected]?to=3D%22Kevin%= 20J.%20McCarthy%22%20%3Ckevin%408t8.us%3E" target=3D"_blank" tabindex=3D"= -1">[email protected]</a>> wrote:</p><blockquote>On Fri, May 15, 2026 at = 08:28:07PM +0800, Kevin J. McCarthy wrote:<br><blockquote>The first = patch does some cleanup in the send email path. It puts<br>mutt_env_to_i= ntl() before the mutt_prepare_envelope(), like everywhere<br>else in the = codebase. This also plugs a theoretical issue where the<br>Mail-Followup= -To didn't come from an already IDNA encoded address, such<br>as = mutt_default_from().<br><br>The second one fixes a bug with gpg key = lookups with intl domains.<br><br>On a related note, Mutt's IDNA = handling is quite basic right now.<br>Parsed addresses are stored in = IDNA format, and only converted to local<br>when viewing or editing. I = believe hooks, patterns, and regexps (e.g.<br>subscribe/lists) need to = be specified in IDNA to work. This is on my<br>"future" list to look = at.</blockquote><br>I pushed these up a few days ago, but forgot to mail = the list.<br><br>-- <br>Kevin J. McCarthy<br>GPG Fingerprint: 8975 A9B3 = 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA</blockquote><div><br></div></bod= y></html> --da1535eb-6a0f-488c-aa1a-b45b12ac3e5a-1--