KUVERT(1)

📦
version 2.2.6build1 · 3 versions
, in ubuntu resolute, ubuntu stonking

kuvert(1) 💖✨

User Commands · the manual page for kuvert 🎀

✨ NAME ✨

kuvert — bestie, this is the tool that automatically signs and/or encrypts your emails based on who you're sending them to 🫶

🌸 SYNOPSIS 🌸

kuvert [-d] [-o] [-r|-k] [-c configfile]

💅 DESCRIPTION 💅

Okay so listen. Kuvert is a tool that protects the integrity and secrecy of your outgoing email — and the way it does it is independent of your mail client and with minimal user interaction. Iconic behaviour honestly.

It reads mails from its queue (or, alternatively, it accepts SMTP submissions), analyzes the recipients, and then decides to whom it should encrypt and/or sign the mail. The resulting mail gets coerced into the PGP-MIME framework defined in RFC3156, and then it's finally sent to your outbound mail server. ✨

Kuvert uses GnuPG for all the cryptographic tasks, and it's designed to interface cleanly with external secret caching tools. no cap, it plays nice 💅

🦋 GETTING STARTED 🦋

If no configuration file (~/.kuvert) exists — or if that file is empty — then kuvert will hand all emails directly on to sendmail, with no modifications whatsoever. literally just passing them along, zero notes 💀

To let kuvert actually perform encryption/signing operations, at a minimum you need to set the "defaultaction" option — and it has to be set to a value other than its default, which is "none". bestie, "none" means none. set it to something else or nothing happens 🙈

👑 OPTIONS 👑

After startup, kuvert periodically scans its queue directory and processes mails from there. Depending on your GnuPG passphrase setup, kuvert may daemonize itself. Either way: kuvert runs forever until it's actively terminated. she's committed. main character energy fr fr 🔥

Kuvert's behaviour is configured primarily using a configuration file — with the exception of the following commandline options:

  • -d — Enables debugging mode: extra debugging information gets written to STDERR. (This is independent of normal logging.) 🐛
  • -o — Enables one-shot mode: kuvert does not loop forever, it just processes only the current queue contents and then exits. Also, in this mode kuvert does not start an SMTP listener. one and done, periodt 💅
  • -r — Tells a running kuvert daemon to reload the configuration file and the gpg keyring. This is equivalent to sending a SIGUSR1 to the respective process. ✨
  • -k — Tells a running kuvert daemon to terminate cleanly. This is equivalent to sending a SIGTERM to the respective process. 💀
  • -c <configfile> — Tells kuvert to use the given config file instead of ~/.kuvert. 🎀
ngl that's the whole vibe so far — but there's more, keep scrolling bestie 🫶

✨ OPERATION ✨

Okay so here's the whole vibe of what kuvert is actually doing with its life 💅

At startup kuvert reads its configuration file and your gnugp keyring, and it remembers the association of email addresses to keys. Like, it memorizes your whole little address→key situationship. 🧠✨

Kuvert then works as a wrapper around your mail transfer agent (MTA): you author your emails like always, but instead of sending them out directly you submit them to kuvert. No cap, that's the entire trick.

Periodically kuvert scans its queue and processes any email therein. If your keyring contains a key for a recipient, kuvert will encrypt and sign the email to that recipient. If no key is available, kuvert will only (clear/detached-)sign the email. Subsequently, the email is sent onwards using your MTA program or SMTP. It's giving responsible bestie who checks the lock twice. 🔐

Emails to be processed can have any valid MIME structure; kuvert unpacks the MIME structure losslessly and repacks the (encrypted/signed) mail into a PGP/MIME object as described in RFC3156. The mail's structure is preserved. Signature and encryption cover all of the mail content with the exception of the top-level headers: for example the "Subject" header will be passed in clear, whereas any body or attached MIME object will be signed/encrypted. So like, your subject line is out there living its truth in the open, but the contents? Locked down. 🔒👑

