[RESOLVED] Can you close an SMTPClient session?

[chris128]

I have an issue with the System.Net.Mail.SMTPClient class - when it sends an email via the Send method it does not seem to send the QUIT command after sending the email so the connection stays open indefinitely (or until the SMTPClient instance is disposed of by the garbage collector) as far as I can tell.
I thought oh well I must just need to call Close or Dispose on it but neither of those methods exist
This is very basic, standard SMTP server usage - every server should send QUIT after it is done sending the other commands used to transfer the email, otherwise the remote server keeps the session open (and some servers have a limit on how many sessions can be open at a time or how many emails can be sent per session) so this could cause some serious problems.

Am I being daft or does there seem to be no way to make it do what pretty much every other SMTP client in the world does? I found a Microsoft Connect topic that had been created about this but it was 4 years old and the response from MS was that they would probably include something in the next version of the framework... which is what we are now on

Your thoughts/ideas?

Thanks
Chris

[Negative0]

Have you tried setting SmtpClient.ServicePoint.MaxIdleTime = 0?

[chris128]

Just tried that and its still not sending the QUIT command. This is the code I'm using to test with:

Dim client As New SmtpClient
client.Host = "localhost"
client.ServicePoint.MaxIdleTime = 0 'Also tried setting it to 1 as per some other websites
client.Send("[email protected]", "[email protected]", "test subject", "test body")

and this is a GUI for the SMTP server I'm writing that is receiving the commands from the other app that has the code above in.


That last line saying the client disconnected is only logged when I actually close the test client app completely

[Negative0]

Just for fun, what if you call a GC.Collect() after that?

[chris128]

Just for fun, what if you call a GC.Collect() after that?

Nope still does nothing, I'm puzzled as to why it doesnt even seem to be closing the connection at all (even if it doesnt send the QUIT command)

[Negative0]

According to the MSDN:

When the MaxIdleTime for a connection associated with a ServicePoint is exceeded, the connection remains open until the application tries to use the connection. At that time, the Framework closes the connection and creates a new connection to the remote host.

So, what if you try to send a second mail with that client. What happens? Does it disconnect and reconnect?

[chris128]

What a stupid way to work... I'll give that a go and see what happens but even if that works its not much use really

[Negative0]

No, but it would confirm that the documentation is correct. . After that maybe we can try and find a way to trick the connection to close.

[chris128]

I'm just busy trying to solve a new problem I have discovered from this little experiment (when the client side throws an exception during SmtpClient.Send there seems to be absolutely no way for my server side code to know as the TCP connection is left open and my server just keeps trying to read data from it ) but I will your suggestion in a minute

[kleinma]

I haven't had to deal with this, but you could try looking at the servicepoint object itself, which has a few methods and properties that may be able to control this.

Like

.ServicePoint.ConnectionLeaseTimeout = 1000
.ServicePoint.CloseConnectionGroup("GroupName")
.ServicePoint.SetTcpKeepAlive()

[chris128]

OK another strange thing I have discovered:
If I dont set the MaxIdleTime property and call Send then the standard SMTP commands are sent and then it just sits there and doesnt send any more data. However, if I set the MaxIdleTime property to anything and then call Send, it sends the normal commands and then constantly sends nothing... I'm using BeginRead and EndRead to read from the stream and I dont quite understand how it can send no data but still trigger my EndRead callback - the MSDN docs state that this is only triggered when data is sent or if an error is encountered but there is no way for me to check if an error was encountered as the Socket still reports as being connected and the NetworkStream still has CanRead set to True...
It also causes my program to go into a never ending loop of trying to read data from the stream, not getting any data from it, then trying to read from it again (and so the loop begins again).

So I just changed it so that if 0 bytes are read from the stream in the EndRead callback then it disconnects the session, this kind of kills two birds with one stone as it means that if a client calls Send and that throws an exception at the client end then my server EndRead callback is triggered and it reads 0 bytes so ends the connection - it also means that if someone specifies this MaxIdleTime property then sends an email to my SMTP server then it wont end up in this constant loop.
However, it does not do what I was originally looking at which is close the connection once the email has been sent (if this MaxIdleTime property has not been set at the client end)

[chris128]

I haven't had to deal with this, but you could try looking at the servicepoint object itself, which has a few methods and properties that may be able to control this.

Like

.ServicePoint.ConnectionLeaseTimeout = 1000
.ServicePoint.CloseConnectionGroup("GroupName")
.ServicePoint.SetTcpKeepAlive()

OK thanks I'll take a look at those properties

[chris128]

According to the MSDN:
So, what if you try to send a second mail with that client. What happens? Does it disconnect and reconnect?

I tried this and it certainly doesnt send the QUIT command (wasnt really expecting it to) but it does cause it to establish a new session so I'm assuming it is doing what the doc says and disconnecting... although im not sure if it automatically creates a new session anyway even without that property set - time to test.

