このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

ASIPにおけるSPAM不正中継防止について警告

発言者:今泉克美
( Date Friday, December 22, 2000 12:19:15 )


*
最近こちらのBBSにて私は
ASIP6.2あるいはASIP6.3における
不正中継防止策に関する投稿をしてきました。

昨日までは、これで不正中継が防げるのだと
固く信じてきたのですが
大き目の穴があることに気付きましたので
ご報告申し上げたほうが良いのかどうか
迷っております。

たった一行書いてしまえば頭のイイ人ならば
不正中継を実施できることでしょう。

実際に、、出来てしまいました。

今の気分を言えば
「ちっくしょー」です。

こちらのBBSでどなたかが
「ASIPでは絶対に不正中継を防止できない」
というメッセージを登録された方がいらして
ずっと不思議だったのですが
その方の言うとおリだとわかりました。
根本的にダメだとわかりました。

どこにかいてあったのかは紛失してしまっております。
申し訳ありません。たしかどこかの大学の管理者の方
でした。

方法を
具体的書いていいのかどうか
憚られますが
ある種の方法に気がつけば
不正中継可能です。

私が採用してきた方法は
http://mtlab.ecn.fpu.ac.jp/webcon.mtxt$001215140422.html
にて詳しく書いてあります。

上記に触れられていない設定としては
自社サーバのユーザアカウント以外の者から
外部へのSMTP送信を禁止する設定、その他を
実施しています。

参考文献として
http://asep.apple.co.jp/tn-bin/tn?TNNO=0313
http://asep.apple.co.jp/tn-bin/tn?TNNO=0318
http://til.info.apple.com/techinfo.nsf/artnum/n31108
があげられますし
私どもの設定もこれらに準拠しておりまして
AbusenetさんやORBSのTESTにも
合格し、
なおかつ
続発していた不正中継をスッパンスッパンと拒否できるように
なって安心していたところなのです。

ともあれ、肩を落としております。
Os9やASIP6.3にアップグレードする気が
完全になくなりました。

メールサーバ機能としては
ASIPは使わないほうが良いという結論です。

(Web&Fileサーバ機能については
優秀なのではないかと思っております。)

−−−−−−−−−−−−−

いずれにせよ
実質的に効果は高いのですから
上記の不正中継対策は実施しておくべきでしょう。
MacのASIPに特化した
不正中継を試みる者は少ないと思いますし
効率も悪いと思います。

また、リアルタイムブラックホールリストは
必須であると考えられます。
ダイアルアップからの試みを禁止したほうが
実質的に効果が高いようです。
標準のリアルタイムブラックホールリストは
使わずに別のものを使ってくださいませ。

−−−−−−− 残念 −−−−−−−−

さんからのコメント
( Friday, December 22, 2000 14:58:36 )

(T_T)....

たまちゃん さんからのコメント
( Friday, December 22, 2000 16:16:35 )

>具体的書いていいのかどうか
>憚られますが

書いていいと思いますよ。もしそれでも書くのはまずいと思われる
のでしたら,躊躇せず至急に Apple に報告するのがいいでしょう。

たとえ ASIP のメールサーバを使わないとしてもです。

深井 さんからのコメント
( Friday, December 22, 2000 16:20:29 )

書き込み失礼いたします
日頃は大変お世話になっており、ありがたく拝見しております。
当方、MacOS9+ASIP6.3にてWEB,File,Mailを運用しています。
丁度、EIMSに変更しようと検討中でしたので、この機会に変更しようと
思います。
今泉様ありがとうございました。

今泉克美 さんからのコメント
( Friday, December 22, 2000 19:09:45 )

ちょっと冷静に。

その1.

こちらは
ASIP6.2ですが

ひょっとしたら仕様ではなくて
バグなのではと思い始めています。
ならば
ASIP6.3では大丈夫かもしれません。

不正中継の防止方法の
設定画面は
ASIP6.2も6.3も全く同じです.

しかし、バグFixされているのかもしれません。

ASIP6.1で不正中継されて
バージョンアップして回避しようとしたときに

6.2でいこうか(OS8.6へ無償でアップできた。)
6.3まであげるか(OS9へは有償だった)
迷ったのです。

不正中継に関して
同じ機能ならばバージョンを上げる必要はあるまいと
判断しておりました。

この件で、当時
Apple(日本)に問い合わせたときには
Helpに書いてあること以外には
わかりませんと回答を頂きましたので
本当のところ詳細は不明です。

