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

Thu Jan 3 01:20:58 UTC 2008

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-server at 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

-- 
-----------------------------------------------------------------------------
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