2009-10-23 18 views
14

Sto lavorando a uno strumento che pianifica le e-mail con il nostro server di posta in C#. Ho utilizzato le classi System.Net.Mail per inviare la posta.System.Net.Mail Alternative

Recentemente mi sono imbattuto in vari problemi riguardanti le violazioni RFC e altri problemi, come SmtpClient che non termina la sessione SMTP in base al protocollo. Ognuno di questi problemi sta contando un punteggio di spam elevato e influisce sulla consegna della posta elettronica, quindi ho bisogno di una soluzione a questi problemi.

Mi chiedo a cosa hanno fatto ricorso altre persone per risolvere questi problemi. Le persone hanno iniziato a utilizzare un componente di terza parte, in caso affermativo quale?

EDIT: Come elementi di prova, si prega di consultare: http://www.codeproject.com/KB/IP/MailMergeLib.aspx

+0

È necessario collegare le prove a supporto di riferimento nel secondo paragrafo. –

+1

Good golly: http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/879f13d7-24e6-4a0f-b396-627e9da25fc1/ Chiaramente non è una priorità alta, quindi. –

+0

In realtà era una priorità per noi risolvere per .NET 4.0 e abbiamo apportato miglioramenti significativi in ​​particolare in questo settore di System.Net.Mail. Vedere la mia risposta di seguito –

risposta

-1

ho utilizzato SQL Server per inviare e-mail in situazioni in cui il desktop client non è stato in grado di inviare la posta (di solito per motivi di sicurezza), ma la server potrebbe.

+1

Perché il downvote? Per i negozi Microsoft, DBMail in SQL Server è una valida alternativa a System.Net.Mail. –

+0

Penso che la domanda possa essere chiaramente intesa come "un'alternativa .NET a SmtpClient" - dice che sta usando C# – PandaWood

+0

Martin ha chiesto, "Le persone hanno iniziato a usare un componente di terza parte, se sì quale?" Ho interpretato "componente di terze parti" per consentire più opzioni di una pura soluzione C#. Sebbene non sia puro C#, SQL DBMail è una soluzione alternativa. –

0

sono stato felice con questi componenti: QuikSoft

2

Se si dispone di un server di posta elettronica Microsoft Exchange 2007, allora si ha la possibilità di utilizzare è web service direzione per inviare e-mail. Il servizio web in sé è un po 'strano, ma siamo stati in grado di incapsulare la stranezza e farlo funzionare proprio come la nostra classe SMTP.

In primo luogo si avrebbe bisogno di fare un riferimento al servizio di cambio web come questo: https://mail.yourwebserver.com/EWS/Services.wsdl

Ecco un esempio:

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; 
} 
0

Per una standard suite di conforme e ampia di strumenti di posta elettronica (e altri standard IETF) Ho trovato più volte/n software IP * Works per essere una buona API. L'ho usato sia in arrivo che in uscita. Per lo scenario in uscita, l'ho usato per un grande supporto di posta e sul mio progetto corrente lo utilizzo per il recupero della posta IMAP su larga scala per le cassette postali di supporto clienti in entrata pesanti. Non ho mai avuto problemi di conformità (finora così buono).

La suite supporta molto di più che solo IMAP e SMTP. Può essere trovato here, e ho trovato il costo di essere abbastanza sopportabile considerando quello che ottieni per i tuoi soldi.

1

SmtpClient è stato modificato in .NET 4.0 in modo da chiudere correttamente le connessioni inviando un messaggio QUIT. Inoltre, sono stati apportati miglioramenti significativi alla conformità degli standard per quanto riguarda la codifica e la piegatura Unicode di lunghezze di linea lunga, quindi dovresti scoprire che i tuoi punteggi di spam scendono se passi a .NET 4.0. Le correzioni di piegatura e codifica fornite in .NET 4.0 Beta 2, ma dovrai attendere fino a .NET 4.0 RC per ottenere la correzione dei messaggi QUIT. Inoltre, SmtpClient implementerà ora IDisposable in modo da poter chiudere in modo deterministico le connessioni smtp una volta terminato l'invio dei messaggi. Questo post del blog dettagli alcuni dei miglioramenti che sono stati fatti, anche se non parla di IDisposable su SmtpClient (dovrebbe essere un altro post sul blog che il blog ad un certo punto che descrive che il cambiamento): http://blogs.msdn.com/ncl/archive/2009/08/06/what-s-new-in-system-net-mail.aspx

+1

I soggetti lunghi sono ancora codificati in modo errato in .NET 4.0. Il team di System.Net.Mail non ha potuto aggiustarlo per anni! È terribile e la squadra lavora terribilmente. – nightcoder

+0

Solo per curiosità, cosa non viene codificato correttamente? Non ci lavoro più ma sono interessato a quello che ti aspetti. Una cosa che ricordo è che ci sono degli standard in termini di codifica che dovresti selezionare e questi sono per lo più ignorati (lo imposta su Q-encoding penso invece su Base64, che dovrebbe essere usato in alcune lingue) ma la codifica attuale dovrebbe essere corretta. –

+0

Jeff, se invio un'e-mail con un lungo oggetto in russo (codifica in cirillico), un destinatario riceve un'e-mail con simboli sbagliati (mostrati come punti interrogativi) nel mezzo del soggetto, qualcosa come "Un lungo molto lungo lungo lungo long long long l ?? ng long long long long subject "(ma in russo ovviamente). Non ricordo la causa esatta, ma come ricordo è a causa di una codifica errata di un soggetto (non seguono lo standard nel soggetto di codifica che penso). – nightcoder

1

Che dire Rebex Secure Mail?

Disclosure: Sono coinvolto nello sviluppo di questa libreria.

1

Un'alternativa è MailKit. Ha un sacco di funzionalità, l'invio può essere cancellato in modo affidabile tramite un CancellationToken, quindi non ha the problem di SmtpClient che non rispetta il timeout specificato. Anche molti download sono disponibili su NuGet.

Anche la recente documentation lo raccomanda:

[System.Obsolete ("SmtpClient e la sua rete di tipi sono mal progettati, si consiglia vivamente di utilizzare https://github.com/jstedfast/MailKit e https://github.com/jstedfast/MimeKit invece")] classe SmtpClient pubblica: IDisposable