その2.

さしさわりがあるようでしたら
削除を願います。

一般的な不正中継者は
IPアドレスをばんばんかえて
(たとえば、数字をひとつずつあげて)
不正中継できそうなところをさがして
利用すると聞いています。
このときは、有名どころでシェアの大きい
サーバを対象に不正中継のロジックを摘要して
数打てば当たる方式を取っているのではと
思います。そのほうが、
短時間でいっぱい処理できるから。
こういう雰囲気ならば
私どものサーバは大丈夫の可能性が高いのです。

いっぽう、MacのASIP6.2をターゲットにするぞと
心に誓う不正中継者もいるかもしれません。

ふところの甘いタイプの機種なりサーバソフトなりが
狙われる例もあったと聞いています。
WinNTサーバで走るDEMIという名前のソフトも
かつて狙いやすかったそうです。これは最新では大丈夫の
ようですが。

はたしてASIP6.2に特化した攻撃方法を取るのかどうか
不明ですが、ひとたび、不正中継者から見つかってしまうと
永遠にしゃぶりつかれるのかもしれません。
運用停止においこまれます。

−−−−−−−−−−−−−−−

では、何がおきたか。

【1】
http://asep.apple.co.jp/tn-bin/tn?TNNO=0313
http://asep.apple.co.jp/tn-bin/tn?TNNO=0318
では
不正中継者による、送り手のメールアカウントが
外部のものであり、かつ、受け手が外部の者
であるメールを中継しないですむような
設定を可能としています。
ASIP6.1でも可能な対応策でした。
ここまでの設定で長崎ネットさんの簡易試験には
合格します。
実際、この手の不正中継を試みる者が多かったのも
事実です。

【2】.
しかしこの方法だけでは
「なりすまし」を使ってくるSPAMmerには
無力です。

ターゲットとなるサーバのメンバのアカウントを
どうにかして入手して
(簡単に手に入りますよね!PosmasterとかWeb上で公開してたり
名刺印刷してたり)
そのアドレスでもって送り元のアカウントを書き換えてやります。
実際の送り元とは異なりますのでウソをつくわけです。
大部分のメールソフトはこんなことは朝飯前に出来ます。
あとは、CCやらBCCやらいっぱいつけたメールを1個
ターゲットに仲介させるだけです。

こちらのBBSにいらっしゃる方なら
このへんは常識なのでしょうが、混乱している私は
頭を整理しながら書いていますので饒舌お許し下さい。

http://asep.apple.co.jp/tn-bin/tn?TNNO=0313
http://asep.apple.co.jp/tn-bin/tn?TNNO=0318
では
不正中継者が、送り手のメールアカウントを
内部のものに詐称して、かつ、受け手が外部の者
であるメールは中継せざるを得ないのです。

これが「なりすまし」で、
対策としては
ASIP6.2で実現された新機能
http://til.info.apple.com/techinfo.nsf/artnum/n31108
を活用すればいいということになります。

【3】
ここまでの対策設定をしていても
なりすましが成功できるパターンがあることが
わかりました。
【2】のなりすまし対策の本質は
HELO検証方式です。
ここに穴があったようです。

仮想のログで穴の説明をします。実物ではありません。多少はしょりました。
実物をもとに、いくつか行を抜いて説明しやすいようにしてあります。

<<< 220 mail.jibun.co.jp AppleShare IP Mail Server 6.2 SMTP Server Ready
>>> HELO dante.mail-abuse.org
<<< 250 Hello, dante.mail-abuse.org, I'm mail.jibun.co.jp
>>> MAIL FROM:<postmaster>

<<<自分のサ−バがまず準備OKですよーと言っています。

>>>次に、不正中継者のほうから名乗ってきますが、
>>>このとき
>>>HELO検証を合格するため、
>>>わざと
>>>正しくウソをつかずに名乗ります。

<<<ASIPは、名乗るなどの返事を出して受けたまわります。

>>>間髪入れずに不正中継者はホスト名のない、しかし
被害にあうサーバが持っているユーザ名になりすますウソをついて
メールを送ろうとします。

これで、不正中継が出来てしまいます。


【4】

一般的なメーラで普通のなりすまし行為を行おうと
するならばHELO検証のときと、MAIL FROM:で名乗る
場合と、SMTP名前が異なるようには、なかなか
できないかもしれません。
スクリプト書くでしょうね、きっと。

