web-dev-qa-db-ja.com

メールクライアントが受信者のSMTPサーバーを直接使用しない理由

通常、電子メールクライアントでは、メールの送信に使用するSMTPサーバーを構成する必要があります。メールを送信する場合、構成済みのSMTPサーバーは、タイプMXのDNS要求を使用して受信者の電子メールアドレスの@atの後のドメインを解決するだけです。 DNSは、受信者のメールプロバイダーのメールエクスチェンジャーSMTPサーバーのアドレスで応答し、SMTPサーバーはそれにメールを転送します。

私の質問は、なぜこれがメールクライアントによって直接行われないのかということです。これは特別なことではありません。これは単なるDNSmxリクエストであり、プロトコルは受信者プロバイダーのメールエクスチェンジャーを直接処理します。常にSMTPです。

もしそうなら、メールは適切なサーバーに直接送られる可能性があります。それはより速く、無駄なトラフィックを避けるはずです。

これは、受信者のSMTPサーバーが何らかの理由でダウンしているか、送信時にメールを処理するには忙しすぎる可能性があるためである可能性があります。したがって、個人のSMTPサーバーを使用する利点は次のとおりです。定期的にメールを送信してみてください？

これが私が見る唯一の理由です。ユーザーがメールクライアントを閉じたり、コンピュータをシャットダウンしたりする可能性があるため、これがメールクライアントの責任である場合、実際にはそれほど実用的ではありません。

これが唯一の理由である場合：SMTPサーバーが電子メールをすぐに処理できないほど頻繁に発生しますか？

emaildnssmtpemail-client
6
WoDoSc

考えられる理由の1つは、送信者が受信者のメールサーバーに直接到達できない可能性があることです。

電子メールとSMTPの初期には、インターネットだけでなく、ビットネットもありました。 UUCPnet/Usenet;バークネット; MILNET; DECnet;など、すべて互換性のないプロトコルを使用しています。 sri-unix.uucpのようなドメインはDNSにIPアドレスを持っていなかった可能性があります–ゲートウェイ（UUCPリンクも持っていたSMTPサーバー）を指すMXレコードだけです。

最近では、IPv4のみのホストとIPv6のみのホスト間の通信でも同様の状況が発生しています（後者はややまれですが）。

その上、ネットワークは正確ではありませんでした信頼できる（そしてまだそうではありません）–「受信者のメールサーバーに到達できません。しばらくお待ちください」を30分見つめたくないでしょう。メッセージを作成していたのと同じコンピューターで24時間年中無休で実行されているsendmailにメッセージを送信し、作業を続行できます。

ボーナス：OldUse.Netで見たいくつかの本当に奇妙な「From：」アドレス：

  • UCBVAX.@[email protected]@Rand-RELAY

  • farber%udel-eecis1.udeecis@[email protected]

  • notes@CSvax:Pucc-H:pur-phy.UUCP

  • utzoo!linus!security!genrad!decvax!harpo!floyd!whuxlb!pyuxll!abnjh!u1100a!pyuxn!pyuxi!mhuxm!mhuxd!mhuxa!houxm!hocda!spanky!burl!akgua!emory!sb6!sb1!ll1!otuxa!we13!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!mcewan

4
user1686

これが唯一の理由である場合：SMTPサーバーが電子メールをすぐに処理できないほど頻繁に発生しますか？

これは、特にSMTPサーバーが小規模な組織によって保守されている場合に発生します。

しかし、受信メールを本当に処理できないことに加えて、処理できるが、処理したくない場合もあります。頭に浮かぶ2つの例：

  1. Grey Listing を使用するサーバーは、スパマーに対する手法として、意図的に、体系的な方法で4xxエラーのある不明な送信者からの最初の試行を拒否します。

  2. 一部のメールプロバイダーは、同じIPアドレスまたはアカウントから単位時間あたりに送信されるメールが多すぎると、4xxエラーで応答して、自社の顧客に対してスロットルを使用します。これにより、意図的に（中小企業がニュースレターを送信する）かどうかにかかわらず（感染の犠牲者として）、顧客がスパムを送信するのを防ぐことができます。私は最近、GMailが1日あたり100通のメッセージでなく、有料アカウントからこれを行っているのを見ました。SMTPメッセージは...あなたのIPアドレスから送信されるメールは一時的にレート制限されています。 ..

ターゲットMXの一時的なDNS障害の場合もあります。

メールクライアントに任せるよりも、最初のSMTPホップでこれらすべてを処理する方が実用的です。

1
Daniel Vérité

コメントのdrk.com.arは正しいです。

ISPからの静的IPがある場合は、独自のSMTPをローカルでホストでき、そのプロセスメールを使用できます。それで問題ありません。それからあなたがそれを悪用するとspamhauseとcoはあなたをブラックリストに載せ、あなたは完全に無視されるでしょう。

動的IPの場合、これは機能しません。60秒程度で変更できるため、IPをブロックすることはできません。したがって、この場合、ISPは送信メールをフィルタリングする責任があります。すべてのメールをSMTPサーバーに転送し、SMTPサーバーがそれをルーティングします。悪用を開始すると、リースレコードはメールの送信者を正確に把握し、それに応じて対応できます。

興味深いことに、ISPの親会社であるCelloがSMTPサーバーを適切に管理せず、一部のクラスターがスパマーとしてブロックされ、受信側で断続的なスパムブロックが発生するという問題が数か月前に発生しました。

お役に立てれば。

1
Linef4ult

実際のサーバーがダウンしている可能性があります。したがって、再試行するにはサーバーが必要です。

そのため、「このメールは受信者に届きませんでした。まもなく再試行します。これについては何もする必要はありません」というメッセージが表示されることがあります。

そして最終的には「受信者に到達しませんでした。この失敗は永続的です」というメッセージが表示されます。

0
guest