EDIT: Ah yeah it doesnt create a new session if I dont set that property. So it must be disconnecting and reconnecting when that property is set... thats such a bad way of doing it though, why on earth have a timeout property that only actually gets checked next time you try to use the class, surely the point of a timeout is that after a set time the connection gets closed or whatever

[Negative0]

I have an email server at home, I'll do some testing as well and let you know what I find.

[chris128]

I have an email server at home, I'll do some testing as well and let you know what I find.

OK cool thanks

[Negative0]

From what I am seeing, it never sends quit. When I set MaxIdleTime = 1, it disconnects almost immediately after sending the message, but never sends the QUIT command. If I don't set the MaxIdleTime, it seems to disconnect after I close my app.

[chris128]

Yeah I have started to give up on the idea of it actually conforming to the SMTP standard (which is possibly one of the most simple networking standards out there!). Still, I'm not sure why yours actually disconnects after sending the message and mine doesnt seem to - how are you verifying that it closes the connection?

[Negative0]

Yeah I have started to give up on the idea of it actually conforming to the SMTP standard (which is possibly one of the most simple networking standards out there!). Still, I'm not sure why yours actually disconnects after sending the message and mine doesnt seem to - how are you verifying that it closes the connection?

Well now that I am testing it again, it is not releasing the connection until I do a GC.Collect() or close the app. Here are the logs from my SMTP server:

"TCPIP"	2768	"2009-09-16 20:03:27.103"	"Created accept socket 1728 on listening socket 1388"
"SMTPD"	2768	9	"2009-09-16 20:03:27.103"	"10.0.0.101"	"SENT: 220 example.com ESMTP"
"SMTPD"	2768	9	"2009-09-16 20:03:27.143"	"10.0.0.101"	"RECEIVED: EHLO MyComputerName"
"SMTPD"	2768	9	"2009-09-16 20:03:27.143"	"10.0.0.101"	"SENT: 250-hmailserver[nl]250-SIZE[nl]250 AUTH LOGIN PLAIN"
"SMTPD"	2768	9	"2009-09-16 20:03:27.183"	"10.0.0.101"	"RECEIVED: MAIL FROM:<[email protected]>"
"SMTPD"	2768	9	"2009-09-16 20:03:27.183"	"10.0.0.101"	"SENT: 250 OK"
"SMTPD"	2768	9	"2009-09-16 20:03:27.223"	"10.0.0.101"	"RECEIVED: RCPT TO:<[email protected]>"
"SMTPD"	2768	9	"2009-09-16 20:03:27.233"	"10.0.0.101"	"SENT: 250 OK"
"SMTPD"	2768	9	"2009-09-16 20:03:27.263"	"10.0.0.101"	"RECEIVED: DATA"
"SMTPD"	2768	9	"2009-09-16 20:03:27.273"	"10.0.0.101"	"SENT: 354 OK, send."
"SMTPD"	2768	9	"2009-09-16 20:03:27.303"	"10.0.0.101"	"SENT: 250 Queued (0.030 seconds)"
"APPLICATION"	2700	"2009-09-16 20:03:27.313"	"SMTPDeliverer - Message 45741: Delivering message from [email protected] to [email protected]. File: C:\Program Files\MailServer\Data\{22046451-AAA4-49D2-B8B9-A79E6BC82426}.eml"
"APPLICATION"	2700	"2009-09-16 20:03:27.343"	"SMTPDeliverer - Message 45741: Message delivery thread completed."
"TCPIP"	2768	"2009-09-16 20:03:27.363"	"Disconnecting socket 1640 for session 9"

[chris128]

Ah I see, same behaviour as I was seeing then pretty much. I suppose I will have to just give up on trying to get it to send the QUIT command and close the connection gracefully and just try and force it to disconnect after sending an email. Pretty naff though, I wonder if this is fixed in .NET 4...

Anyway, thanks for your time and effort (cant rate you as I've got to spread the love first apparently)

[kleinma]

Ah I see, same behaviour as I was seeing then pretty much. I suppose I will have to just give up on trying to get it to send the QUIT command and close the connection gracefully and just try and force it to disconnect after sending an email. Pretty naff though, I wonder if this is fixed in .NET 4...

Anyway, thanks for your time and effort (cant rate you as I've got to spread the love first apparently)

You can always download the beta of .NET 4 and test... but if MS doesn't consider it broken, then they probably didn't do anything to fix it.

[chris128]

Yeah I think I will test it when they bring the next BETA out

[chris128]

Marked this as resolved now as it basically looks like there is no way you can make the SMTPClient send the QUIT command (which is pretty rubbish if you ask me).

EDIT: Oh and I tried it in .NET 4.0 BETA 1 and its still the same

[chris128]

Just a quick update on this in case anyone is interested - this is apparently going to be fixed in the final release of .NET 4.0 (although its not in BETA 2)