I don;t think this is a problem with DNN, but rather the NET framework....however maybe something could be done in DNN to solve the issue. I've logged this issue on Gemini and I'm continuing to look for an easy solution. http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=12939&PROJID=2 Regards, Dave.

Hi Sebastian,

The delay may not be included in the bulk email, but I'm also having the problem on a single email send.  using the DNN sendemail function.  This is then using the .NET framework  system.mail.smtpclient....which has a known bug...have a look at these links...

http://stackoverflow.com/questions/930236/net-best-method-to-send-email-system-net-mail-has-issues

http://connect.microsoft.com/VisualStudio/feedback/details/146711/smtpclient-does-not-gracefully-close-the-underlying-tcp-ip-connection

From what I understand about it (not much btw!!) the problem only has only become a big issue for IIS7, where the cpu jumps sky high.

Of course I've not yet tested the fix I've suggested, so I might be jumping down the wrong road, but once I've tried it I'll post the results on gemini.

And as always, I'll welcome any comments anyone has on what can be done to fix this!!

Regards,
Dave.

 The only ways I've figured out to get around this are
1) Upgrade everything to 4.0 (there's a defect in 4.0 though that you can't attach files greater then like 4 MB)
2) Switch your email processes over to using pickup directory (DNN doesn't have an option for this). Which seems really odd to me.
3) Some people have said this works
System.Net.Mail.SmtpClient client = new System.Net.Mail.SmtpClient();
client.ServicePoint.ConnectionLimit = 1;
client.ServicePoint.MaxIdleTime = 1;

(This only kind of worked for me and still caused a busy thread)

Honestly I just think there's some odd condition that comes to surface and this starts happening with .net 3.5. If you google around the internet you'll notice scattered cases of this and no one has a really awesome solution most of them speak to the defect in 3.5 smtp of not sending that final SMTP protocol command and most recommend switching to pickup directory. Why this only started happening in 5.4.2? I'm sure someone changed something that seemed irrelevant to this and it caused some order of race conditions that causes this to crop up.

I came across this issue on some websites not related to DNN in any way shape or form and we fixed it by switching to pickup directory. Honestly I think relying on .net to send e-mails (unless you are forced to) is not a good idea. Sending messages should be out of process for reasons just like this.

On my DNN instance I don't have anything active that uses DNN's default mail sending so it was easy enough to switch it over to pickup directory and it's been running like a champ ever since.

Sorry I know that's not much of a direct solution but I've never been able to find a direct "oh yea just do this" solution to this issue and ever since I found out about it I always just default to a pickup directory mail structure......

It'd be cool if in 5.5 they added a way to specify pickup directory for mail .... Maybe i'll go create that and we can all vote on it :-p Or maybe there already exists one.