さて
>>> MAIL FROM:<postmaster>
のように書くと、
ASIPは勝手に、自分ちのユーザだと解釈して
@mail.jibun.co.jpを補います。
このときに
dante.mail-abuse.org と
mail.jibun.co.jp とが
異なっていることに
気がついてくれないのです。
@mail.jibun.co.jpを
補う必要がないときには
きちんと比較して
「だめやんけ」と拒絶してくれるようです。

これが私の言っているバグ?です。

【5】簡単な再現TEST
ASIPの管理者の方、是非やってみてください。

ABUSENETの
中継TESTを使います。
パターンはいつも同じなので再現しやすいでしょう。

ここで出来ます。
http://www.abuse.net/relay.html

まず、普通にTESTして
不正中継を起こしていないことを確認します。

次に、メールサーバの中継対策はいっさいいじらずに
次のような工夫をします。

ユーザアカウントとして
<spamtest>
を登録してください。かっこは不要です。
ログイン可能としてください。
また、メール転送の許可を与えてください。
(既定値は、メール不可です。忘れずに)

これで再度、上記のTESTを行ってください。

ログを見てあきれてください。
relay@ほにゃらら様宛てのメールを
送れてしまいます。

−−−−−−−−−−−−−−−

この再現TESTの意味合いは
ABUSENETの自動試験が
ターゲットとなるASIPの
メールアカウント名前を盗んで
なりすましを行ったということを
シミュレーションするものです。

−−−−−−−−−−−−−−−−

【6】その他

私のところのサーバが気が狂っている(機が狂っている)
のであればさいわいです。
であるならば
ここで書いているバグレポートはくずかご行きですみます。

再現TESTをASIP6.3またはASIP.6.2で
確かめたレポートが、このBBSに載ることを
期待しております。

でもその前にこの書きこみ自体
抹消したほうがいいのかもしれません。

他のメールサーバではどうなのでしょう?

みなさんの知恵をお借りしいところです。


−−−−−−−−−−−−−−−−−

しあわせのツボ さんからのコメント
( Friday, December 22, 2000 19:49:31 )

確か直ってなかったんじゃないかな…と思いながら、
うちのASIP6.3.2でテストしてみました。
結論から言うと、通ってしまいます。

メーラに「サーバ:会社のASIP」「アカウント:ASIPのアカウント」と
設定し、個人で持っているISPのアカウント宛のメールを作成。
ISPにダイヤルアップし送信すると、見事ISPのmboxに到着。(TT)
行って戻ってるだけですが、「第三者>ASIP>第三者」であることには
変わりありません。
スクリプトなんぞ使わなくても、普通にメーラを設定するだけで
送れてしまいます。

qmailを勉強ようか、それともやっぱりEIMSを買ってもらうべきか…

今泉克美 さんからのコメント
( Friday, December 22, 2000 21:05:08 )

−−−−−−−−−−−−−−−−−−
さっそくの追試、有難うございます。>しあわせのつぼさん
LANにつながっていない、つまり外部の
個人で持っているパソコン(仮想の不正中継者のPC)に
会社のASIPのサーバ名と会社で使っているアカウントを設定し
送り先をしあわせのつぼさん宛てにして
ためしてみたわけですね?
私のところとは微妙に症状が違うかもしれませんが
大筋において中継されているわけです。

そうですか、普通のメーラでできますか。。。。(TT)

−−−−−−−−−−−−−−−−−−−

さて、さきほどアップの私の記事の実証メールサーバログを
以下に書きます。
途中、二重線でくぎらているのは、私がいれた二重線です。
二重線の前は、ABUSEによるTESTです。
二重線の後は、外部からメーラをつかって試験したものです。
前者は不正中継に成功し
後者は不正中継に失敗しています。
後者は、簡単ななりすましを試みたものです。
別スレッドで御紹介したように、アドレス不一致で失格宣言です。
ただし、HELO検証だけで落としていることが見てとれます。
いきなりはねている。
DNSにて逆引きしてエラーですよと言っています。

凡例:プライバシー保護のためにいくつか偽装しております。
偽装のほかには手を入れていません。

***.***.***.***
--------------------->お世話になっている外部のDNS

111.111.111.111
--------------------->私のところのサーバのグローバルアドレス

www.jibun.co.jp
--------------------->私のところのサーバのホスト名(DNS名)

222.222.222.222
--------------------->お隣さんの会社のグローバルアドレス

