More than 3 years have passed since last update.

AWS SESとLambdaで個人ドメインメールをGmailに転送

Posted at 2020-07-19

英語版はMediumで作成しました：Forwarding Personal Domain Emails to Gmail with AWS Lambda and CloudFormation。日本語に自信がないので、ほぼGoogle Translateで作成しています。

サマリー：個人DomainのEmailを無料で信頼性の高いソリューションを構築するために、AWS無料利用枠サービス（SES、Lambda、S3）を使用してMIMEメールをアーカイブし、Gmailに転送します。他のソリューション：

AWSブログ：受信メールを外部の宛先に転送する
Githubリポジトリ：aws-lambda-ses-forwarder

まずはお試しください！

必要なインフラストラクチャはすべてGithub gistで更新されています。インフラストラクチャ全体を1-clickでセットアップするには、次のスクリプト（Linux / MacOS）を実行します。

前提条件

有効なAWSアカウント（無料利用可能）
AWS Simple Email Serviceで個人ドメインを確認する
AWS Simple Email Serviceで宛先メールを確認する
（SESは、サンドボックスステージで確認済みの宛先のみを許可します）
AWS CLIをインストールする

追加情報

# Only needed if aws credentials are not set in ~/.aws/config, ensures your IAM user has permission to deploy CloudFormation stack
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_DEFAULT_REGION=... e.g. us-west-2
# Configure domain and destination email information
STACK_NAME="EmailProxyStack"
DOMAINS="mydomain1.com,mydomain2.com"
MAIL_RECIPIENT="proxy_destination_email@gmail.com"

スタックを作成する

# Get the CloudFormation template file (containing lambda code)
curl https://gist.githubusercontent.com/willings/7f0310c971278cddada267616a39f091/raw/43ccabcbb5254375e47a006d7d5878a2afff6eaa/email-proxy-stack.yaml > email-proxy-stack.yaml
# Create CloudFormation stack and deploy
aws cloudformation deploy \
    --capabilities CAPABILITY_IAM \
    --template-file email-proxy-stack.yaml \
    --stack-name ${STACK_NAME} \
    --parameter-overrides Domains="${DOMAINS}" MailRecipient="${MAIL_RECIPIENT}"

作成後の手順

作成したメールルールフィルターをコンソールで有効にする
セットアップ全体をテストするためにテストメールを送信する
Gmailフィルターを設定して、ドメインのメールを異なるラベル/バケットに分類します。

仕組み

MX設定がSESレコードに更新された後、ドメインEメールはAWS SESに転送されます：10 inbound-smtp.regionInboundUrl.amazonaws.com。詳細については、SESのドキュメントを参照してください。
メールルールフィルターでは、MIMEメールメッセージ全体をS3バケットに入れて、後で使用するためのアクションを追加します。バケット内のファイル名はメールメッセージIDと同じです。
Eメールルールフィルターでは、S3に格納した後、別のアクションがSES通知によってLambda関数をトリガーし、ラムダ関数コードがS3バケットからEメールをフェッチし、メッセージを目的の形式に更新し、今後の検索のためにCloudWatchログに記録します。
Lambda関数はSES send_raw_email apiを呼び出して、変更された電子メールメッセージを転送します。
SESはSMTPプロトコルを実行して、電子メールを宛先に送信します。

その他

Pros

費用はかかりません（S3は1年間の試用後の費用は少しかかる場合があります）
できるだけ多くのメールアカウントを定義してください！
信頼性が高く、EC2の自己ホスト型電子メールサーバーと比較してサーバーのダウンを心配する必要はありません

Why another wheel？

上記の両方の参照は、次の意味で理想的ではありません。

コードとしてのインフラストラクチャとして実装されていないため、手動で構成する必要があり、人為的なミスが発生する可能性がある
AWSブログの例はGmailでネイティブに表示できない.emlファイルとして転送します
Githubコードはテキストベースの処理を使用します。コードは少し複雑です。 pythonの組み込みのemailパッケージは、より優れたソリューションのようです

将来の改善点

ここでも、非アクティブなルールセットをアクティブに移動する手動の手順が必要です。この手順は、cloudformationスタックにカスタマイズされたリソースラムダを追加することで自動化できます。
処理に失敗した場合は、SNSからSMSに通知して、生のメールをキャッチして表示できるようにすることができます。

トラブルシューティング

メールが宛先メールボックスに転送されません。どこからデバッグを開始できますか？
2〜5に従ってください。
SESが私のメールを処理していることをどのようにして知るのですか？
ドメインのMXレコードが正しく設定されていることを確認してください。DNSレコードの更新に多少の遅延がある可能性があることに注意してください。一部のMX DNSルックアップツール（https://mxtoolbox.com/など）も確認に役立ちます。
ドメインに送信されたメールが「アドレスに到達できません」で拒否されるのはなぜですか？
アクティブな電子メールルールフィルターがないことが原因である可能性があります。作成されたルールフィルターがアクティブか非アクティブかを確認してください。
ラムダがリクエストを処理していることをどのようにして知ることができますか？
S3バケットをチェックして、新しいファイルが存在するかどうかを確認します
CloudWatchログをチェックして、ラムダに処理エラーがあるかどうかを確認します
ラムダが正しくトリガーされても、プロキシされたメールが宛先メールボックスに送信されないのはなぜですか？
宛先のメールアドレスがホワイトリストに登録されていないことが原因である可能性があります。SESはデフォルトで、未確認のドメインへの送信メールをブロックします。
スタックで作成されたリソースを見つけるにはどうすればよいですか？
コンソールでCloudFormationスタックを確認します。正しいリージョンに切り替える必要がある場合があることに注意してください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up