我在从 SendGrid 迁移到 Amazon SES 时遇到了问题。
能否有人分享一下他们的 app.yml 配置，或者确认我的配置是否正确？
## TODO: 用于验证新账户和发送通知的 SMTP 邮件服务器
DISCOURSE_SMTP_ADDRESS: email-smtp.eu-west-2.amazonaws.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: xxxxxxx
DISCOURSE_SMTP_PASSWORD: "xxxxxxxxxx"
DISCOURSE_SMTP_ENABLE_START_TLS: true # （可选，默认为 true）
DISCOURSE_SMTP_AUTHENTICATION: login这里的 auth 参数设置正确吗？
我是否遗漏了什么？
域名已在 SES 中验证，您无需使用 SMTP 认证参数。
此外，如果您的 SES 账户尚未脱离沙盒模式，可能需要将其移出沙盒并申请提高发送限额。沙盒限制是按区域应用的。
是的，已确认域名已验证，处于生产模式，且速率限制已提高。
其他方面看起来都正确吗？
是的，其他设置看起来对我来说是正确的。
密码用引号括起来没问题吗？
是的，那样也可以
嗯……
有没有办法从命令行进行测试？
我每次也都重新构建了应用。
感谢快速回复 
我仍然不明白为什么没有通过 AWS SES 发送电子邮件。
当我通过 Discourse 的管理页面发送测试邮件时，系统仅显示“已发送”。尝试重置密码请求也能正常执行流程，但从未收到邮件。
我认为 SES 不会记录日志，因此我无法检查它是否实际收到了这些邮件。
唯一可能导致问题的因素是，我们的回复地址使用的是 gmail.com 账户，而不是我们网站的域名。
之前有人遇到过这种组合或场景吗？
那将显示在发件人行中的电子邮件地址。它必须是 SES 将用于发送的域名中的地址。SES 不会发送伪装成来自 Gmail 的邮件。您无法控制 gmail.com，因此 SES 不会在发件人行中使用该域名。notification_email 应设置为 something@yourverifieddomain。
通知邮件的发件人字段显示的内容正是如此，是的，我相当确定这就是你的问题。你试过修改它吗？
我也使用 SES，对我来说运行良好。我能看到的唯一区别是，我的配置中没有 DISCOURSE_SMTP_AUTHENTICATION: login 这一行。另外，DISCOURSE_SMTP_ENABLE_START_TLS: true 和 DISCOURSE_SMTP_PORT: 587 在我的配置中都被注释掉了，不过这应该不会影响功能。
我在 app.yml 中只修改了 3 行：SMTP 地址、用户名和密码。其余部分保持默认，从全新安装直接注释掉即可。重建后，我只需确保站点设置中的“通知邮箱”使用的是在 SES 中已验证的域名下的地址。我现在不再在密码上加引号，但我之前的安装加了引号也能正常工作。
是的，值得尝试将“回复地址”更改为使用已验证的 SES 域名下的地址（正如上方回复所建议的），以测试这是否能使其正常发送。
如果仍然不起作用，建议检查一下主机是否阻止了某些端口，并再次确认 SES 凭据是否正确生成。我看到你在上面已经确认过你的域名已在 SES 中验证。
感谢您提供的详细信息 @markersocial
我想问一下，您的“回复到”邮箱地址是否与“发件人”地址属于不同的域名？
别担心 
回复地址确实与发件人域名相同，但在某些情况下，子域名可能不同（不过根域名仍然一致）。这两种情况对我来说都能正常工作。
我相信你已经注意到了这个问题——你验证过 Discourse 用来发送邮件的发件人地址吗？
如果是 notify@yourverifieddomain，你需要进入 SES，在“身份管理”下的第二行添加并验证该发件邮箱。不完成此操作，任何邮件都无法发出。
没有警报，没有鸣笛，只是无法发送。
使用 Gmail 作为回复地址是个好办法。我也是这么做的。否则，由于发件人和回复地址不一致，成员授权邮件会被标记为垃圾邮件。
后来，我写了一个简单的 AWS Lambda 函数（花了一周时间学习如何实现），将收到的邮件转发到 Discourse API。非常简洁，无需 Postfix。