ご注意:前半のABUSEBETさんは、不正中継ができるところまで
確認して、実際にはメールを送ってませんので、
[SMTP-Out]のログは表示されておりません。

また、わかりやすくするため通常のログよりも詳細レベルまで取りました。
具体的には、記録パネルにてプロトコル証明の
SMTP受信接続とSMTP送信接続を採取するようにいたしました。

========= ここよりログ開始 ========

2000年 12月 22日 (金) 7:50:34 PM - AppleShare IP Mail Server 6.2.1 を開始しました。時刻:2000年 12月 22日 (金) 7:50:34 PM
2000年 12月 22日 (金) 7:50:37 PM - サーバはボリューム“Macintosh HD”上にすでに存在するメール・データベースを使用しました。
2000年 12月 22日 (金) 7:50:37 PM - AppleTalk は“使用”に設定されています。
2000年 12月 22日 (金) 7:50:37 PM -     AppleTalk サーバ名:Mac server
2000年 12月 22日 (金) 7:50:37 PM -     AppleTalk ゾーン名:*
2000年 12月 22日 (金) 7:50:37 PM -            AppleTalk ノード: 173
2000年 12月 22日 (金) 7:50:37 PM -         AppleTalk ネットワーク: 41201
2000年 12月 22日 (金) 7:50:38 PM - ### 設定の確認:IP アドレス 111.111.111.111 は DNS 名“www.jibun.co.jp”に割り当てました。
2000年 12月 22日 (金) 7:50:38 PM -                          ドメイン名“www.jibun.co.jp”上のローカル配送の検証確認は進行中です。
2000年 12月 22日 (金) 7:50:53 PM - ### 設定の確認:“www.jibun.co.jp”で受信したすべてのメールはローカルの配送として扱います。
2000年 12月 22日 (金) 7:50:53 PM - TCP/IP は有効に設定されています。
2000年 12月 22日 (金) 7:50:53 PM -                    現在の IP アドレス: 111.111.111.111
2000年 12月 22日 (金) 7:50:53 PM -     現在の DNS サーバの IP アドレス: ***.***.***.***
2000年 12月 22日 (金) 7:50:53 PM -          現在のメールサーバの DNS 名: www.jibun.co.jp
2000年 12月 22日 (金) 7:50:53 PM - 
2000年 12月 22日 (金) 7:50:53 PM - このメモリの容量で許可されている POP3/IMAP 接続数: 26
2000年 12月 22日 (金) 7:50:53 PM - このメモリの容量で許可されている SMTP 受信接続数: 10
2000年 12月 22日 (金) 7:50:53 PM - このメモリの容量で許可されている SMTP 送信接続数: 5
2000年 12月 22日 (金) 7:57:47 PM - SMTP 受信の接続 [208.31.42.77] は、Real-time Blackhole リスト <rbl.maps.vix.com> の検証行程にあります。
2000年 12月 22日 (金) 7:57:47 PM - 
2000年 12月 22日 (金) 7:57:47 PM - SMTP 受信の接続 [208.31.42.77] の接続が許可されました。既知のジャンクメールソースではありません。
2000年 12月 22日 (金) 7:57:47 PM - [SMTP-In  30626] <<   220 www.jibun.co.jp AppleShare IP Mail Server 6.2.1 SMTP Server Ready
2000年 12月 22日 (金) 7:57:47 PM - [SMTP-In  30626]   >> HELO www.abuse.net
2000年 12月 22日 (金) 7:57:47 PM - TCP/IP 経由の SMTP 受信の接続を確立しました。
2000年 12月 22日 (金) 7:57:47 PM -      発信元の DNS 名: “www.abuse.net [208.31.42.77]”
2000年 12月 22日 (金) 7:57:47 PM -                    実際の接続 IP アドレス:[208.31.42.77]
2000年 12月 22日 (金) 7:57:47 PM - [SMTP-In  30626] <<   250 Hello, www.abuse.net [208.31.42.77], I'm www.jibun.co.jp.
2000年 12月 22日 (金) 7:57:56 PM - [SMTP-In  30626]   >> RSET
2000年 12月 22日 (金) 7:57:56 PM - [SMTP-In  30626] <<   250 OK
2000年 12月 22日 (金) 7:58:08 PM - [SMTP-In  30626]   >> MAIL FROM:<spamtest@abuse.net>
2000年 12月 22日 (金) 7:58:08 PM - [SMTP-In  30626] <<   250 <spamtest@abuse.net>... Sender OK
2000年 12月 22日 (金) 7:58:09 PM - [SMTP-In  30626]   >> RCPT TO:<relaytest@abuse.net>
2000年 12月 22日 (金) 7:58:09 PM - [SMTP-In  30626] <<   553 <relaytest@abuse.net> - Recipient Rejected! From domain "abuse.net" has delivery restrictions in place.  No SMTP mail relay is allowed.
2000年 12月 22日 (金) 7:58:09 PM - [SMTP-In  30626]   >> RSET
2000年 12月 22日 (金) 7:58:09 PM - [SMTP-In  30626] <<   250 OK
2000年 12月 22日 (金) 7:58:10 PM - [SMTP-In  30626]   >> MAIL FROM:<spamtest>
2000年 12月 22日 (金) 7:58:10 PM - [SMTP-In  30626] <<   250 <spamtest@www.jibun.co.jp>... Sender OK
2000年 12月 22日 (金) 7:58:10 PM - [SMTP-In  30626]   >> RCPT TO:<relaytest@abuse.net>
2000年 12月 22日 (金) 7:58:10 PM - [SMTP-In  30626] <<   250 <relaytest@abuse.net>... Recipient OK
=====================================2000年 12月 22日 (金) 8:10:02 PM - SMTP 受信の接続 [222.222.222.222] は、Real-time Blackhole リスト <rbl.maps.vix.com.> の検証行程にあります。
2000年 12月 22日 (金) 8:10:02 PM - 
2000年 12月 22日 (金) 8:10:09 PM - SMTP 受信の接続 [222.222.222.222] の接続が許可されました。既知のジャンクメールソースではありません。
2000年 12月 22日 (金) 8:10:09 PM - [SMTP-In  74859] <<   220 www.jibun.co.jp AppleShare IP Mail Server 6.2.1 SMTP Server Ready
2000年 12月 22日 (金) 8:10:09 PM - [SMTP-In  74859]   >> HELO www.jibun.co.jp
2000年 12月 22日 (金) 8:10:25 PM - TCP/IP 経由の SMTP 受信の接続が拒否されました
2000年 12月 22日 (金) 8:10:25 PM -      発信元の DNS 名: “www.jibun.co.jp ([222.222.222.222] <DNS reverse-ip-error - [-3162]>)”
2000年 12月 22日 (金) 8:10:25 PM -                    実際の接続 IP アドレス:[222.222.222.222]
2000年 12月 22日 (金) 8:10:25 PM - [SMTP-In  74859] <<   554 SMTP rejecting connection - Connection HELO name (www.jibun.co.jp ([222.222.222.222] <DNS reverse-ip-error - [-3162]>)) does not match reverse DNS information.

