|
707) メールの送信 まこと 2003/10/17(金) 10:33 |
|
こんにちは バッチ起動でメールを送信したいと思っています。 start mailto:XXXX@XXXX.co.jp?subject=test^&body=test だとメール作成画面が立ち上がるだけでした。 送信まで自動化したいのですが、 何か方法をご存知の方宜しくお願いします。 |
|
708) Re:メールの送信 ふぇむ 2003/10/17(金) 11:13 |
|
>バッチ起動でメールを送信したいと思っています。 メールを送信するということは、 (1)RFCで定められた範囲の形式・書式や文字コード等にのっとった、適切なメールヘッダ・メール本文をもつテキストを作成する。 (2)このテキストを、SMTPプロトコルにのっとり、SMTPサーバに接続して対話しつつ必要ならば適切な情報もさらに付加しつつSENDする。 ということだと思います(添付ファイル等も、(1)の範囲で吸収されます)。 これ全体をラップして、引数等によって必要な情報を得て上記(1)のように整形し、(2)のようにSMTPサーバとの通信をこなしてくれるようなツールがあれば、自力でこのような処理の心臓部分を作成する必要はなくなり、その外側の制御だけを書けばよいことになります。 ということで、このツールとしてバッチ処理から利用可能なものがあれば、所望のことができると思います。 ユーザビリティの高いツールはあまり知らないのですが、とりあえず例えば以下のような手段が思い浮かびます。他にあれば皆さん補足くださいませ。 (1)UNIXベースのコマンド群をWindows上からでも利用できるようにした cygwin を使って sendmail 等のUNIXコマンドで送る。 (2)Microsoft提供のスクリプト環境である Windows Scripting Host からSMTPを話すライブラリ(COM等)を呼ぶような形で書く。 (3)オブジェクト指向スクリプト言語 Ruby にたしかSMTPのライブラリもあったと思うので、それを使ってRubyで書く。その他のスクリプト言語でもSMTPのライブラリがあれば同様です。スク リプト言語 perl に Windows環境で使える SMTPのライブラリがあるかどうかは私は知りません。UNIX上のものが最終的に /usr/lib/sendmail へのパイプ渡しで実装されていたりすると、Windows上では使えません。 うーん、どれも開発っぽいな(^^;。 その他、所望のことができるようなフリーウェアないしシェアウェア等があるかどうかは、検索等で自分で調べてみてくださいませ。また、いいのが見つかったら教えてくださいね。 |
|
709) Re2:メールの送信 ふぇむ 2003/10/17(金) 11:17 |
|
少々補足。 >(2)Microsoft提供のスクリプト環境である Windows Scripting Host からSMTPを話すライブラリ(COM等)を呼ぶような形で書く。 拾ってくる情報がユーザプロパティ等環境側に記述されたものとして扱いたいならば、環境によっては、SMTP直接ではなく MicrosoftのMAPI(Messaging API)経由で送るのが適切かもしれません、が、結構環境に依存するんじゃないかなぁ... |
|
710) Re3:メールの送信 とっぽ 2003/10/17(金) 12:18 |
|
http://forum.nifty.com/fpcu/top/doslog01/0030.htm |
|
以前自分が悩んでいたことに、近いのかな? 過去ログを貼っておきます。 参考になれば・・・・ |
|
711) Re2:メールの送信 ふぇむ 2003/10/17(金) 14:16 |
|
>その他、所望のことができるようなフリーウェアないしシェアウェア等があるかどうかは、検索等で自分で調べてみてくださいませ。また、いいのが見つかったら教えてくださいね。 ちょっと調べてみたら、こういうのもありますね。使えるかも。(私もまだ全然みていません) ●JgaaのwMailTo http://support.jgaa.com/index.php?cmd=ShowProduct&ID=510&PHPSESSID=7a76b280c41ef05c32475c54224a8a33 引用:「wMailTo (TM) is a handy 32 bit DOS program used to send email and news postings directly from the command line. It can be used interactively, or you can call it from other programs, DOS .bat files or Pearl scripts. 」 ●JgaaのwSendMail http://support.jgaa.com/index.php?cmd=ShowProduct&ID=500&PHPSESSID=7a76b280c41ef05c32475c54224a8a33 引用:「wSendmail is a tiny Win32 utility that sends emails from the command line - or you can use the program directly as a standard CGI-BIN app. In CGI-BIN mode it will pick the data from your HTML Forms and send it all as email to whoever you choose.」 |
|
712) Re:メールの送信 じゃく 2003/10/17(金) 14:24 |
|
コマンドラインでメールを送信する専用クライアントが フリーソフトでありました。 http://www2.tokai.or.jp/uminchu/library.html#SSMAIL |
|
714) Re2:メールの送信 まこと 2003/10/20(月) 12:18 |
|
まことです。 >コマンドラインでメールを送信する専用クライアントが >フリーソフトでありました。 >http://www2.tokai.or.jp/uminchu/library.html#SSMAIL ありがとうございます。 早速使おうとおもって、インストール後起動したら、 SMTPのHostを聞かれました。 SMTPのホストってどうやればわかるのでしょうか? ここでの質問内容ではないのかも知れませんが・・・、もしご存知でしたらお願い致します。 |
|
716) Re3:メールの送信 ふぇむ 2003/10/20(月) 14:20 |
|
>早速使おうとおもって、インストール後起動したら、 >SMTPのHostを聞かれました。 >SMTPのホストってどうやればわかるのでしょうか? そのソフトをまだ見てないのでなんともわかりませんが、外から見た自分の名前か、接続先のサーバの名前か、どちらかでしょうね。前者のような気がします が... 前者であれば、それはたぶんメールのエンベロープにおける Return-Path に使われるのではないでしょうか?とすると、メールを受け取ることのできる名前でなければならないでしょう。 後者の場合。通常、SMTP接続先のサーバに関する情報は、配送先に対して定義されたDNSのMXフィールドから情報を得ると思うので、もしもその SMTPクライアントソフトがDNSのMX配送に対応しておらず、STATIC配送を前提としている場合であれば、STATIC配送先のSMTPサーバに 関する情報が固定的に必要となりますので、それかもしれない、ということです。 上のどっちかだと思いますが、マニュアルとかついてません? どっちにしても、環境上どうなっているのかをよくわかっておかないといろんなトラブルを招くおそれがあって、十分注意が必要です...うかつに変なメール を出して大混乱~例えばエラー発生時の戻り先がそのエラー発生元でエラーメールがループ&増殖して最終的にネットワークがダウンするとか...~というよ うなトラブルを起こしたりしないように、注意してくださいね。 |
|
717) Re4:メールの送信 ふぇむ 2003/10/20(月) 14:37 |
|
>トラブルを起こしたりしないように、注意してくださいね。 「注意してくださいね」と書きましたが、すみません、そのままでは注意のしようがないかもしれませんね。(^^; この機会に、自分の周囲の環境はどうなっているのか、メールの送受信にかかわる仕組みはどうなっているのか、などを調べて理解してみると有意義だと思います。 私のお勧めとしては。 メールを自動送信するシステムのテストは、できればまずクローズドなメール配送系をテスト環境系としてつくってその中で行なうことをお勧めします。自由に 使えるUNIX機(Linuxでよい)があれば、環境の構築は(知識があればですが)比較的簡単だと思います。若手技術者の修練という意味でやらせてみる のもためになるかもしれません。 独立のルートドメインに属するDNSをたて、その中にテスト環境にかかわるドメインを立て、メールサーバをMX配送として正しく設定し、参照先のDNSを 上記の独立のルートに属するものにして、メールを受けるサーバにテスト用のアカウントを作成する、でいけるでしょう。このままでも到着したメールは UNIXの mail系コマンドで読めますが、さらに受信したメールをPOPで確認したいならば、メールサーバ上にPOP3のデーモンも立てれば、Outlook Expressなどから読みにいけます。これを独立のネットワーク内で行なえば、変なトラブルが発生しても、外界を大混乱に陥れずにすみます。 書くとちょっと高度に感じるかもしれませんが、実はたいしたことはありません。 私はメールのからみシステムを開発するときは、たいてい上記のように行なっております。だって怖いし、その方がいろいろ確認できるから。不達のテスト等も含めて。 |
|
718) Re4:メールの送信 ふぇむ 2003/10/20(月) 14:44 |
|
>>早速使おうとおもって、インストール後起動したら、 >>SMTPのHostを聞かれました。 >>SMTPのホストってどうやればわかるのでしょうか? > >そのソフトをまだ見てないのでなんともわかりませんが、外から見た自分の名前か、接続先のサーバの名前か、どちらかでしょうね。前者のような気がします が... 前者であれば、それはたぶんメールのエンベロープにおける Return-Path に使われるのではないでしょうか?とすると、メールを受け取ることのできる名前でなければならないでしょう。 メール配送先が直インターネットの場合、SPAMメールを避けるために、インターネット上のメールサーバは、送信自身が称する送信元の名前が、送信元のア ドレスからDNS逆引きして得られるドメインの一部でない場合に却下するというようなことを行なっているかもしれません(つまり勝手に外部ドメインを詐称 できないということ)。この点も注意が必要だと思います。 以上、この場で扱うべき話題ではないかもしれませんが、まあついでということで参考までにお書きしました。お許しください。 |
|
719) Re3:メールの送信 とっぽ 2003/10/20(月) 17:54 |
|
興味があったのでちょいとDLしてみました。 同胞テキストファイルよりの転載です。 -----ここから 1) 設定 ・引数なしで ssmail.exeを起動すると、設定ダイアログがポップアップします。 SMTPホスト メールサーバのホスト名を指定して下さい。 ユーザ名 メールサーバにログインする際のユーザ名を入力して下さい。 メールアドレス 送信元のメールアドレスを指定して下さい。 氏名 送信元の氏名を指定して下さい。日本語はできるだけ使わないで下さい。 BCC宛 送信ログ保管先のアドレスを必要に応じて指定して下さい。 エラーダイアログを表示しない ------ここまで ですので、お聞きになっているのは 送信用のSMTPサーバのホスト名です。 ふぇむ氏が指摘されている件は、サーバで変わりますので お使いのサーバを調べられたら、いかがでしょうか。 昔、僕がやったときは、ローカルにサーバをたてました。 久々に色々探してみたら、色々フリーソフトだいぶん増えていますね~ おっと、コマンドからかなり離れてしまいました。もうしわけない。 |
|
720) Re3:メールの送信 じゃく 2003/10/21(火) 09:40 |
|
まことさん、こんにちは。 >SMTPのホストってどうやればわかるのでしょうか? 確認ですが、まことさんは、「手動ではメール送信できるけど、 バッチを使って自動で送信したい」のですよね。 まことさんが、普段使われているメールソフトか、契約されている プロバイダ、(@nifty とか、 OCN とか Yahoo!BB)を教えてください。調べることができると思います。 例えば@niftyなら、以下のページの送信(SMTP)サーバとして 指示されている、smtp.nifty.com がSMTPのホスト名です。 http://www.nifty.com/support/manual/mail/win_oe55.htm |
|
721) Re4:メールの送信 ふぇむ 2003/10/21(火) 10:12 |
|
>確認ですが、まことさんは、「手動ではメール送信できるけど、 >バッチを使って自動で送信したい」のですよね。 >まことさんが、普段使われているメールソフトか、契約されている >プロバイダ、(@nifty とか、 OCN とか Yahoo!BB)を教えてください。調べることができると思います。 >例えば@niftyなら、以下のページの送信(SMTP)サーバとして >指示されている、smtp.nifty.com がSMTPのホスト名です。 とりあえず補足。 インターネットプロバイダの個人向けのメールサービス経由でメールを送信する場合ですが、@niftyがそうなんですが、一定時間以内に事前にPOPで読 みに行っておかないと認証エラーで送信接続を拒絶されます。これは自分の会員ではないユーザからの勝手な接続を回避するためだと思います。 この環境においてバッチ処理でメールをプロバイダのメールサーバ経由で送る場合、まずPOPで接続して認証を通らないと送信がエラーになることになります。 |
|
723) Re5:メールの送信 ふぇむ 2003/10/21(火) 10:26 |
|
>この環境においてバッチ処理でメールをプロバイダのメールサーバ経由で送る場合、まずPOPで接続して認証を通らないと送信がエラーになることになります。 もう少しすみません、DOSと関係薄いですが行きがかり上。 インターネット上のIP-Reachableなマシンからバッチ処理でメールを出すなら、DNSのMXをひいて相手先の指定するメールサーバに直接SMTP接続する方がいいのではないでしょうか。 直接という意味は、自前でローカルにメールサーバを置いて、クライアントからはいったんそこへ送るということも含めています。この場合、クライアントは固定的にローカルのメールサーバに接続すればよいだけで、プロバイダのメールサーバに接続するのと論理的には変りません。 あとはそのローカルのメールサーバが送信をやってくれます。DNSをひいて、送信を試みて、接続できなかったら一定時間後にリトライするようキューイングして、接続エラーはローカルに落として、.... とかやってくれるので、かえって楽だと思います。 問題はいったん接続して送信し終わった後の送信中継の中でエラーがあった場合の戻り先で、これを自分のメールアカウントになるような設定としておけば、このメールサーバは外からの着信を受ける必要もなく、とりあえず諸問題はクリアになるのではないかと思います。 |
|
724) Re5:メールの送信 ふぇむ 2003/10/21(火) 10:47 |
|
読み返してちょっと補足。 >@niftyがそうなんですが、一定時間以内に事前にPOPで読みに行っておかないと認証エラーで送信接続を拒絶されます。 なんか言い切ってるみたいに見えますが、メールサーバにおける認証方式はいくつかあるので、上記はたまたま @nifty がそうしてるようです(POP before SMTP、であってましたっけ)、ということにすぎず、他プロバイダはまたそれぞれだと思います。 |
|
725) Re6:メールの送信 ふぇむ 2003/10/21(火) 10:51 |
|
いっぱい書き込んだ後に今さらって感じですが(^^;、 まことさん: >バッチ起動でメールを送信したいと思っています。 この動機や背景、主旨・狙いなどを書いていただくと、話が発散しすぎないと思います(^^;。 |
|
728) Re7:メールの送信 まこと 2003/10/21(火) 16:26 |
|
どうも、まことです。 私のレベルではついて行けなくなり、今さら書き込むのもためらっていたのですが(笑)・・。 >いっぱい書き込んだ後に今さらって感じですが(^^;、 いえ、とんでもないです。非常に感謝しています。 > >まことさん: > >>バッチ起動でメールを送信したいと思っています。 > >この動機や背景、主旨・狙いなどを書いていただくと、話が発散しすぎないと思います(^^;。 > えーと、Win2000の中にバッチファイルを置き、FTP送信を自動化しようとしています。 そのFTP送信の中でエラーが発生した場合にメールでエラー通知を行おうとしています。 で、メール送信を行う時に、教えていただいた「Ssmail.exe」を使おうとしたら「SMTPのホスト」を聞かれ、「接続できません」 となってしまいました。 使っているプロバイダですが、申し訳ないのですが、業務上のことなので、ちょっと・・・。 とりあえず、私なりの理解では 「自ら(Win2000Server)がSMTPのホストになればメールが遅れるようになるが、もしメール送信時にエラーが発生した場合の戻りも考慮しなければならない。」 と思っているのですが、あってますか?(おおざっぱ過ぎたらごめんなさい。) |
|
729) Re8:メールの送信 ふぇむ 2003/10/21(火) 18:42 |
|
>えーと、Win2000の中にバッチファイルを置き、FTP送信を自動化しようとしています。 >そのFTP送信の中でエラーが発生した場合にメールでエラー通知を行おうとしています。 ジョブ障害の検知と通知をメールで行なうというわけですね。 気になる点は、まず電子メールというものは必ず到達する保証を持ったものではないので、万が一メールが送信できない場合にその障害が通知されない場合もありうる、という前提は持っておかなければならないと思いますが、そのへんは大丈夫でしょうか。 また、最終的に送信先に到達しなかった場合の戻り先をどうコントロールするか、戻ってきた後の運用をどうするか、などもシステム運用面の観点からは考慮済みでしょうか。 あと、環境面で、SMTP接続する元と接続する先の間のネットワーク上において、ルータやファイアウォール等でSMTP接続をカットするような設定等はないですよね? もしも直接外部とSMTP接続できない事情があれば、間を中継するメールサーバを置く必要があり、そうすると今度はそれがダウンしても良いように配送経路 を二重化する(複数の中継メールサーバを置いてDNSのMX定義で優先順位を振るなど)などのケアも必要となってくると思いますが、そのへんも大丈夫で しょうか。(たとえばインターネット系のシステムで、バッチサーバが内部LANにあり、ネットワークポリシーとしてDMZ上のWebサーバを経由しないと 外と通信できない、などという環境だとすると、特定のWebサーバにだけ中継のメールサーバをおくとそのWebサーバダウンor停止時に送れなくなりま す) 環境面がクリアなら、そのメールを送るバッチジョブ自身からは、直接の接続先であるSMTPサーバと接続できるかどうかだけの話ですね。それはもう単純にSMTPホストに接続するだけ、の話なので、接続できない場合の切り分けは比較的単純ではないでしょうか。 一番ありそうなのは、例えば単純にそのバッチサーバ上でSMTPホストの名前からアドレスが解決できないとか? 例えば、SMTPってポート23 なので、 telnet 接続先SMTPサーバ 23 で接続して手打ちでSMTPプロトコルを行なって、できるならば環境的には問題がないことになります。そこでダメなら環境側、それが通るならそのメールのツールの設定やら引数やら関係、というわけですね。 そうやってちょっとづつ切り分ければいけるのではないでしょうか。 |
|
730) Re9:メールの送信 ふぇむ 2003/10/21(火) 18:46 |
|
>例えば、SMTPってポート23 なので、 > >telnet 接続先SMTPサーバ 23 すみません、SMTPは 25 でした。 23 は telnet そのものでした。失礼。 telnet 接続先SMTPサーバ 25 が正解ですね。 |
|
731) Re8:メールの送信 ふぇむ 2003/10/21(火) 19:01 |
|
>とりあえず、私なりの理解では >「自ら(Win2000Server)がSMTPのホストになればメールが遅れるようになるが、もしメール送信時にエラーが発生した場合の戻りも考慮しなければならない。」 > >と思っているのですが、あってますか?(おおざっぱ過ぎたらごめんなさい。) ローカルないし内部にメールサーバを置くと何が違うかですが、アプリケーションないしジョブから見て「何をもってメール送信成功と見なすか」とか、「SMTP接続失敗時のリトライや再送信をどうするか」とか、設計上の考え方や自由度の点が違うということです。 所詮外部へのSMTP接続は成功するとは限らないので、アプリケーションからSMTP接続して成功したからといってそれは第1段目の中継サーバへは渡った ということにしかなりません(もしもそのサーバのローカルに送信先のアカウントがあれば、その成功がそのまま最終段のメールサーバまでの送信成功を意味し ますが、一般にはそんなことはありません)。 その時に、ジョブが「一定期間待って再度送信」なんてやってると今度はそのジョブ自身の主目的とは異なるでしょうからそれはきっとあんまりよろしくないでしょう。 それなら、ほとんど接続が成功しそうなローカルのメールサーバへ送っておいて、その後送信が成功したかどうかはメールサーバがらみの機構ないし運用にゆだ ねる方が、システム全体から見ると楽、だったりしませんか?せいぜいホップ数が1つ増える程度で、それは現在のインターネットのメール配送系においてホッ プ数オーバーで到達できない可能性は低いでしょうから誤差のうちでしょう。 ジョブ側は、ローカル側のメールサーバに一発接続して送れたら自分の責任範囲はOK、と割り切れます。 送れないとしたらそれはローカルのメールサーバ側つまり自分たちの手の内側の環境的な問題でしょうから、そういうレベルのエラーとして取り扱う。 で、ジョブからの接続・送信は成功したものの、最終的にメールが届かないとしたら、それはジョブとは関係なくメール配送系の上の何らかの問題のため、と切り分けられる。 ここで述べたような考慮の必要がないなら、それまでの話です(^^;。 ん~、「DOSプロンプト活用相談」からはちょっと乖離しすぎですね...(^^; どうしましょう... |
|
732) Re8:メールの送信 とっぽ 2003/10/22(水) 11:40 |
|
本題とは、関係ないのかも、しれませんが・・・ コマンドの掲示板って事で・・・ エラーが発生した時に、別のコンピュータへメッセージを送る って事だけに、注目すれば、こんな事も出来ると思います。 コマンドの中に、NET コマンドがありますよね。 その中に、SEND コマンドがあって、これを使うことで、メッセージが 送られます。 以下は、Win2KのHelpよりの引用です。 このコマンドの構文は次のとおりです: NET SEND {名前 | * | /DOMAIN[:名前] | /USERS} メッセージ たとえば・・・ NET SEND 192.168.1.1 "JOB1 ERROR" これで、メッセージが送れていると思います。 ただし、環境がWinNT、2K、XPで有ることが、前提ですが・・・ これなら、送信エラーのときも、判るんじゃないかな?? |
|
733) 障害通知ほか~Re9:メールの送信 ふぇむ 2003/10/22(水) 16:51 |
|
障害の監視や検知に関するツールと運用のあるシステムなら、そこへの接続手段を設ければいいんでしょうが、「メールで」と書いていらっしゃるということはそういう環境のないシステムなわけですよね。 運用監視ツールとのインタフェースは、例えばSNMPで通知をあげるとか、監視ツール側でなにかログファイル等をモニタ&チェックしてるならそこにログを吐くとか、ですむんでしょうけれど.... どのような運用スタイルかわからないのでなんとも言えませんが、NET SEND をここで使うのは個人的にはあまり推奨したくないですがね... 余談ですが、MS-SQL Server ってALERT系のしくみを持ってて、自前でSNMPを送信したりMAPI経由でメール出せたりしたような気がする... バックアップツールの ARCserve もそんなことができたような。なぜ Windows2000標準にない? そういえば、WindowsXPってコマンドラインレベルのコマンドがかなり充実されてるようで、イベントログへの書き込みや参照とか、イベントをトリガ にして別コマンドを起動とか、SNMPでの情報送信とか、そういうのができるコマンドがいろいろある、という記事を見かけたんですが(いいなぁ)、 Windows2000側にはそういうの追加できないんでしょうかね。Windows2003ならあるのかな? |
|
726) Re6:メールの送信 じゃく 2003/10/21(火) 13:07 |
|
>読み返してちょっと補足。 > >>@niftyがそうなんですが、一定時間以内に事前にPOPで読みに行っておかないと認証エラーで送信接続を拒絶されます。 > >なんか言い切ってるみたいに見えますが、メールサーバにおける認証方式はいくつかあるので、上記はたまたま @nifty がそうしてるようです(POP before SMTP、であってましたっけ)、ということにすぎず、他プロバイダはまたそれぞれだと思います。 ふぇむさん、こんにちは。 補足の補足です (^^) POP before SMTP による送信は、あくまで@nifty のメールサーバを他のプロバイダやネットワークから呼び出して送信する場合に 必要な手順だと認識しています。 @nifty が通常接続しているプロバイダで、@nifty のメールサーバ へ送信する場合は、普通に送信できるはずです。(参考:下記URL) http://www.nifty.com/mail/mailer/smtp_limit.htm |
|
727) Re7:メールの送信 ふぇむ 2003/10/21(火) 15:45 |
|
>@nifty が通常接続しているプロバイダで、@nifty のメールサーバ >へ送信する場合は、普通に送信できるはずです。(参考:下記URL) 情報ありがとうございます。しかし我が家のメインプロバイダは @nifty(フレッツADSL経由) なのに、当初から POP before SMTPのままですよ~。なぜだろう? 旧ニフティサーブ会員のままだからかな?(^^; すみません、まったく余談でした。 |
- ◆707. メールの送信 (まこと) 2003/10/17(金) 10:33
- 708. Re:メールの送信 (ふぇむ) 2003/10/17(金) 11:13
- 709. Re2:メールの送信 (ふぇむ) 2003/10/17(金) 11:17
- 710. Re3:メールの送信 (とっぽ) 2003/10/17(金) 12:18
- 711. Re2:メールの送信 (ふぇむ) 2003/10/17(金) 14:16
- 709. Re2:メールの送信 (ふぇむ) 2003/10/17(金) 11:17
- 712. Re:メールの送信 (じゃく) 2003/10/17(金) 14:24
- 714. Re2:メールの送信 (まこと) 2003/10/20(月) 12:18
- 716. Re3:メールの送信 (ふぇむ) 2003/10/20(月) 14:20
- 717. Re4:メールの送信 (ふぇむ) 2003/10/20(月) 14:37
- 718. Re4:メールの送信 (ふぇむ) 2003/10/20(月) 14:44
- 719. Re3:メールの送信 (とっぽ) 2003/10/20(月) 17:54
- 720. Re3:メールの送信 (じゃく) 2003/10/21(火) 09:40
- 721. Re4:メールの送信 (ふぇむ) 2003/10/21(火) 10:12
- 723. Re5:メールの送信 (ふぇむ) 2003/10/21(火) 10:26
- 724. Re5:メールの送信 (ふぇむ) 2003/10/21(火) 10:47
- 725. Re6:メールの送信 (ふぇむ) 2003/10/21(火) 10:51
- 728. Re7:メールの送信 (まこと) 2003/10/21(火) 16:26
- 729. Re8:メールの送信 (ふぇむ) 2003/10/21(火) 18:42
- 730. Re9:メールの送信 (ふぇむ) 2003/10/21(火) 18:46
- 731. Re8:メールの送信 (ふぇむ) 2003/10/21(火) 19:01
- 732. Re8:メールの送信 (とっぽ) 2003/10/22(水) 11:40
- 733. 障害通知ほか~Re9:メールの送信 (ふぇむ) 2003/10/22(水) 16:51
- 729. Re8:メールの送信 (ふぇむ) 2003/10/21(火) 18:42
- 728. Re7:メールの送信 (まこと) 2003/10/21(火) 16:26
- 726. Re6:メールの送信 (じゃく) 2003/10/21(火) 13:07
- 727. Re7:メールの送信 (ふぇむ) 2003/10/21(火) 15:45
- 725. Re6:メールの送信 (ふぇむ) 2003/10/21(火) 10:51
- 721. Re4:メールの送信 (ふぇむ) 2003/10/21(火) 10:12
- 716. Re3:メールの送信 (ふぇむ) 2003/10/20(月) 14:20
- 714. Re2:メールの送信 (まこと) 2003/10/20(月) 12:18
- 708. Re:メールの送信 (ふぇむ) 2003/10/17(金) 11:13