Hi Derek, On Thu, Apr 18, 2024 at 11:59:29PM GMT, Alejandro Colomar wrote: > Hi Derek, > > On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote: > > g. Protecting the recipients is problematic for potentially several > > reasons--it prevents people from interacting normally with > > threads and their recipients. The SMTP envelope needs at least > > the recipient you're actually sending to in that specific SMTP > > session, and the MTA will add the recipient's address in a > > Received header, so hiding that at least is pointless. But if > > Mutt added these features it would be the only client to do so > > (AFAIK) making it very difficult for anyone using any other > > client to deal with. You couldn't simply "reply-all" to, well, > > reply to all... And again, you can just send separate messages. > > And if you really don't want your recipients to know about each > > other, then you shouldn't be sending them the same message > > anyway! Avoid any possibility of embarrassment or worse--send > > separate messages. > > I don't think you've understood the issue at all. > > Protecting the recipients and the in-reply-to doesn't mean hiding it. > It means providing a copy inside the signed part, so that it can be > verified against tampering. It's not about encrypting them. > > So, if I manage you to send me a message saying "Yeah, go ahead.", and > I change the recipient and in-reply-to header fields, I could maybe > convince someone that you said yes to a different thread. Does that > not look like a security problem to you? Well, that's fine. > > BTW, mutt(1) is already incompatible with e.g. thunderbird(1) regarding > the Subject. That's precisely why I wanted some agreement on this > outside of just neomutt(1). > > > 2. Many of these violate existing standards, or at least have no > > standard. Standards exist for a reason--if you don't follow them, > > other people who don't happen to use the exact same client as you > > won't be able to interoperate. > > I don't think so. Again, I don't think you've understood the points.
BTW, now that I remember, while developing these things for neomutt(1),
I found that mutt(1) has a bug (?) by which it does actually protect
some header fields precisely in the way that I implemented them in
neomutt(1), with the difference that mutt(1) does it on accident.
I use
$ mutt -v | head -n1
Mutt 2.2.12+68 (841caf1c) (2023-10-25)
See the reply that I sent you in the list archives, which I sent with
mutt(1), and you'll find the protected headers
<https://marc.info/?l=mutt-dev&m=171347742508069&q=mbox>:
From mutt-dev Thu Apr 18 21:59:29 2024
From: Alejandro Colomar <alx () kernel ! org>
Date: Thu, 18 Apr 2024 21:59:29 +0000
To: mutt-dev
Subject: Re: Message security; protected header fields
Message-Id: <ZiGXxxwI7_fd4OQs () debian>
X-MARC-Message: https://marc.info/?l=mutt-dev&m=171347742508069
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--T/e8leAN/4bSvaex"
--T/e8leAN/4bSvaex
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 18 Apr 2024 23:59:29 +0200
From: Alejandro Colomar <a...@kernel.org>
To: mutt-dev@mutt.org, neomutt-de...@neomutt.org
Subject: Re: Message security; protected header fields
Hi Derek,
On Thu, Apr 18, 2024 at 05:20:47PM -0400, Derek Martin wrote:
> g. Protecting the recipients is problematic for potentially several
However, I don't see that in your message, which means that either this
bug doesn't reproduce with your configuration, or you use a different
version of mutt(1). Still, I find it interesting that mutt(1) messages
will be protected even if you don't patch mutt(1) --at least in some
cases--. However, you won't be able to benefit from those protections,
since you don't use those headers at all.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
