Internet Engineering Task Force (IETF)                        R. Gellens
Request for Comments: 6409                         QUALCOMM Incorporated
STD: 72                                                       J. Klensin
Obsoletes: 4409                                            November 2011
Category: Standards Track
ISSN: 2070-1721

Message Submission for Mail




This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.


Message relay is unaffected, and continues to use SMTP over port 25.


When conforming to this document, message submission uses the protocol specified here, normally over port 587.


This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements.


Status of This Memo


This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2011 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定(の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents


   1. Introduction ....................................................4
   2. Document Information ............................................5
      2.1. Definitions of Terms Used in This Memo .....................5
      2.2. Conventions Used in This Document ..........................6
   3. Message Submission ..............................................6
      3.1. Submission Identification ..................................6
      3.2. Message Rejection and Bouncing .............................6
      3.3. Authorized Submission ......................................7
   4. Mandatory Actions ...............................................8
      4.1. General Submission Rejection Code ..........................8
      4.2. Ensure All Domains Are Fully Qualified .....................8
      4.3. Require Authentication .....................................8
   5. Recommended Actions .............................................9
      5.1. Enforce Address Syntax .....................................9
      5.2. Log Errors .................................................9
      5.3. Apply Shorter Timeouts .....................................9
   6. Optional Actions ...............................................10
      6.1. Enforce Submission Rights .................................10
      6.2. Enforce Permissions .......................................10
      6.3. Check Message Data ........................................10
      6.4. Support for the Postmaster Address ........................10
      6.5. Adjust Character Encodings ................................11
   7. Interaction with SMTP Extensions ...............................12
   8. Message Modifications ..........................................13
      8.1. Add 'Sender' ..............................................14
      8.2. Add 'Date' ................................................14
      8.3. Add 'Message-ID' ..........................................14
      8.4. Transfer Encode ...........................................14
      8.5. Sign the Message ..........................................14
      8.6. Encrypt the Message .......................................14
      8.7. Resolve Aliases ...........................................15
      8.8. Header Rewriting ..........................................15
   9. Security Considerations ........................................15
   10. IANA Considerations ...........................................16
   11. Acknowledgments ...............................................16
   12. References ....................................................17
      12.1. Normative References .....................................17
      12.2. Informative References ...................................17
   Appendix A. Major Changes from RFC 4409 ...........................20
1. Introduction
1. はじめに

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

SMTP [SMTP-MTA]は、メッセージ*転送*プロトコルとして定義されました。つまり、ルーティング(必要な場合)および完了した(完全な)メッセージを配信する手段です。

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]. 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).

メッセージ転送エージェント(MTA)は、[SMTP-MTA]で必要とされる「Received」、「Return-Path」、およびその他のヘッダーフィールドを追加する場合を除いて、メッセージテキストを変更することは想定されていません。ただし、SMTPは現在、メッセージ*送信*プロトコルとして広く使用されています。つまり、メッセージユーザーエージェント(MUA)がMTAルーティングネットワークに新しいメッセージを導入する手段です。 MUAからのメッセージ送信を受け入れるプロセスは、「メッセージ送信エージェント」(MSA)と呼ばれます。

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


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.


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 the Message Format specification [MESSAGE-FORMAT] and related 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.


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


o Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail.

o セキュリティポリシーを実装し、不正なメールの中継や迷惑なバルクメールの挿入から保護します。

o Implement authenticated submission, including off-site submission by authorized users such as travelers.

o 旅行者などの許可されたユーザーによるオフサイト提出を含む、認証された提出を実装します。

o Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission.

o 関連するソフトウェアコードの違いを分離することにより、各コードベースをより簡単にし、リレーとサブミット用のさまざまなプログラムを可能にします。

o Detect configuration problems with a site's mail clients.

o サイトのメールクライアントの構成の問題を検出します。

o Provide a basis for adding enhanced submission services.

o 強化された提出サービスを追加するための基礎を提供します。

This memo describes a low-cost, deterministic means for messages to be identified as submissions, and it specifies what actions are to be taken by a submission server.


2. Document Information
2. ドキュメント情報
2.1. Definitions of Terms Used in This Memo
2.1. このメモで使用される用語の定義

Many of the concepts and terms used in this document are defined in [SMTP-MTA]; familiarity with those documents is assumed here.


Fully Qualified


Containing or consisting of a domain that can be globally resolved using the Domain Name Service, that is, not a local alias or partial specification.


Message Submission Agent (MSA)


A process that conforms to this specification. An MSA acts as a submission server to accept messages from MUAs, and it either delivers them or acts as an SMTP client to relay them to an MTA.

この仕様に準拠するプロセス。 MSAはMUAからのメッセージを受け入れる送信サーバーとして機能し、MSAを配信するか、MTAに中継するSMTPクライアントとして機能します。

Message Transfer Agent (MTA)


A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server to accept messages from an MSA or another MTA, and it either delivers them or acts as an SMTP client to relay them to another MTA.

[SMTP-MTA]に準拠したプロセス。 MTAは、MSAまたは別のMTAからのメッセージを受け入れるSMTPサーバーとして機能し、メッセージを配信するか、SMTPクライアントとして機能して、別のMTAにメッセージを中継します。

Message User Agent (MUA)


A process that acts (often on behalf of a user and with a user interface) to compose and submit new messages, and to process delivered messages.


For delivered messages, the receiving MUA may obtain and process the message according to local conventions or, in what is commonly referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP [IMAP4] is used to access delivered messages, whereas the protocol defined here (or SMTP) is used to submit messages.

配信されたメッセージの場合、受信MUAはローカルの規則に従ってメッセージを取得して処理するか、一般にスプリットMUAモデルと呼ばれるものでは、Post Office Protocol [POP3]またはIMAP [IMAP4]を使用して配信されたメッセージにアクセスします。一方、ここで定義されたプロトコル(またはSMTP)は、メッセージの送信に使用されます。

2.2. Conventions Used in This Document
2.2. このドキュメントで使用される規則

Examples use the '' domain.


The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].

このドキュメントのキーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」は、[KEYWORDS]で定義されているとおりに解釈されます。

3. Message Submission
3. メッセージの提出
3.1. Submission Identification
3.1. 提出物の識別

Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA], with additional restrictions or allowances as specified here.

このドキュメントで指定されているとおり、ポート587は電子メールメッセージの送信用に予約されています。このポートで受信されたメッセージは発信と定義されています。使用されるプロトコルはESMTP [SMTP-MTA]であり、ここで指定されている追加の制限または許容値があります。

Although most email clients and servers can be configured to use port 587 instead of 25, there are cases where this is not possible or convenient. A site MAY choose to use port 25 for message submission by designating some hosts to be MSAs and others to be MTAs.


3.2. Message Rejection and Bouncing
3.2. メッセージの拒否とバウンス

MTAs and MSAs MAY implement message rejection rules that rely, in part, on whether the message is a submission or a relay.


For example, some sites might configure their MTAs to reject all RCPT commands for messages that do not reference local users, and they might configure their MSA to reject all message submissions that do not come from authorized users, with authorization based on either the authenticated identity or the submitting endpoint being within a protected IP environment.


NOTE: It is better to reject a message than to risk sending one that is damaged. This is especially true for problems that are correctable by the MUA, for example, an invalid 'From' field.


If an MSA is not able to determine a return path to the submitting user, from a valid MAIL FROM, a valid source IP address, or based on authenticated identity, then the MSA SHOULD immediately reject the message. A message can be immediately rejected by returning a 550 code to the MAIL command.

MSAが有効なMAIL FROM、有効な送信元IPアドレスから、または認証されたIDに基づいて、送信ユーザーへのリターンパスを決定できない場合、MSAは直ちにメッセージを拒否する必要があります(SHOULD)。 550コードをMAILコマンドに返すことにより、メッセージをすぐに拒否できます。

Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST NOT, in itself, be cause for rejecting a message. (MUAs need to generate null return-path messages for a variety of reasons, including disposition notifications.)

NULLの戻りパス、つまりMAIL FROM:<>は許可されており、それ自体がメッセージを拒否する原因となってはならないことに注意してください。 (MUAは、廃棄通知を含むさまざまな理由でnullの戻りパスメッセージを生成する必要があります。)

Except in the case where the MSA is unable to determine a valid return path for the message being submitted, text in this specification that instructs an MSA to issue a rejection code MAY be complied with by accepting the message and subsequently generating a bounce message. (That is, if the MSA is going to reject a message for any reason except being unable to determine a return path, it can optionally do an immediate rejection or accept the message and then mail a bounce.)

MSAが送信されるメッセージの有効なリターンパスを決定できない場合を除いて、MSAに拒否コードを発行するように指示するこの仕様のテキストは、メッセージを受け入れて、その後バウンスメッセージを生成することによって遵守される場合があります。 (つまり、MSAが戻りパスを決定できないことを除いて何らかの理由でメッセージを拒否する場合、オプションで即時拒否を行うか、メッセージを受け入れて、バウンスをメールで送信できます。)

NOTE: In the normal case of message submission, immediately rejecting the message is preferred, as it gives the user and MUA direct feedback. To properly handle delayed bounces, the client MUA needs to maintain a queue of messages it has submitted and match bounces to them. Note that many contemporary MUAs do not have this capability.


3.3. Authorized Submission
3.3. 許可された提出

Numerous methods have been used to ensure that only authorized users are able to submit messages. These methods include authenticated SMTP, IP address restrictions, secure IP and other tunnels, and prior POP authentication.


Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It allows the MSA to determine an authorization identity for the message submission, one that is not tied to other protocols.

Authenticated SMTP [SMTP-AUTH]は広く普及しています。これにより、MSAは他のプロトコルに関連付けられていない、メッセージ送信の承認IDを決定できます。

IP address restrictions are very widely implemented, but they do not allow for travelers and similar situations, and they can be easily spoofed unless all transport paths between the MUA and MSA are trustworthy.


Secure IP [IPSEC], and other encrypted and authenticated tunneling techniques, can also be used and provide additional benefits of protection against eavesdropping and traffic analysis.

セキュアIP [IPSEC]、および他の暗号化および認証されたトンネリング技術も使用でき、盗聴およびトラフィック分析に対する保護の追加の利点を提供します。

Requiring a POP [POP3] authentication (from the same IP address) within some amount of time (e.g., 20 minutes) prior to the start of a message submission session has also been used, but this does impose restrictions on clients as well as servers, which may cause difficulties. Specifically, the client must do a POP authentication before an SMTP submission session, and not all clients are capable and configured for this. Also, the MSA must coordinate with the POP server, which may be difficult. There is also a window during which an unauthorized user can submit messages and appear to be a previously authorized user. Since it is dependent on the MUA's IP addresses, this technique is substantially as subject to IP address spoofing as validation based on known IP addresses alone (see above).

メッセージ送信セッションの開始前の一定時間内(たとえば、20分)にPOP [POP3]認証を要求する(同じIPアドレスから)ことも使用されていますが、これによりクライアントとサーバーに制限が課されます、問題が発生する可能性があります。具体的には、クライアントはSMTP送信セッションの前にPOP認証を行う必要があり、すべてのクライアントがこれに対応して構成されているわけではありません。また、MSAはPOPサーバーと調整する必要があるため、難しい場合があります。また、許可されていないユーザーがメッセージを送信し、以前に許可されたユーザーのように見えるウィンドウもあります。 MUAのIPアドレスに依存しているため、この手法は、既知のIPアドレスのみに基づく検証(上記を参照)と同様に、実質的にIPアドレスのなりすましの影響を受けます。

4. Mandatory Actions
4. 必須のアクション

An MSA MUST do all of the following:


4.1. General Submission Rejection Code
4.1. 一般的な提出拒否コード

Unless covered by a more precise response code, response code 554 is to be used to reject a MAIL, RCPT, or DATA command that contains something improper.


4.2. Ensure All Domains Are Fully Qualified
4.2. すべてのドメインが完全に修飾されていることを確認する

The MSA MUST ensure that all domains in the SMTP envelope are fully qualified.


If the MSA examines or alters the message text in any way, except to add trace header fields [SMTP-MTA], it MUST ensure that all domains in address header fields are fully qualified.


Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command that contains improper domain references.


A frequent local convention is to accept single-level domains (e.g., 'sales') and then to expand the reference by adding the remaining portion of the domain name (e.g., to ''). Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains (e.g., 'squeaky.sales'), since such expansion is particularly risky.


4.3. Require Authentication
4.3. 認証が必要

The MSA MUST, by default, issue an error response to the MAIL command if the session has not been authenticated using [SMTP-AUTH], unless it has already independently established authentication or authorization (such as being within a protected subnetwork).


Section 3.3 discusses authentication mechanisms.


Reply code 530 [SMTP-AUTH] is used for this purpose.

この目的のために、応答コード530 [SMTP-AUTH]が使用されます。

5. Recommended Actions
5. 推奨されるアクション

The MSA SHOULD do all of the following.


5.1. Enforce Address Syntax
5.1. アドレス構文を適用

An MSA SHOULD reject messages with illegal syntax in a sender or recipient SMTP envelope address.


If the MSA examines or alters the message text in any way, except to add trace header fields, it SHOULD reject messages with illegal address syntax in address header fields.


Reply code 501 is to be used to reject a MAIL or RCPT command that contains a detectably improper address.


When addresses are resolved after submission of the message body, reply code 554 (with a suitable enhanced status code from [SMTP-CODES]) is used after end-of-data, if the message contains invalid addresses in the header.


5.2. Log Errors
5.2. エラーのログ

The MSA SHOULD log message errors, especially apparent misconfigurations of client software.

MSA SHOULDは、メッセージエラー、特にクライアントソフトウェアの明らかな設定ミスをログに記録する必要があります(SHOULD)。

It can be very helpful to notify the administrator when problems are detected with local mail clients. This is another advantage of distinguishing submission from relay: system administrators might be interested in local configuration problems, but not in client problems at other sites.


Note that it is important to impose limits on such logging to prevent certain forms of denial-of-service (DoS) attacks.


5.3. Apply Shorter Timeouts
5.3. 短いタイムアウトを適用する

The timeouts specified in Section of RFC 5321 [SMTP-MTA] are designed to deal with the many types of situations that can be encountered on the public Internet. The relationship among clients and servers corresponding to this specification is typically much closer and more predictable. Submission clients behave differently from relay client in some areas, especially tolerance for timeouts. In practice, message submission clients tend to have short timeouts (perhaps 2-5 minutes for a reply to any command). Submission servers SHOULD respond to any command (even DATA) in fewer than 2 minutes.

RFC 5321 [SMTP-MTA]のセクション4.5.3.2で指定されているタイムアウトは、公衆インターネットで発生する可能性があるさまざまな状況に対処するように設計されています。この仕様に対応するクライアントとサーバー間の関係は、通常、より密接で予測可能です。送信クライアントは、一部の領域、特にタイムアウトの許容度において、リレークライアントとは異なる動作をします。実際には、メッセージ送信クライアントのタイムアウトは短い傾向があります(コマンドへの応答には、おそらく2〜5分です)。送信サーバーは、2分未満でコマンド(DATAを含む)に応答する必要があります(SHOULD)。

When the submission server has a close administrative and/or network relationship with the submission client(s) -- e.g., with a webmail interface calling on a tightly bound submission server -- mutual agreement on much shorter timeouts MAY be appropriate.


6. Optional Actions
6. オプションのアクション

The MSA MAY do any of the following.


6.1. Enforce Submission Rights
6.1. 提出権の行使

The MSA MAY issue an error response to a MAIL command if the address in MAIL FROM appears to have insufficient submission rights or is not authorized with the authentication used (if the session has been authenticated).

MSAは、MAIL FROMのアドレスに送信権限が不十分であるか、使用されている認証で認証されていない場合(セッションが認証されている場合)、MAILコマンドにエラー応答を発行する場合があります。

Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.


6.2. Enforce Permissions
6.2. 権限を適用する

The MSA MAY issue an error response to a RCPT command if inconsistent with the permissions given to the user (if the session has been authenticated).


Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.


6.3. Check Message Data
6.3. メッセージデータの確認

The MSA MAY issue an error response to the DATA command or send a failure result after end-of-data if the submitted message is syntactically invalid, seems inconsistent with permissions given to the user (if known), or violates site policy in some way.


Reply code 554 is used for syntactic problems in the data. Reply code 501 is used if the command itself is not syntactically valid. Reply code 550 with an appropriate enhanced status code per [SMTP-CODES] (such as 5.7.1) is used to reject based on the submitting user. Reply code 550 with an appropriate enhanced status code (such as 5.7.0) is used if the message violates site policy.

応答コード554は、データの構文上の問題に使用されます。コマンド自体が構文的に有効でない場合は、応答コード501が使用されます。 [SMTP-CODES]ごとに適切な拡張ステータスコードを含む応答コード550(5.7.1など)を使用して、送信ユーザーに基づいて拒否します。メッセージがサイトポリシーに違反している場合は、適切な拡張ステータスコード(5.7.0など)を含む応答コード550が使用されます。

6.4. Support for the Postmaster Address
6.4. ポストマスターアドレスのサポート

If appropriate under local conditions and to facilitate conformance with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit a reduced degree of authentication for mail addressed to the "postmaster" (or one of its alternate spelling forms, see


[SMTP-MTA]), in one or more domains, as compared to requirements enforced for other addresses. Among other benefits, this provides an address of last resort that can be used by authorized users to report problems that otherwise prevent them from submitting mail.


6.5. Adjust Character Encodings
6.5. 文字エンコーディングを調整する

Subject to limits imposed by other protocols and specifications, the MSA MAY convert among character sets or string encodings to improve message usefulness, likelihood of delivery, or conformance with other specifications or recommendations. Such conversions MAY include, when necessary, replacement of addresses whose encoding does not conform to RFC 5321 with ones that do, using information available out of band.

MSAは、他のプロトコルや仕様によって課せられる制限に従い、文字セットまたは文字列エンコーディング間で変換して、メッセージの有用性、配信の可能性、または他の仕様や推奨事項への適合性を向上させることができます。そのような変換は、必要に応じて、帯域外で利用可能な情報を使用して、エンコーディングがRFC 5321に準拠していないアドレスの置換を含む場合があります。

7. Interaction with SMTP Extensions
7. SMTP拡張機能との相互作用

The following table lists Standards Track and Experimental SMTP extensions whose documents do not explicitly specify their applicability to this protocol. Listed are the EHLO keyword, name, an indication as to the use of the extension on the submit port, and a reference.

次の表に、このプロトコルへの適用性を明示的に指定していないドキュメントの標準トラックと実験的なSMTP拡張機能を示します。 EHLOキーワード、名前、送信ポートでの拡張機能の使用に関する指示、および参照がリストされています。

| Keyword            | Name                 |Sub-    | Reference       |
|                    |                      |mission |                 |
|PIPELINING          |Pipelining            |SHOULD  |[PIPELINING]     |
|ETRN                |Extended Turn         |MUST NOT|[ETRN]           |
|   ...              |Extended Codes        |SHOULD  |[SMTP-CODES]     |
|DSN                 |Delivery Status       |SHOULD  |[DSN]            |
|                    |  Notification        |        |                 |
|SIZE                |Message size          |MAY     |[SIZE]           |
|   ...              |521 reply code        |MUST NOT|[REPLY-521]      |
|CHECKPOINT          |Checkpoint/Restart    |MAY     |[CHECKPOINT]     |
|BINARYMIME          |Binary MIME           |MAY     |[CHUNKING]       |
|CHUNKING            |Chunking              |MAY     |[CHUNKING]       |
|8BITMIME            |Use 8-bit data        |SHOULD  |[RFC6152]        |
|AUTH                |Authentication        |MUST    |[SMTP-AUTH]      |
|STARTTLS            |Start TLS             |MAY     |[START-TLS]      |
|NO-SOLICITING       |Notification of       |MAY     |[RFC3865]        |
|                    |  no soliciting       |        |                 |
|MTRK                |Message Tracking      |MAY     |[MSG-TRACK]      |
|ATRN                |On-Demand Relay       |MUST NOT|[RFC2645]        |
|DELIVERBY           |Deliver By            |MAY     |[RFC2852]        |
|CONPERM             |Content Conversion    |MAY     |[RFC4141]        |
|                    |  Permission          |        |                 |
|CONNEG              |Content Conversion    |MAY     |[RFC4141]        |
|                    |  Negotiation         |        |                 |
                             Table 1

Future SMTP extensions SHOULD explicitly specify if they are valid on the Submission port.


Some SMTP extensions are especially useful for message submission:


Extended Status Codes [SMTP-CODES] SHOULD be supported and used according to [CODES-EXTENSION]. This permits the MSA to notify the client of specific configuration or other problems in more detail than the response codes listed in this memo. Because some rejections are related to a site's security policy, care should be used not to expose more detail to unauthenticated senders than is needed.


[PIPELINING] SHOULD be supported by the MSA.

[パイプライン] MSAでサポートされている必要があります。

[SMTP-AUTH] allows the MSA to validate the authority and determine the identity of the submitting user and MUST be supported by the MSA.


[START-TLS] is the most widely used mechanism, at the time this document was written, that allows the MUA and MSA to protect message submission integrity and privacy.


Any references to the DATA command in this memo also refer to any substitutes for DATA, such as the BDAT command used with [CHUNKING].


8. Message Modifications
8. メッセージの変更

Sites MAY modify submissions to ensure compliance with standards and site policy. This section describes a number of such modifications that are often considered useful.


NOTE: As a matter of guidance for local decisions to implement message modification, a paramount rule is to limit such actions to remedies for specific problems that have clear solutions. This is especially true with address elements. For example, indiscriminately appending a domain to an address or element that lacks one typically results in more broken addresses. An unqualified address must be verified to be a valid local part in the domain before the domain can be safely added.


Any message forwarded or delivered by the MSA MUST conform to the requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements permitted by extensions that are supported by the MSA and accepted by the next-hop server.


Message modification can affect the validity of an existing message signature, such as by DomainKeys Identified Mail (DKIM) [DKIM], Pretty Good Privacy (PGP) [RFC4880], or Secure MIME (S/MIME) [RFC5751], and can render the signature invalid. This, in turn, can affect message handling by later receivers, such as filtering engines that consider the presence or absence of a valid signature.

メッセージの変更は、DomainKeys Identified Mail(DKIM)[DKIM]、Pretty Good Privacy(PGP)[RFC4880]、Secure MIME(S / MIME)[RFC5751]などによる既存のメッセージ署名の有効性に影響を与え、レンダリングできる署名が無効です。これは、有効な署名の有無を考慮するフィルタリングエンジンなど、後の受信者によるメッセージ処理に影響を与える可能性があります。

8.1. Add 'Sender'
8.1. 「送信者」を追加

The MSA MAY add or replace the 'Sender' field, if the identity of the sender is known and this is not given in the 'From' field.


The MSA MUST ensure that any address it places in a 'Sender' field is, in fact, a valid mail address.


8.2. Add 'Date'
8.2. 「日付」を追加

The MSA MAY add a 'Date' field to the submitted message, if it lacks it, or correct the 'Date' field if it does not conform to [MESSAGE-FORMAT] syntax.


8.3. Add 'Message-ID'
8.3. 「メッセージID」を追加

The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note that a number of clients still do not generate 'Message-ID' fields.


8.4. Transfer Encode
8.4. 転送エンコード

The MSA MAY apply transfer encoding to the message according to MIME conventions, if needed and not harmful to the MIME type.


8.5. Sign the Message
8.5. メッセージに署名する

The MSA MAY (digitally) sign or otherwise add authentication information to the message.


8.6. Encrypt the Message
8.6. メッセージを暗号化する

The MSA MAY encrypt the message for transport to reflect organizational policies.


NOTE: To be useful, the addition of a signature and/or encryption by the MSA generally implies that the connection between the MUA and MSA must, itself, be secured in some other way, for example, by operating inside of a secure environment, by securing the submission connection at the transport layer, or by using an [SMTP-AUTH] mechanism that provides for session integrity.


8.7. Resolve Aliases
8.7. エイリアスを解決

The MSA MAY resolve and rewrite aliases (e.g., Canonical Name (CNAME) records) for domain names, in the SMTP envelope and/or in address fields of the header, subject to local policy.

MSAは、ローカルポリシーに従い、SMTPエンベロープ内および/またはヘッダーのアドレスフィールド内のドメイン名のエイリアス(Canonical Name(CNAME)レコードなど)を解決して書き換えることができます(MAY)。

NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in addresses and the session-opening announcement. As with other SMTP requirements, RFC 5321 effectively prohibits an MSA from forwarding such messages into the public Internet. Nonetheless, unconditionally resolving aliases could be harmful. For example, if and are both aliases for, rewriting them could lose useful information.

注:SMTP [SMTP-MTA]は、アドレスおよびセッション開始アナウンスでのドメイン名エイリアスの使用を禁止します。他のSMTP要件と同様に、RFC 5321は、MSAがそのようなメッセージを公衆インターネットに転送することを事実上禁止しています。それにもかかわらず、無条件にエイリアスを解決すると有害になる可能性があります。たとえば、www.example.netとftp.example.netが両方ともmail.example.netのエイリアスである場合、それらを書き換えると有用な情報が失われる可能性があります。

8.8. Header Rewriting
8.8. ヘッダーの書き換え

The MSA MAY rewrite local parts and/or domains in the SMTP envelope and, optionally, in address fields of the header, according to local policy. For example, a site may prefer to rewrite 'JRU' as 'J.Random.User' in order to hide login names and/or to rewrite '' as '' to hide machine names and make it easier to move users.


However, only addresses, local-parts, or domains that match specific local MSA configuration settings should be altered. It would be very dangerous for the MSA to apply data-independent rewriting rules, such as always deleting the first element of a domain name. So, for example, a rule that strips the leftmost element of the domain, if the complete domain matches '*', would be acceptable.

ただし、特定のローカルMSA構成設定に一致するアドレス、ローカルパーツ、またはドメインのみを変更する必要があります。 MSAがドメイン名の最初の要素を常に削除するなど、データに依存しない書き換えルールを適用することは非常に危険です。したがって、たとえば、完全なドメインが「*」に一致する場合、ドメインの左端の要素を削除するルールは許容されます。

The MSA MUST NOT rewrite a forward-pointing (destination) address in a way that violates the constraints of [SMTP-MTA] on modifications of local-parts. Changes to addressing and encoding, carried out in conjunction with the action of Section 6.5, do not violate this principle if the MSA has sufficient information available to successfully and accurately apply the substitution.

MSAは、ローカルパーツの変更に関する[SMTP-MTA]の制約に違反する方法で、フォワードポインティング(宛先)アドレスを書き換えてはなりません(MUST NOT)。セクション6.5のアクションに関連して実行されるアドレッシングとエンコードの変更は、MSAが置換を正常かつ正確に適用するために利用できる十分な情報を持っている場合、この原則に違反しません。

9. Security Considerations
9. セキュリティに関する考慮事項

Separation of submission and relay of messages allows a site to implement different policies for the two types of services, including requiring the use of additional security mechanisms for one or both. It can do this in a way that is simpler, both technically and administratively. This increases the likelihood that policies will be applied correctly.


Separation also can aid in tracking and preventing unsolicited bulk email.


For example, a site could configure its mail servers such that the MSA requires authentication before accepting a message, and the MTA rejects all RCPT commands for non-local users. This can be an important element in a site's total email security policy.


If a site fails to require any form of authorization for message submissions (see Section 3.3 for discussion), it is allowing open use of its resources and name; unsolicited bulk email can be injected using its facilities.


Section 3 includes further discussion of issues with some authentication methods.


Section 5.2 includes a cautionary note that unlimited logging can enable certain forms of denial-of-service attacks.


10. IANA Considerations
10. IANAに関する考慮事項

The entries in Table 1 have been corrected (reference for NO-SOLICITING) and extended (ATRN, DELIVERBY, CONPERM, and CONNEG). The "SMTP Service Extensions" registry has been updated to reflect the changed and new entries. Entries in the registry that do not appear in the table above are correct and should not be altered.

表1のエントリは修正され(NO-SOLICITINGのリファレンス)、拡張されました(ATRN、DELIVERBY、CONPERM、およびCONNEG)。 「SMTP Service Extensions」レジストリが更新され、変更されたエントリと新しいエントリが反映されました。上記の表に記載されていないレジストリのエントリは正しいため、変更しないでください。

The entry in the "SMTP Service Extensions" registry for RFC 4409 has been updated to reference this document. The original reference for Submit (RFC 2476), which should have been corrected earlier, has also been updated to point to this document.

RFC 4409の「SMTPサービス拡張」レジストリのエントリは、このドキュメントを参照するように更新されました。以前に修正されていた送信(RFC 2476)の元の参照も、このドキュメントを指すように更新されました。

The entry in the "Service Name and Transport Protocol Port Number Registry" for port 587 has been updated to point to this document.


11. Acknowledgments
11. 謝辞

The preparation and development of the current version of this specification was stimulated by discussions in the IETF YAM and EAI Working Groups. Dave Crocker, Subramanian Moonesamy, Barry Leiba, John Levine, and others provided text that appeared in this document or versions leading up to it.

この仕様の現在のバージョンの準備と開発は、IETF YAMおよびEAIワーキンググループでの議論に刺激されました。 Dave Crocker、Subramanian Moonesamy、Barry Leiba、John Levineなどが、このドキュメントに登場するテキスト、またはそれ以前のバージョンを提供しました。

Nathaniel Borenstein and Barry Leiba were instrumental in the development of RFC 4409, the update to RFC 2476.

ナサニエルボレンシュタインとバリーレイバは、RFC 2476の更新であるRFC 4409の開発に尽力しました。

The original memo (RFC 2476) was developed, in part, based on comments and discussions that took place on and off the IETF-Submit mailing list. The help of those who took the time to review that document and make suggestions is appreciated, especially that of Dave Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.

元のメモ(RFC 2476)は、IETF-Submitメーリングリストの内外で行われたコメントと議論に一部基づいて作成されました。時間をかけてそのドキュメントをレビューし、提案を行った人々、特にデイブクロッカー、ネッドフリード、キースムーア、ジョンマイヤーズ、およびクリスニューマンに感謝します。

Special thanks to Harald Alvestrand, who got this effort started.

この取り組みを始めてくれたHarald Alvestrand氏に特に感謝します。

12. References
12. 参考文献
12.1. Normative References
12.1. 引用文献

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[SMTP-AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

[SMTP-AUTH] Siemborski、R。およびA. Melnikov、「認証用のSMTPサービス拡張」、RFC 4954、2007年7月。

[SMTP-MTA] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[SMTP-MTA] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。

12.2. Informative References
12.2. 参考引用

[CHECKPOINT] Crocker, D. and N. Freed, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.

[チェックポイント]クロッカーD.およびN.フリード、「チェックポイント/再起動用のSMTPサービス拡張」、RFC 1845、1995年9月。

[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.

[CHUNKING] Vaudreuil、G。、「SMTP Service Extensions for Transmission of Large and Binary MIME Messages」、RFC 3030、2000年12月。

[CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.

[CODES-EXTENSION] Freed、N。、「拡張エラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。

[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.

[DKIM] Crocker、D.、Hansen、T。、およびM. Kucherawy、「DomainKeys Identified Mail(DKIM)Signatures」、RFC 6376、2011年9月。

[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

[DSN] Moore、K。、「Simple Mail Transfer Protocol(SMTP)Service Extension for Delivery Status Notifications(DSNs)」、RFC 3461、2003年1月。

[ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.

[ETRN] De Winter、J。、「リモートメッセージキュー開始用のSMTPサービス拡張」、RFC 1985、1996年8月。

[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、2003年3月。

[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[IPSEC] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。

[MESSAGE-FORMAT] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

[MESSAGE-FORMAT] Resnick、P。、編、「インターネットメッセージフォーマット」、RFC 5322、2008年10月。

[MSG-TRACK] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.

[MSG-TRACK] Allman、E.、T。Hansen、「SMTP Service Extension for Message Tracking」、RFC 3885、2004年9月。

[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.

[PIPELINING] Freed、N。、「コマンドパイプライン処理用のSMTPサービス拡張」、STD 60、RFC 2920、2000年9月。

[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

[POP3]マイヤーズ、J。およびM.ローズ、「Post Office Protocol-Version 3」、STD 53、RFC 1939、1996年5月。

[REPLY-521] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995.

[REPLY-521] Durand、A。およびF. Dupont、「SMTP 521 Reply Code」、RFC 1846、1995年9月。

[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999.

[RFC2645] Gellens、R。、「動的IPアドレスを使用したオンデマンドメールリレー(ODMR)SMTP」、RFC 2645、1999年8月。

[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.

[RFC2852]ニューマン、D。、「SMTPサービス拡張による配信」、RFC 2852、2000年6月。

[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004.

[RFC3865] Malamud、C。、「No Soliciting Simple Mail Transfer Protocol(SMTP)Service Extension」、RFC 3865、2004年9月。

[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion", RFC 4141, November 2005.

[RFC4141] Toyoda、K. and D. Crocker、 "SMTP and MIME Extensions for Content Conversion"、RFC 4141、2005年11月。

[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、2007年11月。

[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions(S / MIME)Version 3.2 Message Specification」、RFC 5751、2010年1月。

[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

[RFC6152] Klensin、J.、Freed、N.、Rose、M。、およびD. Crocker、「8ビットMIMEトランスポート用のSMTPサービス拡張」、STD 71、RFC 6152、2011年3月。

[SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.

[サイズ] Klensin、J.、Freed、N。、およびK. Moore、「メッセージサイズ宣言のためのSMTPサービス拡張」、STD 10、RFC 1870、1995年11月。

[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

[SMTP-CODES] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。

[START-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

[START-TLS]ホフマン、P。、「トランスポート層セキュリティを介したセキュアなSMTPのためのSMTPサービス拡張」、RFC 3207、2002年2月。

Appendix A. Major Changes from RFC 4409
付録A. RFC 4409からの主な変更点

The protocol specified by this document is not substantively different from that of RFC 4409. However, the present specification contains several clarifications and updates to reflect changes and revisions to other documents subsequent to the publication of RFC 4409. The following specific changes may be of interest to some readers.

このドキュメントで指定されているプロトコルは、RFC 4409のプロトコルと実質的に違いはありません。ただし、本仕様には、RFC 4409の公開に続く他のドキュメントの変更や改訂を反映するために、いくつかの明確化と更新が含まれています。次の特定の変更が興味深いかもしれません一部の読者に。

o Updated several references to reflect more recent versions of the various specifications. As part of this, reclassified RFC 4954 to a normative reference (SMTP AUTH is a MUST for RFC 4409 and this specification).

o さまざまな仕様のより新しいバージョンを反映するために、いくつかの参照を更新しました。この一環として、RFC 4954を規範的な参照に再分類しました(SMTP AUTHはRFC 4409とこの仕様の必須項目です)。

o Updated the text in Section 7 to reflect the existence and partial population of the registry and the included table (Table 1) to correct one entry and add others. See Section 10 for more information.

o レジストリの存在と部分的な人口を反映するためにセクション7のテキストを更新し、1つのエントリを修正して他のエントリを追加するために含まれるテーブル(表1)を反映しました。詳細については、セクション10を参照してください。

o Added new text (Section 5.3) to clarify that Submission Servers should respond quickly.

o Submission Serverが迅速に応答する必要があることを明確にするために、新しいテキスト(セクション5.3)を追加しました。

o Added text to make it explicit that character encoding changes are permitted.

o 文字エンコーディングの変更が許可されていることを明示するためにテキストを追加しました。

o Added text to make it clear that modifications to signed messages may cause problems and that they should be carefully considered.

o 署名付きメッセージに変更を加えると問題が発生する可能性があり、慎重に検討する必要があることを明確にするためにテキストを追加しました。

Authors' Addresses


Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-2779 USA

Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego、CA 92121-2779 USA


John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA

John C Klensin 1770 Massachusetts Ave、#322 Cambridge、MA 02140 USA

   Phone: +1 617 491 5735