In article <ajioka-1103...@hrsrm1019.gikan.furuno.co.jp>
aji...@feclab.furuno.co.jp (Ajioka) writes:
> 味岡です。
> > れた日には、150x150 で 1 日 22500通、というのは大げさとして
> > も、数増えるのは、勘弁して欲しい。
> MUAのフィルタで受信時に振り分けばMax数千止りですのであまり
> 邪魔にならないのでは。
postmaster 当てのメールの中で、対処すべきものをどうやって探
しているのですか。
> 社内発のは社外には出さずにVirusを除去し、配送はされていない旨を付けて
> ポストマスタとFrom:に返すので良いのでは?
postmaster は勘弁して欲しいんだけど。個人情報みたいなものに
は近づきたくないし。一般企業と大学だとだいぶ違うんでしょうね。
> その際は用件が含まれる可能性があるので、ポストマスタは必ず
> 毎日チェックしなければならないと思います。
postmaster が本業なら、毎日見るのは仕事なんでしょうね。(トー
トロジーだ。)私の本業は、教育と研究なので、postmaster は、
本業ではないので、できるだけ手を抜きたいわけです。
In article <c2nonq$29kj$1...@news.moat.net>
vg3...@moat.net (Hidenori HoRi) writes:
> 全てのユーザにウイルス(or ワーム)がたくさん届くとも限らない
> ですよ。実際わたしの場合、約20のID(メールアカウント)には結構
> 毎日届いていますが、他のIDへは届くのはかなり稀です。
今の所、ワーム系は postmaster には来ていないので、それの対処
はしなくても済んでいます。ワーム系以外は、spam 系で、From:
などが偽装されているものです。あちこち中継している関係で、そ
ういうのも受け取ってしまいます。その後、.forward で転送され
た時、転送先のチェックが厳しくてそういうものを受け取ってもら
えなくて、postmaster に通知が来ます。
たとえば、こんな状況を考えます。
A --> B --> C --> D
A が元の発信、B が中間(ウイルスのフィルタ等)、C が自分の管轄
するもの(postmaster)、D がまた別の所(.forwardの転送先)としま
す。悪いのは、A で、From: を偽装して、spam を送っています。
でも、C-->D の転送に失敗して、C の postmaster にエラーが出る
わけです。
こういうのは、どうしようもないですよね。C も D 並に厳しくす
ればいいのかもしれませんが、それは単に B のエラーが増えるだ
けだし。
このようなメールをうまく捨てたいのですが、procmail などで取
り除けるためのルールなど教えて下さい。
一応、続きは、Followup-To: fj.mail.system にしてみました。
\\ 新城 靖 (しんじょう やすし) \\
\\ 筑波大学 電子・情報 \\
ちょっと状況は違うのですが、便乗です。
<YAS.04Ma...@kirk.is.tsukuba.ac.jp>の記事において
y...@is.tsukuba.ac.jpさんは書きました。
>たとえば、こんな状況を考えます。
>
>A --> B --> C --> D
>
>A が元の発信、B が中間(ウイルスのフィルタ等)、C が自分の管轄
>するもの(postmaster)、D がまた別の所(.forwardの転送先)としま
>す。悪いのは、A で、From: を偽装して、spam を送っています。
>でも、C-->D の転送に失敗して、C の postmaster にエラーが出る
>わけです。
つい最近になって、Bにあたるサーバの管理手伝いを始めました。
今までは誰もpostmaster宛やroot宛のメールを読んでなかった
のですが、さすがにまずいだろうと自分(ホストC)宛に転送したら
来るは来るは。procmail + SpamAsassin による負荷が高すぎたのか
サーバ(C)がダウンしかける状態になり、結局postmaster宛は
転送をやめました。
# メモリ96Mじゃねぇ……今さらSIMM買いたくないしぃ
うちの場合、A が From: ランダムな文字列 @ C のドメイン
という spam メールを送っていて、そのメールが user unknown や
spam チェックに引っかかって C あてに返されます。
ところが C では「ランダムな文字列」というユーザがいませんので、
B に対して user unknown を返します。そして B の postmaster あてに
"Subject: Postmaster notify: see transcript for details"
というメールが送られます。
これが3000件/日。一応捨ててはいませんが、読む気になりません。
これってどこかの設定がまずいのでしょうか?
ホストCを詐称されたら、あきらめるしかないのでしょうか?
>このようなメールをうまく捨てたいのですが、procmail などで取
>り除けるためのルールなど教えて下さい。
Subject あたりで何とかなりませんか?
逆に、受け取るべき postmaster 宛メールってどんなものでしょう。
人間が書いたメールってのはあると思いますが、それ以外で。
--
西 浩孝 Nishi Hirotaka
京都大学大学院 理学研究科 動物生態学研究室
In article <0403142311...@ecol.ecol.zool.kyoto-u.ac.jp>
Nishi Hirotaka <xni...@hotmail.com> writes:
> 西@京都です。
> "Subject: Postmaster notify: see transcript for details"
> というメールが送られます。
> これが3000件/日。一応捨ててはいませんが、読む気になりません。
そうそう。
> >このようなメールをうまく捨てたいのですが、procmail などで取
> >り除けるためのルールなど教えて下さい。
> Subject あたりで何とかなりませんか?
一応、次のような procmail の規則で「分類」しています。
特定の電子メールのアドレス(y...@is.tsukuba.ac.jp)が入っている
ので、そのままでは使えないので、注意して下さい。
------------------------------------------------------------
:0
* ^From: Mail Delivery Subsystem <MAILER-DAEMON>$
* ^To: postmaster$
{
:0 B
* !^[\t ]+for <y...@is.tsukuba.ac.jp>;
* Name server: .*: host not found
postmaster-host/.
:0 B
* !^[\t ]+for <y...@is.tsukuba.ac.jp>;
* The URL contained in your email .* has generated a high volume of complai\
nts.
postmaster-url/.
:0 B
* !^[\t ]+for <y...@is.tsukuba.ac.jp>;
* 554.*over.quota
postmaster-quota/.
}
------------------------------------------------------------
一応、元々自分(y...@is.tsukuba.ac.jp)に関係していたらしいもの
は、スルーさせて、受け取ろうというものです。
host not found のものは、だいたい From: が偽装されていて、そ
れに反応してエラーが出ているものです。たまに DNS 関連のトラ
ブルが発生している可能性もあるので、全部捨てるのは心が痛む気
もするけれど、それをうまく判定する方法はないですかね。
URL なんたらのものは、aol.com 方面から来るんですが、なんなん
でしょうね。メールの本文の URL を見ているのでしょうか。これ
は全部捨てていいでしょう。
quota が溢れたというのは、電子メール以外の方法で連絡してあげ
ると喜ばれるのかもしれません。
> >A --> B --> C --> D
> つい最近になって、Bにあたるサーバの管理手伝いを始めました。
> 今までは誰もpostmaster宛やroot宛のメールを読んでなかった
> のですが、さすがにまずいだろうと自分(ホストC)宛に転送したら
> 来るは来るは。procmail + SpamAsassin による負荷が高すぎたのか
> サーバ(C)がダウンしかける状態になり、結局postmaster宛は
> 転送をやめました。
CPU とかメモリがリッチだと、暗号とかspam対策とか考えると、速
いといろいろ手が抜けます。
しかし、電子メールのエラーを電子メールで返すという辺りに設計
の問題があるんでしょうね。
> > >このようなメールをうまく捨てたいのですが、procmail などで取
> > >り除けるためのルールなど教えて下さい。
> > Subject あたりで何とかなりませんか?
>
> 一応、次のような procmail の規則で「分類」しています。
1回目の配送エラー(バウンス)がまたバウンスしたもの(ダブルバウンス)と、
それ以外のpostmaster宛メイルを区別して考えるのが良いと思います。
ダブルバウンスのほとんどは、返すこともできなかったスパムで、読む価値の
ないものです。ひょっとしたら中には、ユーザが自分のアドレスも宛先のアド
レスも間違えてしまったメイルなんていうのが含まれているかも知れませんが、
そういうのをいちいちpostmasterが発見して対処してあげられた のどかな時
代は終ったんじゃないかと思っています。
そういうミスにはユーザが自分で気づくことを期待して、ダブルバウンスはし
ばらく保管しておいた後で捨ててしまう、という対処しか今は思いつきません。
ダブルバウンスを取り除いてしまえば、postmaster宛のメイルも読めるボリュー
ムまで減るのではないでしょうか。
多くのMTAには、ダブルバウンスを誰に送るか指定できる機能がついています。
sendmail.cf の O DoubleBounceAddress=
qmail の control/doublebounceto
postfix の 2bounce_notice_recipient=
など。
この宛先をpostmasterでなく、doublebounceとかの別のローカルメイルボック
スの名前にしておくと良いのでは。
# ダブルバウンスを他のホストに転送するのは、かなり危険なので、エラーに
# よるループとかが起きないようにくれぐれも注意が必要です。ローカルに保
# 存して捨てるのが無難と思います。
前田敦司
In article <m38yhzp...@nospam.maedapc.cc.tsukuba.ac.jp>
MAEDA Atusi <maeda...@ialab.is.tsukuba.ac.jp> writes:
> 1回目の配送エラー(バウンス)がまたバウンスしたもの(ダブルバウンス)と、
> それ以外のpostmaster宛メイルを区別して考えるのが良いと思います。
なるほど。これは、いいですね。
> 多くのMTAには、ダブルバウンスを誰に送るか指定できる機能がついています。
> sendmail.cf の O DoubleBounceAddress=
> qmail の control/doublebounceto
> postfix の 2bounce_notice_recipient=
> など。
> この宛先をpostmasterでなく、doublebounceとかの別のローカルメイルボック
> スの名前にしておくと良いのでは。
MTA の設定ファイルに書くわけですか。procmail だけで頑張るの
よりはすっきりしています。procmail だと一度書けばいつまでも
どこでも使えるという利点もあります。MTA の設定ファイルは、
MTA を入れ替えたりした時に書き忘れるんですよね。担当者変って
いるかもしれないし。でも思い出したらまた書き足せばいいという
ことで。