| KUVERT(1) | User Commands | KUVERT(1) |
kuvert - Automatically sign and/or encrypt emails based on the recipients
kuvert [-d] [-o] [-r|-k] [-c configfile]
Kuvert is a tool to protect the integrity and secrecy of your outgoing email independent of your mail client and with minimal user interaction.
It reads mails from its queue (or accepts SMTP submissions), analyzes the recipients and decides to whom it should encrypt and/or sign the mail. The resulting mail is coerced into the PGP-MIME framework defined in RFC3156 and finally sent to your outbound mail server. Kuvert uses GnuPG for all cryptographic tasks and is designed to interface cleanly with external secret caching tools.
If no configuration file (~/.kuvert) exists or if that is empty, then kuvert will hand all emails directly on to sendmail, without any modifications whatsoever.
To let kuvert perform encryption/signing operations, at a minimum you need to set the "defaultaction" option (to a value other than its default, "none").
After startup kuvert periodically scans its queue directory and processes mails from there; depending on your GnuPG passphrase setup kuvert may daemonize itself. In either case, kuvert runs forever until actively terminated.
Kuvert's behaviour is configured primarily using a configuration file, with exception of the following commandline options:
At startup kuvert reads its configuration file and your gnugp keyring and remembers the association of email addresses to keys.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Kuvert does not handle your precious keys' passphrases. 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)).
For each recipient, kuvert can be told to apply one of five different action overrides:
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.)
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.
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.
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.
The kuvert configuration file is plain text, blank lines and lines that start with "#" are ignored.
The configuration has of two categories: options and address/action specifications.
Address+action specifications are given one per line. Such lines must start with some whitespace, followed by an address regexp, followed by some whitespace and the action keyword. For actions "fallback" and "fallback-all" kuvert also allows you to specify a single key identifier like this: "fallback,0x42BD645D". The remainder of the line is ignored.
The address regexp is a full Perl regular expression and will be applied to the raw SMTP address (i.e. not to the comment or name in the email address), case-insensitively. The regular expression may need to be anchored with ^ and $; kuvert does not do that for you. You must give just the core of the regexp (no m// or //), like in this example:
# don't confuse mailing list robots ^.*-request@.*$ none
The action keyword must be one of "none", "signonly", "fallback", "fallback-all" or "mustencrypt"; see section "How Kuvert Decides What (Not) To Do" for semantics. Order of action specifications in the config file is significant: the search terminates on first match.
Options are given one per line, and option lines must start with the option name followed by some whitespace. All options are case-sensitive. Depending on the option content, some or all of the remainder of the option line will be assigned as option value. Inline comments are not supported.
In the following list of options angle brackets denote required arguments like this:
defaultkey <hexkeyid>
Options that have boolean arguments recognize "1", "on" and "t" as true and "0", "off", "f" as false (plus their upper-case versions). Other options have more restricted argument types; kuvert generally sanity-checks options at startup.
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.
Kuvert usually logs informational messages to syslog and/or its own logfile, both of which can be disabled and adjusted.
If kuvert detects a fault that makes successful processing of a particular email impossible, kuvert will report that on STDERR (if not detached) and also email an error report if the option mail-on-error is enabled. Such partially or completely unprocessed mails are left in the queue but are renamed (the name is prefixed with "failed."); it is up to you to either remove such leftovers or rename them to something all-numeric once the problem has been resolved.
The behaviour is similar if fatal problems are encountered; after alerting kuvert will terminate with exit code 1.
Kuvert itself uses only on environment variable: $TMPDIR provides the fallback location for kuvert's temporary directory.
Kuvert passes its complete environment to child processes, namely gpg and any passphrase-query programs.
On reception of SIGUSR1, kuvert reloads its configuration file and keyring. Any one of SIGHUP, SIGINT, SIGQUIT and SIGTERM causes kuvert to terminate cleanly, invalidating the passphrases if a query program is used. All other signals are ignored.
gpg(1), kuvert_submit(1), RFC3156, RFC4880, RFC2015
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.
| 2022-02-16 |