SmtpClient.Send throws exception in .net 4, same code works in .net 3.5
- I tried running this code:
It works prefect in 3.5 in 4 I get an SmtpException that has an inner exception stating "{"Index and count must refer to a location within the string.\r\nParameter name: count"}". I have no idea what it's talking about, it looks like it is doing some string parsing, but everything I'm passing in is in the correct format?SmtpClient client = new SmtpClient("mail.server.com"); client.UseDefaultCredentials = true; client.Send("from@email.com", "from@email.com", "Subject", "Body");
Anyone else tried this?
Answers
Thank you for the detailed bug report. The callstack and SMTP protocol log were very useful to us in tracking down this issue.
The problem has to do with the parsing of the 250-AUTH response text from the Exchange 2007 server. This particular server appears to be configured as anonymous connect only and thus has an empty list of SASL mechanisms in the 250-AUTH list. Recent changes to .NET 4.0 in related code caused this bug to appear.
We will make sure to fix this bug before final release of .NET 4.0.
- Proposed As Answer bySteve Horne - MSFT Wednesday, November 11, 2009 9:23 PM
- Marked As Answer byTim Bayer Friday, November 20, 2009 2:25 PM
- The workaround is to configure the Exchange 2007 server so that it supports at least one non-anonymous authentication method in addition to supporting anonymous connections. This will result in the 250-AUTH response containing at least one parameter (perhaps more separated by spaces).
- Marked As Answer byTim Bayer Friday, November 20, 2009 2:25 PM
All Replies
- Tim, we haven't been able to reproduce this yet. Would it be possible for you to send the full stack trace?
We can start from there, but if you could also send us full tracing logs we can analyze those too. The procedure for enabling tracing is here, though you can just put the appropriate sections in your app.config instead of machine.config. - I just ran into this same problem attempting to send email from within a VS2010 BETA2/.NET 4.0 webservice method being called from a silverlight 3.0 app. To duplicate, create a simple web service and add a method something like and then exercise the method.
public void SendEmails(string template, List<string> accts)
{
try
{
MailMessage msg = new MailMessage();
msg.IsBodyHtml = false;
msg.From = new MailAddress("from@foobar.com");
msg.Subject = "Test Subject";
msg.To.Add("to@foobar.com");
msg.Body = "This is the body of the message.";
SmtpClient client = new SmtpClient("mail.foobar.com"); client.Send(msg);
}
catch (Exception e)
{
}
}
I tried to enable tracing by adding the blurb at the page Aaron mentioned to my web.config but couldn't tell that it did anything useful as far as logging more details.
FWIW, I also tried similar code in a simple command line program targeting 4.0 and get the same error, so it seems to be a bug in SmtpClient and not some side effect of it running in a webservice. - I also tried the code I sent in a simple command line program and I got the same error. I will run it again and send the stack trace as soon as I can.
- To date, we've been unable to reproduce this issue. Can you please open a Connect bug on this? Use the "report a bug" option on the Help menu in VS2010.
Please attach the network.log generated by the tracing instructions from Aaron Oneil, the stack trace of the exception and your sample project if possible. Note that you have to click the SUBMIT button to actually create the connect bug before you can get to a screen that allows you to attach files.
If you'd like to send these files directly to me, I'll get them to the System.Net class owners. Send them to shorne at the domain name microsoft dot com. - FWIW, if Aaron can't duplicate the problem, it may be something with our SMTP servers. It crashes inside:
System.Net.Mail.SmtpException: Failure sending mail. ---> System.ArgumentOutOfRangeException: Index and count must refer to a location within the string.
Parameter name: count
at System.String.RemoveInternal(Int32 startIndex, Int32 count)
at System.String.Remove(Int32 startIndex, Int32 count)
at System.Net.Mail.SmtpConnection.ParseExtensions(String[] extensions)
at System.Net.Mail.SmtpConnection.GetConnection(String host, Int32 port)
at System.Net.Mail.SmtpTransport.GetConnection(String host, Int32 port)
at System.Net.Mail.SmtpClient.GetConnection()
at System.Net.Mail.SmtpClient.Send(MailMessage message)
--- End of inner exception stack trace ---
at System.Net.Mail.SmtpClient.Send(MailMessage message)
at ConsoleApplication1.Program.Main(String[] args) in c:\documents and settings\foobar\my documents\visual studio 10\Projects\ConsoleApplication1\ConsoleApplication1\Program.cs:line 29
From digging around, I gather that the ParseExtensions method parses the EHLO data about what extensions a given SMTP supports. On my server, if I telnet to port 25 and do an EHLO, I get back:
220 exchange2007.foobar.com Microsoft ESMTP MAIL Service ready at Tue, 10 Nov 2009 12:13:58 -0800
EHLO 192.168.7.4
250-exchange2007.foobar.com Hello [192.168.7.228]
250-SIZE 52428800
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 XEXCH50
I'm thinking maybe they modified this routine in 4.0 and it maybe doesn't like the last XEXCH50 line because it doesn't have a dash between the 250 and the extension name. Just grasping at straws though. Could you maybe see what your server returns? I will try some different servers as well. - I just tried it on a non microsoft SMTP server that returns normal looking EHLO information and it works fine, so I suspect my theory is more or less correct. Who wants to file the bug?
- I created connect bug 509691 for tracking this issue.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=509691
If you have experienced this bug, please visit the link and 'vote' the bug up by clicking the "I can too" link in the I can too repro section.
Thanks! Thank you for the detailed bug report. The callstack and SMTP protocol log were very useful to us in tracking down this issue.
The problem has to do with the parsing of the 250-AUTH response text from the Exchange 2007 server. This particular server appears to be configured as anonymous connect only and thus has an empty list of SASL mechanisms in the 250-AUTH list. Recent changes to .NET 4.0 in related code caused this bug to appear.
We will make sure to fix this bug before final release of .NET 4.0.
- Proposed As Answer bySteve Horne - MSFT Wednesday, November 11, 2009 9:23 PM
- Marked As Answer byTim Bayer Friday, November 20, 2009 2:25 PM
- Is there a work around?
Mark the best replies as answers! - The workaround is to configure the Exchange 2007 server so that it supports at least one non-anonymous authentication method in addition to supporting anonymous connections. This will result in the 250-AUTH response containing at least one parameter (perhaps more separated by spaces).
- Marked As Answer byTim Bayer Friday, November 20, 2009 2:25 PM