The encrypt-or-sign decision can be overridden on a per-address basis using the configuration file or, even more fine-grainedly, by using directives in the actual email. Kuvert can also be told not to modify an email at all. (Iconic. Sometimes doing nothing IS the slay.)

💌 Submitting Emails to Kuvert 💌

Kuvert primarily relies on mails being dumped into its queue directory. Kuvert operates on files with numeric file names only. Anything that you store in its queue directory with such a filename will be treated as containing a single RFC2822-formatted email. Just yeet a numbered file in there and kuvert's like "bet, that's one email." 📥

However, no mainstream MUA supports such a drop-your-files-somewhere scheme, and therefore kuvert comes with a helper program called kuvert_submit (see kuvert_submit(1)) which mimics sendmail's mail submission behaviour but feeds to the kuvert queue. If your MUA can be instructed to run a program for mail submission, kuvert_submit can be used. ✨

Alternatively, you can send your email to kuvert via SMTP. Kuvert comes with a built-in receive-only mail server, which feeds to the queue directory. As allowing others to submit emails for your signature would be silly and dangerous, kuvert's mail server only listens on the localhost IP address and requires that your MUA uses SMTP Authentication to ensure that only your submissions are accepted. If your MUA supports SMTP AUTH PLAIN or LOGIN and can be told to use localhost and a specific port for outbound email, then you can use this mechanism. 🛡️

bestie. do NOT open that thing to the world. localhost only. it's for you. periodt.

🚚 Transporting Emails Onwards 🚚

Kuvert can send outbound emails either by running a local MTA program or by speaking SMTP to some (fixed) outbound mail server of your choice. Two paths, both valid, pick your fighter. 🥊

🏷️ Recipients, Identities and the SMTP Envelope 🏷️

In general kuvert identifies recipients using the To, Cc, Bcc and Resent-To headers of the queued email. If the mechanism you used to submit the mail to kuvert did explicitely set recipients, then these override the headers within the email. Headers are the default, envelope is the override, that's the whole hierarchy. 👑

This is the case if kuvert_submit is called with a list of recipients and no -t option and for SMTP submission.

If kuvert enqueues email via inbound SMTP, the SMTP envelope overrides the email headers: recipients that are present in the envelope but not the headers are treated as Bcc'd, and recipients listed in the headers but not the envelope are ignored. Any Resent-To header is ignored for SMTP-submitted email. 🙈

