Re: [Exim] Help decoding TLS error log

Pàgina inicial
Delete this message
Reply to this message
Autor: Patrice Fournier
Data:  
A: Marc MERLIN
CC: exim-users
Assumpte: Re: [Exim] Help decoding TLS error log
Quoting Marc MERLIN <marc_news@???>:

> I don't get it, this host seems to have working TLS, but exim still
> complains
> with:
> Malformed SMTP response from mail.epost.de [64.39.38.43] after
> STARTTLS: \025\003\001
>
> Yet, it complains after having said that the mail has been delivered
> correctly.
>


> usw-sf-list1:/etc/mail/virtualdomains/src# delivering message
> 16TUzZ-0000BM-00


Ok, sending message 16TUzZ-0000BM-00...

> Connecting to mail.epost.de [64.39.38.43.25] ... connected

[...]
> SMTP<< 250 <3C4DDC960002DD28> Mail accepted
> tls_close(): shutting down SSL


Mail is sent and accepted and Exim is shutting down SSL!?... I suppose
this shutdown is only on the client side (I can't look at the code right
now)

> LOG: 0 MAIN
> => kapeka@??? R=lookuphost T=remote_smtp H=mail.epost.de
> [64.39.38.43] X=TLSv1:RC4-SHA:128 DN="/C=DE/ST=NRW/L=Germany/O=Deutsche
> Post eBusiness GmbH/OU=ePOST Portal/OU=Terms of use at
> www.d-trust.de/rpa (c) 01/OU=Authenticated by D-TRUST GmbH/OU=Member,
> VeriSign Trust Network/CN=mail.epost.de" C="250 <3C4DDC960002DD28> Mail
> accepted"
> LOG: 0 MAIN
> Completed


Seems another message (16TUla-00065p-00) is waiting for that host,
starting a new Exim process...

> Exim version 3.31-VA-mm2 debug level 1 uid=8 gid=8
> Berkeley DB: Sleepycat Software: Berkeley DB 2.7.7: (08/20/99)
> delivering message 16TUla-00065p-00
> SMTP>> STARTTLS


resend a STARTTLS command... oops, this is against the RFC!

> SMTP<<
> LOG: 0 MAIN
> Malformed SMTP response from mail.epost.de [64.39.38.43] after
> STARTTLS: \025\003\001


Of course, the server is already in encrypted mode and doesn't understand
a thing about what it just got, neither does Exim understands the server's
encrypted response...

Here is the relevent part of the RFC:

Both the client and the server MUST know if there is a TLS session
active. A client MUST NOT attempt to start a TLS session if a TLS
session is already active. A server MUST NOT return the TLS extension
in response to an EHLO command received after a TLS handshake has
completed.

Sorry, no fix for now (except maybe restrict sending of messages over TLS
to one per connection) Does Exim as a server close TLS after it has
successfully received one message? I do suppose sf mailing lists do TLS
with many Exim boxes... and this error would have triggered the same
problem very often, ...

--
Patrice Fournier
pfournier@???