Multiple relay configuration based on sender address with sendmail

One of the needs that came up was to be able to use separate relay configurations based on the sender email address, using sendmail. The problem is that sendmail is missing support for most parts of that sentence.

At the end the solution involved a combination of sendmail, smarttable, procmail and msmtp

The idea is the following:

• Use smarttable to implement sender based rules


• Use the procmail mailer support to use procmail to deliver the emails


• Use procmailrc to pipe messages to msmtp


• Use msmtp to relay via external hosts

Sender based rules

In order to be able to have sender-based rules I used smarttable.m4 from here.

Download the smarttable.m4 and (assuming sendmail config is under /etc/mail) place it under /etc/mail/m4/. Normally it should be placed along the rest of the sendmail features (/usr/share/sendmail/cf/features) but I don't like polluting system dirs. Then use the following config in sendmail.mc:

dnl Change the _CF_DIR for a bit to load the feature from /etc/mail/m4
dnl then change it back
define(`_CF_DIR_OLD', _CF_DIR_)dnl
define(`_CF_DIR_', `/etc/mail/m4/')dnl
dnl This has to be a hash. I.e. not text.
FEATURE(`smarttable',`hash -o /etc/mail/smarttable')dnl
define(`_CF_DIR_', _CF_DIR_OLD)dnl

Then configure smarttable (/etc/mail/smarttable) like this:

test@test.com    procmail:/etc/mail/persource/test.test.com.procmailrc

You can add as many lines as you like, one for each sender. See smarttable's web page for more information on the supported sender formats. Dont' forget to generate the hashed version (smarttable.db)

Procmail config

Configure sendmail for procmail mailer like this:

define(`PROCMAIL_MAILER_ARGS', `procmail -Y -t -m $h $f $u')dnl
MAILER(`procmail')dnl

You have to override the default procmail parameters in order to add the -t switch. This way delivery errors will be interpreted as softfails, otherwise mails will be rejected on the first failure.

Create /etc/mail/persource and put the procmail configs in there (nice and tidy). In this example create /etc/mail/persources/test.test.com.procmailrc as follows:

:0w
|/usr/bin/msmtp -C /etc/mail/persource/test.test.com.msmtprc -a test@test.com -t

The 'w' flag is essential in order to feed failures back to sendmail.

Msmtp config

Create the msmtp config file (/etc/mail/persource/test.test.com.msmtprc) as follows:

defaults
syslog          on
# logfile /tmp/msmtp-test@test.com.log

account         test@test.com
host            smtp.gmail.com
from            test@test.com
user            test@test.com
password        xxx
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt

Your mileage may vary. They above is good for gmail accounts on a debian system.

Done

And that's it. Sending an email as test@test.com will cause sendmail to use smarttable. This will match the sender and use procmail with our config to deliver the email. Procmail will pipe the email to msmtp which will send the email via google's email servers.

OpenVPN and remote-cert-tls server

This required a bit of digging into OpenVPN's and OpenSSL's code to figure out.

The problem

This error:

Thu Sep 11 00:12:05 2014 Validating certificate key usage
Thu Sep 11 00:12:05 2014 ++ Certificate has key usage  00f8, expects 00a0
Thu Sep 11 00:12:05 2014 ++ Certificate has key usage  00f8, expects 0088

The condition

Using openvpn with the following option:

remote-cert-tls server

The solution

(for me) to add this to openvpn's config file:

remote-cert-ku f8

The explanation

Background

remote-cert-tls attempts to solve one problem: Lets say you run a CA and you distribute the certificates to 2 people including me and you. Then you setup a VPN server for us to use and you generate another certificate for the VPN server.

As always, the problem that certificates attempt to solve is "how do you know you're connecting to the remote end you assume you are. In normal SSL pages you trust a CA to verify that the CN of the certificate matches the owner of the domain. If you want to achieve the same thing with openvpn then you need to verify the CN of the remote end against either the hostname or a predefined string. If not then you need to use the "remote-cert-tls server" option.

If you don't use any of the above methods then I can fire up an openvpn server using the certificate you provided me with and since both my certificate and the actual VPN server's certificate are signed by the same CA you would be verifying both and be equally willing to connect to both, thus allowing me to spy on you.

To solve this kind of problems X509 has some properties for certificates that designate them for certain purposes. E.g. one of them is to run a VPN endpoint (TLS Web Client Authentication)

To be precise there are 2+1 such designations in X509:

X509v3 Key Usage: 
    Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement
 
X509v3 Extended Key Usage: 
    TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System, IPSec Tunnel, Time Stamping
 
Netscape Cert Type: 
    SSL Client, SSL Server, S/MIME, Object Signing

"Netscape Cert Type" is kind of old. "Key Usage" is the main one and "Extended Key Usage" is the final addition. Ignoring NS Cert Type, "Key Usage" is a bitmap and thus has limited space for expansion. "Extended Key Usage" on the other hand is a list of object identifiers which allows for unlimited expansion.

The certificate

The certificate I was using for the server-side of the OpenVPN had the above attributes. Ignoring NS Cert Type once more, the other two correspond to the following data:

  494:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
  499:d=5  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:030203F8
 
  433:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Extended Key Usage
  438:d=5  hl=2 l=  52 prim: OCTET STRING      [HEX DUMP]:303206082B0601050507030106082B0601050507030206082B0601050507030506082B0601050507030606082B06010505070308

Starting with "Key Usage", the actual value is "F8". The meaning of each bit can be found in OpenSSL's code:

#define KU_DIGITAL_SIGNATURE    0x0080
#define KU_NON_REPUDIATION      0x0040
#define KU_KEY_ENCIPHERMENT     0x0020
#define KU_DATA_ENCIPHERMENT    0x0010
#define KU_KEY_AGREEMENT        0x0008
#define KU_KEY_CERT_SIGN        0x0004
#define KU_CRL_SIGN             0x0002
#define KU_ENCIPHER_ONLY        0x0001
#define KU_DECIPHER_ONLY        0x8000

On the other hand, the "Extended Key Usage" part contains the following Object IDs:

06082B 06010505070301 -> serverAuth (TLS Web Server Authentication)
06082B 06010505070302 -> clientAuth (TLS Web Client Authentication)
06082B 06010505070305 -> ipsecEndSystem (IPSec End System)
06082B 06010505070306 -> ipsecTunnel (IPSec Tunnel)
06082B 06010505070308 -> timeStamping (Time Stamping)

The "bug"

The first thing to notice is that the failure is for "Key Usage" and not for "Extended Key Usage" (took me some time to figure out).

After that, a bit of digging into the code confirms that OpenVPN attempts to verify a bitmap with equality. I.e. it gets the certificates' value and compares it against a predefined list of allowed values, which according to OpenVPN's documentation defaults to "a0 88" (which means one of them). However the actual certificates bitmap value is 0xf8 as mentioned above. And thus the comparison fails with the error:

Thu Sep 11 00:12:05 2014 Validating certificate key usage
Thu Sep 11 00:12:05 2014 ++ Certificate has key usage  00f8, expects 00a0
Thu Sep 11 00:12:05 2014 ++ Certificate has key usage  00f8, expects 0088

The reason I'm calling this a bug is because it's not sensible to use equality to compare against a bitmap. Instead one can use AND, in which case there would be:

( <certificate's value> & <desired value> ) == <desired value>
or:
( 0xf8 & 0xa0) == 0xa0  -> True

In order for the validation to succeed with the defaults the certificate should have one of the following designations:

0xa0: Digital Signature, Key Encipherment
0x88: Digital Signature, Key Agreement

The solution

So there, since the comparison is done with equality you can do one of the following:

• Use the above Key Usage on the certificate (inconvenient)


• Don't use "remote-cert-tls server" (bad)


• Use "remote-cert-ku XX" where XX is the value of your certificate which can be seen in OpenVPN's messages (the last octet). In my case it's f8.

 

Linux, multicast, bridging and IPv6 troubles (i.e. why my IPv6 connectivity goes missing)

For a long time now I had a very annoying problem with IPv6 under Linux.

My setup is as follows: Linux box <-> Switch <-> Router

The Linux box uses a bridge interface (br0) and usually only has one physical interface attached to it (eth0). That's a very convenient setup.

The problem is that after a couple of minutes the IPv6 connectivity of the host will go away. Now, the host has a static IPv6 assigned to it and it's not that it loses the address or any route. Instead it just stops communicating with everything.

Troubleshooting this showed that the box loses the MAC address of the router and the ND protocol does not work, so it never recovers.

When the problem occurs, the neighbor information becomes stale:

# ip neigh
2a01:XXX:YYY:1::1 dev br0 lladdr 00:11:12:13:14:c4 router STALE
fe80::20c:XXff:feXX:YYYY dev br0 lladdr 00:11:12:13:14:c4 router STALE

I.e the entry remains in a 'STALE' state and never recovers.

My workarounds so far have been:

• Enable promiscuous mode on the interface (ifconfig br0 promisc)


• Clear neighbors (ip neigh flush)

Everything pointed out to multicast issues (what IPv6 ND uses).

Long-story-short, this was an eye opener: http://troglobit.com/blog/2013/07/09/multicast-howto/

What needs to be done is to disable IGMP snooping on the bridge interface because it causes these issues. This is done with:

# echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping

So do yourself a favor and add this to /etc/network/interfaces, in the relevant interface:

    up    echo 0 > /sys/devices/virtual/net/$IFACE/bridge/multicast_snooping