Socketを使用したコネクションの確立
また困ってしまったので、お知恵をお貸しください。
自作プログラムでメールサーバーにwinsockを利用してconnectしたいのですが、コネクションの確立が上手く出来ません。
普通にメールサーバー（xmail）を立て、そちらから転送する様子をパケットトレースしました。
パケットの内容がわからないので、上手く説明できないのですが、
こちらのIP -> 接続先IP
（しばらく時間があり）
接続先IP -> こちらのIP
こちらのIP -> 全く違うIP
全く違うIP -> こちらのIP
～メールのやり取り～
こんな感じで、接続先のIPから返答パケットが帰ってきた後、まったく別のIPへ接続し、メールの送信を行っています。
ところが自作のプログラムではconnect時にタイムアウトとなってしまい、接続の確立が行えません。
こちらのIP -> 接続先IP
（しばらく時間があり）
接続先IP -> こちらのIP
こちらのIP -> 接続先IP
～タイムアウト～
隠蔽されたconnect関数内で行われている事なので、サッパリです。
よろしくお願い致します。
日時:
02/06/29 16:17
コメント
2番目のパケットの詳細がわかれば手がかりがつかめるかも
AUT'Sさん，こんにちわ。
メールサーバにアクセス制限か何か設定されていませんか？
このやり取りを見る限り，SMTPのやり取りが始まる前の，
TCPの接続動作に失敗していますから，
これは，SMTP以前の問題だと思います。
>こちらのIP -> 接続先IP
>（しばらく時間があり）
>接続先IP -> こちらのIP
このパケットの中身がわかると手がかりになるんですが．．．
>こちらのIP -> 接続先IP
>～タイムアウト～
2番目のパケットは．．．
こんわばんわ。
>メールサーバにアクセス制限か何か設定されていませんか？
>これは，SMTP以前の問題だと思います。
そうなんです。IP転送？か何かが設定されているようです。
どうやら、スパム対策のようで．．．。
パケットなのですが、キャプチャするのは良いのですけど、実際見ても全く意味不明なのです。
マスタリングTCP/IP応用編に照らし合わせて読んでるのですけど、不要なパケットが多すぎて、本質をつかめません。
2番目のパケットの中身なのですが、本によると同期を取る手続きをしているみたいです。
その後、なぜか唐突にサーバー側よりコネクションを解除されます。
しかし、本物？メールサーバー（xmail）はなぜか指定もされていないdomainをDNSから解決し、
全く別のサーバーにアクセスして送信を済ませてしまいます。
ところが、connect関数で普通に接続した場合は、上記の作業が行われません。
また、２番目に接続されるサーバーに直接のアクセスは不可能みたいです（pingは帰ってきますが、接続はできません）。
パケットトレースの結果を見てもらえれば解決するかもなのですが、それをお伝えする能力もありません。
どうしたらいいでしょう？（どうか見捨てないで下さい！（汗；）
メールサーバは転送先情報をDNSサーバから入手します
こんばんわ。
今日は蒸し暑かったですね。
>2番目のパケットの中身なのですが、
>本によると同期を取る手続きをしているみたいです。
>その後、なぜか唐突にサーバー側よりコネクションを解除されます。
先日のパケットの説明だと，向こう側からパケットが返ってきたら，
メールサーバは別のサーバに接続しているので，
多分，同期をとっているんじゃなくて，
向こう側が接続を拒否しているんだと思います。
TCPコントロールビットのRSTが1にセットされているんじゃないかしら？
ちなみに，TCPコントロールビットっていうのは，
普通，イーサネットのパケットの先頭から48バイト目の6ビット目です。
>しかし、本物？メールサーバー（xmail）は
>なぜか指定もされていないdomainをDNSから解決し、
>全く別のサーバーにアクセスして送信を済ませてしまいます。
メールサーバは，DNSサーバにメール配送先（メールアドレスの@以後の文字列）
を問合せ，その回答に従って，メールサーバに接続します。
つまり，下の例のように，
DNSサーバからメールサーバが複数回答されるような場合は，
優先順の高いもの（preferenceの値の小さいもの）から順番に接続を試して，
つながった相手にメールを送るわけです。
（メールサーバ自身に，メール転送先が設定されている場合もありますが，それは例外）
だから，別のサーバにアクセスしても不思議はありません。
◆nslookupというユーティリティでDNSサーバに問合せた例
Windowsのサーバ版やXPに入っています。
手元にあったら，試してみるとよいでしょう。
-----[ここから]-----
c:\>nslookup
Default Server: xxxx.glasscom.com
Address: 10.10.1.80
> set type=mx <-- メール配送先を問合せるための指定
> xxxxxxx.com. <-- メールアドレスの@以後の文字列
Server: xxxx.glasscom.com
Address: 10.10.1.80
Non-authoritative answer:
xxxxxxx.com MX preference = 5, mail exchanger = mx1.xxxxxxx.com
xxxxxxx.com MX preference = 10, mail exchanger = mx2.xxxxxxx.com
xxxxxxx.com nameserver = ns.xxxxxxx.com
xxxxxxx.com nameserver = ns.usec.xxxxxxx.com
mx1.xxxxxxx.com internet address = 192.0.2.31
mx2.xxxxxxx.com internet address = 192.0.2.43
-----[ここまで]-----
>また、２番目に接続されるサーバーに直接のアクセスは不可能みたいです
>（pingは帰ってきますが、接続はできません）。
うーむ。
そっちのメールサーバにも，アクセス制限がかかっているのかもしれません。
ファイアウォールでパケットを遮断しているのかな？
まあ，とにかく，何かあるはずです。
>不要なパケットが多すぎて、本質をつかめません。
まず，キャプチャしたパケットを表示するときに，
フィルタ条件を設定して，不要なパケットを表示しないようにしましょう。
>マスタリングTCP/IP応用編に照らし合わせて読んでるのですけど、
そうやって不要なパケットを除いてから，ゆっくり，解説書とにらめっこすれば，
雰囲気はわかると思います。
それから，キャプチャするソフトの表示がわかりにくい，
という場合もあるかもしれません。
分かりにくかったら，別のキャプチャソフトを試して見ましょう。
解説書が分かりにくいのかもしれません。
別の本も読んでみましょう。
パケットの中身を調べるのって最初は難しいかもしれませんけど，
わかってしまえば，『なんだぁ，そんなことかぁ』っていうくらいで，
そんなに難しいことではありません。
あせらず，あきらめず，トライすれば道は開けると思います。
ちょっとだけ進歩しました。
こんばんわ。
こちらは風鈴がなんとか暑さを紛らわせてくれるレベルです。
これ以上に蒸す夜が来ると、クーラーの出番ですね．．．。
>TCPコントロールビットのRSTが1にセットされているんじゃないかしら？
はい、調べてみたら思いっきり拒否されていました。
すぐにRSTが帰ってきてしまい、接続できない状況でした。
>DNSサーバからメールサーバが複数回答されるような場合
複数のサーバーが立っている可能性がある事を、すっかり忘れていました（汗。
さっそく、プロバイダのDNSサーバーより相手先のMXを引いてみました。
すると３つも返ってきました。さすが大手プロバイダ。
>>また、２番目に接続されるサーバーに直接のアクセスは不可能みたいです
>そっちのメールサーバにも，アクセス制限がかかっているのかもしれません。
その様です。ただ、こちらはナゾです。
RSTが帰ってくるのではなく、connect関数がタイムアウトを起してしまいます。
かなり時間がたってからポツンとパケットが届き、ACKが立っています。
サーバーが込み合っているのでしょうか？
また、今回新たに発見された（？）第３番目のサーバーですが、
問題なく繋がるのですが、メール本体を受け取ってくれません。
RCPTステップで551が返ってきます。
念のため、こちらもグローバルIPで25/110/113ポートあたりを
開けてみたのですが、サーバー確認接続に来る様子もありません。
やはり、どこか本物のメールサーバーと違う動きがあるのかもしれません。
>あせらず，あきらめず，トライすれば道は開けると思います。
はい。頑張ります！
そんなこんなで、１日１時間はメールサーバーのパケットの動きを追ってます。
まだ完全に理解はできていませんが、だんだんTCP(UDP)/IPの世界が見えてきました。
実験相手のサーバはどんなもの？
>さっそく、プロバイダのDNSサーバーより相手先のMXを引いてみました。
>すると３つも返ってきました。さすが大手プロバイダ。
実験に使っているサーバは，どこのサーバですか？
もし，実運用中のサーバ，しかも，自分で管理しているものではない
サーバを相手に実験しているのだったら，止めた方がいいと思いますよ。
それが元でトラブルが発生したら大変ですから。
実験するときは，自分でサーバを動かして実験しましょう。
そうすれば，ここでやり取りしているような疑問を持たずに，
スムーズに実験できると思います。
実験環境では問題ないのですが．．．
遅くなってしまい、申し訳ありません。
時間が作れなかったもので．．．。
>実験に使っているサーバは，どこのサーバですか？
DIONのサーバーです。自分の名義で契約しているメールアドレスに対して
メールを送ろうとしました。
>実験するときは，自分でサーバを動かして実験しましょう。
実験環境で問題がなかったので、インターネット上で動作させて見ました。
ところが見事に失敗してしまいましたが．．．。
パケットトレース等はxmailサーバーを立ち上げて、それの動作を追っています。
xmail自体は正しく動作し、またメールも正しく送信されているので、問題ないと思います。
恐らくプロバイダや実運用中のメールサーバーには迷惑をかけてないと思いますが．．．。
甘いでしょうか？
万一障害が起きたら．．．
>恐らくプロバイダや実運用中のメールサーバーには迷惑をかけてないと思いますが．．．。
もちろん，この程度のことでサーバが止まっては困りますから，
プロバイダは，それなりの対策を取っているはずです。
だから，アクセスできないのだと思います。
しかし，世の中に完全な対策というのはありませんから，
これが原因でプロバイダのサーバに支障が起こる可能性はゼロとはいいきれません。
>甘いでしょうか？
甘いか辛いかというようなことではなく，
このような掲示板でそうした行為を勧めるようなことはできないんですよ。