Bug#348046: exim4-daemon-heavy: TLS delivery attempts fail with: (gnutls_handshake): A TLS packet with unexpected length was received.

Andrew McGlashan

unread,

Oct 27, 2007, 1:50:07 AM10/27/07

to

Hi,

I have just discovered this bug and it appears to be rather long term.....
any progress?

Some further information:

SMTP Auth issue with Incredimail using Exim, but not with Gmail...

- SSL over 465 works fine for Outlook Express;

- same machine if running Incredimail fails with msg as per this bug report.

I wonder if Incredimail uses OpenSSL? And if so, is there any way that the
Exim4 can work with both OpenSSL and GNUTLS?

My version details:

Exim version 4.63 #1 built 20-Jan-2007 10:42:32
Copyright (c) University of Cambridge 2006
Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September 6, 2005)
Support for: crypteq iconv() IPv6 PAM Perl GnuTLS move_frozen_messages
Content_Scanning Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb
dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram
redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated

Would it be safe and advisable to provide the output from the
gnutls-cli-debug program here?
gnutls-cli-debug --port 465 -v localhost -d 3
[I only use port 465 with SSL/TLS]

Kind Regards
AndrewM

Andrew McGlashan
Broadband Solutions now including VoIP

Current Land Line No: 03 9912 0504
Mobile: 04 2574 1827 Fax: 03 8790 1224

National No: 1300 85 3804

Affinity Vision Australia Pty Ltd
http://www.affinityvision.com.au
http://adsl2choice.net

In Case of Emergency -- http://www.affinityvision.com.au/ice.html

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Marc Haber

unread,

Oct 27, 2007, 8:30:16 AM10/27/07

to

On Sat, Oct 27, 2007 at 03:29:47PM +1000, Andrew McGlashan wrote:
> I have just discovered this bug and it appears to be rather long term.....
> any progress?

This will most probably not be fixed in etch.

> Some further information:
>
> SMTP Auth issue with Incredimail using Exim, but not with Gmail...
>
> - SSL over 465 works fine for Outlook Express;
>
> - same machine if running Incredimail fails with msg as per this bug report.
>
> I wonder if Incredimail uses OpenSSL?

What is Incredimail? An MTA, or a Mail service?

> And if so, is there any way that the Exim4 can work with both
> OpenSSL and GNUTLS?

You can recompile the packages with OpenSSL.

> Would it be safe and advisable to provide the output from the
> gnutls-cli-debug program here?
> gnutls-cli-debug --port 465 -v localhost -d 3

Probably not since we know that a gnutls client will work nicely with
exim.

I kind of fail to understand what you intend to do and what works and
what not.

Greetings
Marc

Vincent Lefevre

unread,

Oct 27, 2007, 9:00:10 AM10/27/07

to

On 2007-10-27 14:17:24 +0200, Marc Haber wrote:
> You can recompile the packages with OpenSSL.

Is there any reason why this isn't done by default?

--
Vincent Lefèvre <vin...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Andrew McGlashan

unread,

Oct 27, 2007, 10:30:10 AM10/27/07

to

Hi Marc,

Marc Haber wrote:
> On Sat, Oct 27, 2007 at 03:29:47PM +1000, Andrew McGlashan wrote:
>> I have just discovered this bug and it appears to be rather long
>> term..... any progress?
>
> This will most probably not be fixed in etch.

