Hi Derek, On Fri, Apr 19, 2024 at 03:17:17PM -0400, Derek Martin wrote: > On Thu, Apr 18, 2024 at 08:38:29PM -0400, Kurt Hackenberg wrote: > > Signing header fields sounds reasonable, but I don't entirely like an > > implementation that puts a copy of them in the message body, to be covered > > by GPG. I'd prefer something more direct, that signs headers without > > copying them or modifying the message body. > > This makes a lot of sense to me (assuming that this feature has > genuine practical value, of which I remain largely unconvinced). > > First off: Is there an actual RFC for the existing protected header > scheme?
I don't think so. It's being considered for a standard, though. Will posted a link in this thread: <https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/> > If not, someone really ought to actually draft one and submit > it, so that more people than just a handful of interested users of > a small selection of specific mailer software could provide comments > on the Request For Comments... > > Secondly, there is a standard mechanism for adding non-standard > headers to e-mail: use the string "X-" before the thing, and add it > to the normal message headers. Not standard anymore. Talking of RFCs... See <https://www.rfc-editor.org/rfc/rfc6648>. The title of which is: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols > To the extent that this feature is > useful, it would be just as useful for non-encrypted messages as for > encrypted messages. You could do something like this: > > X-protected-header-key: 0x1234567... # probably unnecessary, but > might be interesting for confirmation? > X-protected-headers: (A base64-encoded string representing the precise > and complete contents of the headers which were signed) > X-protected-headers-signature: (the actual signature of the data made > by the specified key) > > The user could verify the signature of the signed headers, so long as > the key is available and trusted. The mailer could display and/or > visually confirm the signed headers against the standard ones, > ignoring white-space differences, etc.. > > This is not very well fleshed out, but it already strikes me as better > than what Mutt currently does: > > - it does not require even having MIME parts in such a message. <https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime> I think these days MIME is not so frowned upon as it once was. But you have a point. patatt(5) actually implements an idea like yours for signing patches including header fields, precisely for avoiding MIME. > - I don't love what Mutt is currently doing--it seems it has the > potential to break existing clients which are not expecting > message headers in the MIME header blocks. A well-behaved client > probably shouldn't break, but as we all know, not all software is > well-behaved. All mailers are expected to accept/ignore X-* > headers. > > Also FYI, I removed the neo-mutt list from this post because I'm not a > member and I don't cross-post; and also you probably don't need to > include Werner separately, he's a longstanding member of this list. :) Considering that this is a discussion for a patch set proposed to both projects, I think cross-posting is fine, but okay. I'll manually tell later neomutt(1) developers about anything interesting. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
