20

I'm working on a tool that schedules emails with our mail server in C#. I had been using the System.Net.Mail classes to send the mail.

Recently I've come across various issues with regards to RFC violations and other issues, such as SmtpClient not ending the SMTP session according to protocol. Each of these problems is counting toward a high spam score and affecting email delivery, so I need a solution to these problems.

I'm wondering what other people have resorted to in order to resolve these issues. Have people started using a third part component, if so which one?

EDIT: As supporting evidence, please see: http://www.codeproject.com/KB/IP/MailMergeLib.aspx

Martin
  • 201
  • 2
  • 4
  • You should link to the supporting evidence you reference in your second paragraph. – Austin Salonen Oct 23 '09 at 15:11
  • 1
    Good golly: http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/879f13d7-24e6-4a0f-b396-627e9da25fc1/ Clearly not a high priority, then. – T.J. Crowder Oct 23 '09 at 15:19
  • Actually it was a high priority for us to fix for .NET 4.0 and we've made significant improvements specifically in this area of System.Net.Mail. See my answer below – Jeff Tucker Dec 15 '09 at 10:08
  • Using even .NET4 SmtpClient basically doesn't work with the current version of MailSlurper - causing connection termination and queue overload - so bad that it basically can't be used. One could try to blame MailSlurper but that seems pretty unlikely - https://github.com/mailslurper/mailslurper/issues/49 – PandaWood Jun 18 '17 at 03:32

8 Answers8

5

One alternative is MailKit. Has a ton of features, sending can be reliably cancelled via a CancellationToken, so it doesn't have the problem of SmtpClient that it doesn't respect the specified timeout. Has a lot of downloads on NuGet, too.

Even the recent documentation recommends it:

[System.Obsolete("SmtpClient and its network of types are poorly designed, we strongly recommend you use https://github.com/jstedfast/MailKit and https://github.com/jstedfast/MimeKit instead")] public class SmtpClient : IDisposable

Gebb
  • 6,371
  • 3
  • 44
  • 56
2

If you have a Microsoft Exchange 2007 email server then you have an option to use it's web service direction to send email. The web service itself is a bit strange but we were able to encapsulate the weirdness and make it work just like our SMTP class.

First you would need to make a reference to the exchange web service like this: https://mail.yourwebserver.com/EWS/Services.wsdl

Here is an example:

public bool Send(string From, MailAddress[] To, string Subject, string Body, MailPriority Priority, bool IsBodyHTML, NameValueCollection Headers)
{
    // Create a new message.
    var message = new MessageType { ToRecipients = new EmailAddressType[To.Length] };

    for (int i = 0; i < To.Length; i++)
    {
        message.ToRecipients[i] = new EmailAddressType { EmailAddress = To[i].Address };
    }

    // Set the subject and sensitivity properties.
    message.Subject = Subject;
    message.Sensitivity = SensitivityChoicesType.Normal;
    switch (Priority)
    {
        case MailPriority.High:
            message.Importance = ImportanceChoicesType.High;
            break;

        case MailPriority.Normal:
            message.Importance = ImportanceChoicesType.Normal;
            break;

        case MailPriority.Low:
            message.Importance = ImportanceChoicesType.Low;
            break;
    }

    // Set the body property.
    message.Body = new BodyType
                   {
                       BodyType1 = (IsBodyHTML ? BodyTypeType.HTML : BodyTypeType.Text),
                       Value = Body
                   };

    var items = new List<ItemType>();
    items.Add(message);

    // Create a CreateItem request.
    var createItem = new CreateItemType()
                     {
                         MessageDisposition = MessageDispositionType.SendOnly,
                         MessageDispositionSpecified = true,
                         Items = new NonEmptyArrayOfAllItemsType
                                 {
                                     Items = items.ToArray()
                                 }
                     };


    var imp = new ExchangeImpersonationType
              {
                  ConnectingSID = new ConnectingSIDType { PrimarySmtpAddress = From }
              };
    esb.ExchangeImpersonation = imp;

    // Call the CreateItem method and get its response. 
    CreateItemResponseType response = esb.CreateItem(createItem);

    // Get the items returned by CreateItem.
    ResponseMessageType[] itemsResp = response.ResponseMessages.Items;
    foreach (ResponseMessageType type in itemsResp)
    {
        if (type.ResponseClass != ResponseClassType.Success)
            return false;
    }

    return true;
}
Nathan Palmer
  • 1,970
  • 1
  • 20
  • 28
