February 1, 2013 at 4:20 pm
Database Mail on our production server was working fine until about mid-morning today. Nothing has changed on the server that I know of or could find, but even "Send Test E-mail" isn't working. I'm trying to figure this out with a couple of SysAdmins and so far we're not getting anywhere. The sysmail_event_log says:
"The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 2 (2013-02-01T16:00:06). Exception Message: Cannot send mails to mail server. (The specified string is not in the form required for an e-mail address.). )"
even though the email address is in the correct format (as it is my work email address after all so I think I know how to get that one right!). I tried running sp_send_dbmail from one stored procedure that used to reliably work (email addresses are valid, etc.). Interesting thing is that everything works fine when done from another one of the database servers (same Exchange server, etc.). Here is what we have tried:
1. Restarting SQL Server Agent
2. Verified that Database Mail is enabled on the server
3. Verified that Port 25 is not blocked
4. Checked the registry key and the profile matches
5. Broker is enabled in MSDB
6. All internal ports are relayed on the exchange servers (tested by a SysAdmin)
I tried changing the Database Mail account to use the other Exchange server and it still didn't resolve the issue.
I'm a sysadmin within SQL Server so it couldn't be a permissions issue. Like I said, it was working fine one minute and not the next. Any idea what happened?
February 3, 2013 at 1:47 pm
I'm not sure how it is done but in my environment the security team have set rules so that our mail servers will not accept mail from dev boxes, clearly it makes our testing a right pain sometimes but for you I wonder if something similar has been effected.
February 4, 2013 at 12:37 pm
One problem I have had on a few SQL 2005 boxes was that McAfee Enterprise AV was not allowing the EXE to send email. We had to establish an AV exception on those servers to permit the EXE to send mail. In Mcafee there is a log entry when this type of blocking occurs. Has there been an AV update in your environment?
February 4, 2013 at 12:46 pm
the error "The specified string is not in the form required for an e-mail address.)" sounds like someone sent "Lowell" to the exchange server, and not lowell@somedomain.com.
For not sending at all with no other changes to the server, it really sounds like the IT guys made a network modification, like blocking port traffic, without checking if it might affect anyone.
Ask the Network guys if they made any network modifications/firewall changes? I think the issue is outside of SQL Server.
Lowell
February 5, 2013 at 10:40 am
The last time this happened in our shop, the Exchange folks had enabled "require authentication" at the Exchange server, and we were using smtp on our sql servers.
February 5, 2013 at 11:08 am
I think I figured it out and it's something interesting that I didn't know about Database Mail. The SQL Server Agent Operators let you specify multiple email addresses per operator. However it appears that for DB Mail accounts, you can only have one email address associated with it. I had done this because the IT Director hijacked my email alias for just DBA stuff because he wanted to receive one particular alert also instead of *asking* me to add him to the recipient list. Pissed off at his abuse of access and lack of communication, I immediately stopped using the email alias intended for just the DBA audience. One of those included making changes to Database Mail. I had three email addresses associated with the Database Mail account so the incorrect email format was coming from that and not the recipient list when calling sp_send_dbmail. Once I changed the account to only have one email address in it, it seemed to start working again.
I also discovered that after the SysAdmin's rebooted SQL Server the other weekend, apparently one of the profile's account information got replaced with another one's which didn't make any sense. But I suppose that's also what happens when SysAdmins insist that they don't need the DBA's involvement with mucking around with the database servers. You know, you reboot the server and of course it's still working right and SQL Server is happy and find because the service is running, right? *rolls eyes*
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply