アカウント名:
パスワード:
spamを投げた元の企業イメージは低下してもいいかも知れないけど、中継する計算機を管理しているところ(Received:を見れば一発)まで巻き添えになったら逆に損害賠償とか請求されたりして?
私はかなり多数のmailing listにはいっている手前、spamもかなり来ます。To:やFrom:などではなかなか区別がつかず、苦労していました。最近ではReceived:をMTAで見るようにしています。MUAで見るタイプのフィルタはいくつかある模様。ただしReceived:のstructureを考慮しているものは私が知る限りありません。したがってフィルタがきつくなり過ぎる恐れがあります。それに、MTAで見ておけば553 Header Errorで返り討ちに合わせることもできます(笑)。
ちなみに、MTAはsendmail、sendmail.cfはCF 3.7Wpl2をベースとしています...が、sendmail.cfをV9に対応させる、あるいはフィルタ機能を追加していくうちにMaster以下の半分には自分の$Id$が入っていましたとさ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
今だからいえるけれど (スコア:5, 興味深い)
spamによる企業イメージの低下に関する資料を上司に
見せて反対しましたが,
「他所がやっているから対抗上やらざるを得ない」
「出会い系だから企業イメージの低下は考慮する必要なし」
という理由で反対意見は却下されました。
当時はドコモ側も,携帯
Re:今だからいえるけれど (スコア:2)
spamを投げた元の企業イメージは低下してもいいかも知れないけど、中継する計算機を管理しているところ(Received:を見れば一発)まで巻き添えになったら逆に損害賠償とか請求されたりして?
私はかなり多数のmailing listにはいっている手前、spamもかなり来ます。To:やFrom:などではなかなか区別がつかず、苦労していました。最近ではReceived:をMTAで見るようにしています。MUAで見るタイプのフィルタはいくつかある模様。ただしReceived:のstructureを考慮しているものは私が知る限りありません。したがってフィルタがきつくなり過ぎる恐れがあります。それに、MTAで見ておけば553 Header Errorで返り討ちに合わせることもできます(笑)。
ちなみに、MTAはsendmail、sendmail.cfはCF 3.7Wpl2をベースとしています...が、sendmail.cfをV9に対応させる、あるいはフィルタ機能を追加していくうちにMaster以下の半分には自分の$Id$が入っていましたとさ。