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. > 3. Probably most importantly, Mutt is basically in maintenance mode, > i.e. no new features. So none of this is likely to get > implemented, even if one of the developers happened to agree with > you. I was just suggesting. If you don't like it, then it's fine. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature