1. Forum
  2. Usenet
  3. COMP.MISC

  • fix your mutt

    From Ben Collver@21:1/5 to All on Thu Mar 2 16:39:37 2023
    # Fix your mutt

    March 1, 2023

    At some point in the recent past, mutt changed the way it generates
    Message-ID header values. Instead of the perfectly good old way of
    doing it, the developers switched to using base64-encoded random
    bytes. The base64 dictionary contains the / character, which causes unnecessary difficulties when linking to these messages on
    lore.kernel.org, since the / character needs to be escaped as %2F for everything to work properly.

    Mutt developers seem completely [2]uninterested in changing this, so
    please save everyone a lot of trouble and do the following if you're
    using mutt for your kernel development needs (should work for all
    mutt versions):

    1. Create a ~/.mutt-hook-fix-msgid file with the following contents
    (change "mylaptop.local" to whatever you like):

    my_hdr Message-ID: <`uuidgen -r`@mylaptop.local>

    2. Add the following to your ~/.muttrc:

    send-hook . "source ~/.mutt-hook-fix-msgid"

    UPDATE: if you have mutt 2.1 or later you can alternatively set the [3]$message_id_format variable to restore the pre-mutt-2.0 behaviour:

    # mutt-2.1+ only
    set message_id_format = "<%Y%02m%02d%02H%02M%02S.G%c%p@%f>"

    Thanks to [4]Thomas Weißschuh for the suggestion! __________________________________________________________________

    References

    2. https://gitlab.com/muttmua/mutt/-/issues/400
    3. http://www.mutt.org/doc/manual/#message-id-format
    4. <https://public-inbox.org/meta/
    [email protected]/>
    5. https://writefreely.org/

    From: https://people.kernel.org/monsieuricon/fix-your-mutt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Ben Collver on Thu Mar 2 12:30:36 2023
    On 3/2/23 9:39 AM, Ben Collver wrote:
    # Fix your mutt

    IMHO Mutt doesn't need to be fixed.

    At some point in the recent past, mutt changed the way it generates Message-ID header values. Instead of the perfectly good old way of
    doing it, the developers switched to using base64-encoded random
    bytes. The base64 dictionary contains the / character, ...

    The use of the forward slash character in a Message-ID: is explicitly
    allowed in RFC 2822.

    § 3.6.4. Identification fields
    ...
    message-id = "Message-ID:" msg-id CRLF
    ...
    msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]

    id-left = dot-atom-text / no-fold-quote / obs-id-left

    id-right = dot-atom-text / no-fold-literal / obs-id-right
    ...

    § 3.2.4. Atom
    ...
    atext = ALPHA / DIGIT / ; Any character except controls,
    "!" / "#" / ; SP, and specials.
    "$" / "%" / ; Used for atoms
    "&" / "'" /
    "*" / "+" /
    "-" / "/" /
    "=" / "?" /
    "^" / "_" /
    "`" / "{" /
    "|" / "}" /
    "~"
    ...
    dot-atom-text = 1*atext *("." 1*atext)
    ...

    I don't see any problem with what the Mutt developers have done.

    Specifically

    Message-ID -> msg-id
    msg-id -> id-left / id-right
    id-left/id-right -> dot-atom-text
    dot-atom-text -> atext
    atest -> "/"

    ... which causes unnecessary difficulties when linking to these
    messages on lore.kernel.org, since the / character needs to be escaped
    as %2F for everything to work properly.

    This seems like a down stream implementation problem that doesn't
    properly handle something that's RFC compliant.

    Mutt developers seem completely [2]uninterested in changing this,

    I see no reason for the Mutt developers to change a perfectly valid and
    RFC compliant behavior.

    so please save everyone a lot of trouble and do the following if
    you're using mutt for your kernel development needs (should work for
    all mutt versions):

    I would suggest exploring other options to make your task simpler. Can
    you streamline the encoding, possibly with a helper?

    Take this up with the lore.kernel.org webmaster / hostmaster and ask
    them to set up something to more gracefully handle the "/" character.
    I'm confident that they can put some sort of rewrite in place to handle
    this more gracefully.

    This does not seem like a Mutt problem to me. What's more is that your proposed solution doesn't address any other MUAs that may behave in a
    similar RFC compliant manner.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Grant Taylor on Thu Mar 2 21:04:11 2023
    Grant Taylor <[email protected]> wrote:
    On 3/2/23 9:39 AM, Ben Collver wrote:
    # Fix your mutt

    IMHO Mutt doesn't need to be fixed.

    Agreed (at least given the info in the GP article).

    ... which causes unnecessary difficulties when linking to these
    messages on lore.kernel.org, since the / character needs to be escaped
    as %2F for everything to work properly.

    This seems like a down stream implementation problem that doesn't
    properly handle something that's RFC compliant.

    In fact, it also sounds like a possible 'lack of proper escaping'
    problem that just might open up an exploit somehow were someone looking
    to investigate the security implications.

    Take this up with the lore.kernel.org webmaster / hostmaster and ask
    them to set up something to more gracefully handle the "/" character.
    I'm confident that they can put some sort of rewrite in place to handle
    this more gracefully.

    Yes, this seems to be an issue to be fixed at the source, which is the
    lack of proper escaping in the lore.kernel.org code, not a mutt
    problem.

    Granted, yes, everyone could reconfigure their mutt (X*Y amount of
    work) or the problem could be fixed at the source (Z amount of work)
    and the size is Z is likely a lot smaller than X*Y and would also fix
    it for all MUA's, not just for mutt users who saw the message.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Rich on Fri Mar 3 08:04:21 2023
    Rich <[email protected]d> writes:
    Granted, yes, everyone could reconfigure their mutt (X*Y amount of
    work) or the problem could be fixed at the source (Z amount of work)
    and the size is Z is likely a lot smaller than X*Y and would also fix
    it for all MUA's, not just for mutt users who saw the message.

    Agreed. It’s not Mutt causing “unnecessary problems”, it’s the spec in RFC2822. I wouldn’t disagree that the syntax it permits for message IDs
    is much broader than it needs to be, but for as long as that is the
    syntax, consumers of message IDs are going to have to cope with it.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Theo@21:1/5 to Richard Kettlewell on Fri Mar 3 11:45:22 2023
    Richard Kettlewell <[email protected]d> wrote:
    Rich <[email protected]d> writes:
    Granted, yes, everyone could reconfigure their mutt (X*Y amount of
    work) or the problem could be fixed at the source (Z amount of work)
    and the size is Z is likely a lot smaller than X*Y and would also fix
    it for all MUA's, not just for mutt users who saw the message.

    Agreed. It’s not Mutt causing “unnecessary problems”, it’s the spec in
    RFC2822. I wouldn’t disagree that the syntax it permits for message IDs
    is much broader than it needs to be, but for as long as that is the
    syntax, consumers of message IDs are going to have to cope with it.

    To me, this is a bit like the 'spaces in filenames' issue. Yes, it's
    allowed to have spaces in filenames. Oftentimes they're a good idea (eg
    names of documents). But they're a PITA for command line users. So it's polite not to use them when you don't need to, especially when your audience might be interacting with your files via the command line.

    That said, the system still must have support for the relevant escaping
    where needed, because sooner or later somebody will emit a filename with a space in it or a Message-ID with a slash, and it mustn't break.

    But it's better to reduce the frequency of using that, purely for ease of
    use and politeness reasons.

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)