我已經實現了一個自定義的電子郵件服務器和Web客戶端。服務器只是一個使用第三方（sendgrid）發送和接收的REST API（類似於google的gmail API）。電子郵件存儲在數據庫中。 Web客戶端僅與REST客戶端進行發送和接收。IMAP服務器外觀 - 如何製作一個？
這種做法是在任何地方都不會實現IMAP，這使得它不可能對標準客戶端（如Outlook，iphone等）來連接並使用我們的電子郵件API的問題。這限制了客戶只使用我們的客戶進行電子郵件。
我需要的是某種IMAP服務器「門面」，將管理到客戶端的連接，並撥打電話到我的REST API的實際處理請求（獲取電子郵件，發送電子郵件等）。
如何實現IMAP門面？有沒有辦法讓現有的郵件服務器，並指出它所有的「事件」來打電話給我的API？
（這基本上是我的再次發表評論，但闡述了相當多的。）
有些IMAP服務器，最值得注意的是達夫科特，被構造使得文件訪問與定義的接口一個單獨的模塊。 Dovecot不是唯一的，但它是迄今爲止最流行的，其後端接口已知是適當的，所以我會採取缺席的具體問題。
已經存在一些非文件模塊，如imapc，這證明是可以做到的。當客戶端打開由imapc支持的郵箱時，Dovecot解析IMAP命令，調用imapc中的消息訪問功能，imapc發佈新的IMAP命令，解析服務器響應，將C structs返回給Dovecot，Dovecot時尚新IMAP響應並將它們返回給客戶端。
我建議你參考dovecot source，看看src/lib-storage/inbox/index/imapc和that directory的其他後端，並實現一個將您的REST API作爲客戶端的實現。
TL：博士;用Perl編寫你的網關;使用Net :: IMAP :: Server;重寫Net :: IMAP :: Server :: Mailbox;並使用許多Perl REST客戶端之一與您的服務器交談。
快速這樣做，保持代碼的安全合理數量的最好的辦法，就是用Perl。你需要兩個Perl模塊。第一個是Net::IMAP::Server，here是該模塊的Github存儲庫。這是一個符合標準的RFC 3501服務器，專門用於配置郵件存儲。您將使用自己的代碼覆蓋默認的Net :: IMAP :: Server :: Mailbox實現，該代碼與您的自定義電子郵件後端進行通信。
對於你的第二個模塊，選擇自己喜歡的Perl模塊（S）使用說話的REST服務器。您的選擇取決於您希望對REST消息的構建和交付進行多少精細控制。
幸運的是，在這裏你有很多選擇。一種可能性是Eixo::REST，它有一個Github存儲庫here。 Eixo :: REST似乎很好地處理異步和同步REST API調用，但它不能提供對X509密鑰管理的很多控制。取決於你的API的googley，還有REST::Google模塊。有趣的是，這個家族也有一個REST::Google::Apps::EmailSettings模塊，專門用於設置Gmail特有的標籤和語言。最後，REST::Consumer模塊似乎封裝了許多特定於https的事物，例如超時和身份驗證，作爲Perl對象實例化的參數。
如果您使用這些現有的框架，那麼應該已經爲您完成了大約90％的必要代碼。
不要通過黑客Dovecot或任何其他使用C或C++編寫的郵件服務器來實現此目的。如果你用一種編譯語言快速破解郵件服務器，你的服務器遲早會遇到緩衝區溢出和堆棧粉碎以及互聯網干擾郵件服務器的所有其他事情。先安全地工作，然後再進行優化。
有道理。 Perl似乎是處理郵件的理想語言，因爲Perl是文本解析和管理的冠軍。所以我需要一個Perl專家，因爲我非常熟悉Perl，並且沒有時間去做這件事...... – richard
既然你熟悉.NET，我會建議任何黑客的IMAPv4服務器根據自己的喜好以下實現：
是的，這是可能的。例如，Dovecot允許您插入存儲模塊。 – arnt
你有語言偏好嗎？ – vzwick
問題說.net，所以c＃ish ...但在C＃中沒有太多的IMAP服務器代碼。客戶端，當然，但不是服務器，到目前爲止，問題的最大部分是服務於IMAP ... – arnt