========= ログ終り ============



今泉克美 さんからのコメント
( Friday, December 22, 2000 21:22:01 )

*発言者の申し出により発言を削除しました。*
(12/22/2000 22:44)

なお、この会議室では、田中が個人で運営しているという運営の都合上、
削除等の申し出にすぐにお応えできない場合があることは、ご理解ください。

今泉克美 さんからのコメント
( Friday, December 22, 2000 21:28:05 )

あぁぁ!プライバシーが洩れている!
田中先生!上の記事を削除願いますーー。

お手間をとらせて
申し訳ありません。m(_ _)m

正しく修正したものを下にペーストします。

以下、さっきの投稿を補正したもの。

−−− 8< −−− 8< −−− 8< −−− 8<

ところで
APPLEには
どのような窓口へ、これらのことを
連絡すれば良いでしょう?
専門の窓口のメールアドレスがあれば
ご教示頂きたくお願い申し上げます。

なお、
spamtestのユーザアカウントを取っ払うと
ABUSENETのTESTには合格します。

また有名どころのPostmasterなどは
受信専用にしています。(転送してしまいます)
Webサイトで公開しているアカウントは
このような処置をとっています。
これならその名前で「なりすまられても」
中継しませんので。

問題は個人のアカウントですねー。
こればっかりはどうにもなりません。

また、さきほど思い出して
アップグレードする前の
Asip6.1時代の
ログを見ていたのですが
上のログと同じで
spamtestをアカウントで用意してあってですね

