差出人アドレスとして顧客の電子メールを使用することがなぜ悪い考えであるか
ユーザーがフォームに入力すると、ユーザーにメールを送信するアプリケーションがあります。 [email protected] fromアドレスとして。顧客は、フォームのメールを送信元アドレスとして使用することを望んでいます。これは、なりすましやブラックリスト、スパムのために悪い考えだと言われました。
特にこれについてクライアントにカウンセリングを試みなければならないので、これがなぜ悪い考えであるのかについての正確な理由について、私は本当に漠然と感じます。これが悪い考えである理由を誰かが私に説明できますか？.
興味深いことに、クライアントは、Gmailアカウントを送信元アドレスとしてデモとして使用しました。これは、正常に機能するだけでなく、アプリケーションがメールの送信を開始できるようにしました（以前は[email protected]）。 Erm-何が起こっているのですか。私は一つのことと逆のことを言われました。
すみません-これは基本的なことですが、Google検索で何でも見つけることができました。質問のフレーミングさえも苦手だからです。
[〜＃〜]編集[〜＃〜]
みんなありがとう-素晴らしい答え。興味深いことに、メールを送信するサーバーと、メールボックスが送信されるメールボックスは、どちらも同じファイアウォールの背後にあるため、クライアントはスパムに関心がないと言っています。しかたがない。
これはいくつかの理由で悪い習慣です：
- 所有していないドメインからメールを送信することはできません。したがって、なりすましの試みとして考えられます。
- これはスパマーが使用する一般的な十分な慣行であり、スパムフィルターによって頻繁にタグ付けされます。
- よく管理されたドメインが [〜＃〜] spf [〜＃〜] または [〜＃〜] dkim [〜＃〜] を使用して保護することはかなり一般的です彼らの評判は、他のシステムがなりすましやスパムを識別するのに役立ちます。当然、DKIMメールヘッダーを追加したり、SMTPサーバーをドメインのSPF DNSレコードに追加したりすることはできないため、メールは（正しく）偽造され、拒否されたと見なされます。
適切な方法は、ローカルドメインを送信者として使用し、存在しないアドレスをユーザー名として使用することです。
実際には、あなたがFromアドレスを顧客の電子メールに設定することは許可されています。ただし、 正しくSenderフィールドを設定する を自分のアドレスに設定します。 これがPaypalです。 する 使用していた！
FROM：[email protected] TO：[email protected] SENDER：[email protected]
ほとんどの電子メールクライアントは、これを "[email protected]の代わりに[email protected]から"としてレンダリングします。お客様のドメインのSPFまたはDKIMに問題はないはずです。
また、おそらく Reply-to header をお客様の住所に送信するため、返信はお客様の住所ではなくお客様の住所に送信されます。
TL; DR：
フォームのメールアドレスを使用することはお勧めしません。代わりに、このメーリングリスト専用のメールアドレスを使用してください。
ロングバージョン：
まず、実際には2つのメールアドレスが使用されています。 1つはエンベロープ送信者で、もう1つはメールのFrom:行に表示されるものです。
エンベロープ送信者は、メールサーバーが配信不能通知を発行するために使用する送信者です。メーリングリストを実行している場合、そのアドレスは通常、機能していないアドレスをメーリングリストから削除できるスクリプトになります。
From:アドレスは、メールの受信者が[返信]をクリックしたときに使用されるアドレスです。この場合、受信者が返信する可能性のある質問に実際に回答できる（または少なくとも回答できる人に転送できる）人物を指す必要があります。
受信者自身のメールアドレスをエンベロープ送信者として使用する場合、一部または多くのメールサーバーがメールを拒否するか、スパムである可能性があるとしてタグ付けすることが予想されます。外部サーバー。
受信者自身のメールアドレスをFrom:- senderとして使用すると、ユーザーは必要に応じてメッセージに応答できなくなります。メールメッセージの本文のどこかにリンクを配置するだけでは不十分です。人々は依然として電子メールクライアントの[返信]ボタンを使用し、それが機能しない場合は動揺します。
ここで、技術的な問題について話しているいくつかの素晴らしい答えがあります。これを顧客に販売するという点では、質問を少し言い換えると役立つ場合があります。顧客はおそらく、「はい、うまくいきます」のバリエーションを求めています。その答えは「はい、そのようなメールを送信できます」です。
彼らが検討すべきより良い質問は、「それが「届く」のか、それがそのように送信された場合に顧客がそれを見るのか」です。最新のスパムフィルターの答えは「いいえ、おそらく違う」です。
私が考えることができる2つの問題があります。最大の問題は、配信できない可能性のあるメールを送信することです。返信アドレスも当然そうなるため、多くのメールが待機してタイムアウトになることを意味します。 。サーバーが特定のドメインからのメールを特定のマシンから（DKIMルールに従って）探しているため、これらのメールの一部がスパムになってしまうという小さな問題の可能性があります。
[email protected]アドレスを作成し、後で電子メールをどう処理するかを決定します。
ユーザー自身のアドレスをFrom：として偽装することはお勧めできません。スパム対策フィルターがそれを偽造と見なす可能性があるため、これはメールがユーザーに届かないようにするための良い方法です（これはデファクトです！）。
「thisdomain」のSMTPサーバーがTCP「thisdomain」外の接続からの「MAIL From：user @ thisdomain」リクエストを拒否することは非常に合理的で一般的です。（ローカルホストからのこのような要求により、「thisdomain」ネットワーク内のユーザーは互いにメールを送信できます。）
実際には、[email protected]もお粗末です。
これは、SMTPサーバー（Eximソフトウェア）からの構成スニペットで、noreply送信者からのメッセージをバウンスするように構成しています。
deny
message = Sorry, we do not accept SMTP traffic from "noreply" senders. \
We believe that it is less than polite to send messages from \
nonexistent e-mail addresses \
which cannot be replied to! E-mail is a "two-way street". \
If you want us to accept \
your mail, then please accept replies.
senders = ^noreply@.*
電子メールは、返信を受け入れることができる実際の送信者のみが送信する必要があります。
私の言うことに対して耳が詰まっている場合、なぜ私はあなたの言うことを聞く必要がありますか？
何人かの人々はとにかくこれらの電子メールに返信し、適切なカスタマーサポートアカウントにルーティングする必要があります。