Page 3

1.  Introduction

SMTP was defined as a message *transfer* protocol, that is, a means
to route (if needed) and deliver finished (complete) messages.

1. はじめに

SMTPはメッセージ「転送」プロトコルと定義された。すなわち、完成された（完全な）メッセージを（必要ならば）経路制御して配送する手段である。

Message Transfer Agents (MTAs) are not supposed to alter the message
text, except to add 'Received', 'Return-Path', and other header
fields as required by [SMTP-MTA].

メッセージ転送エージェント（MTA）は、‘Received’、‘Return-Path’その他の［SMTP-MTA］で要求されているヘッダフィールドの追加を除いては、メッセージのテキストを変更しないとされている。

However, SMTP is now also widely used as a message *submission*
protocol, that is, a means for Message User Agents (MUAs) to
introduce new messages into the MTA routing network.  The process
that accepts message submissions from MUAs is termed a Message
Submission Agent (MSA).

しかし、SMTPはいまや、メッセージ「投函」プロトコルとしても広く使われている。すなわち、メッセージユーザエージェント（MUA）がMTA経路制御ネットワークに新しいメッセージを導入する手段として使われているのである。MUAからのメッセージ投函を受け入れるプログラムがメッセージ投函エージェント（MSA）と呼ばれる。

In order to permit unconstrained communications, SMTP is not often
authenticated during message relay.

制限のない通信を許容するため、SMTPがメッセージ中継の間認証されていることは希である。

Authentication and authorization of initial submissions have become
increasingly important, driven by changes in security requirements
and rising expectations that submission servers take responsibility
for the message traffic they originate.

セキュリティ要求の変化と、投函サーバが自身の発するメッセージトラフィックに対して責任を負うことへの期待の高まりによって、最初の投函における認証と権限付与はますます重要になってきている。

For example, due to the prevalence of machines that have worms,
viruses, or other malicious software that generate large amounts of
spam, many sites now prohibit outbound traffic on the standard SMTP
port (port 25), funneling all mail submissions through submission
servers.

たとえば、ワームやウィルスに感染した機器や、その他の大量のスパムを生成する悪意を持ったソフトウェアの流行によって、多くのサイトは現在標準SMTPポート（ポート25）での送出トラフィックを禁止し、すべてのメール投函を投函サーバを通じて行っている。

In addition to authentication and authorization issues, messages
being submitted are in some cases finished (complete) messages, and
in other cases are unfinished (incomplete) in one or more aspects.
Unfinished messages may need to be completed to ensure they conform
to [MESSAGE-FORMAT], and later requirements.  For example, the
message may lack a proper 'Date' header field, and domains might not
be fully qualified.  In some cases, the MUA may be unable to generate
finished messages (e.g., it might not know its time zone).  Even when
submitted messages are complete, local site policy may dictate that
the message text be examined or modified in some way, e.g., to
conceal local name or address spaces.  Such completions or
modifications have been shown to cause harm when performed by
downstream MTAs -- that is, MTAs after the first-hop submission MTA
-- and are in general considered to be outside the province of
standardized MTA functionality.

認証や権限付与の問題に加え、投函されるメッセージはある場合には完成された（完全な）メッセージであり、別の場合には1つ以上の点で完成されていない（不完全な）メッセージである。完成されていないメッセージは、［MESSAGE-FORMAT］やその後の要求に準拠するために完成させる必要があるかもしれない。たとえば、メッセージに正しい‘Date’ヘッダフィールドが欠けていて、ドメインが完全に正しいと確認できないかもしれない。場合によっては、MUAが完全なメッセージを生成できないこともある（たとえば、自分のタイムゾーンを知らないなど）。投函されるメッセージが完全であっても、ローカルのサイトポリシによって、メッセージのテキストを検査したり、たとえばローカル名やアドレス空間を隠蔽するなど、何らかの方法で変更を行うことがある。このような補足や修正は、下流MTA（すなわち、投函MTAから1ホップ後のMTA）によって実行されると害になるので、通常は標準的なMTA機能の範囲外だと考えられている。

Separating messages into submissions and transfers allows developers
and network administrators to more easily do the following:

メッセージを投函と転送に分割すると、開発者やネットワーク管理者にとって以下のことがずっと容易になる：

[Page 3]