すべてのSMTP通信にポート587を使用するように開発者を説得する必要があるのはなぜですか？

Why Should I Convince Developers Use Port 587

解決：

RFCをざっと読んだところ、SMTPの世界を2つの領域に分割することを考えていました。メールの転送（SMTPが開発された目的です）とメールの送信です。

著者は、SMTPはメールクライアント（MUA、メッセージユーザーエージェント）によって使用されることを意図しておらず、メールサーバーによってのみ使用され、メールを宛先にルーティングすると主張しています。彼らは、SMTPの世界をこのように分割すると、MUAのみがアクセスすることを意図したSMTPサーバーを作成できると考えています。このサーバーは、SMTPサーバーを転送する必要があるかどうかにかかわらず、処理を実行して「通常の」仮定を行うことができます。 「通常の」SMTPサーバーは常にMTA、メッセージ転送エージェントと呼ばれてきました。著者は、新しいタイプのSMTPサーバーMSA、メッセージ送信エージェントに名前を付けることを提案しています。

これにより、2つのサーバータイプの実装がより簡単になり、おそらくさらに安全になると彼らは考えているようです。 RFCは、MTAと比較した場合にMSAで何が異なる必要があるかを説明しています。たとえば、RFCは、元のSMTPプロトコルに許可の使用を義務付けていませんが、許可の使用を義務付けています（SMTP AUTHは後で追加されましたが、RFC 2476のようですが、SMTP AUTH自体は、後でRFC 2554で指定され、置き換えられました。 RFC 4954による）。

さまざまな送信元からさまざまな宛先にメッセージを中継する必要があるMTAは、すべてのメッセージに認証を使用できるわけではありません（別のサーバーがサーバーに対してどのように認証する必要がありますか？）。ただし、メッセージの開始点であるMSAは、そのピアであるメールクライアントからの認証を要求する可能性があります。また、MTAはメッセージを変更せずに中継する必要がありますが、受信したヘッダー。MSAは電子メールを「サニタイズ」する場合があります。不足しているヘッダーなどを入力します。

見てください。

http://www.uceprotect.net/downloads/MAAWGPort25English.pdf

足りないのは、ポート587が認証されているだけだと思います。受信者がローカルであるかどうかに関係なく、ポート587で認証されていない電子メールを受け入れるべきではありません。私たちは（ISPとして）、送信ポート25をブロックして、直接からmxへのスパムを防ぎます。たとえば、ボットされたコンピュータから。住宅/動的ユーザーベースがポート25でアウトバウンドを送信するのをブロックすると（ポート25のIPスペースからの認証されていないリレーは引き続き許可されます）、不正使用レポートが85％以上減少しました。

ISPSは587のブロックを開始しません（MTAからMTAを使用するためのものではなく、送信ポートであるためMUAからMTAのみを使用するため、ブロックするべきではありません）。また、管理がはるかに簡単になります。また、MTA側では、すべてのローカルユーザーに認証を強制することで、スパムの軽減がはるかに簡単になります。ボックスが所有され、SMTPクレジットを侵害したとき。あなたがする必要があるのは彼らのアカウント/パスワードを無効にすることです。 IPによるリレーを使用する場合は、メールサーバーへの接続をブロックする必要があります（これは、DSL /ケーブル接続にACLを動的に適用することによって行います）。

MUAまたはMTAのいずれかを記述している場合は、両方をサポートする必要があります。MUAまたは何かが電子メールを送信する場合は、デフォルトで587のTLS試行とsmtp authを実行し、次の場合にのみ465、25にフェールバックする必要があります。それは失敗します。