:(

> What is Incredimail? An MTA, or a Mail service?

Incredimail is an email client [MUA], much like Outlook Express, but it is
heavily used in the Windows world.

FWIW, I don't like Incredimail, however, I have a client whom does like it
and I want to host his email -- the problem is the TLS handling as I enforce
SMTP Auth usage and only with port 465 with SSL.

>> And if so, is there any way that the Exim4 can work with both
>> OpenSSL and GNUTLS?
>
> You can recompile the packages with OpenSSL.

I prefer to stick with standard packages as supplied by apt package
management.... I am not interested in doing any re-compiles and moving too
far away from the standards that are currently in place. However, if a
special package was made available in the normal way, then I would be happy
to install it -- so long as it is maintained as a 'normal' package would be.

>> Would it be safe and advisable to provide the output from the
>> gnutls-cli-debug program here?
>> gnutls-cli-debug --port 465 -v localhost -d 3
>
> Probably not since we know that a gnutls client will work nicely with
> exim.

I am guessing that if OpenSSL is used by an MUA, then it too might fail
similarly.

> I kind of fail to understand what you intend to do and what works and
> what not.

I want to be able to support the use of Incredimail against my mail server
without departing from my strict policy of using SMTP Auth over port 465
with SSL security.

Kind Regards
AndrewM

Andrew McGlashan

unread,

Oct 27, 2007, 11:50:07 AM10/27/07

to

Receiving mail via POPS on port 995 with SSL works fine with Incredimail
[and other tried MUAs] but that is using openssl through qpopper to get the
mail.

Extract from /var/log/mail.info :

Oct 26 11:56:36 www in.qpopper[15103]: (v4.0.5) TLSv1/SSLv3 handshake with
client at XXXXXX.xxxx.xxxxx.net.au (ip.ad.dr.ess); new session-id; cipher:
RC4-MD5 (RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 ), 128 bits
[pop_tls_openssl.c:543]

So... we either need Incredimail to support GNUTLS or we need Exim4 to
include support for the data formats / handshaking as used by openssl. It
would seem that gmail most probably uses openssl and that is why it works
with Incredimail.

Marc Haber

unread,

Oct 28, 2007, 9:50:07 AM10/28/07

to

On Sun, Oct 28, 2007 at 12:16:10AM +1000, Andrew McGlashan wrote:
> Marc Haber wrote:
> >You can recompile the packages with OpenSSL.
>
> I prefer to stick with standard packages as supplied by apt package
> management.... I am not interested in doing any re-compiles and moving too
> far away from the standards that are currently in place.

Then you're out of luck.

> However, if a special package was made available in the normal way,

I do not have time and resources to maintain two of them, and am not
sure about licensing issues.

> >>Would it be safe and advisable to provide the output from the
> >>gnutls-cli-debug program here?
> >> gnutls-cli-debug --port 465 -v localhost -d 3
> >
> >Probably not since we know that a gnutls client will work nicely with
> >exim.
>
> I am guessing that if OpenSSL is used by an MUA, then it too might fail
> similarly.

No, you can connect to exim just fine with an openssl client. Just try
openssl s_client.

You might want to use gnutls-serv as a test target against your
incredimail client.

> >I kind of fail to understand what you intend to do and what works and
> >what not.
>
> I want to be able to support the use of Incredimail against my mail server
> without departing from my strict policy of using SMTP Auth over port 465
> with SSL security.

Port 465 is an RFC violation anyway, it was never assigned for SMTP
over SSL in the first place. Microsoft is the only instance who
insists on using this non-standard.

The widely accepted standardized way to do secure SMTP is STARTTLS,
which is kind of SMTP-over-SSL-over-SMTP and can be run on the
standardized ports 25 (SMTP) and 587 (mail submission).

But you are likely to fall into the same trap with your incredimail
that way.

Greetings
Marc

--

Andrew McGlashan

unread,

Oct 28, 2007, 11:20:15 AM10/28/07

to

Hi Marc,

Marc Haber wrote:
>> I prefer to stick with standard packages as supplied by apt package
>> management.... I am not interested in doing any re-compiles and
>> moving too far away from the standards that are currently in place.
>
> Then you're out of luck.

Okay.... well I'll persevere if I can with some more information.

>> I want to be able to support the use of Incredimail against my mail
>> server without departing from my strict policy of using SMTP Auth
>> over port 465 with SSL security.
>
> Port 465 is an RFC violation anyway, it was never assigned for SMTP
> over SSL in the first place. Microsoft is the only instance who
> insists on using this non-standard.

I have just re-configured my server to accept 25 / 265 and 587 for SSL/TLS
connections.

03_exim4-config_tlsoptions:
tls_on_connect_ports=465:587

AND in /etc/default/exim4
SMTPLISTENEROPTIONS='-oX 587:465:25 -oP /var/run/exim4/exim.pid'

Now.... I can send using port 25 or 465 both with SSL with OE, but 587 with
OE times out and eventually gives the same error on the server as does
IncrediMail -- although IM does it almost immediately.

Leaving the port at 25 is not acceptable because any old wireless hotspot
will interfere with my direct SMTP Auth connections by hijacking the port 25
traffic and using their own sending mail servers.

I don't know why port 587 with SSL isn't working with OE though.

By default if you select SSL for outgoing mail server with OE, then it uses
port 25 -- this has to be changed to 465 in my case to work as I prefer.

GMAIL also breaks the RFC then as they only use port 465....

> The widely accepted standardized way to do secure SMTP is STARTTLS,
> which is kind of SMTP-over-SSL-over-SMTP and can be run on the
> standardized ports 25 (SMTP) and 587 (mail submission).
>
> But you are likely to fall into the same trap with your incredimail
> that way.

IM will not work on port 25, 465 or 587.

On my server, I can see the following:

# netstat -an|grep -e 25 -e 465 -e 587|grep tcp
tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 192.168.2.2:25 80.161.186.2:63657
TIME_WAIT

And when OE is 'waiting' on port 587 tests:

# netstat -an|grep -e 25 -e 465 -e 587|grep tcp
tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 192.168.2.2:587 192.168.0.158:2854
ESTABLISHED

When I give up on the waiting, the following is sent to
/var/log/exim4/mainlog:

2007-10-29 02:06:07 TLS error on connection from [192.168.0.158]
(gnutls_handshake): A TLS packet with unexpected length was received

Kind Regards
AndrewM

Andrew McGlashan

unread,

Oct 28, 2007, 11:30:21 AM10/28/07

to

Marc Haber wrote:
> You might want to use gnutls-serv as a test target against your
> incredimail client.

Okay, well I set up port 588 for the test:

# gnutls-serv -p 588
Echo Server ready. Listening to port '588'.

Error in handshake
Error: Could not negotiate a supported cipher suite.

Kind Regards
AndrewM

Marc Haber

unread,

Oct 31, 2007, 4:50:11 PM10/31/07

to

On Mon, Oct 29, 2007 at 02:14:19AM +1100, Andrew McGlashan wrote:
> Marc Haber wrote:
>> You might want to use gnutls-serv as a test target against your
>> incredimail client.
>
> Okay, well I set up port 588 for the test:
>
> # gnutls-serv -p 588
> Echo Server ready. Listening to port '588'.
>
> Error in handshake
> Error: Could not negotiate a supported cipher suite.

Please retry with -d 5

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834

Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

Andrew McGlashan

unread,

Oct 31, 2007, 9:50:08 PM10/31/07

to

Marc Haber wrote:
> On Mon, Oct 29, 2007 at 02:14:19AM +1100, Andrew McGlashan wrote:
>> Marc Haber wrote:
>>> You might want to use gnutls-serv as a test target against your
>>> incredimail client.
>>
>> Okay, well I set up port 588 for the test:
>>
>> # gnutls-serv -p 588
>> Echo Server ready. Listening to port '588'.
>>
>> Error in handshake
>> Error: Could not negotiate a supported cipher suite.
>
> Please retry with -d 5

# gnutls-serv -p 588 -d 5

Echo Server ready. Listening to port '588'.

|<4>| REC[8070cf0]: V2 packet received. Length: 76
|<4>| REC[8070cf0]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8070cf0]: Received Packet[0] Handshake(22) with length: 76
|<4>| REC[8070cf0]: Decrypted Packet[0] Handshake(22) with length: 76
|<3>| HSK[8070cf0]: CLIENT HELLO(v2) was received [76 bytes]
|<3>| HSK[8070cf0]: SSL 2.0 Hello: Client's version: 3.1
|<3>| HSK[8070cf0]: Parsing a version 2.0 client hello.
|<2>| ASSERT: gnutls_handshake.c:2674
|<3>| HSK[8070cf0]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5
|<2>| ASSERT: gnutls_handshake.c:2674
|<3>| HSK[8070cf0]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<2>| ASSERT: gnutls_handshake.c:2674
|<3>| HSK[8070cf0]: Removing ciphersuite: ANON_DH_AES_128_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|<3>| HSK[8070cf0]: Removing ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[8070cf0]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8070cf0]: Removing ciphersuite: RSA_AES_128_CBC_SHA1
|<2>| ASSERT: gnutls_handshake.c:632
|<2>| ASSERT: gnutls_v2_compat.c:181
|<2>| ASSERT: gnutls_handshake.c:1952
|<2>| ASSERT: gnutls_handshake.c:2415

