通過插入觸發器安全地發送數據庫郵件
到目前為止，我已經花了大約 30 個小時試圖去
sp_send_dbmail上班。我終於得到了一些工作，但我對它的安全性表示嚴重懷疑。我想知道一種更好但快速且易於設置的方法（此時我的時間受到嚴重限制），以及“理想”（最佳實踐）解決方案。目前 SQL Server 2005 配置
- `After Insert` Trigger on table executes `sp_send_dbmail` - Database Mail SMTP Account setup (with successful mail test) - Database Mail Profile setup (with "Public Profile" ticked) - "guest" account added to "DatabaseMailUserRole"我發現這篇文章建議了“正確”的解決方案，我閱讀了這篇文章，發現這是一個非常複雜的解決方案，似乎有太多可能出錯的地方，更不用說難以維護了。
我對替代解決方案的想法是這些。
1. Setup an Application Role in msdb (this would be my first time using one and not even sure if it IS a solution :P), and use it to ensure that email can ONLY be generated from the app and not by connecting directly to the server. 2. Abandon the trigger and instead run a job on the table to send email. Definitely NOT ideal as I would prefer the email to go out instantly, but at least this way I would be able to control the user context. Additionally this is similar to the current mechanism, except it would use a Stored Procedure instead of a DTS package.這 30 個小時我一直在解決的問題以及我詢問的原因與執行觸發器的安全上下文有關。當我進行測試時，一切都很好，因為我是一名 DBA，但是當我的使用者使用負責生成電子郵件的應用程序時，它會中斷，因為他們的憑據不足以讓觸發器執行
sp_send_dbmailproc，因此它破壞了應用程序。（不幸的是，我在 SQL Server 級別的錯誤處理目前不太理想）。
您最好簡單地插入觸發器中的郵件隊列表並讓單獨的電子郵件程序處理郵件 - 在 SQL Server 代理或外部程序中。
這使您可以根據需要使用觸發器，延遲相對較低，因為其他作業一旦送出就可以看到郵件，獨立管理郵件負載的可擴展性等。
您可以正確地將郵件隊列包裝到事務中。如果郵件伺服器暫時不可用或您有電子郵件地址問題，則排隊應用程序是可靠的。如果需要重新發送郵件，只需重置已發送標誌即可。您可以對郵件進行過期設置，使無法發送到 SMTP 的郵件在一定時間後不會被重試。您可以快速將所有郵件路由到測試郵箱。您可以根據隊列中的數據對附件和其他事情做一些非常有趣的事情，而無需長時間綁定觸發器——比如生成報告等。
因此，該應用程序將郵件責任轉移到另一個組件，並且可以自由地完成數據庫事務並將成功返回給使用者，而郵件子系統繼續其工作，確保您想要對郵件執行的所有操作都完成。