[neomutt-devel] Message security; protected header fields

[Alejandro Colomar]

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 <alx at kernel.org>
	To: mutt-dev at mutt.org, neomutt-devel at 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/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mailman.neomutt.org/pipermail/neomutt-devel-neomutt.org/attachments/20240419/0ae600c2/attachment.sig>