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.
e.g.
C: STARTTLS
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.
n8
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:
C: STARTTLS
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. <...>
...
handshake_failure
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
connection.
Philip Guenther