私のアプリケーションのユーザーは、SMTP情報を介して電子メールを送信できます。
SMTPに代わって100%メールを送信したい。誰かがスパムを送信し始めた場合、他のユーザーに悪影響を与えたくありません。
しかし、受信したヘッダーにはサーバーのIPが表示されているので、誰もが影響を受けると思います。
サーバーが責任を負わないようにするにはどうすればよいですか?1人が他の人を台無しにしないようにする必要があります。
私のアプリケーションのユーザーは、SMTP情報を介して電子メールを送信できます。
SMTPに代わって100%メールを送信したい。誰かがスパムを送信し始めた場合、他のユーザーに悪影響を与えたくありません。
しかし、受信したヘッダーにはサーバーのIPが表示されているので、誰もが影響を受けると思います。
サーバーが責任を負わないようにするにはどうすればよいですか?1人が他の人を台無しにしないようにする必要があります。
あなたは仲介者であるため、このシナリオでは、つまり、他の人に代わってSMTPサーバーに接続しているため、スパムを処理するのはアプリケーション次第です。これをネットワークレベルだけで解決することはできません。
PHPから送信された電子メールのヘッダーにサーバーIPが表示されているので、私は次のように想定するのが正しいでしょうか。
これが当てはまる場合、侵害されてスパムを送信しているユーザーに対する保護に関して、いくつかの制限されたオプションがあります。
最初のオプションは、PHPアプリケーションにレート制限を実装し、永続ストアを使用して一定期間に送信された電子メールの数を記録することです。ただし、このソリューションはSMTPサーバー自体の悪用をカバーしていないため、非常に制限されています。
ポリシー付きなどのポリシーサーバーを調査し、クォータを実装することをお勧めします。1時間あたりの最大送信速度を指定するSASLユーザー名を使用するクォータは、スパムブラックリストに追加される可能性を減らすのに役立ちます。選択したポリシーサーバーがクォータに達したという通知をサポートしている場合は、それも実装します(クォータに定期的に達しているユーザーを識別して、アカウントに問題があることを示します)。
ユーザーのニーズと保護のバランスをとる必要があるため、送信を制限するレートを決定することは困難です。おそらく、出発点として、ユーザーが1時間あたりに送信する電子メールの平均数を監視し、これを出発点として使用することをお勧めします。
繰り返しになりますが、上記は上記の3つのポイントが正しいことを前提としています。認証なしで単にメールをSMTPデーモンに渡す場合、またはサーバーが外部にあり、変更できない場合は、PHPで制限を適用する必要があります。