Hi Derek, On Fri, Apr 19, 2024 at 04:56:30PM -0400, Derek Martin wrote: > You're missing the point: All software has bugs. This would be a > bug, but it's forseeable that mailers would have this bug. For > example, if the header parser you implement differentiates where to > put the headers it's parsed based on what the header is--i.e. standard > header vs. mime header, it may add the header to the wrong object, and > now you have two subjects, two from headers, etc... They are both > headers, valid headers, that should be treated as headers--it just got > the context wrong based on the name. > > In most cases this bug would be completely innocuous--and perhaps even > beneficial (e.g. because it simplified the parser)--because mime > header blocks typically should not have RFC 822 headers in them. > Except now you've added a reason why they might. Depending on what > the borked client does next, this could inject further broken e-mail > into the thread causing problems for everyone on it. > > Does this bug exist anywhere? Does any similar bug exist anywhere? I > don't know, but it's forseeable that such bugs may exist.
Actually, I've seen this bug. My mail server (migadu) inserted a header
field right after the From field. Since mutt(1) (and neomutt(1) with my
patches) insert a From in the protected MIME part, migadu also a field
after that From, invalidating my signature.
They fixed the bug in a few minutes after my report.
All software has bugs, but that doesn't mean not to use software, nor
not improve them. Just fix the bugs.
> Should you
> always avoid implementing functionality that might interact with a
> bug? No... but if you can find a better design that is far less
> likely to interact with bugs, you should probably use that instead.
Having the signature in a header means redesigning the whole crypto in
emails. That's likely going to trigger many bugs too. I see your point
but I'm not sure the alternative is definitely better.
> > already a decent time frame that other projects can do the same thing.
> > Moreover, Memory Hole, later autocrypt, and now the IETF proposed draft,
> > all use this mechanism. So we can say it's de-facto standard, even if
> > it's not yet standard.
>
> I don't think you can... I've never heard of Memory Hole, nor until
> this conversation had I heard of autocrypt.
$ MANWIDTH=72 man neomuttrc | grep -A22 crypt_protected_headers_read$
crypt_protected_headers_read
Type: boolean
Default: yes
When set, NeoMutt will display protected headers ("Memory
Hole") in the pager, When set, NeoMutt will display pro‐
tected headers in the pager, and will update the index and
header cache with revised headers.
Protected headers are stored inside the encrypted or signed
part of an an email, to prevent disclosure or tampering.
For more information see https://github.com/autocrypt/pro‐
tected-headers Currently NeoMutt only supports the Subject
header.
Encrypted messages using protected headers often substitute
the exposed Subject header with a dummy value (see
$crypt_protected_headers_subject). NeoMutt will update its
concept of the correct subject after the message is opened,
i.e. via the <display-message> function. If you reply to a
message before opening it, NeoMutt will end up using the
dummy Subject header, so be sure to open such a message
first. (Crypto only)
TBH, I don't know why it's called memory hole. But it's what mutt(1)
uses.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
