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: =?b?abcd?= or From: [email protected]. Mutt seems to me the kind of client that ought to facilitate grepping, not the kind that should lean into =?b?...?= or xn--… 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:[email protected]?to=%22Kevin%20J.%20McCarthy%22%20%3Ckevin%408t8.us%3E > wrote: > > On Fri, May 15, 2026 at 08:28:07PM +0800, Kevin J. McCarthy wrote: > > > > > The first patch does some cleanup in the send email path. It puts > > mutt_env_to_intl() before the mutt_prepare_envelope(), like everywhere > > 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(). > > > > The second one fixes a bug with gpg key lookups with intl domains. > > > > 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. > > > I pushed these up a few days ago, but forgot to mail the list. > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA >
