[Top] [All Lists]


2008-10-23 22:57:13
That is what I did in the end.
At first, my SMTP server was sending the client an error, and then closing
the connection, but it was breaking some clients.  IIRC, it was a Microsoft
Exchange server complaining that it received two responses to one command,
and of coure, that was true.

S: 220 Ready to start TLS
<TLS negotiation fails>
S: 454  4.4.3  TLS not available: error negotiating handshake
C: huh?

So I just skipped the error, and dropped the connection.

On Thu, Oct 23, 2008 at 1:19 AM, Ivar Lumi <ivar(_at_)lumisoft(_dot_)ee> wrote:

Thanks,  this is what i was looking for.

So in case of SMTP, server just should close connection.

Philip Guenther wrote:

On Thu, 23 Oct 2008, Ivar Lumi wrote:

After reading RFC 3207, i found probably non documented item.

For example:
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>

Now if negotiation fails, whats then ?
Send error ? close connection ?
Whats the proper action ?

RFC 3207 cites/defers to RFC 2246 for the definition of the TLS protocol.
So follow the rules over in the TLS specification.  To quote RFC 2246:

7.2.2. Error alerts

  Error handling in the TLS Handshake protocol is very simple. When an
  error is detected, the detecting party sends a message to the other
  party. Upon transmission or receipt of an fatal alert message, both
  parties immediately close the connection.  <...>
     Reception of a handshake_failure alert message indicates that the
     sender was unable to negotiate an acceptable set of security
     parameters given the options available.  This is a fatal error.

(Other errors may apply, depending on exactly what you mean by
"negotiation fails".)

I.e., if your end detects a fatal error, send a fatal error alert and
close the connection.  If your end receives a fatal error alert, close the

Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>