kuvert - Automatically sign and/or encrypt emails based on the recipients
kuvert [-d] [-o] [-r|-k]
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.
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
Kuvert's behaviour is configured primarily using a configuration file,
with exception of the following commandline options:
Enables debugging mode: extra debugging information is written to STDERR.
(This is independent of normal logging.)
Enables one-shot mode: kuvert does not loop forever but processes
only the current queue contents and then exits. Kuvert does also not
start an SMTP listener in this mode.
Tells a running kuvert daemon to reload the configuration file
and the gpg keyring. This is equivalent to sending a SIGUSR1 to the
Tells a running kuvert daemon to terminate cleanly. This is equivalent
to sending a SIGTERM to the respective process.
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
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
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.
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.
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.
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.
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
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 programs available for secret caching, eg. quintuple-agent
or the Linux in-kernel keystorage (keyctl(1)). Kuvert interfaces
cleanly with these.
How Kuvert Decides What (Not) To Do
For each recipient, kuvert can be told to apply one of
four different actions:
The email is sent as-is (except for configuration directive removal).
The email is (clear/detached-) signed.
The email is encrypted and signed if there is a key available for this
recipient or only signed.
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.)
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.
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.
If no matching directive is found, the default action given in
the configuration file is applied.
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/signing'' for
some addresses, then this cannot be overridden in a blanket fashion.)
Kuvert then analyzes each recipient email address. If an address
has the format
Some Text ``action=someaction'' <email@example.com>",
kuvert strips the quoted part and overrides the addressee's
action with someaction.
Finally kuvert checks if any recipient has action ``fallback-all''. If so,
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
checks if keys for all recipients (except Bcc'd) are available. If not,
all ``fallback'' and ``fallback-all'' actions are downgraded to ``signonly''.
Recipients which are given in a Bcc: header are always treated independently
and separately from all others:
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.
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:
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:
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
Address and Action
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
# don't confuse mailing list robots
The action keyword must be one of ``none'', ``signonly'', ``fallback''
or ``fallback-all''; 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
In the following list of options angle brackets denote required
arguments like this:
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.
syslog <syslog facility or blank>
Whether kuvert should use syslog for logging, and if so, what facility to
use. Default: nothing. This is independent of the logfile option below.
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.
mail-on-error <email address or blank>
If kuvert encounters serious or fatal errors, an email is sent back
to this address if set. Default: undef. This email is sent in addition to the
normal logging via syslog or logfile.
Where kuvert and its helper programs store mails to be processed.
Default: ~/.kuvert_queue. The directory is created if necessary. The directory
must be owned by the user running kuvert and have mode 0700.
Where kuvert stores temporary files. Default: a directory called
kuvert.<username>.<pid> in $TMPDIR or /tmp. The directory is created if
necessary, and must be owned by the user running kuvert and have mode 0700.
This directory is completely emptied after processing an email.
Whether kuvert should add an X-Mailer header to outbound emails.
Default: false. The X-Mailer header consists of the program name and version.
This sets the queue checking interval in seconds. Default: 60 seconds.
Mail Submission Server for outbound email. Default: unset.
If this is set, kuvert will use SMTP to send outbound emails.
If not set, kuvert uses the mail submission program on the local machine.
See msp below.
The TCP port on which the Mail Submission Server listens. Default: 587.
Ignored if msserver is not set.
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
The password for SMTP authentication. Ignored if msserver or msuser are not set.
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 will be asked again, until
Indicates to kuvert that it can background itself on startup, detaching
from the terminal. Default: false. This is possible only if you either
delegate passphrase handling to gpg-agent, or if your secret-query program
does not require interaction via the original terminal (e.g. if it is an
X11 program with its own window).
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 want to 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).
This option 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.
Kuvert does not accept emails for processing via SMTP unless you prove your
identity with SMTP Authentication (or anybody on your local machine could
use kuvert to send emails signed by you!). Kuvert currently supports only
AUTH PLAIN and LOGIN (which is not a major problem as we listen on the loopback
interface only). This option sets the username kuvert recognizes as yours.
This can be anything and doesn't have to be a real account name.
This option 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 does not have to be (actually 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).
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 section ``Key Selection''.
Which action is to be taken if no overrides are found for a recipient.
Default: none. See section ``How Kuvert Decides What (Not) To Do'' for recognized actions.
Whether gpg should be told to trust all keys for encryption or not.
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
but rather 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.
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.
ENVIRONMENT AND SIGNALS
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.
The configuration file read by kuvert and kuvert_submit.