4

通知メールメッセージを送信するアプリケーションを開発する場合、

  1. ホスティング会社からスパマーとしてフラグが立てられていない。（次のいずれかをカバーします:)
    • メールサーバーをフラッディングしないための最良のテクニック
    • あなたがあなた自身をセットアップすることになったならば、最高のメールサーバー製品
    • 特定のユーザーからのようにメッセージを送信しますが、適切な電子メールのエチケットを損なうことなく、アプリケーションから明確に送信します（苦情などが確実に返されるようにするため）。
    • 学んだ他の教訓
  2. 受信者のクライアントによってスパムとしてフラグが立てられていませんか？（次のいずれかをカバーします:)
    • メールが正しく識別されるように、sender-id、domain-keys、SPF、reverse-dnsなどを構成および使用する
    • ユーザーに電子メールを送信するときにスパムとしてフラグが立てられないようにするための最良のSMTPヘッダー技術（たとえば、SenderヘッダーとFromヘッダーを一緒に使用する）
    • 学んだ他の教訓

追加の要件：このアプリケーションは、イベントに基づいて単一の受信者に単一のメッセージを送信します。したがって、同じメッセージを複数の受信者に送信する手法は適用されません。

4

3 に答える 3

5

メールサーバーをフラッディングさせない最善の方法

メールサーバー管理者に確認する以外に、これについてできることはあまりありません（共有ホスティングアカウントの場合/自分の管理下にない場合）。ただし、要件がイベントごとに 1 人の受信者に 1 通の電子メールである場合は、それほど問題にはなりません。メール システムを詰まらせる傾向があるのは、数百 (またはそれ以上) の受信者を持つ電子メールです。

常に発生するイベントがある場合は、それらを統合して定期的に要約する電子メールを送信することを検討してください。

特定のユーザーからであるかのようにメッセージを送信するが、アプリケーションから明確に送信する (苦情などが確実にあなたに返ってくるようにするため) 良い電子メールのエチケットを破ることはありません

これは、"Reply-To" ヘッダーを使用することで実現できます。これにより、電子メール メッセージの作成時に、クライアントは差出人アドレスの代わりにそのアドレスを使用するようになります。

また、メールの "Return-Path" ヘッダーを設定する必要があります。これがないメールはフィルターで除外されることがよくあります。

元。

From: me@me.com
Return-Path: me@me.com
Reply-To: auto@myapp.com

送信者 ID、ドメイン キー、SPF、リバース DNS などを構成および使用して、メールが適切に識別されるようにする

これはすべて、メール サーバーと DNS サーバーの所有権に大きく依存します。spf/sender-id などはすべて DNS の問題であるため、DNS にアクセスできる必要があります。

あなたの例では、これはかなりの問題を引き起こす可能性があります。特定のユーザーからのメールを設定しているため、そのユーザーは DNS に SPF を設定して、メール サーバーを有効な送信者として許可する必要があります。さまざまなドメイン名を持つ多数のユーザーがいると、これがどれほど厄介なことになるか (完全に不可能ではないにしても) を想像できます。

逆引き DNS などに関しては、本当に依存します。ほとんどのクライアント ISP などは、逆引き DNS が設定されていることを確認するだけです。(つまり、1.2.3.4 は、host.here.domain.com が 1.2.3.4 に解決されなくても、host.here.domain.com に解決されます)。これは、そこにある共有ホスティングの量によるものです (メール サーバーは、実際のメール サーバーではなく、クライアントのドメイン名として自分自身を報告することがよくあります)。

リバース DNS の一致を必要とする厳しいネットワークがいくつかありますが、これには、そもそも一致しない場合にメール サーバーを制御する必要があります。

もう少し具体的に教えていただければ、もう少しアドバイスを提供できるかもしれませんが、一般的に、アプリケーション メールを送信する必要があり、環境を制御することができない人には、次のことをお勧めします。 :

  • 「Return-Path」を必ず設定してください
  • 「X-Mailer」と「X-Abuse-To」などのヘッダーにアプリと不正使用の情報を追加すると便利です (これらはカスタム ヘッダーであり、情報提供のみを目的としています)。
  • 送信メール サーバーの IP アドレスに逆引き DNS が設定されていることを確認します。
于 2008-09-22T00:03:56.567 に答える
0

今価値がある他のビットのために

言及されているIPはあなたのメールサーバーです

aあなたのIPのptrが同じIPFQDNに解決される名前を指すようにします

bサーバーhelo/ehloにwhatever.domain.comを設定します。ここで、domain.comは、手順Aの名前のドメインと同じです{以下の理由の名前は同じではありません}

cそのhelo/ehloサーバー名もサーバーのIPに解決されます

d次のspfレコードをそのhelo/ehlo名"v= spf1 a -all"に追加します{これは、ipのこの名前が指すだけのこの名前のhelo/ehloを許可することを意味します}

e次のsender-id行をhelo/ehlo名に追加します{完全を期すために"spf2.0/ mfrom、pra -all" {つまり、users@this-domainはありません}

f次のspfをサーバーのFQDNS-nameおよびその他のホスト名に追加します"v= spf1 -all" {つまり、この名前としてhelo / ehloを実行するマシンはなく、users@this-domainもありません}

{fqdns名はボット/感染によって決定される可能性があるため、この名前をhelo / ehloグリーティングで直接使用できないようにする方がよいため、helo /ehloIDと同じドメインからのもので両方の有効性を証明できます。 }

于 2009-01-29T02:04:38.933 に答える
0

最初に以前の簡単な修正

return-path: 受信メッセージのエンベロープ送信者に基づいて受信システムによって追加されるヘッダーです。

spf が機能するには、return-path/envelope-sender が yourapp@yourdomain.com である必要があります

yourdomain.com の spf レコード (または、ユーザーごとの spf の場合) yourapp@yourdomain.com で、アプリをホストする/メールを送信するサーバーでメールを発信できるようにします。

このエンベロープ送信者は、すべてのバウンス/エラーを受信するアドレスです

現在、sender-id は完全に異なり、return-path/envelope-sender と from: アドレス {メッセージ内に保存されている} をチェックします。

hisname hisaddres@hisdomain.com から送信する場合、これは問題になりません。

Resent-From: hisname yourapp@yourdomain.com を追加する必要があります。これは、from: を無視するように指定されているためです。

于 2009-01-29T01:50:58.490 に答える