メッセージ送信エージェント

メッセージ送信エージェント（MSA ）またはメール送信エージェントは、メールユーザーエージェント（MUA）から電子メールメッセージを受信し、メール転送エージェント（MTA）と連携してメールを配信するコンピュータプログラムまたはソフトウェアエージェントです。RFC 6409で指定されているように、シンプルメール転送プロトコル（SMTP）のバリエーションであるESMTPを使用します。[ ^1]

多くのMTAはMSAの機能も果たしますが、完全なMTA機能を備えずにMSAとして特別に設計されたプログラムもあります。^[2]歴史的に、インターネットメールでは、MTAとMSAの両方の機能がポート番号25を使用していますが、MSAの公式ポートは587です。 ^[1] MTAはユーザーの受信メールを受け入れ、MSAはユーザーの送信メールを受け入れます。

MTA機能と MSA 機能を分離すると、いくつかの利点が生まれます。

MSA の利点の 1 つは、作成者の MUA と直接やり取りするため、メッセージ形式の小さなエラー (日付、メッセージ ID、宛先フィールドの欠落、またはドメイン名のないアドレスなど) を修正したり、作成者にエラーをすぐに報告して、受信者に送信される前に修正したりできることです。別のサイトからメッセージを受け入れる MTA は、このような修正を確実に行うことができず、このような MTA によって生成されたエラー レポートは、メッセージが送信された後にのみ作成者に届きます (届く場合も)。

もう 1 つの利点は、専用のポート番号 587 を使用すると、ユーザーがいつでも自分のドメインに接続して新しいメールを送信できることです。スパム (ボットネットの被害者が無意識に送るスパムを含む) に対抗するため、多くのISPや組織ネットワークでは、ポート 25 でリモート MTA に接続する機能を制限しています。ポート 587 ^[3]の MSA にアクセスできるため、移動の多いユーザー (たとえば、ラップトップで作業しているユーザー) は、他のネットワーク内からでも、好みの送信サーバーを介してメールを送信し続けることができます。送信者ポリシーまたは署名方法が強制される 場合は、特定の送信サーバーの使用が必須です。

もう 1 つの利点は、MTA と MSA の機能を分離することで、MTA がリレーを拒否しやすくなることです。つまり、ローカルでサービスされているドメインの受信者宛てではないメールを拒否するということです。これは、ISP がウイルスに感染したクライアント コンピュータからのスパムの送信を防ぐために使用する戦略です。対照的に、MSA は一般にインターネット上のすべての受信者宛てのメールを受け入れる必要がありますが、そのようなメールは、その MSA の使用を許可され、認証によって MSA に ID を確立した作成者からのメールのみを受け入れます。メールの送信と受信メールの受信の両方が通常同じプロトコルと同じサーバーを使用して実行されていた時代には、認証なしで任意の宛先にメールを送信できる機能により、スパマーは MTA をスパムの配布手段として使用できました(1 つのメッセージ トランザクションで、MTA に多数の受信者へのメッセージのリレーを要求できるため)。また、メッセージの送信元を追跡することがより困難になりました。

さらに、MSA と MTA は、スパムのフィルタリングに関して異なるポリシーを持つことができます。ほとんどの MSA では、作成者が提供するユーザー名とパスワードによる認証が必要です。したがって、このような MSA が受信したメッセージは、MSA と直接関係のある作成者まで追跡可能であり、作成者は自分の行動に責任を負うことができます。これにより、MSA はスパム フィルタリングをまったく行わないか、他のドメインからの受信メールを受け入れる目的で存在する MTA よりもスパム フィルタリングを緩くすることができます。任意のドメイン間で送信されたメールの信頼を確立することは困難です。なぜなら、通常、それらのドメイン間には信頼を確立したり、アイデンティティを確立したりできる直接的な関係がないためです。このような信頼がない場合、MTA は通常、スパムと正当なトラフィックを区別するためにヒューリスティックとサードパーティのレピュテーション サービスに頼らなければなりませんが、これらのメカニズムはどちらもエラーが発生しやすいという歴史があります。^{[4] [5]} MSAとMTAを分離することで、メール送信時に信頼性の低いスパム認識メカニズムの使用を回避し、正当なメールが正常に配信される可能性が高まります。

最近のメールクライアントはデフォルトでポート587を使用していますが、古いクライアントは依然としてポート25を提案しています。後者の場合、ユーザーは手動でポート番号を変更する必要があります。また、MUAは、そのドメインのSRVレコードを検索して、特定のドメインのMSAを提供するサーバーを自動的に検出することもできます。ドメインexample.comは、次のようにレコードを公開できます。^[6]

  _submission._tcp.example.com。SRV 0 1 587 mail.example.com。

RFC 6409 では、メール送信サービスを使用するために、クライアントが承認および認証されることが要求されています。これには、たとえば SMTP-AUTH (ESMTPA) で説明されている方法、またはRADIUS、公開鍵証明書、または (ほとんど廃止された) POP before SMTPなどの他の手段が使用されます。

MSA は、送信されたメールが構文的に有効であり、関連するサイト ポリシーに準拠していることを確認する必要があります。RFC 6409 には、いくつかのオプション機能が含まれています。

• 送信権限を強制すると、エンベロープ送信者アドレスが有効であり、使用されている認証で承認されていることが保証されます。これは本質的に、RFC 7208 で指定されているSPFモデルに準拠しています。
• エンベロープ送信者アドレスが「From」ヘッダー フィールドのどの作成者アドレスとも一致しない場合は、送信者アドレス ヘッダー フィールドを追加するための送信者許可を追加できます。これは、RFC 4406 で指定されている送信者 IDモデルにほぼ準拠しています。ただし、RFC 6409 でカバーされていない Resent-From ヘッダー フィールドの厄介なケースは無視されます。

• 電子メール認証
• メールサーバーのリスト
• メールサーバーの比較
• スマートホスト
• 電子メールエージェント（インフラストラクチャ）（MxA）
• メール配信エージェント(MDA)
• メール ユーザー エージェント(MUA)

• Klensin, J. (2001 年 4 月). Simple Mail Transfer Protocol. IETF . doi : 10.17487/RFC2821 . RFC 2821. 2013 年11 月 14 日閲覧.
• 「SMTP は安全ではありません」。Kasoft Central。2008年 6 月 14 日取得。