>>> MAIL FROM:<spamtest>
<<< 250 <spamtest@www.jibun.co.jp>... Sender OK
>>> RCPT TO:<user2@popovich.net>
<<< 553 <user2@popovich.net> -www.jibun.co.jp" has delivery restrictions in place.  No SMTP mail relay is allowed.

となっていてキチンと中継を阻止していました。(−−)?

わっかんねーよーーーーー


今泉克美 さんからのコメント
( Friday, December 22, 2000 22:28:00 )

しあわせのつぼさんの
実験を見て私もやり方を変えてみました。

さきほど揚げた長大なログの後半は
2000年 12月 22日 (金) 8:10:09 PM - SMTP 受信の接続 [222.222.222.222] の接続が許可されました。既知のジャンクメールソースではありません。
で始まっています。
これはお隣の会社のサーバから直にやりました。

やはりお隣にお邪魔して
LAN上のクライアント
富士通系で出しているポケットメイラーで
サーバ名とアカウント名前を設定してみたのがひとつ
やはりLAN上のクライアントから
MSのoutlookExpress97で
サーバ名とアカウント名前を設定してみたのが2番目
以上を実験しましたが
LANから行ったせいか
お隣さんのサーバのアドレスがどうしても正直に出てしまい
554 SMTP rejecting connection - Connection HELO name (www.jibun.co.jp (***** <DNS ??????reverse-ip-error - [-3162]>)) does not match reverse DNS information.
で中継拒否されてしまいます。但し、****と?????は偽装しました。

実をいうと、ASIP6.2にアップグレードして
SPAM対策をこうじたあと、まっさきに
今日と同じことをして
「しめしめ、効いてる効いてる。」
と思ったのです。
その前のASIP6.1時代では、私風のなりすましで大通りであったもので
それとくらべて一安心していたわけです。

不正中継元として
ダイアルアップで実験する必要があるような気がしてきました。

もう帰ります。ネムイから。


しあわせのツボ さんからのコメント
( Saturday, December 23, 2000 00:33:26 )

逆引エラー-3162は「そんなレコードはない」かな?
クライアントがDHCPでIPをもらってて、そのIPを
DNSの逆引に登録していなかったりする場合によく出ます。

先ほどの実験にはブラウザボードを使い、PIAFSのAPに
ダイヤルアップして実験しました。
ログによると、クライアントはHELOの後に生IPを名乗っています。
そもそも逆引チェックができません。あまり見ない仕様ですね。
家に帰ってNetscape Messangerで追試しようとしたところ、
「ちゃんと@以下も書かなきゃダメだよー」と
ASIP以前にMessagnerに弾かれました(苦笑)。

穴があること自体は(決していいことではないのですが)
人がつくるものですからしょうがないとは思うのですが、
既知の穴を直さないのには不信を抱きます。

SIMS太郎 さんからのコメント
( Saturday, December 23, 2000 16:53:31 )

MRJなんかもそうだけど、アップルは積極的にセキュリティホールを
ふさぐような会社じゃないんでしょう。

>>qmailを勉強ようか、それともやっぱりEIMSを買ってもらうべきか…

SIMSじゃダメなんですか?


たまちゃん さんからのコメント
( Sunday, December 24, 2000 23:07:14 )

>MRJなんかもそうだけど、アップルは積極的にセキュリティホールを
>ふさぐような会社じゃないんでしょう。

今年に入ってからだと思いますけど,ASIP のウェブサーバにセキュ
リティホールが見つかって,ASIP ML で報告や議論がなされ,かなり
早く修正版が出たのをご存知でしょうか。また Open Transport に潜
んでいた数々の穴を防いできたのをご存知でしょうか。

問題を的確に伝えて,再現性が確認されて,なおかつ対応がなされな
かった場合に「積極的でない」と判断すればどうかと思います。

このスレッドの1件については,事態を把握していない恐れがあるか
もしれません。ASIP のメーリングリストに投稿されてみてはどうで
しょうか。何らかの反応があるはずです。

SIMS もいいメールサーバだと思いますが,セキュリティ面で EIMS や
Communigate Pro の方に実装されていて,SIMS にないものもあります
ので,無条件に選択出来ないかもしれません(フリーウェアのサーバ
としてはサポートも含め,すぐれているとは思います)。

今泉克美 さんからのコメント
( Monday, December 25, 2000 10:20:07 )

田中先生、お疲れのところ
削除いただきありがとうございます。
以後、気をつけます。

>みなさま
コメントありがとうございます。
こういう雰囲気がありがたいです。

