Hi Derek, On Thu, Apr 18, 2024 at 08:16:15PM -0400, Derek Martin wrote: > On Thu, Apr 18, 2024 at 11:59:29PM +0200, Alejandro Colomar wrote: > > 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. > > You can already do this in mutt by using a script as your editor to > parse the headers, add the info you want to the body, and then edit > your message. But it doesn't really guarantee what you want because > as I already pointed out, the message headers may differ from the > actual recipients for a variety of reasons (Bcc, forwarding, mailing > lists, etc.). It may indicate a difference--it does not guarantee > that the difference is caused by tampering. It most likely is not, so > it will most likely mislead you.
Hmmm, thanks. I'll take the mailing list case into account. Bcc is not in the protected fields that I implemented, for obvious reasons. When forwarding, you're creating a new message (like when replying), and it gets a new signature; I don't think this issue applies. > The message interception scenario is possible, but I think highly > improbable, especially for the sort of people who are using Mutt and > encryption--savvy users. It requires the attacker have superuser > access to the mail system somewhere between you and your genuine > recipients, AND either be known to your recipients, or your recipients > must have no idea who should be on the message. The attacker needs to > be able to prevent the delivery of the original, to have time to > inject the bogus message. And your recipients need to already have > the attacker's public key and trust it, or be set up to automatically > download and use untrusted public keys... Well, if you see that your friend already sent an encrypted message to that key, that could help trust that key, at least temporarily. It only needs a man in the middle, but if they target you, that's a reasonable scenario, I think. And if the message is not encrypted, but only signed, it's not even necessary a man in the middle. An attacker can search for messages of yours in mailing lists (or talk to you to get a new one, so the date is more recent), download them, edit the headers, and bounce. > > 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). > > How so? I used thunderbird(1) for some time in the past (until 2023). When you receive an encrypted message created by mutt(1) and read it in thunderbird(1), you only see the "..." subject. You don't see the actual subject. Or maybe it was the other way around, I don't remember well. > > > 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. > > For instance, if you rely on the in-body headers when they differ from > the message headers, the other recipients' response behavior will > differ from yours, because that is not how e-mail works. The > standards dictate that e.g. the reply-to header--not some random text in > the message body--is the address that e-mail clients should send > replies to. So yes, it violates the spec. Well, we could just add the warnings, and continue using the outer headers. It will be up to the user to decide if the warning is valid or not. Thanks for pointing these issues; that's precisely why I wanted more review. Thanks! > > > Have a lovely night! > > You too! Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
