- - PR -
指定日にメール送信をする一般的な方法について
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-05-23 23:15
????? ごめん。よくわかんない。 上の「すぐに送る」は管理者宛? 下の「指定日にも送る」はユーザー宛? 管理者が有効期限を設定したタイミングでメールが送られてきても、全然う れしくないですよね(と、これは前の投稿でも書いたとおり)。 Jitta さんの前の投稿による「とりあえず、すぐに出す」も含めて、こう…主語 が足りてないというか、文章としてうまく読めないのですよ。
うん。これはわかります。
そこからココにたどり着く経過というか課程がわからない、と前にも書きました。 やっぱり「言葉が足りない」と感じます。 メールの遅延があり得る、だから出してすぐ届くことを期待してはいけない。そこま ではわかるんです。なので、その場合は一週間ぐらい早いタイミングでメールを 送信するとか、いろいろとるべき策はあると思うのだけど、その辺はこの質問の後 で考えるべき問題なんじゃないかなぁと思うんです。 心配はわかるけど、その辺の「Jitta さんの考えたこと」がすっ飛ばされた状態で 「とりあえず、すぐに出す」だけじゃわかんねーよコンチクショー!って話です。 僕は Jitta さんのことを知らない仲でもない(と思っている)ので、あ〜きっと Jitta さんのことだからいろいろ考えまくった結果がこういう感じで出てるんだろうな、でも それってもしかしたら余計なことを勘ぐりすぎているとも言えるんじゃないのかな? と思って書いたのが、僕の前の投稿ですよと。 Jitta さんのことを知っている(はずの)僕ですら「わがねじゃ」と思ってしまうぐらい なので、投稿するときはそこんところをもう少しかみ砕いて説明していただけると助 かります。 # ani さんの質問自体は解決しているようなので、この辺で止めておきまス。 _________________ ぽぴ王子@わんくま同盟 ぽぴ王子の人生プログラミング中 / ぽぴンち。 | ||||||||||||
|
投稿日時: 2007-05-24 02:14
って Serviced Component (COM+) ではなく、Windows Service だったのか。。。
送信する件数が半端じゃないというか、ひっきりなしに送信しているなら perfomance がよくなると思います。 ただし、送信がめったにないなら常に resource を保持している分無駄だといえるかもね。 それから、Windows Service にした方が、user 単位で schedule 可能な mail 件数に閾値を設けたりするような制御が簡単にできそうですね。 また、ASP.NET から Task Scheduler を扱う場合、権限で問題になるので下手なことやるくらいなら、Windows Service にしてやるのが案外いいかも。 匿名認証以外を利用しているなら、その user に対して Task Scheduler を扱えるよう権限を付与してやるのも一つの手ですが、匿名認証を利用している場合お勧めできるものではありません。 匿名認証を利用して Task Scheduler を扱わせるなら、COM+ server application とかを使って、別の account で Task Scheduler を扱うようにした方がいいです。 あと、Windows Service は当然ですが、[訂正]BUILTIN\SYSTEM[/訂正]NT AUTHORITY\SYSTEM なんかで起動しちゃダメよ。 専用の user を作ってその account で動作させるようにしてください。 _________________ ちゃっぴ@わんくま同盟 ちゃっぴの監禁部屋 [ メッセージ編集済み 編集者: ちゃっぴ 編集日時 2007-05-24 11:49 ] [ メッセージ編集済み 編集者: ちゃっぴ 編集日時 2007-05-24 11:50 ] | ||||||||||||
|
投稿日時: 2007-05-24 09:36
Jittaさん、ぽぴ王子さん、ちゃっぴさん、返信ありがとうございます。
私の説明が不足していたため、混乱を与えてしまったようで申し訳ありません。
要求としては、上記でぽぴ王子さんがおっしゃっている通りです。 遅延については現状は別問題として考慮していません。 ただ、メール送信が有効期限日当日だとさすがにまずいので、ぽぴ王子さんがおっしゃる通り、一週間前ぐらいを指定日として設定すればいいかなぐらいに思っています。
この説明がまずかったですね。これだと有効期限当日にメールを送信するととれますものね。 すみません。 アプリにするかサービスかは一長一短のようなのでもう少し検討してみたいと思います。 ありがとうございました。 | ||||||||||||
|
投稿日時: 2007-05-26 00:18
2回もだめ出し食らってしまったorz
んと、他の案件で検索されたときのことを考えて、書き残しておきます。 現在(投稿日)のところ、E-mail には、確実性がありません。(電波の速度による遅延はないものとして)出した瞬間に届くとか、必ず届くというものではありません。 これの例として、携帯電話での配送遅延の例を挙げました(2007-05-23 19:06 の投稿)。 また、配信元(配信者のメールサーバ)に障害が無くても、伝送経路に障害があれば受け取ることができないことの例として、NTT東日本の光ネットワーク障害を挙げます。 → http://www.itmedia.co.jp/news/articles/0705/16/news091.html 特に、メールが受け取られることを前提としたシステムは、今のところ、作るべきではないでしょう。これの例として、「RFID 児童登下校管理システム」の障害を挙げます。 → http://blog.feijue.com/index.php?catid=4722&blogid=1898 (31 January, 10 January, 20 December) メールが来ることによって安心できるシステムは、配信システム(送信から伝送経路、受信まで含む)による不具合によって、「安心できない状況」を作り出してしまいます。 児童登下校管理システムの場合は発信するサーバに問題があったわけですが、問題が他のところにあったなら、このシステムの立ち上げに関わった人がどう動いたのか、非常に興味を覚えます。 上記3つの障害例より、メールを受け取ることでアクションを起こすようなシステムは、十分な余裕を持ったシステムにしておく必要があると思います。 そのため、まず設定したときに、「何月何日に、次の内容でメールを発送する予定です。このメールは、設定の確認のために送信しました。」というような内容で送信。 その後は、システムの内容によって、当日0時に発送するとか、数日前から定期的に発送するとか、まぁ、それなりに。 つまり、冗長な作りにすることを勧めます。 たとえば、ちょうど最近あったのでマイクロソフトの満足度調査を参考に挙げてみます。 これの場合、数日前にメールと掲示板で、「これこれのアドレスから、メールを送信します。スパム判定されないように、設定の見直しをお願いします」というお知らせが届きます。 調査開始日に、詳細メールが届き、同時に「メールが配信されていると思います。内容の確認と、アンケートへのご協力をお願いします」というメールが送られてきます。 調査期間中、定期的に「アンケートにご協力いただけましたでしょうか」というメールが届きます。 まぁ、これは鬱陶しいくらいに冗長ですが、一例ということで。 _________________ | ||||||||||||
|
投稿日時: 2007-05-26 02:57
なぜ、だめ出しされたのか理由がわかってないように思えるのですが。 いいたい事は良くわかりますし、参考になります。しかし、 「それは別の話だろ」というのがJittaさんの一連の投稿に対する正直な感想です。 | ||||||||||||
|
投稿日時: 2007-05-26 09:34
そうですか? aniさんからフォロー入っていますが、
ここ、どういう有効期限で、その有効期限によってどうなるのか、わかりません。 「切れたらどうなるんだろう?」と考えました。 「その日に見ていなかったら、どうするんだろう?」と考えました。 また、5-26 の投稿については、「他の案件で検索されたときのことを考えて」と、前置きしています。その前の2つの投稿が、意味不明なままで終わらないように、という意図です。aniさんからのフォローで考えすぎなのはわかったので、投稿しないでおこうかとも思ったのですが、他の方が検索し、ヒットしたときに、その方には有用な情報になるかもしれません。 と、いうところを前置きしているのですが、ここまで書かなければいけませんか? どちらにしても、「メールによってアクションを起こさせる」ということについては、今の時点では時期尚早ではないか、というのは、システムの設計に関わることであり、外れてはいないと思います。ど真ん中でもありませんけど。 私は、質問として現れているのは、問題の一部である、と思っています。なので、質問されていることを解決しても、問題が解決しないこともあると考えます。 この案件の場合、メールを出してから受け取るまでの経路も不明なのですが、社内システムであれば、私が挙げている問題は、まず発生しないでしょう。 しかし、どういうシステムなのか、書いてありません。これは、書いていないことを責めているわけではありません。特に関係がないと思われたのでしょう。それは、それでいいと思います。 しかし、私のところであったのですが、一部署内で使うために作ったシステムに、他の拠点の部署も接続できるようにしてくれと依頼がありました。こういう、システムのアップグレードも考えておかなければいけないかもしれません。アップグレードしたあとで問題が発生し、またそのときに考えるのですか? システム設計屋であれば、問題が発生してから対応を考えることが難しいことを、ご存じだと思うのですが? だから、今考えておく、またはアップグレードするときに考えられるようにしておきましょうよ...と思うのですが、いかがでしょう? もちろん、アップグレードするかどうかもわかりません。しかし、問題はaniさんだけではないでしょう。もしaniさんだけなら、同じような質問が、繰り返しあちこちでされることもないですから。つまり、「他の案件で検索されたときのことを考えて」いるのですが、いかがでしょう? ↑ ↑ というところを、「いろいろ考えまくった結果がこういう感じで出てるんだろうな、でもそれってもしかしたら余計なことを勘ぐりすぎているとも言えるんじゃないのかな?」と言われているのはわかっていますが、基本、お節介なので。申し訳ない。 _________________ |