Error in handshake
Error: Could not negotiate a supported cipher suite.

|<4>| REC: Sending Alert[2|40] - Handshake failed
|<4>| REC[8070cf0]: Sending Packet[0] Alert(21) with length: 2
|<4>| REC[8070cf0]: Sent Packet[1] Alert(21) with length: 7
|<2>| ASSERT: gnutls_record.c:242

Kind Regards
AndrewM

Marc Haber

unread,

Nov 1, 2007, 5:30:16 AM11/1/07

to

On Thu, Nov 01, 2007 at 11:43:36AM +1100, Andrew McGlashan wrote:
> # gnutls-serv -p 588 -d 5
> Echo Server ready. Listening to port '588'.
>
> |<4>| REC[8070cf0]: V2 packet received. Length: 76
> |<4>| REC[8070cf0]: Expected Packet[0] Handshake(22) with length: 1
> |<4>| REC[8070cf0]: Received Packet[0] Handshake(22) with length: 76
> |<4>| REC[8070cf0]: Decrypted Packet[0] Handshake(22) with length: 76
> |<3>| HSK[8070cf0]: CLIENT HELLO(v2) was received [76 bytes]
> |<3>| HSK[8070cf0]: SSL 2.0 Hello: Client's version: 3.1

After thinking for a while, why did your incredimail not complain
about the server not presenting a certificate?

