|Subject:||Re: Capabilities not set during Connect|
|Posted by:||Remy Lebeau (Indy Team) (firstname.lastname@example.org)|
|Date:||Wed, 13 Sep 2006|
"Wynn Richardson" <wy…@umn.edu> wrote in message
> I am upgrading an app from BDS2005/Indy 9 to BDS2006/Indy 10
> and have run into some trouble
What exactly are you having a problem with? Please be more specific.
> The snippet of code that actually does the send is pretty simple...
You do not need to call Authenticate() yourself. Send() does that
> However, now with BDS2006/Indy 10, an EIdSMTPReplyError
> exception gets raised.
That is because you are using the TIdSMTP incorrectly. Keep reading.
> in the Authenticate method when StartTLS is called, the check
> of SupportsTLS fails. Because this check fails, in the subsequent call
> of ProcessTLSNotAvail a call is made to Disconnect which is where
> the exception is being raised.
The SendCmd() call for the QUIT command is receiving the rest of the reply
that belongs to the initial EHLO command. Which means that Disconnect() is
being called while Connect() is still running.
> In the Disconnect call, the SendCmd of 'QUIT' is expecting a 221
> response but a 250 response is actually coming back from the server.
> Now, this 250 response from the server *appears* to be a remnant
> line from the original Connect call.
The only way that can happen is if you are calling Authenticate() while
Connect() is still running, such as in the OnConnect event. That is exactly
what your log is actually showing is happening - QUIT is sent while EHLO is
still sending its reply back.
> It appears what *should* be happening is in the SendGreeting method
> (called from Connect) the LastCmdResult after the EHLO command
> should get added to the Capabilities list.
It already does exactly that.
> Then Capabilities is later checked to see if it contains STARTTLS
> in SupportsTLS.
> After placing breakpoints around, the LastCmdResult.Text is empty
> in the SendGreeting method after the EHLO command.
That is because the SendCmd() call inside of Disconnect() already read the
reply data before the SendCmd() in SendGreeting() could read it.
> You can see that the QUIT command gets sent before the 250
> response line I really want is received.
Again, the only way that can happen is if you are doing something with the
TIdSMTP before Connect() has exited, such as in the OnConnect event. There
is no other way what you describe can be happening.
Capabilities not set during Connect posted by Wynn Richardson on Wed, 13 Sep 2006