Only if no overriding recipients are given, kuvert checks the mail for a Resent-To header. If present, the email is sent out immediately to the Resent-To addresses without further processing. (This is the standard "bounce" behaviour for MUAs that don't pass recipients on to an MSP/MTA directly.) 🏓

When sending outbound email, kuvert usually uses the From header from the queued email as identity. If the email was queued via SMTP, the envelope again overrides the mail headers. Envelope stays undefeated, fr fr.

Note that kuvert sets the envelope sender using "-f" if sending email via a local MTA program; if you are not sufficiently trusted by your MTA to do such, your mail may get an X-Authentication-Warning header tacked on that indicates your username and the fact that the envelope was set explicitely. 😭 (not the warning header showing up uninvited...)

🔑 Passphrase Handling 🔑

Kuvert does not handle your precious keys' passphrases. Absolutely not her job, she's not touching those. 💅

You can either elect to use gpg-agent as an (on-demand or caching) passphrase store, or you can tell kuvert what program it should run to query for a passphrase when required. Such a query program will be run in a pipeline to GnuPG, and kuvert will not access, store or cache the passphrases themselves: there are better options available for secret caching, for example the Linux in-kernel keystorage (keyctl(1)). 🧚

🤔 How Kuvert Decides What (Not) To Do 🤔

For each recipient, kuvert can be told to apply one of five different action overrides:

  • none — The email is sent as-is (except for configuration directive removal). Doing the absolute least and honestly? Respect.
  • signonly — The email is (clear/detached-) signed. Signature only, no envelope, no secrets. ✍️
  • fallback — The email is encrypted and signed if there is a key available for this recipient or only signed if not. It'll try its best for you, bestie. 🫶
  • fallback-all — The email is encrypted and signed if keys are available for all recipients, or only signed otherwise. Recipients whose action is set to "none" and Bcc'd recipients are not affected by this action.

The fallback-all action is an "all-or-nothing" action as far as encryption is concerned and ensures that no mix of encrypted or unencrypted versions of this email are sent out: if we can we use encryption for everybody, or otherwise everybody gets it signed (or even unsigned). (Bcc'd recipients are the exception.) Like, the whole group chat gets the same treatment or nobody does. 🎀

  • mustencrypt — The mustencrypt action is an "all-or-nothing" action and ensures that any emails involving such addresses are only sent out if the email can be encrypted for every recipient.

The email is rejected and not sent to anybody at all, if any addresses are present that have the mustencrypt directive set but where no key is known. Bcc'd recipients are included in this decision.

This action overrides fallback-all. ⚠️

🎯 Specifying Actions 🎯

Kuvert uses four sources for action specifications: directives in the individual email addresses, action directives in the configuration file, an X-Kuvert header in your email, and finally the default action given in the configuration file. Four layers, one final answer. 🌈

  1. First kuvert looks for action directives in your configuration file. Such directives are given as action plus regular expression to be matched against an address, and the first matching directive is used.
  2. If no matching directive is found, the default action given in the configuration file is applied.
  3. Kuvert now checks for the presence of an X-Kuvert header: its content must be an action keyword, which is applied to all recipients of this email except the ones whose action at this stage is "none". (In other words: if you specify "no encryption and no signing" for some addresses, then this cannot be overridden in a blanket fashion.) 🙅
  4. Kuvert then analyzes each recipient email address. If an address has the format
 Some Text "action=someaction" <user@some.host>"

kuvert strips the quoted part and overrides the addressee's action with someaction.

  1. If any "mustencrypt" recipient action is present, but no key is known (or given in an override, see section "Key Selection"), then the whole mail is rejected and not sent to anybody. 💀
  2. Finally kuvert checks if any recipient has action "fallback-all". If so, kuvert
    • a) checks if any recipients (except Bcc'd) have action "signonly" or "none". If this is the case, all "fallback" and "fallback-all" actions are downgraded to "signonly".
    • b) checks if keys for all recipients (except Bcc'd) are available. If not, all "fallback" and "fallback-all" actions are downgraded to "signonly".
  3. Recipients which are given in a Bcc: header are always treated independently and separately from all others (except for mustencrypt): any "fallback-all" action is downgraded to "fallback" for Bcc'd addresses, and if encryption is used, the email is encrypted separately so that no record of the Bcc'd recipient is visible in the email as sent out to the "normal" recipients. Also, any Bcc: header is removed before sending an email onwards. 🤫 (secret bestie stays secret, that's the rule.)

🔍 Key Selection 🔍

Kuvert depends on the order of keys in your keyring to determine which key (of potentially many) with a given address should be used for encryption. By default kuvert uses the last key that it encounters for a given address. For people who have multiple keys for a single address this can cause problems, and therefore kuvert has override mechanisms for encryption key selection: You can specify a key to encrypt to for an address in the configuration file (see below), or you can override the key selection for and within a single mail. 🗝️

If the recipient address is given in the format

 Some Name "key=keyid" <user@some.host>

Kuvert will strip the double-quoted part and use this particular key for this recipient and for this single email. The keyid must be given as the hex key identifier. This mechanism overrides whatever associations your keyring contains and should be used with caution. Note that both key and action overrides can be given concurrently as a single comma-separated entry like this:

 Some Name "action=fallback,key=0x12345" <user@some.host>

The signing key can be overridden in a similar fashion: if the From address contains a "key=keyid" stanza, kuvert will use this key for signing this single email. ✍️✨

fr fr, key=keyid is powerful but like — be careful with it. the caution note is there for a reason, bestie. 🙈

🌸 CONFIGURATION 🌸

Okay bestie, so the kuvert configuration file is just plain text. Blank lines? Ignored. Lines that start with #? Also ignored, they're just little comments living their best life. 💅

The whole config is giving two categories: options and address/action specifications. Let's get into it.

✨ Address and Action ✨

Address+action specs go one per line. Each such line has to start with some whitespace, then an address regexp, then more whitespace, then the action keyword. For the actions fallback and fallback-all, kuvert is also chill with you handing over a single key identifier, like this: fallback,0x42BD645D. Anything after that on the line? Ignored, not even looked at. 🙈

The address regexp is a full Perl regular expression, and it gets applied to the raw SMTP address — so like, not the comment or the name part of the email address — and it's matched case-insensitively. Heads up though: the regexp may need anchoring with ^ and $, and kuvert is not doing that for you, no cap. You give just the core of the regexp (no m//, no //), like in this lil example:

# don't confuse mailing list robots
^.*-request@.*$  none

The action keyword has to be one of none, signonly, fallback, fallback-all, or mustencrypt — go peek at the section "How Kuvert Decides What (Not) To Do" for the semantics, iykyk. ⭐

Order matters, bestie! The order of action specifications in the config file is significant — the search terminates on first match. First one wins, periodt.

💖 Options 💖

Options are also one per line, and option lines must start with the option name followed by some whitespace. Every option is case-sensitive, so don't get cute with the capitalization. 💀 Depending on what the option is, some or all of the rest of the line gets assigned as the option value. And no, inline comments are not supported — sorry babe.

In the option list below, angle brackets mean a required argument, like this:

defaultkey <hexkeyid>

Options with boolean arguments recognize 1, on, and t as true, and 0, off, f as false (plus their upper-case versions, because equal rights ✨). Other options have more restricted argument types, and kuvert generally sanity-checks options at startup. 👑

👑 Known Options 👑

  • syslog <syslog facility or blank> — Whether kuvert should use syslog for logging, and if so, which facility to use. Default: nothing. This is independent of the logfile option below. kuvert uses your locale's encoding for all messages sent to syslog. 🫶
  • logfile <path or blank> — Whether kuvert should write log messages to a file, appending to it. Default: not set. This is independent of the syslog option above. kuvert uses your locale's encoding for saving data to the logfile.
  • mail-on-error <email address or blank> — If kuvert hits serious or fatal errors, an email gets sent back to this address, if it's set. Default: undef. This email is sent in addition to the normal logging via syslog or logfile.
  • queuedir <path> — Where kuvert and its helper programs store mails that need processing. Default: ~/.kuvert_queue. The directory is created if necessary. It must be owned by the user running kuvert and have mode 0700. 🔒
  • tempdir <path> — Where kuvert stores temporary files. Default: a directory called kuvert.<username> in $TMPDIR or /tmp. Created if necessary, must be owned by the user running kuvert, and must have mode 0700. This directory gets completely emptied after processing an email.
  • identify <boolean> — Whether kuvert should add an X-Mailer header to outbound emails. Default: false. The X-Mailer header consists of the program name and version. ✨
  • preamble <boolean> — Whether kuvert should include an explanatory preamble in the generated MIME mail. Default: true.
  • interval <number> — Sets the queue checking interval, in seconds. Default: 60 seconds. ⏰
  • msserver <hostname-or-address> — Mail Submission Server for outbound email. Default: unset. If this is set, kuvert will use SMTP to send outbound emails. If it's not set, kuvert uses the mail submission program on the local machine — see msp below.
  • msport <portnumber> — The TCP port the Mail Submission Server listens on. Default: 587. Ignored if msserver is not set.
  • ssl <string> — Whether SSL or STARTTLS are to be used for outbound SMTP submission. The value must be either starttls to use STARTTLS, or ssl for raw SSL. SSL encryption is not used if this option is unset. 🔐
  • ssl-cert <client cert path.pem>, ssl-key <client key path.pem>, ssl-ca <ca cert path.pem> — If an SSL client certificate is to be presented to the SMTP server, set both ssl-cert and ssl-key. If your system-wide CA certificate setup doesn't include the certificate your SMTP server uses, set ssl-ca to point to a PEM file containing all the relevant CA certificates. All of these are ignored if the ssl option isn't set.
  • msuser <username> — The username to use for SMTP authentication at the Mail Submission Server. SMTP Auth is not attempted if msuser isn't set. Ignored if msserver is not set.
  • mspass <password> — The password for SMTP authentication. Ignored if msserver or msuser are not set. 🤫
  • mspass-from-query-secret <boolean> — Whether the mspass should be retrieved using the query-secret program instead of giving the mspass in the config file. Ignored if msserver or msuser are not set. If this option is set, the query-secret program will be used to ask for the "smtp-password" when the first mail is processed. The password will be cached if authentication succeeds — or you'll be asked again, until authentication succeeds. 🔁
  • msp <program-path and args> — Defines the program kuvert should use to deliver email. Default: "/usr/sbin/sendmail -om -oi -oem". This is ignored if msserver is set. The argument must include the full path to the program, and the program must accept the common mail transfer agent arguments as defined in the Linux Standards Base (see <http://refspecs.linux-foundation.org/LSB_2.0.0/LSB-Core/LSB-Core.html#BASELIB-SENDMAIL-1>).
  • gpg <program-path> — Defines which custom GnuPG executable kuvert should use. If this option is given, the argument must be a full path to an executable. Default: "gpg", i.e. anywhere in the path. 🧚
  • can-detach <boolean> — Tells kuvert it can background itself on startup, detaching from the terminal. Default: false.

Detaching works only if your chosen mechanism for passphrase entry doesn't require interaction via the original terminal. This is the case if you delegate passphrase handling to gpg-agent and configure it for X11 pinentry, or if your secret-query program is an X11 program with its own window. 🪟

  • maport <portnumber> — Kuvert can accept email for processing via SMTP. This option sets the TCP port kuvert listens on (localhost only). Default: 2587. Ignored if ma-user and ma-pass are not both set. If you wanna use this mechanism, tell your mail program to use localhost or 127.0.0.1 as outgoing mail server and enable SMTP Authentication (see below). 📬
  • ma-user <username> — Sets the required SMTP authentication username for accepting mails via SMTP. Default: undef. Kuvert does not listen for SMTP submissions unless both ma-user and ma-pass are set. And kuvert does not accept emails for processing via SMTP unless you prove your identity with SMTP Authentication — otherwise anybody on your local machine could use kuvert to send emails signed by you! 😱 Kuvert currently supports only AUTH PLAIN and LOGIN (which isn't a major problem, since we listen on the loopback interface only). This option sets the username kuvert recognizes as yours — it can be anything and doesn't have to be a real account name.
  • ma-pass <password> — Sets the password your mail user agent must use for SMTP Authentication if submitting mails via SMTP. Default: unset. Kuvert does not listen for SMTP submissions unless both ma-user and ma-pass are set. This password doesn't have to be — and honestly shouldn't be — your real account's password. Note that using SMTP submission requires that you protect your kuvert configuration file with strict permissions (0600 is suggested). 🔒
  • defaultkey <hexkeyid> — Specifies a default key to use as signing key. Default: unset, which means GnuPG gets to choose (usually the first available secret key). Can be overridden in the From: address — see the section "Key Selection". 🔑
  • defaultaction <action> — Which action is to be taken if no overrides are found for a recipient. Default: none. See the section "How Kuvert Decides What (Not) To Do" for recognized actions.
  • alwaystrust <boolean> — Whether gpg should be told to trust all keys for encryption or not. Default: false. 💀
  • use-agent <boolean> — Whether kuvert should delegate all passphrase handling to the gpg-agent and call gpg with appropriate options. Default: false. If not set, kuvert will ask the user (or some nominated passphrase store) for passphrases on demand.
  • query-secret <program-path and args with %s> — Tells kuvert which program to use for passphrase retrieval.

Default:

"/bin/sh -c 'stty -echo; read -p \"Passphrase %s: \" X; \
stty echo; echo $X'"

Ignored if use-agent is set. Kuvert does not store passphrases internally — instead it runs the indicated program in a pipeline with gpg when signing. If you use a passphrase store (like the Linux-kernel keyutils, or secret-agent, or the like), enter your retrieval program here. The program is run with kuvert's environment, the first %s in the argument spec is replaced with the hex keyid, and the passphrase is expected on stdout. The exit code is ignored. If can-detach is not set, the program has access to kuvert's terminal. Note that the default query program prohibits kuvert from backgrounding itself. 🙈

  • flush-secret <program-path and args with %s> — This program is called to invalidate an external passphrase cache if kuvert is notified by gpg of the passphrase being invalid. Default: undef. Ignored if use-agent is set. The program is run with kuvert's environment, and with the first %s of its argument spec being replaced by the hex keyid in question. Its exit code is ignored. If can-detach is not set, the program has access to kuvert's terminal. 🫧

💅 DIAGNOSTICS 💅

Okay bestie, when kuvert has thoughts, it usually writes them down as informational messages — to syslog and/or to its own lil logfile. And plot twist: both of those can be turned off and tuned, so you're never stuck with chatter you didn't ask for.

But if kuvert hits a fault that makes it literally impossible to successfully process a particular email? Here's the whole drama, step by step:

  • it reports that on STDERR — but only if it's not detached
  • and it also emails you an error report, if the mail-on-error option is enabled
  • such partially or completely unprocessed mails stay in the queue, but they get renamed — the name gets prefixed with "failed."
Heads up, gorgeous: cleaning up those failed. leftovers is on you. Either delete them, or rename them to something all-numeric once you've actually fixed the problem. kuvert is not your mom, she's just your mail wrapper. 🫶

And if something fatal goes down? Same energy, but spicier: after alerting you, kuvert terminates with exit code 1. Periodt.

✨ ENVIRONMENT AND SIGNALS ✨

kuvert is a low-maintenance queen and only uses one environment variable:

  • $TMPDIR — gives the fallback location for kuvert's temporary directory.

That's it. One. Iconic minimalism.

However, kuvert does pass its complete environment to its child processes, namely gpg and any passphrase-query programs. So whatever vibe your env is giving, the kids inherit it. 🌈

🦋 Signals, aka the mood ring

  • SIGUSR1 — kuvert reloads its configuration file and keyring. Fresh start, new me. ✨
  • SIGHUP, SIGINT, SIGQUIT, SIGTERM — any one of these makes kuvert terminate cleanly, invalidating the passphrases if a query program is used.
  • everything else — ignored. Not today, bestie. 💀

🎀 FILES 🎀

  • ~/.kuvert — the configuration file read by kuvert and kuvert_submit.
  • ~/.kuvert_queue — the default queue directory.
  • /tmp/kuvert.pid.<uid> — holds the pid of a running kuvert daemon.

🌸 SEE ALSO 🌸

gpg(1), kuvert_submit(1), RFC3156, RFC4880, RFC2015

(go read them, iykyk 💜)

👑 AUTHOR 👑

Alexander Zangerl <az@snafu.priv.at>

copyright 1999-2014 Alexander Zangerl <az@snafu.priv.at>

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation.

and that's the whole page, bestie!! 🎉

This gem comes to you from the Mail corner of the manual-verse, dated 2026-01-22, filed under KUVERT(1). Go forth and encrypt your mail, you absolute main character. 💅✨🎀🦋

📦 where this page comes from