Add an "encryption" option 'use_transport' which does not bother with
encryption and just relies on transport security.
For admins this makes sense as none of the admin messages is really
confidential.
This is also a valid option for a subscriber and makes some sense in
scenarios where the mail provider manages the subscriber key (sic!)
and does server side decryption. Think twice before using this.
Requested-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
When using pipe mode configuration updates are not handled until the next
mail is sent to the list. That means that e.g. welcome mails are delayed.
Add a command line option to allow the invocation of remail_pipe just to
deal with configuration updates without trying to process mail from stdin.
The update handling is serialized against concurrent incoming mail via the
folder lock, so no extra serialization is required. Whichever comes first
handles it.
Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
For open lists and especially contact points the 'From' mangling is
suboptimal as the senders email address is not contained in the mail
itself. Due to re-encryption a eventual signature is not longer intact
which means that the GPG key or the S/MIME certificate which are embedded
into the signature are not transported either.
Add infrastructure to collect sender information including key/certificate
if available and attach it to the mail. The first attachment contains
sender information and the second one if available contains the key or the
certificate.
The information is only stored when the config switch is enabled and the
sender is not subscribed to the list.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This allows setups where there is no S/MIME. In some scenarios using just
GPG is fine and S/MIME might even be discouraged. Previously this required
to provide a dummy S/MIME key just to make remail happy. With this new flag
there is no need for that key if S/MIME is not required for the list.
Signed-off-by: Andreas Rammhold <andreas@rammhold.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
According to RFC2919, List-Id header should be in the form of a hostname
value enclosed inside angle brackets. This change does two things:
1. Fixes the default to be the list address with "@" replaced by a "."
2. Allows setting custom list-id values inside remail.yaml
3. Documents the "listid" optional setting in the manpage
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://tools.ietf.org/html/rfc2919
We want to be able to support ECC subkeys, which limits us to gnupg
versions 2.2 and above. CentOS-7 ships with gnupg-2.0, which cannot be
easily upgraded to 2.2 due to a slew of potential problems, so we
install the newer version into /opt/gnupg22 and must call it as
/opt/gnupg22/bin/gpg.
Allow specifying gpg binary path to use instead of the default "gpg" in
$PATH.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Add a handle pipe function to the remailer and a pipe script for handling
mail in a MTA delivery path.
Requested-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
