11

最近、トランザクション メールの送信をMailgunに移動しました

これまでのところうまく機能していますが、return-path ヘッダーについて疑問に思っています。

このメールを検討してください (プライバシー保護のため、無関係なヘッダーを削除し、メール/ドメインを置き換えました)

Delivered-To: RECIEVER@gmail.com
Received: by 10.76.154.104 with SMTP id vn8csp478308oab;
        Wed, 4 Sep 2013 05:04:44 -0700 (PDT)
X-Received: by 10.50.22.105 with SMTP id c9mr1537992igf.36.1378296283817;
        Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Return-Path: <bounce+a801a1.c2b37-RECIEVER=gmail.com@my-website.com>
Received: from so254-63.mailgun.net (so254-63.mailgun.net. [198.61.254.63])
        by mx.google.com with ESMTP id k5si1620852igx.55.1969.12.31.16.00.00;
        Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Received-SPF: ...stripped...
Authentication-Results: ...stripped...
DKIM-Signature: ...stripped...
DomainKey-Signature: ...stripped...
Received: by luna.mailgun.net with HTTP; Wed, 04 Sep 2013 12:04:42 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: ...stripped...
From: my-website <support@my-website.com>
To: RECIEVER@gmail.com
Message-Id: <20130904120442.1488.88532@my-website.com>
X-Mailgun-Sid: WyI5YmI1OSIsICJqb2Vob3BmK2VlZ2VpN2lkMm9pbW9vYm9vZmFpQGdtYWlsLmNvbSIsICJjMmIzNyJd
Date: Wed, 04 Sep 2013 12:04:43 +0000
Sender: support@my-website.com
Content-Transfer-Encoding: base64

...email body...

これは、Gmail の受信トレイにある実際のメールから表示される生のメールです。ご覧のとおり、Return-Path ヘッダーには、次で終わる電子メール アドレスが含まれています。@my-website.com

しかし、送信メール用の dns レコード (spf、ドメインキーなど) しか設定していません。受信メール用ではありません。つまり、私の MX レコードはまだ別の場所 (私の場合は Google アプリ) のメールサーバーを指しています。

バウンス電子メールが mailgun サーバーに到着する可能性はありますか?

ヘッダー@some-mailgun-server.comで終わるメールアドレスが表示されることを期待していたでしょう!Return-Path

以前に Amazon SES を使用していましたが、Return-Pathヘッダーの末尾がamazonses.com

メールガンのサポートに問い合わせたところ、次のような回答がありました。

Nick: あなたの設定は正しいです。mx レコードが別の場所を指していても、Mailgun はバウンスを自動的に処理します。

彼らは、すべて問題ないと保証しましたが、説明はありませんでした (彼らの仕事は、私が知らないことを教えることではなく、信頼できる電子メール サービスを提供することなので、問題ありません...)。

だから誰かが私にこれを説明してくれることを願っています。

ポイントが明確であることを願っています。そうでない場合は、質問してください。質問を明確にしようとします。

編集：

私の 1 つの理論は、バウンス メールが実際に Google メール サーバーに送信され、そこで破棄されるというものです。ただし、プロセス中にエラー応答が送信メールサーバーにも送信されるため、これは冗長です (ターゲットメールサーバーへの tcp 接続を開くとき)。

この理論をテストするために、Return-Path メールは の形式でありbounce+SOMETHING@my-website.com、Google は文字の後に何が来るかに関係なく、すべてのメール+をその前のユーザーに配信するため、先に進んbounce@my-domain.comで Google アプリでアカウントを作成しました。

にもメールを送信しようとしましたbounce+a801a1.c2b37-RECIEVER=gmail.com@my-website.com。

それは私の受信トレイに届きました。

これで、受信トレイにバウンス トラフィックが届くことを期待していました。そのため、存在しない hotmail アドレスにメールを送信しました。Google Apps の受信トレイにメールが届きませんでしたが、mailgun はバウンスを正常に追跡しました。

だから...それは確かにうまくいくようです。理由がわかりません。

私が持っているもう 1 つの理論は、バウンス メールが配信されるメール サーバーは、MX レコードを使用して解決されないというものです。この場合は常に配信サーバーluna.mailgun.netが選択されます。アドレスで終わるドメインReturn-Pathはサーバー上のメールボックスの名前にすぎませんが、ドメインはメールが実際に配信されるサーバーとは何の関係もありません。

FromとReturn-Pathアドレスのドメインが一致すると、配信率が向上する可能性があるため、このようにすることも理にかなっています。

ただし、これは理論にすぎません。また、バウンスを受信できるメールボックスは、送信に使用されるサーバーと同じサーバー上にある必要があることも意味します。

つまり、メールを送信する実際のサーバー以外の場所でホストされているバウンスメールアドレスを受信するメールボックスを持つことは不可能です。しかし、これも私には奇妙に聞こえます...

誰かが私を啓発できることを願っています。

4

1 に答える 1

8

さまざまな種類のバウンスがあることがわかります。

バウンスが発生すると、通常、バウンスはメールを送信しているサーバーに返され、MX レコードには従いません。

そのため、メールガン サーバーに送信され、そこにも到達します。

ただし、ドメイン内の MX レコードを使用してメールサーバーとして宣言されたサーバーに送信される、いわゆる「遅延バウンス」もあります。

これらの遅延バウンスは一般的に処理が難しく、RFC に違反しているという意見があります。

ただし、これらのバウンスは非常にまれです。そのため、mailgun はそれらを処理しません。リターン パス アドレスでクライアント ドメインを使用する理由は、正しいアカウントに割り当てることができるようにするためです。彼らはそれをそのようにエンコードするだけです...

実際、Google Apps メールのバウンス用にメールボックスを設定していたときに、そのような遅延バウンスを 1 回受け取りました。

この問題の理解につながる適切なデバッグを可能にしたのは、この電子メールでした。

要約すると：

はい、住所が間違っています。サーバーは MX レコードを使用して送信するのではなく、接続を開始したサーバーに直接送信するため、ほとんどのバウンスでは問題ありません。

ただし、遅延バウンスの場合、これも発生することがありますが、バウンスはリターン パス アドレスで指定されたドメインの mx レコードの背後にあるサーバーに実際に送信されます。

これらのメールは、mailgun サーバーでバウンスとして正しく認識されません。

于 2013-09-05T14:33:37.213 に答える