のようなメッセージが後付けされた自動メールをよく見かけます。
※ご注意：このメールは、受信メールを受け付けないアドレスから送信されています。この同じ問題について再度お問い合わせいただく必要がある場合は、上記のリンクを使用してください。
このメッセージには返信しないでください。監視されていないメールアドレスから送信されました。このメッセージは、Twitter の使用に関するサービス メールです。
助けが必要？Google Checkout ヘルプセンターにアクセスしてください。このメッセージには返信しないでください。
この警告のすぐ下に、Gmail の返信入力フィールドが表示されます。受信者の電子メールクライアントに返信を許可しないように指示する、そのような自動化された電子メールに添付できるヘッダーのようなものがあるべきだと私には思えます。
そのようなヘッダーはありますか？そうでない場合、電子メール形式を管理するグループによって議論されたことはありますか?
そのようなヘッダーはありますか？
いいえ、そのようなことはないと確信しています。あったとしても、非標準であり、広くサポートされていないため、現時点ではほとんど役に立ちません。たとえそれが標準になったとしても、そのようなヘッダーはおそらく単なる情報提供になるでしょう。また、下位互換性のために、サポートは電子メール クライアントに対して完全にオプションである必要があります。クライアントはそれを実装するのに時間がかかり、多くのユーザーはまだ古いバージョンのメール クライアントを使用しています。
そうでない場合、電子メール形式を管理するグループによって議論されたことはありますか?
おそらく。人々は長い間、電子メールであらゆる種類のことを提案してきましたが、私の直感では、それが実装されることは決してないでしょう。ええと...電子メールが何をするように設計されているかという考えに根本的な変化がない限り、そうではありません. メールを送信するときに「返信」ボタンさえなければ、Google はもっと喜んでくれると思います。 donotreply@...
電子メールは、実際のメールボックスから送信されるように設計されています。RFC 2822 および RFC 5322 は次のように述べています。
いずれの場合も、「From:」フィールドには、メッセージの作成者に属さないメールボックスを含めることはできません (SHOULD NOT)。
私にとって、これは電子メールがブロードキャストではなく、会話の手段として設計されていることを明確に示しています。
おそらく、変更の最大のキラーは、その線の少し上にあり、完全に再定義する必要があります。これにより、解決されるよりも多くの問題が発生します。
発信者フィールドは、メッセージに返信するときに必要な情報も提供します。「Reply-To:」フィールドが存在する場合、メッセージの作成者が返信の送信先として提案するアドレスを示します。「Reply-To:」フィールドがない場合、返信を作成する人が特に指定しない限り、デフォルトで「From:」フィールドで指定されたメールボックスに返信を送信する必要があります (SHOULD)。
いいえ、no-replyヘッダーはありません。
ただし、空のreply-toヘッダーを追加できます。
reply-to: <>
これは、 RFC 5322 のセクション 3.6.2に従って有効です。reply-to残念ながら、RFC では、空のフィールドが何を意味するのかを実際に指定することはありません。ほとんどの電子メールクライアントはそれを無視していると思います。
RFC 6854はRFC 5322を更新して、グループ構造をFromフィールドでも (特に) 使用できるようにします。グループは空にすることができます。これは、グループ構文が使用されているのを見たことがある唯一の方法です: undisclosed-recipients:;.
RFC のセクション 1Fromには、フィールドでグループ構成を許可する動機の中で「無応答」が明示的にリストされています。
「From:」フィールドの使用例は進化しています。電子メールを送信したいが、返信を処理できない自動システムの例は数多くあります。使用可能なアドレスのない「From:」フィールドは、その目的に非常に役立ちます。
次の例を提供します。From: Automated System:;
ただし、同じセクションの最後で、RFC は次のようにも述べています。
このドキュメントでは、現時点ではこれらのフィールドでグループ構文を一般的に使用しないことを推奨しています
セクション 3で、RFCは、Fromフィールドのグループ構文が限定使用のみであることを明確にしています。
Return-Path個人的には、関連するすべてのクライアントが元のドメインを別の方法で (または新しいヘッダーから再構築して) 表示することが確実でない限り、この方法は使用すべきではないと思います。そうしないと、ドメイン認証 (SPF、DKIM、および DMARC) に対するすべての努力が無効になります。クライアントが返信ボタンを単純に非表示にする追加のヘッダー フィールドを導入することは、私にははるかに優れたアプローチのように思えます。
セクション 5のこの側面に関する RFC のコメント:
一部のプロトコルは、「From:」アドレスを特定の検証済みドメインと照合することによって発信者アドレスを検証しようとします (そのようなプロトコルの 1 つについては、Author Domain Signing Practices (ADSP) ドキュメント [RFC5617] を参照してください)。このようなプロトコルは、「From:」フィールドに実際の電子メール アドレス (本物か偽物かにかかわらず) がないメッセージには適用できません。このようなメッセージの処理方法はローカル ポリシーによって決定されるため、送信者は、「From:」でグループを使用すると、メッセージの配信可能性に悪影響を及ぼす可能性があることに注意する必要があります。
何という失敗した機会…</p>