回答:
技術的には、コンピューターから受信者のSMTPサーバーに直接電子メールを送信することができます。
歴史的に見て、リモートSMTPサーバーがダウンしている場合、システムにそれを自動的に処理させ、再試行を続けるようにしたいので、SMTPサーバーがあります。同様に、昔は、すべてのメールサーバーが常に接続されていたわけではありませんでした。長距離リンクは高価であったため、リンクが確立されるとメールがキューに入れられて送信されました。
インターネットが安価な場所に移動すると、サーバーが利用できない場合に電子メールの送信を再試行するメカニズムがあることは依然として有用であり、この機能をMUA（メールユーザーエージェント/エンドユーザーメールプログラム）に書き込むのは理想的ではありません。これらの関数は、MTA（メールサーバー/ SMTPサーバー）に適合します。
しかし、さらに悪化しているのがスパマーです。ほとんどのメール（80％以上）はスパムです。そのため、メールプロバイダーはこの問題を軽減するためにできる限りのことを行います。また、多数の手法が電子メールの配信方法を想定しています。以下は重要な考慮事項です。
グレーリスト：送信者と受信者が以前に通信したことがない場合、一部のプロバイダーは自動的にメール接続をドロップし、SMTPサーバーが常に想定されるのに対して、スパマーはしばしばそうしないので、2度目の試行を期待します。これにより、スパムの量が約80％削減されます。ただし、これを行う必要があるのは残念です。
評判：有名な既知のSMTPサーバーを介してメールを送信する人は、夜間のサーバーよりも合法である可能性が高いです。評判をつかむために、プロバイダーはいくつかのことを行います。
動的/クライアントアドレスをブロックします（100％ではありませんが、インターネットの大部分がマッピングされています）。
リバースDNSとフォワードDNSが一致しているように見えます。実行するのはそれほど難しくありませんが、ある程度の説明責任とベストプラクティスの知識を示しています。多くのクライアントアドレスブロックにはないものです。
評判：他のSMTPサーバーと通信する場合、多くのプロバイダーはスパムの量と送信される電子メールの量を追跡し、接続を制限してこれらのパラメーターを監視することでスパムの量を減らすことができます。（これを行う方法はたくさんありますが、そのすべてが明白ではありませんが、既知の送信者が必要です）。
SPFおよびDKIM：これらのメカニズムは、DNSリソースをドメイン名に結び付けてメールの偽造を難しくします（ただし、メールプログラム（MUA）が送信メールを担当している場合は、展開が必ずしも不可能ではありません。）すでに受け入れられているので完了します。私の心を滑らせたので、以下のポスターにクレジットするべきですが、それにもかかわらず、非常に有効です）
おそらく他にも小さな懸念がありますが、これらは大きな懸念です。
メールを送信するために中間SMTPサーバーが必要なのはなぜですか？クライアント（Outlook、Thunderbird）が受信者のSMTPドメインにメッセージを直接送信できないのはなぜですか？
1991年（および1990年代前半のほとんど、さらにそれ以前）に、あなたが説明したことを行えるようになるかもしれません。しかし2015年の現実は、メールサービスがインストールされている任意のマシンからだれにでも技術的にメールを送信できる一方で、スパムの世界はその方法を事実上役に立たなくしました。
「実際の」SMTPサービスを使用する場合、PTRレコード、SPFレコード、さらには1つの目的と1つの目的のみのために確立されたDomainKeyのようなものが設定されます。そうでない場合は？メッセージをSPAMフォルダーまたは「グレートアビス」の削除にフィルターします。これらの各アイテムの内訳は次のとおりです。
PTR（ポインターレコード/リバースDNSレコード）：サーバーレベルの検証。ここで説明し、PTRレコードは、ホスト名へのネットワーク・インターフェース（IP）をマッピングするために使用されます。123.456.789.0SMTPサーバーにメールを送信するアドレスがある場合、smtp.example.comそのための適切なPTRレコードは次のようになりますsmtp.example.com。単純すぎるように見えますが、実際にPTRレコードを設定できるのはIPアドレスの所有者だけであり、ハードウェア上でのみ設定できるため機能します。そのため、そのIPアドレスの所有者、実行者、管理者に対する検証ポイントとして機能します。
SPF（送信者ポリシーフレームワーク）：ホスト名DNSエントリレベルの検証。ここで説明するように、SPFレコードは、基本的にドメイン名保有者によって設定されるDNSレコードであり、そのドメイン名の電子メールを送信できるサーバーのIPアドレスとホスト名のリストを提供します。これもまた、SMTPサーバーの真のドメイン名所有者のみがメールを送信できることを保証する別の検証手順です。のIPアドレスを持つサーバー123.456.789.9がにメールを送信しているとしexample.comます。がをsmtp.example.com使用していることは既にわかっています123.456.789.0が、SPFレコードエントリにexample.comは「Hey！123.456.789.9良いサーバーです！彼は合法だ！彼のメールを尊重してください！」
DKIM（DomainKeys Identified Mail）：メールメッセージレベルの検証。ここで説明すると、上のウィキペディア、「DKIMは、ドメインからの受信メールがそのドメインの管理者とすることを（添付ファイルを含む）の電子メールを許可されていることを確認するために、メール交換を受信できるようにする仕組みを提供することにより、電子メールのなりすましを検出するために設計された電子メールの検証システムであり、暗号化ハッシュを使用することにより、DKIMはメール自体が送信中にフィルタリングまたは改ざんされていないことを確認します。これは、「合法ですか、それともスパムですか？」チェーンのさらに別の検証ポイントとして機能します。
そのため、最終的には、公開サーバーに相当するSMTPサーバーには、これらのアイテムのうち少なくとも2つ（PTRとSPF）が設定され、SMTPサーバーと関連する電子メールが正当であることを確認します。誰もがDKIMを使用しているわけではありませんが、SPAMmerがSPAMを送信しようとする努力に粘り強くなるにつれて、今日ではますます人気が高まっているもう1つの検証レイヤーです。
ほとんどの家庭用ISPは、スパムネットワークへの参加を防ぐためにTCPポート25（SMTP）をブロックします。PCが感染した場合、他の誰かの要請でPCがスパムを吐き出す可能性があります。
他の回答はすべて優れており、スパムはそれと多くの関係があります。
しかし、実際には、よりシンプルでより一般的な答えがあります。機能です。SMTPを介した電子メールの送信は、実際には非常に複雑な作業です。スパムがなくても、すべての電子メールクライアントにSMTPプロトコルの機能セット全体を実装することは望ましくありません。専用のソフトウェア（sendmail、postfixなどは、* nixの世界では大きなものであり、Windowsの世界ではExchangeです）を使用する方が良いでしょう。
たとえば、最も基本的な場合でも、「実際の」SMTPサーバーは少なくともMXレコードを解決できる必要があります。次に、機能をネゴシエートする必要があります（ほとんどがTLSですが、他の機能もあります）。再試行のためのキューを管理したり、配信不能レポートを生成したりする必要があります。
そして、それはサーバーが機能しない基本的な、必須の機能です。アドレスの書き換え、メーラテーブルなども含まれていません。UUCPなど、sendmailなどがサポートする他の12個以上のプロトコルは言うまでもありません。
Outlook、ThunderbirdなどでのSMTP実装は非常に最小限です。せいぜい、sendmailでスマートホストを使用する場合とほぼ同じです。
関連するが、別の問題：電子メールは非常にセキュリティに敏感なトピックであり、各デスクトップに潜在的に数百または数千の個別のサーバーではなく、1つまたはごく少数の中央管理サーバーで処理する必要があります。
メールを送信するために中間SMTPサーバーが必要なのはなぜですか？クライアント（Outlook、Thunderbird）が受信者のSMTPドメインにメッセージを直接送信できないのはなぜですか？
これを行う電子メールプログラムを作成することができ、他の人が以前にそれを行った（または試みた）ことは間違いありません。
基本的には、MUA（メールユーザーエージェント）とMTA（メール転送エージェント）の両方を兼ね備えたツールを作成することになります。
これが伝統的にさまざまなツールに分離されている理由は、MTAが「サーバー側」に存在するため、オープンインターネット経由でメールを送信するMTAは書き込みと設定がかなり複雑であり、また、信頼できる「常時接続」サーバー。
MTAには以下が必要です。
信頼していないサーバー、または不正な動作をしている可能性のあるサーバーを検索して接続し、メールを失わない適切な方法でエラー状態に対処します。
ダウンしているサーバーに対処し、代替サーバーにルーティングするか、後で再試行するためにメールをキューに入れます。これは、インターネットに「常時接続」されているサーバープロセスで最適に実行されます。また、メール転送エージェントは、キューに入れられたメール用に独自のストレージ領域を必要とすることを意味します。
さまざまなサーバー機能の範囲に対処し、受信サーバーの機能に応じて動作を調整します。
エラー状態について、またはメールが配信できない場合にユーザーに報告して、メールが単に失われないようにします。
優れたセキュリティ慣行を持ち、非常にセキュリティを意識します。
理想的には、安定したIPアドレスと逆DNSエントリを備えた、信頼性の高い常時接続されたサーバー、つまり公開サーバーに適したインターネット接続に常駐します。これは、他のシステムがスパムとして送信されたメールを検出しないのに役立ちます。
これらの要件を考えると、SMTPサーバーを公開された常時接続のサーバーのどこかに収容し、その特定のジョブを実行するのに適したツールを試して使用することは理にかなっています。
もう1つ考慮すべきことは、返された電子メールを受信することです。少なくとも、すべての送信メールには、応答を送信できるFROMアドレスがあります（不明なユーザー、休暇の返信など）。返信先アドレスを解決するには、返信用受信トレイの場所を指すMXレコードが存在する必要があります。常にオンになっている静的IPアドレスを持つコンピューターから電子メールを送信する場合を除き、これらのインバウンドメッセージを処理するサーバーが必要になります。これは通常（常にではありませんが）同じサービスによって処理されます。
GMail、Outlook 365、およびYahoo Mailは、電子メールを送信している個人が使用する電子メールサービスの例です。商用メール送信には、MailChimp、Marketo、Eloquaなどのサービスがあります。これらのサービスは、企業に大量のメールを送信し、バウンス、スロットル、配信可能性などの処理に非常に優れています。