1

I have used SQL Server to send e-mail in situations where the client desktop was not able to send mail (usually for security reasons) but the server could.

Doug L.
  • 2,676
  • 1
  • 19
  • 33
  • 1
    Why the downvote? For Microsoft shops, DBMail in SQL Server _is_ a viable alternative to System.Net.Mail. – Roy Tinker Aug 14 '15 at 19:36
  • I think the question can clearly be understood as "a .NET alternative to SmtpClient" - he says he is using C# – PandaWood Jun 18 '17 at 03:33
  • 1
    Martin asked, "Have people started using a third part component, if so which one?" I interpreted "third part component" to allow more options than a pure C# solution. While not pure C#, SQL DBMail is a workaround. – Doug L. Jun 24 '17 at 06:59
1

SmtpClient was modified in .NET 4.0 so that it properly closes connections by sending a QUIT message. In addition, significant improvements were made to standards compliance with respect to unicode encoding and folding of long line lengths so you should find that your spam scores go down if you switch to .NET 4.0. The folding and encoding fixes shipped in .NET 4.0 Beta 2 but you'll have to wait until .NET 4.0 RC to get the QUIT message fix. In addition, SmtpClient will now implement IDisposable so that you can deterministically close your smtp connections when you are finished sending messages. This blog post details some of the improvements that have been made although it doesn't talk about IDisposable on SmtpClient (should be another blog post on that blog at some point that describes that change): http://blogs.msdn.com/ncl/archive/2009/08/06/what-s-new-in-system-net-mail.aspx

Jeff Tucker
  • 3,387
  • 22
  • 19
  • 1
    Long subjects are still encoded incorrectly in .NET 4.0. The System.Net.Mail team could not fix it for years! It is awful and the team works awfully. – nightcoder Jul 08 '11 at 00:02
  • Just out of curiosity, what is not being encoded correctly? I don't work there anymore but I'm interested in what you're expecting. One thing I do remember is that there are standards in terms of which coding you should select and these are mostly ignored (it defaults it to Q-encoding I think instead of Base64, which is should for some languages) but the actual encoding should be correct. – Jeff Tucker Jul 14 '11 at 20:36
  • Jeff, if I send an email with a long subject in russian (cyrillic encoding) then a recipient gets an email with wrong symbols (shown as question marks) in the middle of the subject, something like "A very long long long long long long long long l??ng long long long long subject" (but in russian of course). I don't remember the exact cause, but as I remember it is because of a wrong encoding of a subject (they don't follow standard in encoding subject I think). – nightcoder Sep 14 '11 at 20:13
  • You can set the encoding manually if I remember right, although I forget the method to invoke to do that. I recall there being two different encodings for Russian and that they weren't compatible but this was a long time ago when I worked on it. – Jeff Tucker Sep 23 '11 at 08:20
  • 2
    Long non-ASCII subjects are encoded incorrectly because in .NET 4.0's SmtpClient when the subject is split into two encoded-words a **multi-byte character**'s bytes can be split between the two encoded-words. RFC 2047 says encoded-words should be self-contained, so the generated headers are invalid. – Alex Jun 20 '12 at 10:54
  • Btw, we tried QuikSoft.EasyMail component, but the same problem is also there - long subjects in multi-byte encodings are encoded incorrectly. After that we tried MailBee.NET Objects (http://www.afterlogic.com/mailbee-net/email-components) and it seems to work correctly. – nightcoder Aug 26 '12 at 20:36
1

What about Rebex Secure Mail?

Disclosure: I'm involved in development of this library.

Martin Vobr
  • 5,757
  • 2
  • 37
  • 43
0

Castle Email.Sender component?

Krzysztof Kozmic
  • 27,267
  • 12
  • 73
  • 115
0

I have been happy with these components: QuikSoft

Ray
  • 21,485
  • 5
  • 48
  • 64
0

For a standards compliant and broad suite of mail tools (and other IETF standards) I have several times found /n software's IP*Works to be a good API. I've used it in both incoming and outgoing scenarios. For the outgoing scenario, I used it for large mail-out support, and on my current project I use it for large scale IMAP mail retrieval for heavy use incoming customer support mailboxes. I've never had any compliance issues (so far so good).

The suite supports much more than just IMAP and SMTP. It can be found here, and I've found the cost to be quite bearable considering what you get for your money.

Andrew Matthews
  • 3,006
  • 2
  • 29
  • 42