Relaying Sendmail via SSL

This howto will hopefully get sendmail relaying to the new SSL enabled server, but the same technique should work with other servers too.

A little info:

The new virginmedia SMTP server uses SSL on port 465. Nothing wrong with that for most email clients like Thunderbird and the like. With mutt though we need to get sendmail to relay to it, and that's where the problem is, because sendmail will hang waiting for the client greeting and the mail never gets sent.

You may notice if you just try to telnet to port 465 you will get disconnected just by issuing a EHLO.

To bypass this problem we need to create an SSL tunnel to the server and have sendmail relay through it. The application that I will use to do that is stunnel which is installed by default in Slack - it just needs some setting up.


Stunnel has two modes - server and client. We will use it as a client and create what is in effect a proxy to VM's SMTP server. I am still quite new to using stunnel so there may well be better/other ways to do this. Drop me a mail if you have suggestions.

We will create a simple config file for stunnel:

david@Junius(~)% cat /etc/stunnel/stunnel.conf
sslVersion = SSLv3

[ req ]
client = yes
accept = 2525
connect =

relay-domain is going to be our stunnel hostname, defined in /etc/hosts. I'm just running it locally so I use for the IP, but you can have it running on a different box. 2525 will be the port that it runs on. My hosts file now looks like this:

david@Junius(~)% cat /etc/hosts
.. snip .. localhost relay-domain
.. snip ..

I've read that relay-domain must come after localhost (I'm not sure how that works when it's running on a different box).

Now run stunnel with some flags:

stunnel /etc/stunnel/stunnel.conf -c -d relay-domain:2525

You should now be able to telnet in via stunnel and get the proper SMTP response:

david@Junius(~)% telnet relay-domain 2525
Connected to relay-domain.
Escape character is '^]'.
220 ESMTP 15sm258258pxi.4
EHLO junius at your service, []
250-SIZE 35651584
221 2.0.0 closing connection 15sm258258pxi.4
Connection closed by foreign host.

Success :-)

You will notice that actually reroutes to I have tried connecting directly to google but it doesn't work. Google picks up that the connection was routed through VM, I guess.


Before playing with sendmail settings backup and in /etc/mail

First we need to make an authinfo.db with our Virgin login info for relay-domain:

cd /etc/mail
mkdir auth
chmod 700 auth
cd auth

Now make a file 'authinfo' and edit it with some credentials. This is what mine looks like: "I:
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it.
"U:root" "P:password" "M:PLAIN" "I: This e-mail address is being protected from spambots. You need JavaScript enabled to view it. "
"U:root" "P:password" "M:PLAIN"

Change 'password' to your SMTP login password. Notice I have used the full hostname.domain ( here. This is also set in my hosts file, so you need to set that to whatever you have set for domain name.

makemap hash authinfo < authinfo
chmod 600 authinfo*

The permissions will ensure that the login info isn't world readable. Put yourself in /usr/share/sendmail/cf/cf and backup and Edit and These are the settings we need in both:

FEATURE(`authinfo',`hash -o /etc/mail/auth/authinfo.db')
define(`RELAY_MAILER_ARGS', `TCP $h 2525')
define(`ESMTP_MAILER_ARGS', `TCP $h 2525')

You may need to play with the order and where these settings are in the actual files. The Build script will moan if they are in the wrong order.


cp /etc/mail
cp /etc/mail
/etc/rc.d/rc.sendmail restart

echo "This is a test" | mailx -s "TEST" 
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it.

If all went well you should have recieved it without any problems.

But, wait. Did you notice that the From: header is changed to your This e-mail address is being protected from spambots. You need JavaScript enabled to view it. ? (Might be the same thing for ex-ntl users too).

I won't go into the arguments I had on the VM forum about this header changing nonsense :>