このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。 |
非常に初歩的な質問なんだろうとは思うんですが、 メールのリレーというものの概念がよくわかりません。 今まで EIMS 1.x を使っていたのですが、そのメールアカウントで、 他のメールサーバに送信はできます。それで、リレーはしない、 という設定のようです。 しかし、よく考えなくても、SMTP って認証がないので、 そのアカウントのふりをして第三者が大量にメールを送るという 行為を許すような穴がある気がしています。 qmail にしたところ、自分のネットワークのみリレーを許可したところ、 送信で拒否されるようになってしまいました。 inet 経由で使用をしているのですが、hosts.allow の tcp-env : 127. 192.168.1. : setenv = RELAYCLIENT に外部ネットワークのアドレスを書けば、 送信はできるのですが、これって、ORBS だとかに リストアップされちゃうんでしょうか? たとえ、POP before SMTP を導入したところで、 やってることは、IP で制限する代わりに、パスワード認証をして、 それでリレーを自分以外のネットワークから認めることに 代わりはないので、リレーはリレーだと思うのですが。
大西 恒樹 さんからのコメント
( Sunday, June 24, 2001 13:08:08 )
自分（そのメールサーバー）宛以外のメールを受け取ることが、 全てリレーです。 リレーを行わないと、ローカル配送しかできませんので、どこへも メールは送れません。したがって、ほとんど全てのメールサーバーは リレーを行います。違いはOpenRelayか、RestrictedRelayか、だけの ことです。 qmailではqmail-smtpdというデーモンがリレーの受け取りを処理します ので、これを相手ホストのIPアドレスを限定して起動します。 私が運用するqmailサーバーはtcpserverを使ってこれを起動していますが、 まあ、inetdでも基本的には同じ原理で、ここにリレーを許可するホストの IPアドレスをリストすればよいでしょう。
重松修 さんからのコメント
( Monday, June 25, 2001 12:43:18 )
大西さん、コメントありがとうございます。 なるほど、いわれてみれば、リレーしないとメールが外に送れませんね。 inetd はパフォーマンスに問題があるようですが、 そのうちに、tcpserver に切替えたいと思います。 とりあえず、不特定多数が使う訳ではないので、POP before SMTP ではなく、 hosts.allow の設定でリレーするクライアントを限定し、 運用しようと思います。
p さんからのコメント
( Monday, June 25, 2001 13:52:02 )
ＳＭＴＰリレーが行われない場合 ローカル ｔｏ ローカル ＯＫ 外部 ｔｏ ローカル ＯＫ ローカル ｔｏ 外部 ＮＧ 外部 ｔｏ 外部 ＮＧ ＃サーバとクライアントが同一構内で物理的に ＬＡＮで接続されていても、クライアントが ローカルであることをサーバに認識されない場合もあります。 この場合、クライアントからどこにも発信できない ことでしょう。 余談ですが 不正な中継を許さない設定をしたらクライアントから 外部への発信が出来なくなるという不具合な症状の多くは クライアントがローカルでないよと、思われているわけです。 ＳＭＴＰリレーを、全部許す場合 ローカル ｔｏ ローカル ＯＫ 外部 ｔｏ ローカル ＯＫ ローカル ｔｏ 外部 ＯＫ 外部 ｔｏ 外部 ＯＫ ＃この第４番目が、踏み台となりうるわけですね。 昔はこれでＯＫだったわけです。 ＳＭＴＰリレーを、適切な条件によっては許す場合 ローカル ｔｏ ローカル ＯＫ 外部 ｔｏ ローカル ＯＫ ローカル ｔｏ 外部 ＯＫ 外部 ｔｏ 外部 ＮＧ ＃このようにすれば、不正な中継を禁止してありますし ローカルなクライアントからはどこにでも送信ＯＫ 外部からのメールは、サーバのローカルなユーザにのみ ＯＫとなります。ローカルなクライアントは ＰＯＰすればメールを引き取れます。 （ＰＯＰの認証は、ＰＯＰアカウントと付随するパスワードのみ ですので、原則的には、ローカルでない場所からでもＯＫに なるサーバが多いですね） ＃さて、どんな条件をもって「ローカル」であると認識させるのか？ いくつかの条件を複合的に設定して、その組み合わせで判定すること が多いのです。 ＃とっても脇の甘い例では、 サーバ登録済みのメールアカウントで、ありさえすればＯＫというのも あります。これは、穴ですね。メールアカウントは外部に公開する のが原則ですから。ＳＭＴＰはパスワードチェックしないのが おおもとの考えですから、事実上、悪用を防げません。 ＃たとえば、おお甘なサーバ運用ならば ローカルな条件として 「ＰＯＰ ｂｅｆｏｒｅ ＳＭＴＰ」のみ採用することでしょう。 複合技を使わないわけですね。 ＳＭＴＰをクライアントが利用する場合に、そのクライアントが あらかじめサーバに登録済みのＰＯＰアカウントを利用していること そして、そのパスワードがＯＫであること、これを先にチェックする 仕様ですね。ＳＭＴＰの前にＰＯＰを強制的に促して、ＰＯＰＯＫ ならばその後１０分間だけはＳＭＴＰを許してあげよう、、となります。 ＃上記までの条件の例では、アカウント、ないし、そのパスワードで 判定しようとするものでした。 別な条件を組み合わせる手があります。 ＩＰアドレスによる制限です。 代表的なものが、サーバと同じＩＰアドレスのセグメントならば 「ローカル」であると認証しようとするものです。 ＃構成上、上のチェックができないのであるのらば 特定のＩＰアドレスのみ「ローカル」であると 認めさせるのもひとつの考え方です。 サーバがグローバルなＩＰを持っていて、 クライアントがプライベートなＩＰを持っているとき などはこの考え方が、よろしいでしょう。 ルータの設定によって、Ｉｎｔｅｒｎｅｔの世界からの アクセスで、プライベートなアドレスできたものは 当然、遮断となっているのが原則です。 ＃応用ですが、 構内にサーバがあり、ＬＡＮでクライアントが 直結されていて、そのクライアントのＩＰならば ＳＭＴＰリレーを許す設定に、条件を ＯＲでプラスアルファすることがあります。 構内が本社で、外部の別な場所の出先のＩＰアドレスが グローバルな意味で、固定であるときなどがわかりやすい ですね。構内ＬＡＮのプライベートアドレスと 出先のグローバルアドレスからのみ、ＳＭＴＰリレーを 許します。ただし、メールアカウントは、サーバに 登録済みであるとします。（アカウントは詐称されるので あまり当てにできませんが、ないよりマシです） ＃別な応用ですが、サーバがホスティングされて構内に 無い場合を考えます。 構内は、インターネット上のサーバに対して どのように、「ローカル」だよ、と身を立てればいいでしょう？ ＡＤＳＬで接続を許す一部のＩＳＰは、グローバルなＩＰアドレス を付与してくれますので、そのＩＰであるならばＯＫとしても よろしいでしょう。グローバルなＩＰアドレスしかくれない ＩＳＰならば（ＮＴＴさんとか） サーバが、ＰＯＰ ｂｅｆｏｒｅ ＳＭＴＰ か もしくは、はるかに優れている ＳＭＴＰ ＡＵＴＨ 認証を かましてくれることに期待するのがいいでしょう。 これしかできないというのもさびしいことですが ＩＰアドレスは払底する一方ですので、固定アドレスの払出を 受けることはむつかしいのかもしれません。 ＃構内のサーバを、一部の外部の利用者にＰＰＰ接続などで 接続を許したい場合に、ＰＰＰ接続の電話番号を知っている という事実だけで、ＳＭＴＰを許すという例があるようです。 ＞しかし、よく考えなくても、SMTP って認証がないので、 そのアカウントのふりをして第三者が大量にメールを送るという 行為を許すような穴がある気がしています。 おっしゃられる通りです。 ＳＭＴＰ認証の機能があるものが望ましいですね。 ＰＯＰ ｂｅｆｏｒｅ ＳＭＴＰ ではちょっとさびしいです。 ＞qmail にしたところ、自分のネットワークのみリレーを許可したところ、 送信で拒否されるようになってしまいました。 お使いのメールクライントは、本当に、許可されたネットワーク上に あると、qmailに認識されているのでしょうか？