こんばんわ。 今日は蒸し暑かったですね。
>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応用編に照らし合わせて読んでるのですけど、
そうやって不要なパケットを除いてから，ゆっくり，解説書とにらめっこすれば， 雰囲気はわかると思います。 それから，キャプチャするソフトの表示がわかりにくい， という場合もあるかもしれません。 分かりにくかったら，別のキャプチャソフトを試して見ましょう。 解説書が分かりにくいのかもしれません。 別の本も読んでみましょう。
パケットの中身を調べるのって最初は難しいかもしれませんけど， わかってしまえば，『なんだぁ，そんなことかぁ』っていうくらいで， そんなに難しいことではありません。 あせらず，あきらめず，トライすれば道は開けると思います。
More information about text formats
メールサーバは転送先情報を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応用編に照らし合わせて読んでるのですけど、
そうやって不要なパケットを除いてから，ゆっくり，解説書とにらめっこすれば，
雰囲気はわかると思います。
それから，キャプチャするソフトの表示がわかりにくい，
という場合もあるかもしれません。
分かりにくかったら，別のキャプチャソフトを試して見ましょう。
解説書が分かりにくいのかもしれません。
別の本も読んでみましょう。
パケットの中身を調べるのって最初は難しいかもしれませんけど，
わかってしまえば，『なんだぁ，そんなことかぁ』っていうくらいで，
そんなに難しいことではありません。
あせらず，あきらめず，トライすれば道は開けると思います。