如何在Azure中通過SMTP處理入站電子郵件

Question

我想將所有入站電子郵件發送到由Azure上的SMTP服務器處理的特定域（可能是工作者角色），並且要將所有電子郵件添加到Azure排隊，以便我可以處理每封電子郵件並應用特定的業務規則，其中可能包括將原始電子郵件轉發到新的電子郵件地址（因此我想保留整個電子郵件消息）。

我發現這篇文章

http://blog.smarx.com/posts/emailtheinternet-com-sending-and-receiving-email-in-windows-azure

但現在是將近5歲和所需的組件（CSES）的一個不再可用Sourceforge上。

任何人有任何建議嗎？例子？他們可以指點我的文章？

乾杯邁克

Answer 1

你當然可以做到這一點 - 但我不會推薦它的原因，我下面會解釋，除非你是在談論數以千萬計的電子郵件。我在幾年前曾考慮過類似的原因，並以服務（我的情況爲Postmark）結束。

簡而言之，您需要在端口25和端口465上設置TCP偵聽器的Worker角色。然後您需要編寫可以「聊天SMTP」的代碼，並且如您所說，CSES是但我敢肯定，你將不得不編寫自己的協議解析器。好消息是SMTP協議非常簡單。壞消息是多年來它一直是個混蛋，你不得不處理像TLS（端口465）等東西。總之，你需要抓住SMTP規範並開始寫很多代碼。從CSES開始並從那裏出發可能是明智的。

但是，有很好的理由說明爲什麼這種方法對您來說不太可能具有成本效益。我不知道Sendgrid的定價結構;我使用郵戳，但我懷疑他們是相似的。對於批量定價，如果內存服務，我會爲200萬封電子郵件支付1000英鎊。

如果你確實寫自己的，你必須編寫和維護代碼並修復任何錯誤。你還必須處理恢復能力，所以你可能需要兩名工作人員或虛擬機 - 而且你可能需要另一臺DC中的另外兩名DC來防止DC故障（他們很少發生，但確實發生）。您還需要爲隊列編寫故障轉移代碼，以防DC中的隊列基礎結構出現問題。所以，最終你會得到相當多的服務器和大量的代碼來編寫和維護。

如果您預計的電子郵件容量確實是如此之高，使用像Sendgrid或郵戳服務將超過該費用的成本，那麼你就必須走那條路並沒有真正的捷徑。另外，我承認，我沒有回答你真正的問題。

如果你還不知道你會得到，你爲什麼不現在使用的服務的一個什麼量和寫入時使用該服務的成本開始變得如此之大，它是成本這個其他代碼有效地自己寫嗎？