I have run into a problem that appears to be somewhat common but also left unanswered everywhere I've looked thus far and, since many of us are using .NET 2.0 with CSLA, I'm hoping this may be the place to finally get an answer!
The issue I am running into has to do with the new System.Net.Mail features (replacing System.Web.Mail). I have been all over the web and read and posted messages elsewhere for the so-called "pros" to help but none have come up with an explanation of the problem let alone a resolution. I've also seen more than a dozen posts within the last 6 months on forums.asp.net covering this and they all end the same way. Experts-Exchange couldn't help, etc.
So, here's hoping this is the top where the cream has risen...
In my case, just as most others I have seen, I am able to easily generate and send an email from my application to users within my domain. HOWEVER, I cannot get any messages to go to recipients OUTSIDE of my domain. Here is a pared down block of code demonstrating what I am trying to do:
System.Net.Mail.SmtpClient smtpClient = new System.Net.Mail.SmtpClient("127.0.0.1");
System.Net.Mail.MailMessage message = new System.Net.Mail.MailMessage();
message.To.Add(new System.Net.Mail.MailAddress(Customer.EmailAddress, Customer.FullName));
message.From = new System.Net.Mail.MailAddress(User.EmailAddress, User.FullName);
message.Subject = EmailSubject.Text;
message.Body = EmailBody.Text
message.IsBodyHtml = true;
smtpClient.Send(message);
I've tried turning off the UseDefaultCredentials property and assigning a new System.Net.NetworkCredentials object to the smtpClient.Credentials property - I've even used the Domain Administrator's account! I've used "localhost", "127.0.0.1" and even our actual MS-Exchange server name for the SmtpClient host with no change in the results. I have ensured that the local system has relaying enabled (for the localhost/127.0.0.1 only) in IIS and played with every combination of setting up the email addresses, etc. All of these were suggestions made on other forums but when those people had no better success than we have after doing all of this, the threads went dead.
Again, all of this works perfectly when the recipient is within our domain. If the address is outside, the message gets stuck in the "C:\Inetpub\mailroot\Queue" folder indefinitely. It is critical that we are able to send outside of our domain as I'm sure almost everyone that has developed a web app needs to do. At this point I am looking to revert back to System.Web.Mail and just ignore the warning messages during compilation until someone (MS!) figures out how to educate us on getting this right!
But! I am hopeful that one of you may hold the key to this and we won't have to take a step backward.
Thanks in advance for the help.
I think you need to first be sure whether or not it is really related to your .NET code. Try a regular smtp client such as Outlook, Outlook Express or Thunderbird and send from and to the same addresses via the same outgoing smtp host and see what happens. They usually display the server response if things don't work.
I'm not sure what uses C:\Inetpub\mailroot\Queue. I don't think the .NET classes use that. I think its the somewhat lame smtp server that comes "free" with IIS or at least used to. I guess that is what you're talking to on 127.0.0.1 But again, try a regular email program talking to 127.0.0.1 and see what happens. I don't think System.Net.Mail has any built-in queuing so if you're talking to MS Exchange or another smtp server then that folder shouldn't even get involved at all.
Do you have an ISP's outgoing mail server that you can talk to? That is often the path to take although if you have an inhouse smtp server then that is probably better because it will handle retries etc if your connection is down.
Cheers
Ross
The Queue folder is a result of System.Net.Mail working with IIS to offload delivery of the mail messages. It is one of the options using the SmtpClient.DeliveryMethod property (and enumeration). See this for more info:
http://msdn2.microsoft.com/en-us/library/system.net.mail.smtpdeliverymethod.aspx
I enabled it as part of my testing so that I could see if the mail was getting routed into the queue or badmail, etc. But, what's funny is that even when I set the DeliveryMethod to Network, the message STILL ends up in the Queue folder!?!?!
Anyway, you may have helped me stumble onto the problem!!!
I changed the DeliveryMethod to Network, ran the app again with the same results. Just to be thorough, I changed the host name to our mail server's name (instead of localhost/127.0.0.1) and the thing WORKED!!!
I'm gonna play around with the credentials and other settings to see what is really required, but obviously the documentation which says that Network is the default delivery method is wrong, eh?
I have this problem on two separate networks/domains so now that it appears that I have it working on at least on of them, I have hope that I should be able to get the other working as well. I'll know that later today.
Thanks for the help getting me there!
first smtpclient IMHO is silly and confusing, it should be smtpServer!
I use systemmail all the time w/o any problems.
if you have an email server in your domain and you are sending messages to outside users then start with this:
smtpclient => yourmailserver
from => a valid mailbox in your domain
to => someone@domain.com
test with telnet.
telnet mailserver 25
if you can connect then you should be able to send.
you may need to add login credt if your server requires auth before send.
use iis local only if you have it confiured to send messages to another server that will handle the emails.
if you need more help post back and I can try and walk thru some of the possible problems.
but use telnet, smtp and pop3 are text based and you can do a lot with telnet,
you can create small test emails from telnet and see it takethem or give an error.
When you use localhost the loopback interface comes into play.
Sounds like it might also interfere with your Network setting.
I always use the name of the real SMTP server on my network.
Glad to see you found a solution.
Joe
Yea, the key was getting the combination of Host and DeliveryMethod correct. Once I had this set to my Exchange server and DeliveryMethod.Network, I was able to strip out all of the other b.s. that had been added and tried as a result of the myriad of suggestions on other forums (incl. new credentials, etc.)
Come to find out, as I reviewed the MS documentation again, although the docs don't say that you have to have the DeliveryMethod set to Network for this to work, if you look at that sample XML to configure the SmtpClient class via the application's config file, you will see that they have the deliveryMethod="Network" attribute included in the <smtp> tag. This goes without mention but is obviously important and why none of the code samples included this statement (since they must've assumed the config settings when preparing the samples)!
Anyway, I have it working on both networks now thanks to this. Again I appreciate the help even if was just getting me to look closer at things in order to explain them. Sometimes that's all it takes, eh?!?!?
One more thing, the name SmtpClient actually IS perfectly suited as the class is not providing you with the SMTP service but provides you access to the service, thus the Host and Port properties. This is the definition of a client as this class does do the same thing as Outlook, etc. by allowing you to package and send a message but does not provide any of the actual SMTP functionality such as routing, delivery, etc. It provides client functionality (behavior), not server.
Thanks again.
Copyright (c) Marimer LLC