Category: email

Courier mail server and SSL error SSL3_GET_RECORD:wrong version number

Just realized that some of the incoming mails where bouncing, meaning that the other mailserver wasn’t able to connect at all.

This concerned all all mailservers starting a STARTTLS SMPT connection. In the logs the “SSL routines:SSL3_GET_RECORD:wrong version number” occured.

It turned out to be a configuration problem of courier. In the default install TLS_PROTOCOL is set to TLS1. The problem dissapears when setting it to SSL23 instead.

Sending emails with windows scripting host

You can send emails from within Windows scripting host with the following code (VBS in this case):

Set objMessage = CreateObject("CDO.Message")
objMessage.Subject = "My Subject"
objMessage.From = "From Header"
objMessage.To = "Recipient Address"
objMessage.TextBody = "text in body"
objMessage.AddAttachment("Path/to/file")
objMessage.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
objMessage.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserver") = "mailserver.example.com"
objMessage.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
objMessage.Configuration.Fields.Update
objMessage.Send

This should work with all recent Windows versions, starting at least with Windows XP as CDO message gets installed by default.

STARTLS and courier mail server

I finally managed to use STARTTLS together with the Courier Mail Server. SSL connections (imapd-ssl and esmptd-ssl) already worked with the generated certificate. But although SSL worked trouble free and TLS options had nearly the same settings I could not get STARTTLS to work.

The overall reason was that the certificate file was owned 600 by root. With SSL this is not a big problem as the daemon which listens on port 465 and 993 does all the crypto handshake itself and runs under root. But with STARTTLS the connection is already forwarded to a non-privileged process before TLS starts its handshake (in fact it is initiated by the client over a cleartext connection).

So the solution was quite easy: Just give the certificate file the same owner the non-privileged courier processes run under – user “daemon” in case of CentOS 4/5.

Update: Yes, the solution appears to be quite obvious. But in fact courier doesn’t give any usefull information about the missing permissions. Instead it is handled as there would no no certificate file at all and SSL is disabled silently.