Simple Mail Transfer Protocol

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

Simple Mail Transfer ProtocolSMTP)は、電子メール送信用インターネット標準 通信プロトコルです。メールサーバーやその他のメッセージ転送エージェントは、SMTPを使用してメールメッセージを送受信します。ユーザーレベルの電子メールクライアントは通常、中継のためにメールサーバーにメッセージを送信するためにのみSMTPを使用し、RFC8314に従ってポート587または465でメールサーバーに送信電子メールを送信ますメッセージを取得するために、IMAP (古いPOP3を置き換えた)が標準ですが、プロプライエタリサーバーは、 ExchangeActiveSyncなどのプロプライエタリプロトコルも実装することがよくあります。 

1981年のSMTPの導入以来、SMTPは何度も更新、変更、拡張されてきました。現在一般的に使用されているプロトコルバージョンは、認証暗号化、バイナリデータ転送、および国際化された電子メールアドレスのさまざまな拡張機能を備えた拡張可能な構造を備えていますSMTPサーバーは通常、ポート番号25(プレーンテキストの場合)および587(暗号化された通信の場合)で 伝送制御プロトコルを使用します。

歴史

SMTPの前身

1960年代には、さまざまな形式の1対1の電子メッセージングが使用されていました。ユーザーは、特定のメインフレームコンピューター用に開発されたシステムを使用して通信しました。特に米国政府のARPANETで相互接続されるコンピューターが増えるにつれ、異なるオペレーティングシステム間でメッセージを交換できるようにするための標準が開発されました。SMTPは、1970年代に開発されたこれらの標準から発展しました。

SMTPは、1971年に説明された2つの実装にそのルーツをたどります。メールボックスプロトコル(実装については異議が唱えられていますが[2]) 、 RFC 196およびその他のRFCで説明されています。またSNDMSGプログラムは、 RFC 2235によると、BBNは、 TENEXコンピュータがARPANETを介してメールメッセージを送信するために発明されました。 [3] [4] [5]この時点で、50未満のホストがARPANETに接続されていました。[6]  

さらなる実装には、両方とも1973年からのFTPメール[7]とメールプロトコルが含まれます。[8]開発作業は、ARPANETが1980年頃に現代のインターネットに移行するまで、1970年代を通して続けられました。

オリジナルSMTP

1980年、JonPostelはRFC772公開しました。これは、メールのファイル転送プロトコル(FTP)の使用に代わるものとしてメール転送プロトコルを提案しました。1981年5月のRFC780は、FTPへのすべての参照を削除し、 TCPおよびUDPにポート57を割り当てました[要出典] 、その後IANAによって削除されました1981年11月、PostelはRFC788「SimpleMailTransferProtocol」を公開しまし   

SMTP標準は、いくつかの類似点がある1対多の通信ネットワークであるUsenetとほぼ同時期に開発されました。[要出典]

SMTPは1980年代初頭に広く使用されるようになりました。当時、これはUnix to Unix Copy Program(UUCP)を補完するものであり、断続的に接続されたマシン間の電子メール転送を処理するのに適していました。一方、SMTPは、送信側と受信側の両方のマシンが常にネットワークに接続されている場合に最適に機能します。どちらもストアアンドフォワードメカニズムを使用しており、プッシュテクノロジーの例です。Usenetのニュースグループは依然としてサーバー間でUUCPを使用して伝播されていましたが、[9]メールトランスポートとしてのUUCPは、メッセージルーティングヘッダーとして使用されていた「バングパス」とともに事実上消滅しました[10] 。[11]

1981年11月にRFC788が公開された直後の1982年に4.1cBSDでリリースされたSendmailは、 SMTPを実装した最初のメール転送エージェントの1つでした。[12] BSD Unixがインターネット上で最も人気のあるオペレーティングシステムになるにつれて、Sendmailは最も一般的なMTA(メール転送エージェント)になりました。[13] 

元のSMTPプロトコルは、認証されていない暗号化されていない7ビットASCIIテキスト通信のみをサポートし、些細な中間者攻撃なりすましスパムの影響を受けやすく、送信前にバイナリデータを読み取り可能なテキストにエンコードする必要がありました。適切な認証メカニズムがないため、設計上、すべてのSMTPサーバーはオープンメールリレーでした。インターネットメールコンソーシアム( IMC )は、メールサーバーの55%が1998年にオープンリレーであったと報告しましたが[ 14 ] 2002年には1%未満でした オリジナルのSMTPをインターネットでの一般的な使用には本質的に非実用的にします。

最新のSMTP

1995年11月、RFC 1869は拡張簡易メール転送プロトコル(ESMTP)を定義しました。これは、元のSMTPにない機能を追加することを目的とした、既存および将来のすべての拡張機能の一般的な構造を確立しました。ESMTPは、ESMTPクライアントとサーバーを識別し、サーバーがサポートされている拡張機能を示すことができる、一貫性のある管理可能な手段を定義します。  

メッセージ送信(RFC 2476)とSMTP-AUTHRFC 2554)は、1998年と1999年に導入され、どちらも電子メール配信の新しいトレンドを説明しています。元々、SMTPサーバーは通常、組織の内部にあり、外部から組織宛てのメールを受信し、組織から外部にメッセージを中継していましたしかし、時が経つにつれて、SMTPサーバー(メール転送エージェント)は、実際には、メールユーザーエージェントのメッセージ送信エージェントになるためにその役割を拡大し、その一部は現在、外部からメールを中継していました。  組織の。(たとえば、会社の幹部が会社のSMTPサーバーを使用して旅行中に電子メールを送信したい場合。)この問題は、World Wide Webの急速な拡大と人気の結果であり、 SMTPにはメールを中継するための特定のルールと方法を含める必要がありました。迷惑メール(スパム)の中継などの悪用を防ぐためにユーザーを認証します。メッセージ送信に取り組む(RFC 2476 )は元々、一般的なメールサーバーが、修飾されていないアドレスにドメイン名を追加するなど、メールの問題を修正するためにメールを書き換えることが多かったために開始されました。この動作は、修正中のメッセージが最初の送信である場合に役立ちますが、メッセージが他の場所から発信されて中継されている場合は危険で有害です。メールを送信とリレーに明確に分離することは、リレーの書き換えを禁止しながら、送信の書き換えを許可および奨励する方法と見なされていました。スパムが蔓延するにつれ、組織から送信されるメールの承認とトレーサビリティを提供する方法としても見られていました。このリレーと送信の分離は、すぐに最新の電子メールセキュリティ慣行の基盤になりました。

このプロトコルは純粋にASCIIテキストベースで始まったため、バイナリファイル、または多くの英語以外の言語の文字をうまく処理できませんでした。多目的インターネットメール拡張機能(MIME)などの標準は、SMTPを介して転送するためのバイナリファイルをエンコードするために開発されました。Sendmailの後に開発されたメール転送エージェント(MTA)も8ビットクリーンで実装される傾向があったため、代替の「8ビット送信」戦略を使用して任意のテキストデータを送信できます(8ビットASCIIのような文字エンコード) SMTP経由。メールアドレス自体はASCIIのみを許可していましたが、ベンダー間で文字セットマッピングが異なるため、文字化けは依然として問題でした。今日の8ビットクリーンMTAは8BITMIME拡張をサポートする傾向があり、一部のバイナリファイルをプレーンテキストとほぼ同じくらい簡単に送信できます(行の長さの制限と許可されたオクテット値が引き続き適用されるため、ほとんどの非テキストにはMIMEエンコーディングが必要ですデータといくつかのテキスト形式)。2012年に、SMTPUTF8拡張機能はUTF-8テキストをサポートするために作成され、キリル文字中国語などの非ラテン文字で国際的なコンテンツとアドレスを使用できるようになりました。

多くの人々がコアSMTP仕様に貢献しました。その中には、Jon PostelEric Allman、Dave Crocker、Ned Freed、Randall Gellens、John KlensinKeithMooreなどがあります。

メール処理モデル

青い矢印は、SMTPバリエーションの実装を示しています

電子メールは、メールクライアント(メールユーザーエージェント、MUA)によってTCPポート587でSMTPを使用してメールサーバー(メール送信エージェント、MSA)に送信されます。ほとんどのメールボックスプロバイダーは、従来のポート25での送信を引き続き許可します。MSAはメールをメール転送エージェント(メール転送エージェント、MTA)。多くの場合、これら2つのエージェントは、同じマシン上で異なるオプションを使用して起動された同じソフトウェアのインスタンスです。ローカル処理は、単一のマシンで実行することも、複数のマシンに分割して実行することもできます。 1台のマシンのメールエージェントプロセスはファイルを共有できますが、処理が複数のマシンで行われる場合、SMTPを使用して相互にメッセージを転送します。各マシンは、次のマシンを次のマシンとして使用するように構成されています。スマートホスト各プロセスは、それ自体がMTA(SMTPサーバー)です。

境界MTAは、DNSを使用して、受信者のドメイン(の右側の電子メールアドレスの一部)のMX(メールエクスチェンジャー)レコードを検索しますMXレコードには、ターゲットMTAの名前が含まれています。ターゲットホストおよびその他の要因に基づいて、送信側MTAは受信者サーバーを選択し、それに接続してメール交換を完了します。 @

メッセージ転送は、2つのMTA間の単一の接続で、または中間システムを介した一連のホップで発生する可能性があります。受信SMTPサーバーは、最終的な宛先、中間の「リレー」(つまり、メッセージを保存および転送する)、または「ゲートウェイ」(つまり、SMTP以外のプロトコルを使用してメッセージを転送する)の場合があります。RFC 5321セクション2.1によると、各ホップはメッセージに対する責任の正式な受け渡しであり、受信サーバーはメッセージを配信するか、配信の失敗を適切に報告する必要があります。  

ファイナルホップは着信メッセージを受け入れると、ローカル配信のためにメール配信エージェント(MDA)にメッセージを渡します。MDAは、関連するメールボックス形式でメッセージを保存します。送信と同様に、この受信は1台または複数のコンピューターを使用して実行できますが、上の図では、MDAはメールエクスチェンジャーボックスの近くに1つのボックスとして示されています。MDAは、メッセージをストレージに直接配信するか、 SMTPまたはこの目的のために設計されたSMTPの派生物である ローカルメール転送プロトコル(LMTP)などの他のプロトコルを使用してネットワーク経由で転送する場合があります。

ローカルメールサーバーに配信されると、メールは認証されたメールクライアント(MUA)によるバッチ取得のために保存されます。メールは、メールへのアクセスを容易にし、保存されたメールを管理するプロトコルであるインターネットメッセージアクセスプロトコル(IMAP)、または通常は従来のmboxメールを使用するPost Office Protocol (POP)を使用して、電子メールクライアントと呼ばれるエンドユーザーアプリケーションによって取得されます。ファイル形式、またはMicrosoft Exchange / OutlookやLotusNotes / Dominoなどの独自のシステムWebメールクライアントはどちらの方法も使用できますが、取得プロトコルは正式な標準ではないことがよくあります。

SMTPは、メッセージの内容ではなく、メッセージの転送を定義します。したがって、メールエンベロープとそのパラメータ(エンベロープ送信者など)は定義されますが、ヘッダー(トレース情報を除く)やメッセージ自体の本文は定義されません。STD10RFC5321はSMTP(エンベロープ)を定義し、 STD11とRFC5322はメッセージ(ヘッダーと本文)を定義します。これは正式にはインターネットメッセージフォーマットと呼ばれます。   

プロトコルの概要

SMTPはコネクション型テキストベースのプロトコルであり、メール送信者はコマンド文字列を発行し、信頼できる順序付けられたデータストリームチャネル(通常は伝送制御プロトコル(TCP)接続)を介して必要なデータを提供することにより、メール受信者と通信します。SMTPセッションは、SMTPクライアント(開始エージェント、送信者、または送信者)によって発信されたコマンドと、SMTPサーバー(リスニングエージェント、または受信者)からの対応する応答で構成され、セッションが開かれ、セッションパラメーターが交換されます。セッションには、0個以上のSMTPトランザクションが含まれる場合があります。SMTPトランザクション 3つのコマンド/応答シーケンスで構成されます。

  1. MAILコマンド。リターンアドレスを確立します。これは、リターンパス、[17]リバースパス、[18] バウンスアドレス、mfrom、またはエンベロープセンダーとも呼ばれます。
  2. メッセージの受信者を確立するためのRCPTコマンド。このコマンドは、受信者ごとに1つずつ、複数回発行できます。これらのアドレスもエンベロープの一部です。
  3. メッセージテキストの開始を通知するDATA ; エンベロープではなく、メッセージの内容。これは、空の行で区切られたメッセージヘッダーメッセージ本文で構成されます。DATAは実際にはコマンドのグループであり、サーバーは2回応答します。1回目はDATAコマンド自体に応答してテキストを受信する準備ができていることを確認し、2回目はデータの終わりのシーケンスの後に受け入れまたは拒否します。メッセージ全体。

DATAの中間応答に加えて、各サーバーの応答は正(2xx応答コード)または負のいずれかになります。否定的な返信は、永続的(5xxコード)または一時的(4xxコード)になります。拒否は永続的な障害であり、クライアントはそれを受信したサーバーにバウンスメッセージを送信する必要があります。ドロップは肯定的な応答であり、配信ではなくメッセージの破棄が続きます。

開始ホストであるSMTPクライアントは、メールユーザーエージェント(MUA)として機能的に識別されるエンドユーザーの電子メールクライアント、またはSMTPクライアントとして機能するSMTPサーバーであるリレーサーバーのメール転送エージェント(MTA)のいずれかです。 、関連するセッションで、メールを中継するため。完全に機能するSMTPサーバーは、一時的な障害の原因となったメッセージ送信を再試行するためのメッセージのキューを維持します。

MUAは、その構成から送信メールSMTPサーバーを認識します。リレーサーバーは通常、各受信者のドメイン名のMX(Mail eXchange)DNSリソースレコードを検索することにより、接続するサーバーを決定しますMXレコードが見つからない場合は、準拠したリレーサーバー(すべてではない)が代わりにAレコードを検索します。スマートホストを使用するようにリレーサーバーを構成することもできますリレーサーバーは、SMTPの「既知のポート」でサーバーへのTCP接続を開始します。ポート25、またはMSAに接続する場合はポート587です。MTAとMSAの主な違いは、MSAに接続するにはSMTP認証

SMTPとメールの取得

SMTPは配信プロトコルのみです。通常の使用では、メールは到着時に宛先メールサーバー(またはネクストホップメールサーバー)に「プッシュ」されます。メールは、宛先の個々のユーザーではなく、宛先サーバーに基づいてルーティングされます。Post Office Protocol(POP)やInternet Message Access Protocol (IMAP)などの他のプロトコルは、メッセージを取得してメールボックスを管理する個々のユーザーが使用するために特別に設計されています断続的に接続されたメールサーバーがオンデマンドでリモートサーバーからメッセージをプルできるようにするために、SMTPには、リモートサーバーでメールキュー処理を開始する機能があります(リモートメッセージキューの開始を参照)。下)。POPとIMAPは、断続的に接続されたマシンでメールを中継するのに不適切なプロトコルです。これらは、メールリレーの正しい動作に不可欠な情報(「メールエンベロープ」)が削除されたときに、最終配信後に動作するように設計されています。

リモートメッセージキューの開始

リモートメッセージキューの開始により、リモートホストはサーバー上のメールキューの処理を開始できるため、対応するコマンドを送信することで、リモートホスト宛てのメッセージを受信できます。元のTURNコマンドは安全でないと見なされ、RFC 1985で、ドメインネームシステム情報に基づく認証方法を使用してより安全に動作するコマンドで拡張されました。[19] ETRN

送信メールSMTPサーバー

電子メールクライアントは、最初のSMTPサーバーのIPアドレスを知っている必要があり、これは構成の一部として指定する必要があります(通常はDNS名として指定します)。このサーバーは、ユーザーに代わって送信メッセージを配信します。

送信メールサーバーのアクセス制限

サーバー管理者は、どのクライアントがサーバーを使用できるかをある程度制御する必要があります。これにより、スパムなどの悪用に対処できます2つのソリューションが一般的に使用されています。

  • これまで、多くのシステムでは、クライアントの場所によって使用制限が課され、サーバー管理者が制御するIPアドレスを持つクライアントによる使用のみが許可されていました。他のクライアントIPアドレスからの使用は許可されていません。
  • 最新のSMTPサーバーは通常、アクセスを許可する前に資格情報によるクライアントの認証を必要とする代替システムを提供します。

場所によるアクセスの制限

このシステムでは、ISPのSMTPサーバーは、ISPのネットワーク外にいるユーザーによるアクセスを許可しません。より正確には、サーバーはISPから提供されたIPアドレスを持つユーザーにのみアクセスを許可する場合があります。これは、同じISPを使用してインターネットに接続していることを要求するのと同じです。モバイルユーザーは、通常のISP以外のネットワークに接続していることが多く、構成されたSMTPサーバーの選択肢にアクセスできなくなったため、電子メールの送信に失敗することがあります。

このシステムにはいくつかのバリエーションがあります。たとえば、組織のSMTPサーバーは、同じネットワーク上のユーザーにのみサービスを提供し、より広いインターネット上のユーザーによるアクセスをブロックするためにファイアウォールでこれを強制する場合があります。または、サーバーがクライアントのIPアドレスに対して範囲チェックを実行する場合があります。これらの方法は通常、組織内でのみ使用するアウトバウンドメール用のSMTPサーバーを提供する企業や大学などの機関で使用されていました。ただし、これらの機関のほとんどは、以下で説明するように、現在クライアント認証方式を使用しています。

ユーザーがモバイルで、さまざまなISPを使用してインターネットに接続する可能性がある場合、この種の使用制限は面倒であり、構成されたアウトバウンド電子メールSMTPサーバーアドレスを変更することは実用的ではありません。変更する必要のない電子メールクライアントの構成情報を使用できることが非常に望ましいです。

クライアント認証

最近のSMTPサーバーは通常、前述のように場所によるアクセスを制限するのではなく、アクセスを許可する前に資格情報によるクライアントの認証を必要とします。このより柔軟なシステムはモバイルユーザーにとって使いやすく、構成済みのアウトバウンドSMTPサーバーを固定的に選択できます。SMTP認証(SMTP AUTHと略されることが多い)は、認証メカニズムを使用してログインするためのSMTPの拡張です。

ポート

メールサーバー間の通信は、通常、SMTP用に指定され た標準のTCPポート25を使用します。

ただし、メールクライアントは通常、これを使用せず、代わりに特定の「送信」ポートを使用します。メールサービスは通常、次のいずれかのクライアントからの電子メール送信を受け入れます。

ポート2525などは、一部の個々のプロバイダーによって使用される場合がありますが、正式にサポートされたことはありません。

現在、多くのインターネットサービスプロバイダーは、顧客からのすべての発信ポート25トラフィックをブロックしています。主にスパム対策として[20]、また、おそらくそれを開いたままにすることを必要とする少数の顧客からより多くを請求することによって、それを開いたままにするときに彼らが持っているより高いコストを治すために。

SMTPトランスポートの例

同じメールドメイン(example.com )にある2つのメールボックス( aliceboss )にSMTP経由でメッセージを送信する典型的な例は、次のセッション交換で再現されます。(この例では、会話部分にはサーバークライアントのそれぞれにS:C:のプレフィックスが付いています。これらのラベルは、交換の一部ではありません。)

メッセージ送信者(SMTPクライアント)がメッセージ受信者(SMTPサーバー)への信頼できる通信チャネルを確立した後、セッションはサーバーによる挨拶で開かれます。通常、完全修飾ドメイン名(FQDN)(この場合はsmtp.example )が含まれます。 .comHELOクライアントは、コマンドのパラメータでFQDN(または使用可能なアドレスリテラルがない場合はアドレスリテラル)で自分自身を識別するコマンドで応答することにより、ダイアログを開始します。[21]

S:220 smtp.example.comESMTPPostfix
C:HELOリレー.example.org
S:250こんにちはrelay.example.org、お会いできてうれしいです
C:メール送信元:<[email protected]>
S:250 OK
C:RCPT TO:<[email protected]>
S:250 OK
C:RCPT TO:<[email protected]>
S:250 OK
C:データ
S:354 <CR> <LF>でデータを終了します。<CR> <LF>
C:From: "Bob Example" <[email protected]>
C:宛先:「アリスの例」<[email protected]>
C:Cc:[email protected]
C:日付:2008年1月15日火曜日16:02:43 -0500
C:件名:テストメッセージ
C:
C:こんにちはアリス。
C:これは、メッセージ本文に5つのヘッダーフィールドと4つの行があるテストメッセージです。
C:あなたの友達、
C:ボブ
C:。
S:250 Ok:12345としてキューに入れられました
C:終了
S:221バイ
{サーバーは接続を閉じます}

クライアントは、コマンドでメッセージの発信元の電子メールアドレスを受信者に通知しますMAIL FROM。これは、メッセージを配信できない場合のリターンアドレスまたはバウンスアドレスTo:でもあります。この例では、電子メールメッセージは同じSMTPサーバー上の2つのメールボックスに送信されます。1つはおよびCc:ヘッダーフィールドにリストされている受信者ごとに1つです。対応するSMTPコマンドはRCPT TOです。コマンドの受信と実行が成功するたびに、サーバーは結果コードと応答メッセージ(たとえば、250 Ok)を使用して確認応答します。

メールメッセージの本文の送信はDATAコマンドで開始され、その後、行ごとに逐語的に送信され、データの終わりのシーケンスで終了します。このシーケンスは、改行(<CR><LF>)、単一の終止符.)、それに続く別の改行(<CR><LF>)で構成されます。メッセージ本文には、テキストの一部としてピリオドのみを含む行を含めることができるため、クライアントは、行がピリオドで始まるたびに2つのピリオドを送信します。これに対応して、サーバーは行の先頭にある2つのピリオドのすべてのシーケンスを1つのピリオドに置き換えます。このようなエスケープ方法は、ドットスタッフィングと呼ばれます。

例示されているように、データの終わりに対するサーバーの肯定的な応答は、サーバーがメッセージを配信する責任を負っていることを意味します。この時点で通信障害が発生した場合、たとえば電力不足が原因で、メッセージが2倍になる可能性があります。送信者がその250 Ok応答を受信するまで、メッセージが配信されなかったと見なす必要があります。一方、受信者はメッセージを受け入れることを決定した後、メッセージが受信者に配信されたと想定する必要があります。したがって、この期間中、両方のエージェントは、配信しようとするメッセージのアクティブなコピーを持っています。[22]このステップで通信障害が発生する確率は、サーバーがメッセージ本文に対して実行するフィルタリングの量に正比例します。ほとんどの場合、スパム対策の目的で行われます。制限タイムアウトは10分に指定されています。[23]

QUITコマンドはセッションを終了します電子メールに他の受信者がいる場合、クライアントはQUIT、現在の宛先がキューに入れられた後、後続の受信者のために適切なSMTPサーバーに接続します。クライアントがコマンドで送信する情報はHELOMAIL FROM受信サーバーによってメッセージに追加のヘッダーフィールドとして追加されます(サンプルコードには表示されません)。Receivedそれぞれ、Return-Pathヘッダーフィールドを 追加します。

一部のクライアントは、メッセージが受け入れられた後に接続を閉じるように実装されている250 Ok: queued as 12345ため()、最後の2行は実際には省略される場合があります。これにより、221 Bye応答を送信しようとしたときにサーバーでエラーが発生します。

SMTP拡張機能

拡張機能検出メカニズム

クライアントEHLOは、元のの代わりに、以下に例示するように、グリーティングを使用してサーバーでサポートされているオプションを学習しますHELOサーバーがグリーティングHELOをサポートしていない場合にのみ、クライアントはフォールバックします。[24]EHLO

最近のクライアントは、ESMTP拡張キーワードSIZEを使用して、受け入れられる最大メッセージサイズをサーバーに照会する場合があります。古いクライアントとサーバーは、分単位で支払われるネットワークリンクへの接続時間など、ネットワークリソースを消費した後に拒否される、サイズが大きすぎるメッセージを転送しようとする場合があります。[25]

ユーザーは、ESMTPサーバーが受け入れる最大サイズを事前に手動で決定できます。HELOクライアントはコマンドをコマンドに置き換えますEHLO

S:220 smtp2.example.comESMTPPostfix
C:EHLO bob.example.org
S:250-smtp2.example.com Hello bob.example.org [192.0.2.201] 
S:250-SIZE 14680064 
S:250-PIPELINING 
S:250 HELP

したがって、 smtp2.example.comは、14,680,064オクテット(8ビットバイト)以下の固定最大メッセージサイズを受け入れることができると宣言します。

最も単純なケースでは、ESMTPサーバーは。SIZEを受信した直後に最大値を宣言しますEHLOただし、 RFC 1870によると、応答の拡張子の数値パラメータはオプションです。代わりに、クライアントは、コマンドを発行するときに、転送するメッセージのサイズの数値の見積もりを含めることができます。これにより、サーバーは、過度に大きなメッセージの受信を拒否できます。  SIZEEHLOMAIL FROM

バイナリデータ転送

元のSMTPはASCIIテキストの単一の本文のみをサポートするため、バイナリデータは、転送前にメッセージの本文にテキストとしてエンコードしてから、受信者がデコードする必要があります。通常 、 uuencodeBinHexなどのバイナリからテキストへのエンコーディングが使用されていました。

8BITMIMEコマンドは、これに対処するために開発されました。1994年にRFC1652 [ 26]として標準化されました。これは、通常Base64でエンコードされるMIMEコンテンツ部分としてエンコードすることにより、7ビットASCII文字セット外のオクテットを含む電子メールメッセージの透過的な交換を容易にします 

メール配信メカニズムの拡張機能

オンデマンドメールリレー

オンデマンドメールリレーODMR )は、 RFC 2645で標準化されたSMTP拡張機能であり、断続的に接続されたSMTPサーバーが、接続時にキューに入れられた電子メールを受信できるようにします。  

国際化拡張

元のSMTPは、 ASCII文字のみで構成される電子メールアドレスをサポートします。これは、ネイティブスクリプトがラテン語ベースではないユーザー、またはASCII文字セットにない発音区別符号を使用するユーザーにとっては不便です。この制限は、アドレス名でUTF-8を有効にする拡張機能によって緩和されました。RFC 5336は実験的な[25]コマンドを導入し、その後、コマンドを導入したRFC6531に取って代わられました。これらの拡張機能は、電子メールアドレスのマルチバイト文字と非ASCII文字(ダイアクリティック文字やギリシャ語中国語などの他の言語文字など)のサポートを提供します。[27]  UTF8SMTP SMTPUTF8

現在のサポートは限られていますが、ラテン語(ASCII)が外国語のスクリプトである大規模なユーザーベースを持つ 中国のような国でRFC6531および関連するRFCを広く採用することに強い関心があります。 

拡張機能

SMTPと同様に、ESMTPはインターネットメールの転送に使用されるプロトコルです。これは、サーバー間トランスポートプロトコルと(制限された動作が適用される)メール送信プロトコルの両方として使用されます。

ESMTPクライアントの主な識別機能は、 (Hello、元のRFC 821標準)EHLOではなく、コマンド(Extended HELLO)を使用して送信を開くことです。サーバーは、構成に応じて、成功(コード250)、失敗(コード550)、またはエラー(コード500、501、502、504、または421)で応答します。 ESMTPサーバーは、ドメインとサポートされている拡張機能を示すキーワードのリストを含む複数行の応答でコード250OKを返します。 RFC 821準拠のサーバーはエラーコード500を返し、ESMTPクライアントがまたはのいずれかを試行できるようにしますHELO HELOQUIT

各サービス拡張機能は、後続のRFCで承認された形式で定義され、Internet Assigned Numbers Authority(IANA)に登録されています。最初の定義は、RFC 821オプションサービスでした:SENDSOML(送信またはメール)、SAML(送信およびメール)EXPN、、、HELPおよびTURN追加のSMTP動詞の形式が設定され、およびの新しいパラメーター用に設定されましMAILRCPT

現在使用されている比較的一般的なキーワード(すべてがコマンドに対応しているわけではありません)は次のとおりです。

ESMTP形式はRFC2821 ( RFC 821に取って代わります)で修正され、2008年にRFC 5321の最新の定義に更新されました。サーバーでのコマンドのサポートが必須になり、必須のフォールバックが指定されました。   EHLOHELO

非標準の未登録のサービス拡張機能は、二国間契約によって使用できます。これらのサービスはEHLO、「X」で始まるメッセージキーワードで示され、追加のパラメーターまたは動詞も同様にマークされます。

SMTPコマンドでは、大文字と小文字は区別されません。ここでは、強調のために大文字で示しています。特定の大文字と小文字を区別する方法を必要とするSMTPサーバーは、標準に違反しています。[要出典]

8BITMIME

少なくとも次のサーバーが8BITMIME拡張機能をアドバタイズします。

次のサーバーは、8BITMIMEをアドバタイズするように構成できますが、非8BITMIMEリレーに接続する場合、8ビットデータから7ビットへの変換は実行しません。

SMTP-AUTH

SMTP-AUTH拡張機能は、アクセス制御メカニズムを提供します。これは、クライアントがメールの送信プロセス中にメールサーバーに効果的にログインするための認証ステップで構成されています。 SMTP-AUTHをサポートするサーバーは通常、クライアントにこの拡張機能の使用を要求するように構成でき、送信者の本当のIDが確実にわかるようにします。 SMTP-AUTH拡張機能は、RFC4954で定義されてます 

SMTP-AUTHを使用すると、正当なユーザーがメールをリレーしながら、スパマーなどの許可されていないユーザーへのリレーサービスを拒否できます。 SMTPエンベロープ送信者またはRFC2822「From:」ヘッダーのいずれかの信頼性を必ずしも保証するものではありませんたとえば、1人の送信者が他の誰かになりすます スプーフィングは、サーバーがメッセージの送信元アドレスをこのAUTHedユーザーが許可されているアドレスに制限するように構成されていない限り、SMTP-AUTHで引き続き可能です。 

SMTP-AUTH拡張機能を使用すると、あるメールサーバーが別のメールサーバーに、メールの中継時に送信者が認証されたことを示すこともできます。一般に、これには受信側サーバーが送信側サーバーを信頼する必要があります。つまり、SMTP-AUTHのこの側面がインターネットで使用されることはめったにありません。[要出典]

SMTPUTF8

サポートするサーバーは次のとおりです。

セキュリティ拡張機能

メール配信は、プレーンテキストと暗号化された接続の両方で発生する可能性がありますが、通信する当事者は、他の当事者が安全なチャネルを使用できるかどうかを事前に知らない場合があります。

STARTTLSまたは「便宜的なTLS」

STARTTLS拡張機能を使用すると、サポートするSMTPサーバーは、TLS暗号化通信をサポートしていることを接続クライアントに通知でき、クライアントがSTARTTLSコマンドを送信して接続をアップグレードする機会を提供します。TLS暗号化セッションへのアップグレードは、接続しているクライアントがこのオプションを実行することを決定することに依存するため、拡張機能をサポートするサーバーは、それ自体の実装から本質的にセキュリティ上の利点を得ることができません。したがって、便宜的なTLSという用語が使用されます。

STARTTLSネゴシエーションはプレーンテキストで行われ、アクティブな攻撃者はSTARTTLSコマンドを簡単に削除できるため、STARTTLSは受動的な監視攻撃に対してのみ有効です。このタイプのman-in-the-middle攻撃は、 STRIPTLSと呼ばれることもあり、一方の端から送信された暗号化ネゴシエーション情報がもう一方の端に到達することはありません。このシナリオでは、両方の当事者が、他方がSTARTTLSを適切にサポートしていないことを示すものとして、無効または予期しない応答を受け取ります。デフォルトでは、従来のプレーンテキストのメール転送になります。[41] STARTTLSはIMAPPOP3にも定義されていることに注意してください 他のRFCでは、これらのプロトコルは異なる目的を果たします。SMTPはメッセージ転送エージェント間の通信に使用され、IMAPとPOP3はエンドクライアントとメッセージ転送エージェントに使用されます。

2014年、Electronic FrontierFoundationは「STARTTLSEverywhere」プロジェクトを開始しました。このプロジェクトでは、「HTTPS Everywhere」リストと同様に、事前の通信なしで安全な通信をサポートする他の当事者を信頼者が発見できるようにしました。プロジェクトは2021年4月29日に提出の受け入れを停止し、EFFはピアのTLSサポートに関する情報を発見するためにDANEとMTA-STSに切り替えることを推奨しました。[42]

RFC  8314は、プレーンテキストの廃止を公式に宣言しており、暗黙的なTLSを使用してポートを追加し、常にTLSを使用することを推奨しています。

SMTPMTA厳密なトランスポートセキュリティ

「SMTPMTAStrict Transport Security(MTA-STS)」と呼ばれる新しい2018 RFC 8461は、サーバー上の特定のファイルおよび特定のDNSで安全なチャネルを使用する能力を宣言するメールサーバーのプロトコルを定義することにより、アクティブな攻撃者の問題に対処することを目的としていますTXTレコード。証明書利用者は、そのようなレコードの存在を定期的にチェックし、レコードで指定された時間だけキャッシュし、レコードの有効期限が切れるまで、安全でないチャネルを介して通信することはありません。[41] MTA-STSレコードはメールサーバー間のSMTPトラフィックにのみ適用され、ユーザーのクライアントとメールサーバー間の通信はSMTP / MSA、IMAP、POP3、またはHTTPSを使用したトランスポート層セキュリティによって保護されることに注意してください。 組織的または技術的なポリシーと組み合わせて。基本的に、MTA-STSは、そのようなポリシーをサードパーティに拡張する手段です。

2019年4月、GoogleMailはMTA-STSのサポートを発表しました。[43]

SMTPTLSレポート

多くのプロトコルでメッセージの安全な配信が可能ですが、設定の誤りや意図的なアクティブな干渉が原因で失敗し、メッセージが配信されなかったり、暗号化されていないチャネルや認証されていないチャネルで配信されたりする可能性があります。RFC8460 「 SMTPTLSレポート」では、受信者ドメインとの潜在的な障害に関する統計および特定の情報を共有するためのレポートメカニズムと形式について説明しています。受信者ドメインは、この情報を使用して、潜在的な攻撃の検出と意図しない設定ミスの診断の両方を行うことができます。  

2019年4月、GoogleMailはSMTPTLSレポートのサポートを発表しました。[43]

なりすましとスパム

SMTPの元の設計には、送信者を認証したり、サーバーが送信者に代わって送信を許可されていることを確認したりする機能がありませんでした。その結果、電子メールのなりすましが可能になり、電子メールのスパムフィッシングで一般的に使用されます。

SMTPを大幅に変更したり、完全に置き換えたりする提案が時折行われます。この一例はInternetMail 2000ですが、従来のSMTPの巨大なインストールベースの ネットワーク効果に直面して、それも他のものもあまり進歩していません。

代わりに、メールサーバーは、 RFC 5322[44] [45] DomainKeys Identified MailSender Policy FrameworkDMARCDNSBL、グレーリストなどの標準の厳格な施行など、さまざまな手法を使用して疑わしい電子メールを拒否または隔離します。[46] 

実装

たとえばnginxのようなSMTPプロキシの実装もあります。[47]

コメントの関連リクエスト

  • RFC  1123 –インターネットホストの要件—アプリケーションとサポート(STD 3)
  • RFC  1870 –メッセージサイズ宣言用のSMTPサービス拡張機能(廃止:RFC 1653 
  • RFC  2505 – SMTP MTAのスパム対策の推奨事項(BCP 30)
  • RFC  2821 – Simple Mail Transfer Protocol
  • RFC  2920 –コマンドパイプライン用のSMTPサービス拡張(STD 60)
  • RFC  3030 –ラージおよびバイナリMIMEメッセージを送信するためのSMTPサービス拡張
  • RFC  3207 –トランスポート層セキュリティを介したセキュアSMTPのSMTPサービス拡張(RFC 2487は廃止) 
  • RFC  3461 –配信ステータス通知用のSMTPサービス拡張(RFC 1891は廃止) 
  • RFC  3463 – SMTPの拡張ステータスコード(RFC 1893は廃止され、 RFC 5248によって更新されました  
  • RFC  3464 –配信ステータス通知用の拡張可能なメッセージ形式(RFC 1894は廃止) 
  • RFC  3798 –メッセージ処理通知(RFC 3461を更新) 
  • RFC  3834 –電子メールへの自動応答に関する推奨事項
  • RFC  3974 –混合IPv4 / v6環境でのSMTP運用経験
  • RFC  4952 –国際化された電子メールの概要とフレームワーク(RFC 5336によって更新) 
  • RFC  4954 –認証用のSMTPサービス拡張(RFC 2554を廃止、RFC 3463を更新、RFC 5248で更新)   
  • RFC  5068 –電子メール送信操作:アクセスと説明責任の要件(BCP 134)
  • RFC  5248 – SMTP拡張メールシステムステータスコードのレジストリ(BCP 138)(RFC 3463を更新) 
  • RFC  5321 – Simple Mail Transfer Protocol(RFC 821、別名STD 10、RFC 974RFC 1869RFC 2821 、 RFC 1123を更新     
  • RFC  5322 –インターネットメッセージ形式(RFC 822、別名STD 11、およびRFC 2822は廃止されました)  
  • RFC  5504 –電子メールアドレスの国際化のためのダウングレードメカニズム
  • RFC  6409 –メールのメッセージ送信(STD 72)(RFC 4409RFC 2476は廃止)  
  • RFC  6522 –メールシステム管理メッセージのレポート用のマルチパート/レポートコンテンツタイプ(RFC 3462、さらにはRFC 1892を廃止)  
  • RFC  6531 –国際化された電子メールアドレスのSMTP拡張機能(RFC 2821RFC 2822RFC 4952、およびRFC 5336を更新)    
  • RFC  8314 –クリアテキストは廃止されたと見なされます:電子メールの送信とアクセスのためのトランスポート層セキュリティ(TLS)の使用

も参照してください

メモ

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ 電子メールの歴史Tom Van Vleck:「このプロトコルがこれまでに実装されたことは明らかではありません
  3. ^ 最初のネットワークEメールレイ・トムリンソン、BBN
  4. ^ PDP-10のDanMurphyによる「最初の電子メールコンピュータ」の写真
  5. ^ 2007年11月18日、 WaybackMachineでアーカイブされたDanMurphyのTENEXおよびTOPS-20ペーパー
  6. ^ RFC 2235 
  7. ^ RFC 469 –ネットワークメール会議の概要 
  8. ^ RFC 524 –提案されたメールプロトコル 
  9. ^ "Tldp.org"
  10. ^ "draft-barber-uucp-project-conclusion-05 –UUCPマッピングプロジェクトの結論"
  11. ^ 送信者の書き換えに関する記事には、 RFC1123より前の初期のSMTP履歴とソースルーティングに関する技術的な背景情報が含まれています 
  12. ^ Eric Allman(1983)、Sendmail – Internetwork Mail Router(PDF)、BSD UNIXドキュメントセット、Berkeley:University of California 、 2012年6月29日取得
  13. ^ Craig Partridge(2008)、インターネット電子メールの技術開発(PDF)、IEEE Annals of the History of Computing、vol。30、IEEE Computer Society、pp。3–29、doi10.1109 / MAHC.2008.32S2CID 206442868、2011年5月12日にオリジナル(PDF)からアーカイブ  
  14. ^ ポールホフマン(1998年2月1日)。「SMTPでの中継の許可:調査」インターネットメールコンソーシアム2010年5月30日取得
  15. ^ ポールホフマン(2002年8月)。「SMTPでの中継の許可:一連の調査」インターネットメールコンソーシアム2007年1月18日にオリジナルからアーカイブされました2010年5月30日取得
  16. ^ 「Unixでは、オープンメールリレーとは何ですか?-ナレッジベース」2007年6月17日。2007年6月17日のオリジナルからアーカイブ2021年3月15日取得
  17. ^ 「MAIL、RCPT、およびDATA動詞」、[DJ Bernstein]
  18. ^ RFC5321セクション-7.2 
  19. ^ システム、メッセージ。「メッセージシステムは、新しいAPI駆動機能を備えた最新バージョンのMomentumを導入します」www.prnewswire.com 2020年7月19日取得
  20. ^ Cara Garretson(2005)。「ISPはスパムを止めるために売り込みます」PCワールド2016年1月18日取得先月、Yahoo、America Online、EarthLink、およびMicrosoftによって結成されたスパム対策テクニカルアライアンスは、ポート25のフィルタリングを含むスパム対策の推奨事項のリストを発行しました。
  21. ^ RFC 5321 Simple Mail Transfer Protocol、J。Klensin、The Internet Society(2008年10月) 
  22. ^ RFC 1047 
  23. ^ "rfc5321#section-4.5.3.2.6"
  24. ^ ジョン・クレンシン; ネッド・フリード; マーシャルT.ローズ; Einar A. Stefferud; デイブクロッカー(1995年11月)。SMTPサービス拡張IETF土井10.17487 / RFC1869RFC1869_
  25. ^ a b "メールパラメータ"IANA。2020年2月14日。
  26. ^ 2011年に当時の新しいSTD71に対応するRFC6152によって廃止されまし 
  27. ^ Jiankang Yao(2014年12月19日)。「中国のメールアドレス」EAI(メーリングリスト)。IETF 2016年5月24日取得
  28. ^ 「SMTPサービス拡張パラメータ」IANA 2013年11月5日取得
  29. ^ JamesServer-ChangeLogJames.apache.org。2013年7月17日に取得。
  30. ^ gmail-smtp-in.l.google.comポート25でEHLOに応答してアドバタイズされた8BITMIMEサービス、2011年11月23日チェック
  31. ^ QmailのバグとウィッシュリストHome.pages.de。2013年7月17日に取得。
  32. ^ 8BITMIME拡張Cr.yp.to. 2013年7月17日に取得。
  33. ^ PostfixSMTPUTF8サポートはデフォルトで有効になっています、2015年2月8日、postfix.org
  34. ^ 「メッセージシステムは新しいAPI駆動機能を備えたMomentumの最新バージョンを紹介します」(プレスリリース)。
  35. ^ 「バージョン6.2改訂履歴」CommuniGate.com
  36. ^ Sam Varshavchik(2018年9月18日)。「Courierパッケージの新しいリリース」courier-announce(メーリングリスト)。
  37. ^ 「HalonMTA変更ログ」GitHub2021年11月9日。v4.0:新しいSMTPUTF8サポート新しいバージョン用に更新
  38. ^ 「MS-OXSMTP:簡易メール転送プロトコル(SMTP)拡張機能」2018年7月24日。
  39. ^ 「TLDにおけるEAIの準備」(PDF)2019年2月12日。
  40. ^ 「CommunicationsMessagingServerリリースノート」oracle.com2017年10月。
  41. ^ a b "MTA Strict Transport Security(MTA-STS)の紹介|ブログの強化"www.hardenize.com 2019年4月25日取得
  42. ^ 「STARTTLSEverywhere」EFF 2021年12月4日取得
  43. ^ a b シンパヌ、カタリン。「GmailはMTA-STSとTLSレポートをサポートする最初の主要な電子メールプロバイダーになります」ZDNet 2019年4月25日取得
  44. ^ 「RFC5322に準拠していないメッセージ」
  45. ^ 「メッセージを配信できませんでした。メッセージがRFC5322に準拠していることを確認してください」
  46. ^ 「ポリシー上の理由でMicrosoftアカウントに送信された電子メールが拒否されるのはなぜですか?」
  47. ^ 「NGINXドキュメント|メールプロキシサーバーとしてのNGINXの構成」

参考文献

  • ヒューズ、L(1998)。インターネット電子メール:プロトコル、標準、および実装アーテックハウス出版社。ISBN 978-0-89006-939-4
  • ハント、C(2003)。sendmailクックブックオライリーメディア。ISBN 978-0-596-00471-2
  • ジョンソン、K(2000)。インターネット電子メールプロトコル:開発者ガイドアディソン-ウェスリープロフェッショナル。ISBN 978-0-201-43288-6
  • Loshin、P(1999)。重要な電子メール標準:RFCとプロトコルが実用化されました。ジョン・ワイリー&サンズ。ISBN 978-0-471-34597-8
  • Rhoton、J(1999)。インターネットメールのプログラマーガイド:SMTP、POP、IMAP、およびLDAPエルゼビア。ISBN 978-1-55558-212-8
  • ウッド、D(1999)。インターネットメールのプログラミングオライリー。ISBN 978-1-56592-479-6

外部リンク