Failure of encrypted connection Kerio Mailserver


A customer called recently to complain that I had not responded to several of his emails. That's more than a little unusual for me - I'm not one to ignore my customers no matter what happens to be going on in my life. Still, he had apparently sent four different requests for help and I had not responded to any of them. What the heck was going on?

A bit of investigation of both his and my logs showed that I'd never received any of those messages. His logs showed that delivery was delayed, but it had not been long enough to give up yet. As my mailserver has not experienced any outages, I was at a loss to explain that - especially as he tried sending again as we spoke and that messages was also unsuccessful.

He then tried a manual impersonation of a mailserver to send me a test message.. at first I thought that had failed also, but it turned out to be in Spam:

X-Spam-Status: Yes, hits=6.9 required=3.0
        tests=EMPTY_MESSAGE: 2.32,MISSING_DATE: 1.36,MISSING_HEADERS: 1.021,
        MISSING_MID: 0.497,MISSING_SUBJECT: 1.799,TOTAL_SCORE: 6.997,
X-Spam-Flag: YES

Note that if you are impersonating a mailserver, it's best to include the normal headers like "Date" and "Subject" and NOT just send an empty message!

However, the fact that this did get so far as spam processing means that there was some other reason why his normal email was being delayed. What could it be?

I asked Kerio support for debugging suggestions. They immediately asked me to turn on "SMTP Server" in the Debug log and for my customer to turn on "SMTP Client".

SMTP client DebugSMTP  Debug

With that debugging on, he tried again to send email. Here's what I saw in my debug log when he did that:

[14/Jul/2012 11:32:43][31331] {smtps} Sent SMTP greeting to
[14/Jul/2012 11:32:43][31331] {smtps} Command EHLO
[14/Jul/2012 11:32:43][31331] {smtps} Sent reply to EHLO: 250 ...
[14/Jul/2012 11:32:44][31331] {smtps} Command STARTTLS
[14/Jul/2012 11:32:45][31331] {smtps} Successfully switched to TLS mode
[14/Jul/2012 11:32:46][31331] {smtps} Command EHLO
[14/Jul/2012 11:32:46][31331] {smtps} Sent reply to EHLO: 250 ...
[14/Jul/2012 11:32:46][31331] {smtps} Connection to SMTP server lost: connection closed by remote host.
[14/Jul/2012 11:32:46][31331] {smtps} SMTP server session end
[14/Jul/2012 11:32:46][31331] {smtps} Task 22152 handler END

That looked normal - except for the abrupt close, of course. What happened from his server's point of view?

[14/Jul/2012 09:11:40][19237] {smtpc} Sending email to SMTP server, 
delivering mail from <[email protected]>
[14/Jul/2012 09:11:40][19237] {smtpc} Connecting to ( 
using local interface
[14/Jul/2012 09:11:40][19237] {smtpc} Connected to
[14/Jul/2012 09:12:06][19237] {smtpc} Received greeting: 220 ESMTP ready
[14/Jul/2012 09:12:06][19237] {smtpc} Sending EHLO
[14/Jul/2012 09:12:06][19237] {smtpc} Switching connection to TLS
[14/Jul/2012 09:12:06][19237] {smtpc} Sending EHLO
[14/Jul/2012 09:12:06][19237] {smtpc} Connection closed by remote host prematurely.

Again an abrupt termination. The obvious difference from his manual connection is that the servers negotiated TLS. According to both ends, the switch to TLS was successful.. but my suspicions were raised because of the immediate exit after that switch.

What could be wrong? I didn't have any more debugging options other than setting up a packet trace, but I didn't expect to find out any more with that than I already knew: the connection was being dropped unexpectedly.

SSL Certificate

I don't know why I next went to look at my SSL certificate. I use a self-generated cert on this server, so I don't think about it much. To my surprise, I found that it was expired. Why didn't I know that already? It had been expired for a week; I had certainly accessed webmail on that server every day - so why hadn't I been warned about the expiration?

Maybe I had been and had mindlessly overridden it? I don't know, but I'm suspicious because my wife also accesses that server daily and she had not complained to me about any messages she didn't understand. Oh well, whatever: I regenerated a new certificate and, just for the heck of it, asked my customer to try sending email again. He did, and that arrived seconds later, followed almost immediately by the delayed messages he had tried to send earlier.

So, problem solved. I understand why it couldn't do TLS, but I think this is incorrect implementation: if the certificate is invalid, it should have refused the STARTTLS and the mail could have been delivered unencrypted. The problem here is that it told the sender that it could do TLS when in fact it could not.

In any case, the lesson here is to watch your certificate expiration!

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Failure of encrypted connection Kerio Mailserver


Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Tue Jul 17 21:22:05 2012: 11207   DaveGillam


I agree that an expired cert should have resulted either in the server MTA not advertising TLS, or the client MTA not accepting the cert, and reverting back to non-TLS. Since the server obviously presents the cert without first evaluating it, and the client did not revert to non-TLS, it's possible the client is configured to enforce TLS with your domain. If that's not the case, then there's also a code problem on the client side, imho. If the client is so configured, then it should have given a more meaningful error message (server's cert is expired).

I'd consider this an implementation bug, and report it to Kerio for fixing.



Tue Jul 17 21:26:07 2012: 11208   TonyLawrence


No, I asked if he was enforcing any restrictions - he is not.

I say "bug"..

Fri Jul 20 08:12:56 2012: 11209   NickBarron


Out of interest, you haven't got the self signed certificate added to the always trust option on the Mac have you?

Might explain how it expired and didn't warn you.

Fri Jul 20 09:44:44 2012: 11210   TonyLawrence


I had thought of that, but my wife certainly wouldn't have.. I don't know - it was only a few days, maybe we just hadn't noticed yet..

Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

We are stuck with technology when what we really want is just stuff that works. (Douglas Adams)

We are stuck with technology when what we really want is just stuff that works. (Douglas Adams)

This post tagged: