What is a More Robust SMTP Library for .NET?

[Wowbagger]

I realize there will only be a few folks on here, who could answer this. But, it is worth a shot.

I am considering replacing my usage of the built-in .NET SMTP systems, (System.Web.Mail and System.Net.Mail), with something else, perhaps much more "robust". Anyone have any recommendations?

It also needs to be inexpensive, if not free, because non-profit organizations and/or poor slob friends of mine, would be using it, and they would gawk at expensive licenses.

For example: Does anyone know if Quiksoft's FreeSMTP.Net is any good?

(Man, it has been a loooong time since I looked into SMTP libraries. I have not done so since the days of Classic ASP.)

 

[ravdin]

System.Web.Mail has always worked out all right for my purposes, but I haven't done anything like spam, um, I mean direct marketing. All kidding aside, if I need to send out emails it's generally from a service that continuously queries a database then sends out notifications if needed. What do you need to do that requires a more robust solution?

 

[Wowbagger]

Nothing much. No, it is NOT spam or direct marketing. I would have no truck with such things. These are e-mails going out strictly to people who would want them.

There are a few problems cropping up: Sometimes duplicate e-mails are going out; and there is a weird problem where HREF tags are automatically getting truncated in HTML messages. I traced all these issues back to the SMTP client. Either it, or something after it, is causing all this. It does not seem to be anything in my own code.

And, in some cases, we have older applications (pre-.NET) that do NOT have these symptoms, even when run on the same machine, and pointing to the same mail server.

 

[ravdin]

Nothing much. No, it is NOT spam or direct marketing. I would have no truck with such things. These are e-mails going out strictly to people who would want them.

There are a few problems cropping up: Sometimes duplicate e-mails are going out; and there is a weird problem where HREF tags are automatically getting truncated in HTML messages. I traced all these issues back to the SMTP client. Either it, or something after it, is causing all this. It does not seem to be anything in my own code.

And, in some cases, we have older applications (pre-.NET) that do NOT have these symptoms, even when run on the same machine, and pointing to the same mail server.

I know that SMTP doesn't like lines with more than 1024 characters. But if your classic ASP applications can send identical messages without any problems, and you're specifically seeing truncation in HREF links, I don't have a good explanation for this.

 

[Wowbagger]

But if your classic ASP applications can send identical messages without any problems, and you're specifically seeing truncation in HREF links, I don't have a good explanation for this.

Frankly, I am a bit mystified by that, too. It might not be the SMTP protocol doing it. The HTML content might be filtered on the other end. But, only from certain applications. Weirder and weirder....

 

[Wowbagger]

Well... dang! It seems the dupe e-mailing problem is sometimes occuring even with alternative SMTP libraries!

Anyone have other ideas about that?

 

[CrikeyBobs]

Are you able to perform network monitoring to see if the dups are coming out of the application server or out of the SMTP server? I use Microsoft Network Monitor on my dev machine.

 

[Wowbagger]

Are you able to perform network monitoring to see if the dups are coming out of the application server or out of the SMTP server? I use Microsoft Network Monitor on my dev machine.

We can tell from the logs, and other things, that they are coming from the application.

In some experiments, I noticed that the rate of dupes seems to be dependent on the processing occurring in the application's loop. If I remove lots of features and code before .Send is called, there are no dupes. If I put them back, they sometimes appear. But, .Send is only being called once per message, either way.

 

[69dodge]

some random thoughts:

Are the duplicates caused by the specific code that you removed, or do you also get duplicates if, instead of removing the code entirely, you replace it by a useless loop that does nothing, but takes a long time doing it (about the same amount of time as the original code)?

Is every message that should be sent actually getting sent, and in addition some duplicates are also sent, or are the duplicate messages perhaps being sent instead of others that are erroneously not being sent at all? I am imagining something like this: you reuse the same object for different mail messages, but fail to properly synchronize the updating of its fields with the actual sending of the message, so sometimes you end up sending two copies of one message and none of another. I don't know anything about .NET's mail-sending classes, so maybe this isn't even possible. Anyway, if you create a new object for each message and let the garbage collector clean them up, this wouldn't be the cause of the problem.

But, .Send is only being called once per message, either way.

How do you know?

 

[Wowbagger]

Are the duplicates caused by the specific code that you removed, or do you also get duplicates if, instead of removing the code entirely, you replace it by a useless loop that does nothing, but takes a long time doing it (about the same amount of time as the original code)?

I have not tried it with a completely useless loop that does nothing, yet.

However, I do know that if I replace calls to a database with different calls that also pulls something from a database (even if it is useless data), the dupes still occur. Etc.


Perhaps I can also make a call to Thread.Sleep, in place of that, to test your idea. I will check that out.

Is every message that should be sent actually getting sent, and in addition some duplicates are also sent, or are the duplicate messages perhaps being sent instead of others that are erroneously not being sent at all?

All the messages that need to go out, are going out at least once. Sometimes twice. Very rarely three times.

Anyway, if you create a new object for each message and let the garbage collector clean them up, this wouldn't be the cause of the problem.

A new message object is created for each one that goes out. I am not reusing the objects. And, if the API allows it, I am even calling .Dispose() when it is done. (I am experimenting with a few different SMTP APIs, and not all of them have IDisposable message objects. Those that do seem to require it, if you are sending attachments or embedded images, and expect to use those files again, while the program is running.)

How do you know?

I put a counter on it. There is only one spot, in all the code, where .Send is called. And, every time it hits that spot, it increments a counter, and outputs it to the form.
In addition, I also stepped through the code, a bunch of times.


The dupes are also always sent within the exact same millisecond of each other. If I put a Thread.Sleep(2000) call immediately after .Send, so that messages being sent through the loop will only get sent one every two seconds, the dupes are still coming out at precisely the same time!

This is evidence that it is not my loop that is the problem.

It so happens I located an old paper that may yield some clues: http://www.ietf.org/rfc/rfc1047.txt

 

[Wowbagger]

I can confirm that a completely useless loop that does nothing, is also causing the problem.

Both a for loop that churns through nothing thousands of times, and a long Thread.Sleep will do it.
Placing too many try...catch blocks also does the trick, even if there is no code in them.

Weird.

Well, I suppose I could have two loops: One that does lots of processing, and holds stuff in memory, and a second loop that only sends the messages out. Or something like that.

 

[Wowbagger]

Weirder and weirder....

It seems that the same client with the URL truncating is also suffering dupes, but ONLY when a certain word (part of the client's name) is in the message! And, it is also the same word getting truncated out of the URL. And, this seems to be happening outside of my application - after the message is actually sent out of the SMTP sender.

Leave the word out - no dupes, leave it in - you get dupes. If you split the word up, no dupes, either.
For example, if the word was "Nameo", I would have to replace it with "N<!--x-->ameo", otherwise a duplicate will be sent out.
But, that does not solve the URL issue, though.

This naming problem does not seem to affect other clients. Some other clients seem to be getting dupes for other reasons.