amazon ses
One fine day, for no discernible reason, my Ubuntu 18.04 business server stopped forwarding mail to my Gmail address.
好的一天,我没有任何明显的理由,我的Ubuntu 18.04 商业服务器停止转发邮件到我的Gmail地址。
Just the day before, the .forward files I'd created in the home directories of the local server accounts I use for email - like /home/office/.forward - were cheerfully redirecting all the mail aimed at my business addresses to my daily-use Gmail account. And then they suddenly stopped.
就在前一天,我在用于电子邮件的本地服务器帐户的主目录中创建的.forward文件(例如/home/office/.forward)正在愉快地将所有针对我的营业地址的邮件重定向到我的日常-使用Gmail帐户。 然后他们突然停了下来。
When I noticed something was wrong, I immediately consulted my server logs. /var/log/mail.err was spitting out charming messages that included things like:
当我发现有问题时,我立即查阅了服务器日志。 /var/log/mail.err散发出包含以下内容的迷人消息:
status=deferred (delivery temporarily suspended: connect to alt2.gmail-smtp-in.l.google.com[219.8.202.27]:25: Connection timed out)
Checking the server mailboxes told me that mail was coming in, but that Postfix couldn't establish a connection to Gmail to forward messages to my address.
检查服务器邮箱时,得知有邮件进来,但Postfix无法建立与Gmail的连接以将邮件转发到我的地址。
Naturally I restarted Postfix, but that didn't help.
自然,我重新启动了Postfix,但这没有帮助。
sudo systemctl restart postfix
I confirmed that there was nothing blocking outgoing messages from leaving my server on port 25 (SMTP). Then I checked to make sure my domain hadn't somehow been blacklisted (there are numerous online tools that'll do that for you), and peeked at the state of my MX records by running dig from the command line:
我确认没有任何东西阻止传出邮件离开我的服务器在端口25(SMTP)上。 然后,我检查以确保我的域没有被列入黑名单(有许多在线工具可以为您完成此工作),然后通过从命令行运行dig来查看MX记录的状态:
dig MX bootstrap-it.com
Nothing doing. Everything seemed to check out.
无所事事。 一切似乎都结帐了。
After a few frustrating troubleshooting sessions I gave up and figured I'd try something completely different.
经过几次令人沮丧的故障排除会议后,我放弃了,以为我会尝试完全不同的尝试。
Being an AWS solutions architect and having co-authored two books for Wiley/Sybex on AWS (one a guide to the Cloud Practitioners exam and one for the Solutions Architect Associate exam), shouldn't I be willing and able to build my own stack of AWS tools that'll handle my email server needs in the cloud?
作为一名AWS解决方案架构师,并且与人合着了两本关于AWS上的Wiley / Sybex(一本是Cloud Practitioners考试的指南 ,另一本是Solutions Architect助理考试的书 ),我不应该并且也不会能够构建自己的堆栈可以在云中处理我的电子邮件服务器需求的AWS工具?
Well it turns out that I was both willing and - after some serious research and trial and error - able. Getting it done would require:
事实证明,在经过认真的研究和反复试验后,我既愿意,又能够。 完成它需要:
- Creating an S3 bucket where incoming emails will be stored. 创建一个S3存储桶,用于存储传入的电子邮件。
- Creating a Simple Notification Service (SNS) topic to email me a notice every time a new email arrives. 创建一个简单通知服务(SNS)主题,以在每次收到新电子邮件时通过电子邮件将通知发送给我。
- Configuring Amazon's Simple Email Service (SES) to take over my email domain (bootstrap-it.com) and handle incoming mail. That involves adding an MX record to Route 53 (where my domains are managed) and pointing SES to my domain; adding and verifying each email address I want SES to control; and then telling SES to send new messages to my S3 bucket while also triggering an alert for the SNS topic. 配置Amazon的简单电子邮件服务(SES)来接管我的电子邮件域(bootstrap-it.com)并处理传入的邮件。 这涉及向Route 53(管理我的域的地方)添加MX记录,并将SES指向我的域; 添加并验证我希望SES控制的每个电子邮件地址; 然后告诉SES将新消息发送到我的S3存储桶,同时还触发有关SNS主题的警报。
Assuming you will also want to send email messages through the service, it's also a good idea to configure SES to sign your outgoing messages using DomainKeys Identified Mail (DKIM).
假设您还希望通过该服务发送电子邮件,将SES配置为使用DomainKeys Identified Mail(DKIM)对您的传出消息进行签名也是一个好主意。
I'm not going to describe all those steps in detail here. There's plenty of excellent documentation available for that. But I will briefly mention some pain points you might encounter.
我将不在这里详细描述所有这些步骤。 有很多出色的文档可供使用。 但我会简要地提到您可能会遇到的一些痛点。
You'll have to add an MX record to your DNS hosted zone for each domain you're using. Even if your domains are managed within Amazon's Route 53, you'll need to provide a value for your record.
您必须将MX记录添加到您正在使用的每个域的DNS托管区域中。 即使您的域名是在Amazon的Route 53中管理的,您也需要提供记录值。
What you use for that value will depend on the AWS region where your SES resource is located. In my case, it looked like this:
用于该值的值将取决于SES资源所在的AWS区域。 就我而言,它看起来像这样:
10 inbound-smtp.us-east-1.amazonaws.com
The SNS notifications will arrive in a single long string of text containing just a couple of short morsels of useful but hard-to-read information. That'll be enough to identify spam, but you'll usually need more information than what you'll find here. I use the notifications as a heads-up telling me that there's new mail in my S3 bucket.
SNS通知将以单个长长的文本字符串到达,其中仅包含几个简短但有用但难以理解的信息。 这足以识别垃圾邮件,但通常您需要的信息比这里的信息还多。 我将通知用作提醒,告知我S3存储桶中有新邮件。
Viewing the emails themselves within your S3 bucket via the AWS Management Console isn't the end of the world if it only happens once or twice a month. But if they're coming in faster than that, you'll need to find a better way to access and read your messages.
如果每月仅发生一次或两次,则通过AWS管理控制台在S3存储桶中查看电子邮件本身并不是世界末日。 但是,如果它们的传入速度比那快,那么您将需要找到一种更好的方式来访问和阅读消息。
However, creating a protocol for automating that process is really a local operating system problem that requires an entirely different set of tools. I solved the problem for myself using the AWS CLI and a cool Bash script. If you'd like to see how I did that, click through to this article.
但是,创建用于自动化该过程的协议实际上是一个本地操作系统问题,需要一套完全不同的工具。 我使用AWS CLI和一个很酷的Bash脚本自己解决了这个问题。 如果您想了解我是如何做到的, 请单击以浏览本文 。
There's much more administration goodness in the form of books, courses, and articles available at my bootstrap-it.com.
我的bootstrap-it.com上提供了书籍,课程和文章形式的管理优势。
翻译自: https://www.freecodecamp.org/news/aws-simple-email-service-email-server/
amazon ses