Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Indy idSMTP with SSL leaving socket connection open tcp


This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 4 - Last Post: Sep 12, 2014 11:18 AM Last Post By: Remy Lebeau (Te...
Lukasz Rewak

Posts: 15
Registered: 6/10/04
Indy idSMTP with SSL leaving socket connection open tcp  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 11, 2014 10:07 PM
Hi,

I'm having an issue with a hosted exchange server and we have been told that it is because there are too many connections open from my IP address.

Testing the below code used to send emails via Indy SMTP/SSL it looks like the connection is not being closed properly. When I send a number of individual emails I can see in the Windows Resource Monitor the TCP connections opening - but they stay black for a long time instead of going gray... when sending via regular SMTP without SSL, the connections go gray nearly straight away.

It looks like something to do with SSL sockets? Is there any way to FORCE disconnect/close of the connection so we can avoid these issues?

var
  IdMessage: TIdMessage;
  SMTP: TIdSMTP;
  SSLHandler: TIdSSLIOHandlerSocketOpenSSL;
  IdUserPassProvider: TIdUserPassProvider;
  IdSASLLogin: TIdSASLLogin;
begin
  IdMessage := TIdMessage.Create(nil);
  try
    IdMessage.From.Address := 'email';
    IdMessage.Recipients.EMailAddresses := 'email';
    IdMessage.Subject := 'test email';
    SMTP := TIdSMTP.Create(nil);
    try
      SSLHandler := TIdSSLIOHandlerSocketOpenSSL.Create(SMTP);
      SSLHandler.SSLOptions.Method := sslvSSLv23;
      SSLHandler.SSLOptions.Mode := sslmClient;
      SSLHandler.SSLOptions.VerifyMode := [];
      SSLHandler.SSLOptions.VerifyDepth := 0;
      SMTP.IOHandler := SSLHandler;
      SMTP.UseTLS := utUseExplicitTLS;
      SMTP.AuthType := satSASL;
      IdUserPassProvider := TIdUserPassProvider.Create(SMTP);
      IdUserPassProvider.Username := 'user';
      IdUserPassProvider.Password:= 'pass';
      IdSASLLogin := TIdSASLLogin.Create(SMTP);
      IdSASLLogin.UserPassProvider := IdUserPassProvider;
      SMTP.SASLMechanisms.Add.SASL := IdSASLLogin;
      SMTP.Host := 'smtpauth';
      SMTP.Port := 587;
      SMTP.Connect;
      try
        SMTP.Send(IdMessage);
      finally
        SMTP.Disconnect;
      end;          
    finally
      SMTP.Free;
    end;
  finally
    IdMessage.Free;
  end;
end;


Thanks,
Lukasz
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Indy idSMTP with SSL leaving socket connection open tcp  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 11, 2014 11:30 PM   in response to: Lukasz Rewak in response to: Lukasz Rewak
Lukasz wrote:

It looks like something to do with SSL sockets? Is there any way
to FORCE disconnect/close of the connection so we can avoid
these issues?

Disconnect() should already be closing the socket, regardless of whether
SSL is used or not. If it is not, you are going to have to step into it
with the debugger to find out why.

Check to make sure the TIdSMTP.OnStatus event is being triggered with the
hsDisconnecting and hsDisconnected states. Those are reported by Disconnect()
before and after it closes the socket.

The alternative would be to call Disconnect() with its ANotifyPeer parameter
set to false (it is true by default). That will bypass sending a QUIT command
to the server to end the current SMTP session, and will immediately close
the socket without doing anything else.

--
Remy Lebeau (TeamB)
Lukasz Rewak

Posts: 15
Registered: 6/10/04
Re: Indy idSMTP with SSL leaving socket connection open tcp  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 11, 2014 11:46 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Thanks for your quick response.

Remy Lebeau (TeamB) wrote:
Check to make sure the TIdSMTP.OnStatus event is being triggered with the
hsDisconnecting and hsDisconnected states. Those are reported by Disconnect()
before and after it closes the socket.

I do appear to get both disconnect states when running the code...
2 => Connected.
5 => Encoding text
3 => Disconnecting.
4 => Disconnected.

The alternative would be to call Disconnect() with its ANotifyPeer parameter
set to false (it is true by default). That will bypass sending a QUIT command
to the server to end the current SMTP session, and will immediately close
the socket without doing anything else.

Also tried with SMTP.Disconnect(False) but does not seem to make a difference.

Any other ideas?
Lukasz Rewak

Posts: 15
Registered: 6/10/04
Re: Indy idSMTP with SSL leaving socket connection open tcp  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 12, 2014 1:04 AM   in response to: Lukasz Rewak in response to: Lukasz Rewak
Just tried running wireshark to get the network packets and here is what I found:

This is connecting to standard SMTP on port 25
435	21.147490	Client	Server	TCP	50894 > smtp [FIN, ACK] Seq=261 Ack=509 Win=66272 Len=0
436	21.170981	Server	Client	TCP	smtp > 50894 [ACK] Seq=509 Ack=262 Win=131840 Len=0
437	21.170982	Server	Client	TCP	smtp > 50894 [FIN, ACK] Seq=509 Ack=262 Win=131840 Len=0
438	21.171086	Client	Server	TCP	50894 > smtp [ACK] Seq=262 Ack=510 Win=66272 Len=0


This is connecting to the server via SSL port 587
6059	527.418649	Client	Server	TCP	50965 > submission [FIN, ACK] Seq=1595 Ack=4643 Win=65964 Len=0
6060	527.467884	Server	Client	TCP	submission > 50965 [FIN, ACK] Seq=4643 Ack=1595 Win=66304 Len=0
6061	527.467966	Client	Server	TCP	50965 > submission [ACK] Seq=1596 Ack=4644 Win=65964 Len=0
6062	527.468941	Server	Client	TCP	submission > 50965 [ACK] Seq=4644 Ack=1596 Win=66304 Len=0


The actual commands sent from client/server appear to be different. Should it be like that or could this explain the issue why its not being disconnected properly?

Thanks,
Lukasz
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Indy idSMTP with SSL leaving socket connection open tcp  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 12, 2014 11:18 AM   in response to: Lukasz Rewak in response to: Lukasz Rewak
Hello Lukasz,

The actual commands sent from client/server appear to be different.

That are physically different, but semantically doing the same thing. Keep
in mind that FIN and ACK are treated independantly. The presence of an ACK
simply acknowledges a previous packet. As an optimization, TCP allows FIN
and ACK to appear in any packet, they do not need to be in their own packets,
though that is a possibility as well.

In the first case, the client is sending a packet that both ACKs a previous
packet and FINs to signal a socket close. The server is ACKing the client's
FIN, then sending its own FIN in a separate packet, which the client ACKs.
This is a normal client-FIN server-ACK server-FIN client-ACK sequence.

In the second case, the client is sending a packet that both ACKs a previous
packet and FINs to signal a socket close. The server is ACKing the client's
FIN and sending its own FIN in the same packet, which the client ACKs. This
is also a normal client-FIN server-ACK server-FIN client-ACK sequence.

So in actuality, the socket connections are properly being closed in both
scenarios. Now, it might be possible that the socket handles inside of
your app are not being released from memory correctly, or maybe you are passing
through a router/firewall that is not handling its own FIN/ACKs correctly
to close its connection to the server. But, either way, those would be separate
issues. As far as your client app is concerned, its local TCP stack is handling
the FIN/ACK sequences correctly and closing its local end of the connections.

You shoud not see the connections in an ESTABLISHED state (they should be
in TIME_WAIT or CLOSED state) when you run the command-line NETSTAT app.
See the following diagram for TCP socket state transitions:

http://www.cis.temple.edu/~giorgio/cis307/readings/tcpstates.gif

--
Remy Lebeau (TeamB)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02