SMTP authentication oddities
-
I'm experiencing some (new) and very odd behaviours trying to send outbound email from my ASP.Net websites. These are running on a shared-host setup and use ASP.Net Framework webforms. In the past I've been able to do this very simply: In Web.config:
then in the code
SmtpClient smtp = new SmtpClient();
smtp.Send("sender@mydomain.com", "recipient@somedomain.com" "subject", "message");NOTE that the password defined in web.config really is the literal "notneeded". When running these sites on my local development box, the correct password for the named sending account is indeed required; but when uploaded to the server, the password is ignored (and the setting can be removed completely).
As of some time on Friday I became aware that email sending from all my sites was failing. I reported the issue to my hosting company but in the meantime attempted to find a fix myself. I found that entering the "correct" password worked fine. (Later this weekend the hosting company, who had denied ANY configuration changes at their end, then made further changes that resulted in all the amended sites failing again. They then told me to change to a different SMTP server (
mail.hostingcompany.com); however that didn't work for me. After several hours further testing showed it DID now work, so I updated all the sites again. Later this evening I also found that once again the originalmail.mydomain.comhost address was working again.This was all pretty frustrating; I don't pretend to understand SMTP very well and am really not sure how / why omitting the password (or using a dummy one) worked, but it did. That was a Good Thing because it meant I didn't have to hard-code my email password in plain text in web.config, and also meant that when I change my email password I don't also need to go in and change web.config for the domain and all its sub-domains.
So I have some questions:
1. WHY did omitting password work, when the site was running on the same server as the SMTP host?
2. WHAT configuration change could the host have made to cause this to STOP working?
3. Most confusingly of all... there is ONE subdomain that continued to work fine WITHOUT the -
I'm experiencing some (new) and very odd behaviours trying to send outbound email from my ASP.Net websites. These are running on a shared-host setup and use ASP.Net Framework webforms. In the past I've been able to do this very simply: In Web.config:
then in the code
SmtpClient smtp = new SmtpClient();
smtp.Send("sender@mydomain.com", "recipient@somedomain.com" "subject", "message");NOTE that the password defined in web.config really is the literal "notneeded". When running these sites on my local development box, the correct password for the named sending account is indeed required; but when uploaded to the server, the password is ignored (and the setting can be removed completely).
As of some time on Friday I became aware that email sending from all my sites was failing. I reported the issue to my hosting company but in the meantime attempted to find a fix myself. I found that entering the "correct" password worked fine. (Later this weekend the hosting company, who had denied ANY configuration changes at their end, then made further changes that resulted in all the amended sites failing again. They then told me to change to a different SMTP server (
mail.hostingcompany.com); however that didn't work for me. After several hours further testing showed it DID now work, so I updated all the sites again. Later this evening I also found that once again the originalmail.mydomain.comhost address was working again.This was all pretty frustrating; I don't pretend to understand SMTP very well and am really not sure how / why omitting the password (or using a dummy one) worked, but it did. That was a Good Thing because it meant I didn't have to hard-code my email password in plain text in web.config, and also meant that when I change my email password I don't also need to go in and change web.config for the domain and all its sub-domains.
So I have some questions:
1. WHY did omitting password work, when the site was running on the same server as the SMTP host?
2. WHAT configuration change could the host have made to cause this to STOP working?
3. Most confusingly of all... there is ONE subdomain that continued to work fine WITHOUT theMy guess would be that the SMTP server was set up to implicitly trust the web server without requiring authentication, and something caused that trust to fail. Is the site that's still working on the same server as the others? And if so, does the server have multiple IP addresses? If you have access to IIS Manager on the server, you can configure the SMTP settings at the root level, and all of the sites should inherit those settings without needing the
mailSettingselement at all.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
My guess would be that the SMTP server was set up to implicitly trust the web server without requiring authentication, and something caused that trust to fail. Is the site that's still working on the same server as the others? And if so, does the server have multiple IP addresses? If you have access to IIS Manager on the server, you can configure the SMTP settings at the root level, and all of the sites should inherit those settings without needing the
mailSettingselement at all.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Thanks Richard. Yes, I think they moved the SMTP server to a separate box, and have subsequently put DNS forwarding for mail.mydomain.com to the new server, so that it works but does not automatically authenticate. That would also explain why it broke again for a while but subsequently worked once the DNS changes propagated. The subdomain that is still working without a password is an oddity - as far as I can tell it's on the same server (I guess there may be some checks I can do to verify, even looking at the IIS logs etc maybe). But as they've now setup a dedicated mail server it seems unlikely it would still be on that box... I'll do some more tests (and clone a page from one of the other sites to this one, as the code is slightly different though not using a password) to verify it's nothing different in the logic. I run multiple sites with this host, and manage sites for clients on other shared hosts - all seem to suffer from the problem of unplanned, unannounced and undocumented configuration changes that break sites. I guess the majority of their income comes from static or otherwise trivial sites. I left my last host because they changed DBMS (from MySql to MariaSQL) with no warning, breaking a number of things, and claiming that MySql had been "renamed" MariaSql. That level of ignorance and stupidity was truly scary so they barely saw me for dust... :laugh:
