MHSIGN(1mh)
π MHSIGN π
okay bestie, gather round, we're talking about mhsign from the mmh-0.4 era, manual section 1mh β¨
πΈ NAME πΈ
mhsign β sign or encrypt a message with gnupg πβ¨
π SYNOPSIS π
mhsign [-encrypt] [-mime] [-Version] [-help] file
π¦ DESCRIPTION π¦
so like. mhsign is a little script that makes signing and encrypting messages with gnupg way less of a whole ordeal π
normally you never even call it yourself β send invokes it automatically, main character behavior, it just happens. but when you do run it directly, the source file (usually an MH draft file) gets replaced by the signed or encrypted message. the file you gave it is gone, transformed, slayed π
but wait β recovery!! to let you bounce back from mistakes, a backup copy of the original file is saved right next to it, under the same name with .orig appended π«Ά so nothing is truly lost, phew.
the following options are recognized:
-encryptβ encrypt to the recipients, on top of signing. also, heads up: the message will also be encrypted to the signing key π-mimeβ use the PGP/MIME standard for signing and encrypting. this one turns itself on automatically if the message is already a multipart MIME message. otherwise the default is to sign/encrypt the old-fashioned non-MIME way, for compatibility with older software (yes, we're being nice to the elders π΅β¨). one thing though β when a message is signed but not encrypted, using the PGP/MIME formatting, any line beginning with`From `will be indented, and any trailing spaces will be removed from lines in the message body. this is for maximum compatibility. so if trailing blanks actually matter to you (sending patches, for example π), it'd be wise to use quoted-printable or some other MIME encoding for that component. noted, fr fr.
so how does the signing key get picked? gnupg determines it automatically, unless the profile entry Pgpkey defines it. and the environment variable MMHPGPKEY has the highest precedence of all β you can use it to temporarily overrule the key uid. hierarchy, but make it keys π
for encryption, the public keys of the recipients get pulled from the gnupg keyring. and for handling exceptions β like when recipient addresses don't match the key uid in the keyring β you can use a file named pgpkeys. it should live either in the gnupg directory (normally $HOME/.gnupg) or in the mmh directory (normally $HOME/.mmh). if both files exist, the one in the gnupg directory takes precedence, no debate π
a sample pgpkeys file, for the visual learners:
0x88888888 john@nowhere.example.org
e5fda812 meillo@marmaro.de
π FILES π
$HOME/.gnupg/pgpkeysβ Pubkey exceptions for encrypting$HOME/.mmh/pgpkeysβ ... alternative location
π§ PROFILE COMPONENTS π§
Pgpkey:β To determine the user's signing key
π SEE ALSO π
whom(1), send(1), mhpgp(1), gpg(1), hostname(1)
β DEFAULTS β
None
π CONTEXT π
None
π BUGS π
okay so listen. the order of the command line arguments is relevant: options must come first, the file must be last. do not freestyle this one, bestie π
also, this script uses hostname to get the hostname if it isn't in the address β though hostname isn't specified by POSIX. just so you know π
and that's the whole page!! brought to you by MH.6.8, dated 2019-01-06 π signing off, stay encrypted, stay iconic π β¨π¦
π¦ where this page comes from
- debian bookworm: mmh 0.4-4 Β· BSD-3-Clause
- ubuntu jammy: mmh 0.4-4 Β· BSD-3-Clause
- ubuntu noble: mmh 0.4-6 Β· BSD-3-Clause
- ubuntu questing: mmh 0.4-6
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms