Re: [nmh-workers] Change {encrypted} to %(encrypted) in mh-format

[Robert Elz]

    Date:        Fri, 17 May 2019 12:39:49 -0400
    From:        Ken Hornstein <address@hidden>
    Message-ID:  <address@hidden>

  | Sigh.  You KNOW what I mean.  I mean that if you want to run
  | "pick -search hello" on encrypted email, you're going to have to decrypt
  | it, which very well might require you to enter in a PIN to unlock a
  | smartcard or a password to unlock a GPG key, or something that requires
  | a UI interaction that is not required today.

Actually, I probably wouldn't - it would get decrypted on arrival
(and stored in an encrypted filesystem) so I can access the content
like any other content - and is available for searching (or whatever).

Anyone who wants to send me encrypted mail that is so secret that it
is only allowed to be decrypted for the few seconds it is being
actually read should reconsider - because that just isn't going to happen.

Also generally I've found searching e-mail bodies is almost always
futile, from time time I decide that I really need to try that, and
almost always give up (the problem is generally way too many false
matches, so the actual target gets buried in the trash, rather than
failing to match the message being sought.)

  | And I guess I don't see fundamentally what is wrong with a user deciding
  | to perform some operation automatically based on the otuput of scan(1);

If you mean using scan as a tool, with a custom format, then yes, that's
fine, but ...

  | Now if your issue is with the DEFAULT scan output, then fine, I can
  | understand that concern.

that is what we were discussing, so yes.

  | MH documentation refers to what RFC 5322 calls "fields" as
  | "components".

Different context.   Fields are in an e-mail header (or these days, a
MIME header, which includes HTTP) - components are in mh-profile, or
perhaps a "components" file (template message).

kre