Gpg-remailer decrypts received PGP/GPG messages, verifies the received signature, and re-encrypts the e-mail for a well defined group of recipients. Gpg-remailer can also be configured so as to process clear-text e-mail.
Using gpg-remailer the list of members of a group of people who want to exchange encrypted and authenticated e-mails (and maybe also clear-text messages) can be maintained at one location, allowing the members of the group to specify just one e-mail address to send PGP/GPG signed and encrypted (or optionally clear-text) e-mail to.
Gpg-remailer reads incoming e-mail from its standard input stream.
If the incoming e-mail is clear-text, it resends the e-mail to one or more configurable e-mail addresses.
If the incoming e-mail is PGP/GPG encrypted (and optionally signed) it re-encrypts the received information for every member of a configurable group, and send the re-encrypted information to one or more configurable e-mail addresses.
By itself, gpg-remailer is not a mailing list. However, the configured recipient address could be, e.g., a mailing list address, for further distribution of the processed e-mail. Gpg-remailer is a remailer: it uses the message's data, but not its headers. Having received an e-mail it resends, rather than forwards, the received e-mail. The e-mail that is received via gpg-remailer therefore contains a completely new set of e-mail headers.
A configuration file as well as command line options can be used to fine-tune gpg-remailer's behavior.
Gpg-remailer always returns 0 to the operating system to prevent unknown mailer error messages in the MTA's logs. However, when gpg-remailer ends prematurely an error message is written to the standard error stream.
In order to use gpg-remailer the following requirements must be met (all commands should be issued by the root user):
adduser --home /var/lib/secmail --disabled-password secmail
addgroup gpg-remailer adduser secmail gpg-remailer chown root.gpg-remailer /usr/sbin/gpg-remailer chmod o-rx /usr/bin/gpg-remailer
Runas_Alias REMAILERS = secmail mail mailhost.org=(REMAILERS) NOPASSWD: /usr/sbin/gpg-remailerE.g., if gpg-remailer runs on a computer named remailer.mydomain.nl which may receive incoming e-mails, then specify remailer.mydomain.nl for mailhost.org.
secmail: "|sudo -u secmail /usr/sbin/gpg-remailer"
su - secmail gpg --gen-keyAt the gpg --gen-key command the gpg program asks for some details. Accept the defaults unless you have reason not to, but make sure you do not require a pass-phrase: press Enter twice when asked for one.
Some additional suggestions:
define default RSA key, size 2048, never to expire
real name: secmail gpg-remailer functional account
email address: secmail@mailhost.org
No passphrase required: press Enter twice.
default-key 1234ABCD
force-mdcto ~/.gnupg/gpg.conf. This prevents the warning
WARNING: message was not integrity protected
keyserver keys.gnupg.netto ~/.gnupg/gpg.conf.
gpg --armor --export secmail > secmail.puband the members of the group can import the remailer's public key using:
gpg --import secmail.pub
If available, single letter options are listed between parentheses following their associated long-option variants. Single letter options require arguments if their associated long options require arguments as well.
Each --recipient option should normally only define one plain e-mail address (e.g., recipient@domain.iso, but multiple --recipient options are also accepted. The format of the e-mail addresses is not checked by gpg-remailer, but providing any information in addition to or differing from a plain e-mail address may result in gpg-remailer being unable to re-encrypt or resend e-mail messages.
In addition to plain e-mail addresses, the specification --recipient members can be used to indicate that the re-encrypted mail must be sent to all e-mail addresses specified using member specifications.
hdrs (write the mail headers),
org (write the mail data),
dec (only for PGP encrypted e-mail: write the decrypted info),
doc (only for PGP encrypted e-mail: create the info to send),
enc (only for PGP encrypted e-mail: encrypt the info to send),
clearmail (send clear-text mail),
clearmail:address (send mail only to the provided address, ignore
recipient(s) specified otherwise).
pgpmail (send pgp-encrypted mail),
pgpmail:address (send pgp-encrypted mail only to the provided
address, ignore recipient(s) specified otherwise).
Step hdrs is completely optional. Later steps depend on earlier steps. E.g., --step doc can only be requested after having specified --step dec in a previous run.
With clear-text e-mail steps dec, doc, enc and pgpmail should not be provided.
With PGP encrypted mail step clearmail should not be provided.
The default configuration file is ~/etc/gpg-remailer.rc under the pseudo user's home directory. Its path may be altered using a program option.
Empty lines are ignored. Information at and beyond #-characters is interpreted as comment and is ignored as well.
All directives in the configuration file obey the pattern
directive: value
A line may at most contain one directive, but white space (including comment at the end of the line) is OK. Several directives may be specified multiple times; otherwise the first occurrence of a directive is used. All directives are interpreted case insensitively, but their values are used as specified. E.g., DeBUG: true is as good as debug: true, but debug: TRUE is not recognized. Non-empty lines not starting with a recognized directive are silently ignored.
The following directives are supported (default values are shown between parentheses; when none is specified there is no default). When equivalent command line options are used then they overrule the configuration file specifications.
clear-text: rejected
specification. If clear-text e-mail should be allowed specify
clear-text: accepted
It is also possible to specify the envelope addresses that are accepted for received clear-text e-mail. If this is required, specify
clear-text: envelope
and define the accepted envelope e-mail addresses using the envelope: configuration option.
envelope: members
may be used to indicate that envelope addresses which are equal to the addresses specified using member specifications are all accepted.
All envelope addresses are interpreted case-insensitively. By default (if no envelope specification has been provided) all envelope addresses are accepted, in which case the specification clear-text: envelope reduces to clear-text: accepted.
recipient: members
can be used to indicate that the re-encrypted mail must be sent to all e-mail addresses specified using member specifications.
SECMAIL signed AND encrypted <secmail@mailhost.org>This specification should be according to the requirements defined in RFC 822: Standard for ARPA Internet Text Messages. Failing to comply with RFC 822 may result in the e-mail sending program rejecting the e-mail that is submitted by the gpg-remailer.
Although using PGP/GPG in e-mail is established technology, various formats of the e-mail are possible. Currently gpg-remailer recognizes the following formats:
Below a description is given of the actual contents of PGP encrypted en decrypted files.
All PGP encrypted e-mail shows the following headers (the boundary values will differ over different e-mail messages):
Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inlineAll PGP encrypted e-mail shows the following organization (the lines are used to separate the e-mail organization from the text of this man-page and are not actually present in the e-mail or in the decrypted information; empty lines, where shown, are required):
---------------------------------------------------------------------- mail headers --+QahgC5+KEYLbs62 Content-Type: application/pgp-encrypted Content-Disposition: attachment Version: 1 --+QahgC5+KEYLbs62 Content-Type: application/octet-stream Content-Disposition: inline; filename="msg.asc" -----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE----- --+QahgC5+KEYLbs62-- ----------------------------------------------------------------------Note that boundaries consist of
The various PGP encrypted e-mail formats differ in the way they organize the decrypted information.
Simple Encrypted Messages.
During decryption the signature is verified, and the result of the verification is written to the standard error stream. The decrypted message itself contains but one message, organized as follows:
---------------------------------------------------------------------- Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable decrypted text of the message ----------------------------------------------------------------------
Multi-part Encrypted Messages.
During decryption the signature is verified, and the result of the verification is written to the standard error stream. The decrypted message itself contains multiple messages, organized as follows:
---------------------------------------------------------------------- Content-Type: multipart/mixed; boundary="f+W+jCU1fRNres8c" Content-Disposition: inline --f+W+jCU1fRNres8c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Text of the first attachment --f+W+jCU1fRNres8c Content-Type: application/pdf Content-Disposition: attachment; filename="attachment.pdf" Content-Transfer-Encoding: base64 text of the attachment.pdf in base64 encoding --f+W+jCU1fRNres8c-- ----------------------------------------------------------------------Multiple attachments might follow in the same way.
Encrypted Messages Containing Detached Signatures.
During decryption the signature is not verified (but the recipient(s) is (are) shown) and the decrypted file is organized as follows:
---------------------------------------------------------------------- Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TNwuMvq+TfajHhvqBuO7" --=-TNwuMvq+TfajHhvqBuO7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Text of the message --=-TNwuMvq+TfajHhvqBuO7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- ... signature text -----END PGP SIGNATURE----- --=-TNwuMvq+TfajHhvqBuO7-- ----------------------------------------------------------------------The last part represents the detached signature, The contents section must be separated from the decrypted file (named, e.g., decrypted) (creating, e.g., the file contents). That latter file's signature may then be verified using the command
gpg --verify decrypted contentsresulting in the signature verification written to the standard error (as usual). The contents start immediately following the first boundary, and continues up to, but not including, the new line just before the next boundary.
addgroup(1), adduser(1), chmod(1), chown(1), gpg(1), sudo(1), umask(1),
None reported
Frank B. Brokken (f.b.brokken@rug.nl).