7

I was planning to use the SMTP server that comes with IIS7 (for a website) but then I came across this link and started to get worried (read the accepted solution), on the other hand I have a limited budget and I can't afford to buy MS Exchange or another expensive server, besides, I'm using ASP.NET for my app which works very well with IIS SMTP server (I was going to use the pickup folder delivery option, this is esp. good for web apps so that the user won't have to wait until the message is sent).

I heard about hmailserver but it seems it doesn't have the pickup folder option (not completely sure though, so please correct me if I'm wrong). I also don't know if the performance is better than the IIS SMTP server. If this is good enough, I could probably relay from IIS SMTP server to hmailserver, so that I can still use the pickup folder option. Sorry, if I sound like I'm talking to myself here but I'm trying to find the best option and it's not clear so far.

Any suggestions would be really appreciated...

Mee
  • 845
  • 5
  • 15
  • 24

5 Answers5

4

IIS SMTP is good enough for high loads too.

Related StackOverflow question

Community
  • 1
gbn
  • 6,079
  • 1
  • 18
  • 21
3

I would definitely go with the hMailServer option. We've used IIS SMTP in the past, but when there's a problem, it is a real pain to troubleshoot. hMailServer has much better logging and finer control over various SMTP settings.

You should see what the response is without using the pickup folder...we use hMailServer directly for our apps and it seems to work out OK. As you mentioned, you can do smart host relaying as well, but in my experience it is better to have less steps to troubleshoot.

Adam Brand
  • 6,127
  • 2
  • 30
  • 40
  • "You should see what the response is without using the pickup folder", but this means the user will have to wait until the message is delivered. – Mee Jul 18 '09 at 17:41
  • No they don't. They just have to wait until the local SMTP server accepts it in the Queue. Then the SMTP server asynchronously takes it from the queue and delivers it. – Adam Brand Jul 18 '09 at 17:54
  • FYI I just timed it on my own server and it takes about 1/10th of a second for hMailServer to accept a message and add it to the queue. – Adam Brand Jul 18 '09 at 17:58
  • 1
    I must've got wrong then. But there's something that's still really good about the pickup folder option, I tried to send mails from the app with the smtp service down and this worked with no problems (the messages are just saved to the pickup folder, no communication here). When I started the service it moved the files in the pickup folder to the queue and started processing them. This means there's no chance that the users may get any errors even with the service down. – Mee Jul 18 '09 at 18:11
  • 1
    From time to time, you just have to make sure the SMTP is up and running. Now, without the pickup delivery option, if the SMTP server is down or not responding, users will get errors with any thing they do that involves email. This is not good for the user experience. This is what I really like about the pickup folder, just send and forget about it. – Mee Jul 18 '09 at 18:14
  • We haven't had any issues with hMailServer going down, but if you don't want users to see the error, you can do a try{}catch{} in your code and perform some other action if there is an error (like write what would have been in the email to the log file). – Adam Brand Jul 18 '09 at 18:20
  • Yes, but this means the message was never delivered, now you have more work to do (check the logs to find the messages that were not sent .. etc). With the pickup folder, the message is sent to the SMTP whether it's running or not, it's just a folder on the computer. BTW, actually I used try .. catch blocks in my code exactly as you described but removed them after I decided to use the pickup folder option :) – Mee Jul 18 '09 at 18:32
1

Well - we used it in our production environment - but I have to caveat the solution:

1) We used it locally so that the queueing would never go down, we had it deliver to a smarthost (we used Postfix). The local queue was just there to accept the messages and send them on. The performance of IIS SMTP deliveing to multiple domains was horrible with volume.

2) If you drop directly to a DROP folder, then your app is tied to that solution. If you deliver with CDO (which should be configured to use SMTP, not just DROP), then you have a problem with high-bit characters in email addresses. This caused us to eventually deliver directly to our Postfix boxes, despite the drawbacks of not using a machine-local queue.

3) Inbound messages went through a third-party spam filter. We found DataEnter's XWall to be a great price/performance fit. Not exactly intuitive, but good performance and a lot of options for configurations. If you use it, I recommend getting the ESET add-on from Ceratec to give you some extra features missing from the core product.

BTW: You could use XWall to deliver outbound - we did this for a few apps and it worked pretty well. Postfix will handle a big load for free, but means managing another app and OS (Linux)...

  • 1
    Thanks a lot for your answer, but why do you recommend not using IIS to relay to another SMTP server (i.e. delivering to a smarthost)? Did you have problems with this configuration? – Mee Aug 01 '09 at 02:47
0

It'll be fine with low to moderate volume. If it'll be used for incoming mail, eventually you will be driven to another type of server due to spam problems and a lack of functionality.

That is in spite of the fact that the core of IIS SMTP is pretty solid -- it's actually what Exchange uses to handle the SMTP layer of things. Microsoft just hasn't invested a lot in the management tools or making features available, because they want you to pay for Exchange.

mhud
  • 531
  • 1
  • 3
  • 10
0

I have used the IIS SMTP option for several large web sites sending mass amounts of mail (2000+ a day). In all cases I have had no issues (knock on wood). If you opt for IIS SMTP check out this post for troubleshooting help. Most issues I have encountered with IIS SMTP were quickly resolved with a bit of DNS troubleshooting.

http://msmvps.com/blogs/bernard/archive/2004/09/28/14480.aspx

rojay12
  • 51
  • 1