>しあわせのつぼ様

>逆引エラー-3162は「そんなレコードはな「」かな?
>クライアントがDHCPでIPをもらってて、そのIPを
>DNSの逆引に登録していなかったりする場合によく出ます。

DHCPのときにも(設定しだいでは)出るメッセージでしたか。。
うちはDHCP使ってなかったので、参考になりました。
ありがとうございます。(DHCP使おうかな?と思っていたものですので)

www.jibun.co.jpの本来のアドレスが111.111.111.111/24
のはずなのに、
222.222.222.222から
www.jibun.co.jpから来るとはなにごとじゃ?
という検査ですが
この検査のときにDNS逆引きをしているのだと思います。たぶん。

これで、なりすましを防ごうとしているのでしょう。

ところで、DHCPですが。
メールサーバがグローバルアドレスを持っているときに
クライアントがDHCPで,プライベートアドレスを振られて
そのまんまメールサービスを使おうとすると
www.jibun.co.jp(192.168.***.***)とは
なにごとじゃ?www.jibun.co.jp(111.111.111.***)であるべきじゃ!
と判断してエラーにしてくれるのではないかと
推察されます。このときにも
-3162とか-3170とかが出ると思います。

この辺まわりでは
プライベートアドレスを振っているLAN上のクライアントと
サーバとの間で、NATでもかますとうまくいくのかもしれませんが
実験できるほどのゆとりもないので確証とれていません。

>しあわせのつぼ様wrote
>ログによると、クライアントはHELOの後に生IPを名乗っています。
>そもそも逆引チェックができません。あまり見ない仕様ですね。

そうですね。あまりみない仕様ですね。
プライベートアドレスを固定で持つ場合、
グローバルアドレスを持つメールサーバ(ASIP)に直接
つなげる場合に、上記の逆引きHELO検証に抵触しないように
する裏ワザ?として、
win95で取りえる手段を書いてみます。

[ネットワークのプロパティー]/[ネットワークの設定]パネル/
/[TCI/IPのプロパティー]選択/[DNS設定]パネル選択/
/「DNSを使う」を選択し
ホスト名=クライアントに与えられたIP
ドメイン名=空白

以上で、HELO検証にひっかからないクライアントが
作れてしまいます。
しあわせのつぼ様御指摘のログのように
生IPが直接見えるだけの変なログに
なりますが、動作上は使えてしまいます。

クライアントが
他にWindowsNTのドメインとか、そういったものに
はいる必要があるときには使えませんし
DHCPでも使えません。

------------------------------
実をいうと
ホスト名
ドメイン名
について

クライアントがプライベートアドレス
ASIPメールサーバがグローバルアドレス
を持っている場合に
いったい何を設定するのが
一番マトモなのか
恥ずかしながら
私には不明です。

SPAMさわぎがおこる前に
構築されていたクライアントの
ホスト名、ドメイン名を見ると
各クライアントは全部同じ設定に
なっておりまして(--)
ホスト名=ワークグループ名(ASIPで定義してあるもの)
ドメイン名前=www.jibun.co.jp
になっておりました。
ASIP6.2の
不正中継対策を行ったあとは
上記の設定で
社内から、社外にメールが出せなくなりました。
プライベートアドレス上のクライアントが
【外部】のPCだと認識されたため、
外部へのメール送信を禁止されたのです。

DNSの設定をきちんと行えばすむ話なので
しょうけれども、、確証がえられず、
裏ワザで逃げているのが実情です。


コレ以上恥さらしてもしょうがないのですが
192.168.
ではじまるクラスCは
自動的に内部のクライアントだよ、と
ASIPが認識してくれると
とてもありがたいですね。
内部のクライアントからの
SMTP-IN
に対して
いちいち
リアルタイムブラックホールリストを
見にいったり
外部に委託してあるDNSを見にいったりで
マシンの負荷が高くなります。

私どものネットワーク構成のどこかが
間違っているからそうなるのだ
とわかればとても有りがたいことです。

なお、DNSを外部に委託していますが
こちらの設定を、クライアントごとに
プライベートアドレスを書いていくことが
何か、おかしな気がします。

ASIPの設定で
「こいつは内側のパソコンだからチェックしなくても大丈夫」
と思ってくれると嬉しいのです。

HELPみましたが
さっぱり手がかりがありませんでした。

-----------------------

ASIP ML 
のアドレスを教えてください。