Please try again and give gnutls-serv the same certificate that your
exim also uses.

For reference, you might want to try openssl:

openssl s_server -cert /etc/exim4/tls/certs/exim.crt -key /etc/exim4/tls/key/exim.key -accept 588 -debug

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834

Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190

Andrew McGlashan

unread,

Nov 1, 2007, 7:50:14 AM11/1/07

to

Marc Haber wrote:
> After thinking for a while, why did your incredimail not complain
> about the server not presenting a certificate?

It was dropping out with the error as given already with no hint of any
certificate issue. I have my own ca.crt certificate installed in the
trusted root in order to stop questions about a certificate that I already
trust (or others made by myself).

> Please try again and give gnutls-serv the same certificate that your
> exim also uses.
>
> For reference, you might want to try openssl:

Tried this:
# gnutls-serv -d 5 -p 588 \
--x509certfile /etc/exim4/exim.crt \
--x509keyfile /etc/exim4/exim.key

Failed in the same manner, IM gave immediate error and quit trying to send.

On my Debian box:

Echo Server ready. Listening to port '588'.

|<4>| REC[80738b0]: V2 packet received. Length: 76
|<4>| REC[80738b0]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[80738b0]: Received Packet[0] Handshake(22) with length: 76
|<4>| REC[80738b0]: Decrypted Packet[0] Handshake(22) with length: 76
|<3>| HSK[80738b0]: CLIENT HELLO(v2) was received [76 bytes]
|<3>| HSK[80738b0]: SSL 2.0 Hello: Client's version: 3.1
|<3>| HSK[80738b0]: Parsing a version 2.0 client hello.
|<2>| ASSERT: gnutls_handshake.c:2674
|<3>| HSK[80738b0]: Removing ciphersuite: ANON_DH_ARCFOUR_MD5
|<2>| ASSERT: gnutls_handshake.c:2674
|<3>| HSK[80738b0]: Removing ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<2>| ASSERT: gnutls_handshake.c:2674
|<3>| HSK[80738b0]: Removing ciphersuite: ANON_DH_AES_128_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[80738b0]: Keeping ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[80738b0]: Keeping ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[80738b0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<2>| ASSERT: gnutls_handshake.c:2674
|<3>| HSK[80738b0]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<2>| ASSERT: gnutls_handshake.c:2674
|<3>| HSK[80738b0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<2>| ASSERT: gnutls_handshake.c:2664
|<3>| HSK[80738b0]: Removing ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|<3>| HSK[80738b0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[80738b0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[80738b0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[80738b0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[80738b0]: Selected cipher suite: RSA_ARCFOUR_MD5
|<2>| ASSERT: gnutls_db.c:327
|<2>| ASSERT: gnutls_db.c:247
|<3>| HSK[80738b0]: SessionID:
dd9ee262aef8cf92e30193819a8a13ea830a19326bf476e36260acac5c605c97
|<3>| HSK[80738b0]: SERVER HELLO was send [74 bytes]
|<4>| REC[80738b0]: Sending Packet[0] Handshake(22) with length: 74
|<4>| REC[80738b0]: Sent Packet[1] Handshake(22) with length: 79
|<3>| HSK[80738b0]: CERTIFICATE was send [916 bytes]
|<4>| REC[80738b0]: Sending Packet[1] Handshake(22) with length: 916
|<4>| REC[80738b0]: Sent Packet[2] Handshake(22) with length: 921
|<3>| HSK[80738b0]: CERTIFICATE REQUEST was send [9 bytes]
|<4>| REC[80738b0]: Sending Packet[2] Handshake(22) with length: 9
|<4>| REC[80738b0]: Sent Packet[3] Handshake(22) with length: 14
|<3>| HSK[80738b0]: SERVER HELLO DONE was send [4 bytes]
|<4>| REC[80738b0]: Sending Packet[3] Handshake(22) with length: 4
|<4>| REC[80738b0]: Sent Packet[4] Handshake(22) with length: 9
|<2>| ASSERT: gnutls_buffers.c:289
|<2>| ASSERT: gnutls_buffers.c:1087
|<2>| ASSERT: gnutls_handshake.c:949
|<2>| ASSERT: gnutls_buffers.c:565
|<2>| ASSERT: gnutls_record.c:891
|<2>| ASSERT: gnutls_buffers.c:1087
|<2>| ASSERT: gnutls_handshake.c:949
|<2>| ASSERT: gnutls_handshake.c:2463
Error in handshake
Error: A TLS packet with unexpected length was received.
|<4>| REC: Sending Alert[2|22] - Record overflow
|<4>| REC[80738b0]: Sending Packet[4] Alert(21) with length: 2
|<4>| REC[80738b0]: Sent Packet[5] Alert(21) with length: 7
|<2>| ASSERT: gnutls_record.c:242

> openssl s_server -cert /etc/exim4/tls/certs/exim.crt -key
> /etc/exim4/tls/key/exim.key -accept 588 -debug

Using openssl:
# openssl s_server \
-cert /etc/exim4/exim.crt \
-key /etc/exim4/exim.key \
-accept 588 -debug

Causes IM to continually be stuck at 'connecting' at the 'securing' point.

Last lines shown on Linux console [putty]:

-----BEGIN SSL SESSION PARAMETERS-----
MHUCAQECAgMBBAIABAQgE3hoE42fCVtNzS+IIc4qomwaLjHyA9LsHCXJkjcmmYYE
data removed
BqEGAgRHKbLBogQCAgEspAYEBAEAAAA=
-----END SSL SESSION PARAMETERS-----
Shared
ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:DES-CBC-SHA:EXP-RC4-MD5:EXP-RC2-CBC-MD5:EDH-DSS-DES-
CBC3-SHA:EDH-DSS-DES-CBC-SHA
CIPHER is RC4-MD5

Okay.... then I hit enter on the putty session and more data appeared, so I
continued to hit enter until I saw this:

read from 0x80d0b50 [0x80c5538] (5 bytes => 0 (0x0))
ERROR
shutting down SSL
CONNECTION CLOSED
ACCEPT

Then, IM fails again with "Failed to connect to the outgoing server,
'myserver'. Please try again later.
- "Socket Error: (0) The operation completed successfully.

Kind Regards
AndrewM

Marc Haber

unread,

Jan 2, 2008, 8:50:16 PM1/2/08

to

On Mon, Oct 29, 2007 at 02:05:18AM +1100, Andrew McGlashan wrote:
> Marc Haber wrote:

> >> I want to be able to support the use of Incredimail against my mail
> >> server without departing from my strict policy of using SMTP Auth
> >> over port 465 with SSL security.
> >
> > Port 465 is an RFC violation anyway, it was never assigned for SMTP
> > over SSL in the first place. Microsoft is the only instance who
> > insists on using this non-standard.
>
> I have just re-configured my server to accept 25 / 265 and 587 for SSL/TLS
> connections.
>
> 03_exim4-config_tlsoptions:
> tls_on_connect_ports=465:587
>
> AND in /etc/default/exim4
> SMTPLISTENEROPTIONS='-oX 587:465:25 -oP /var/run/exim4/exim.pid'
>
> Now.... I can send using port 25 or 465 both with SSL with OE, but 587 with
> OE times out and eventually gives the same error on the server as does
> IncrediMail -- although IM does it almost immediately.

The standardized usage of TCP/587 is STARTTLS, so technically,
tls_on_connect_ports=587 is likely to confuse conforming clients. I do
not have an idea how OE or Incredimail behave, but I wouldn't be
surprised that they would choke when expecting a cleartext ESMTP
handshake with STARTTLS and being presented with an on-connect TLS
handshake.

If you want to be sure, try finding out what IM and OE do when you
have them connect to a netcat process on TCP/587 that immediately
shows them a cleartext ESMTP greeting. If they respond with a
cleartext EHLO, then you have your exim misconfigured and need to
remove the 587 from tls_on_connect_ports.

> GMAIL also breaks the RFC then as they only use port 465....

$ gnutls-cli -p 587 smtp.gmail.com -s
Resolving 'smtp.gmail.com'...
Connecting to '72.14.221.111:587'...

- Simple Client Mode:

220 mx.google.com ESMTP 4sm12205522fge.8
EHLO test.client.example
250-mx.google.com at your service, [77.1.33.179]
250-SIZE 28311552
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
STARTTLS
220 2.0.0 Ready to start TLS
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 1 certificates.

- Certificate[0] info:
# The hostname in the certificate matches 'smtp.gmail.com'.
# valid since: Mon Jul 30 18:58:07 CEST 2007
# expires at: Tue Jul 29 18:58:07 CEST 2008
# fingerprint: 32:66:6C:0A:DC:4F:2D:F9:83:2E:B4:AA:22:A7:E0:E7
# Subject's DN: C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com
# Issuer's DN: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,EMAIL=premium...@thawte.com

- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS 1.0
- Key Exchange: RSA
- Cipher: 3DES 168 CBC
- MAC: SHA
- Compression: NULL

502 5.5.1 Unrecognized command 4sm12205522fge.8
EHLO test.client.example
250-mx.google.com at your service, [77.1.33.179]
250-SIZE 28311552
250-8BITMIME
250-AUTH LOGIN PLAIN
250 ENHANCEDSTATUSCODES
quit
221 2.0.0 mx.google.com closing connection 4sm12205522fge.8
*** Fatal error: A TLS packet with unexpected length was received.
*** Server has terminated the connection abnormally.
$

This looks to me as they have a compliant submission agent on TCP/587
as well.

> > The widely accepted standardized way to do secure SMTP is STARTTLS,
> > which is kind of SMTP-over-SSL-over-SMTP and can be run on the
> > standardized ports 25 (SMTP) and 587 (mail submission).
> >
> > But you are likely to fall into the same trap with your incredimail
> > that way.
>
> IM will not work on port 25, 465 or 587.
>
> On my server, I can see the following:
>
> # netstat -an|grep -e 25 -e 465 -e 587|grep tcp
> tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
> tcp 0 0 192.168.2.2:25 80.161.186.2:63657
> TIME_WAIT

This indicates a TCP session that has already finished.

> And when OE is 'waiting' on port 587 tests:
>
> # netstat -an|grep -e 25 -e 465 -e 587|grep tcp
> tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
> tcp 0 0 192.168.2.2:587 192.168.0.158:2854
> ESTABLISHED

That looks like the session is still up and either side is waiting.
Might be possible that OE is waiting for a clear text SMTP banner
while the exim (with smtp_on_connect_ports including 587) is waiting
for a TLS handshake. Both sides will wait until timeout.

> When I give up on the waiting, the following is sent to
> /var/log/exim4/mainlog:
>
> 2007-10-29 02:06:07 TLS error on connection from [192.168.0.158]
> (gnutls_handshake): A TLS packet with unexpected length was received

This is also an indication of exim expecting the remote side to talk
TLS while the remote side isn't.

Greetings
Marc

--