メールの暗号化 - とみたまさひろ - Rabbit Slide ShowPage: 1 メールの暗号化 とみたまさひろ NSEG #40 2013/06/08 メールの暗号化 Powered by Rabbit 2.0.9 Page: 2 自己紹介 とみた まさひろ プログラマー (Ruby & C) http://d.hatena.ne.jp/tmtms http://twitter.com/tmtms 好きなもの Ruby, MySQL, Linux Mint, Emacs, Git メールの暗号化 Powered by Rabbit 2.0.9
milter-greylist の Tarpit 機能 - JULY’s diary
長らく、バージョンアップが無かった milter-greylist ですが、10/11 に Ver. 4.4 がリリースされ*1、長い間、開発版扱いだった Ver 4.3 系に実装された機能が、リリース版となりました。 milter-greylist の Tarpit 機能は、milter-manager の開発に携わっている、株式会社クリアコードの須藤功平さんが作成したパッチで、Ver. 4.3.4 でマージされました*2。その機能が、リリース版で使えるようになった、ということで、実際に動作を確認してみました。 Tarpitting とは 語源は「tar pit」で、日本語に訳すと「タール抗」で、タール状の物が貯まっているようなところを指すようです。 spam 対策での Tarpitting は、送信相手に対して、わざとレスポンスを遅らせます。送信相手が普通のサーバであれば、分単位でレス
自分が死んだらGmailに溜まったメールはどうなるか （プレジデント） - Yahoo!ニュース
■秘密と相続 GmailやFacebookなどで、自分のプライベートなデータをネット企業に預けている人は多いだろう。セキュリティに気をつけていれば、際どい内容が含まれていても、その中身が外に漏れることはない。ただ、本人が死んでしまったら、そのデータはどうなるのだろうか。 言うまでもないが、通信の秘密は国民に認められた権利であり、憲法や電気通信事業法で保障されている。政府はもちろん、インターネットサービスプロバイダなどの電気通信事業者、さらに一般人も人の電子メールを勝手に見てはいけないことになっている。犯罪捜査で捜査機関がプロバイダに情報開示を迫ることはあるが、それも無制限ではない。インターネット上の法律問題に詳しい落合洋司弁護士は、次のように解説する。 「プロバイダが警察から捜査関係事項照会を受けて、ユーザーの名前や住所などの登録情報を本人の同意なく提供するケースはあります。ただ、メ
仙石浩明の日記: SPF (Sender Policy Framework) チェックをパスしてしまう迷惑 (スパム) メールが増えている
私の自宅サイト GCD (と勤務先の KLab) では、 qmail にパッチをあてて、 外部から届くメールのヘッダに SPF (Sender Policy Framework) チェックの結果を挿入するようにしている。 例えば以下のような感じ: Received-SPF: pass (senri.gcd.org: SPF record at thelobstershoppe.com designates 89.215.246.95 as permitted sender) Message-ID: <34f301c7df7d$2e65ece5$5ff6d759@unknown.interbgc.com> From: "Sales Department" <sales@thelobstershoppe.com> 「Received-SPF: pass」というのは、 このメール (実は迷惑メー
なぜチェーンメールはいけないのか - モーグルとカバとパウダーの日記
ソレ チェーンメールだよ！そういうの転送するのって迷惑だよ。という前にできること。 - インフラ管理者の独り言（はなずきん＠酒好テム管理者） で指摘されてるように、チェーンメールはやめよう、と指摘するのはなかなか難しい。 それには、なぜチェーンメールはいけないのか、という説明が理解してもらいにくいということもあると思う。 実は、嫁のところにもチェーンメールが来たので、チェーンメールは転送しないほうが良いよと言ったところ、なんでチェーンメールはいけないの？という質問をされた。が、やってみると説明がなかなか難しかった。 なので、チェーンメールが良くない理由を書いてみたい。 しかし、もっと良い説明があればぜひ教えてください。 まず最初に結論から。 チェーンメールは仕組み的にデマが広まりやすく、デマで大きな迷惑を掛ける。 だからチェーンメールという仕組み自体を使わないようにすべき。 なぜそういう結
Amazon Web Service、大量メール送信代行サービスを開始 | スラド IT
Amazon Web Services が、「Amazon Simple Email Service」なる新サービスを発表した (プレスリリース、Amazon Web Service ブログより) 。 大量のメールを送信するためのサービスとのことで、「年間 10 億通のメールを送る」という Amazon のサイトで使われている技術をベースにしているとのこと。送信できるメール数は初期状態では 24 時間ごとに 1000 通までだが、送信したメール数や reject されたメール数、バウンス数、クレーム数などから判断し、問題が無ければ送信できるメールの量や送信速度は増えていくとのこと。 API 経由で操作が可能なので、独自のアプリケーションなどとの連携も容易にできそうだ。
オープンソースのバウンスメール解析システム BounceHammer | gihyo.jp
何らかのバウンスメールが返ってきたら、そのメールアドレスを配信不能なアドレスとして扱うという単純なバウンス処理を行った場合、“メールボックスがいっぱい”や“メールが大きすぎる”のようなエラーで宛先アドレスに配信不能フラグを立ててしまうという誤った対処をしてしまう危険性があります。 エラーになった理由ごとに適切な対処をすれば、メールアドレスの状態変化を管理しつつ、宛先不明アドレスの割合増加による遅延を回避ができます。検出できるエラーについての詳細は、http://bouncehammer.jp/features/engine/reasonをご覧ください。 読みにくいバウンスメールを構造化する BounceHammerは解析したバウンスメールの内容をYAML形式で出力します。YAML形式の解析結果は1行1レコードで書き出しているので、コマンドラインからcatで眺めたり、wcで行数計測す
［ITpro EXPO 2010］「メールをやめましょう」---サイボウズ青野社長
「皆さんのコミュニケーションツールは、いまだに電話とメールだけだったりしませんか。本当にメールが便利だと思いますか」。サイボウズの青野慶久代表取締役社長は2010年10月20日、ITpro EXPO 2010の特別講演で、聴衆にこう問いかけた。 青野社長は、「Eメール時代の終焉 ─ソーシャルワークスタイルの到来─」と題した講演で、「情報共有のツールとして、メールは不便」との持論を展開した。青野社長は、その根拠として、メールの七つの弱点を指摘する。 まず、メールは一度送信を完了してしまうと取り消せないことだ。「あて先を間違うだけで、個人情報の漏洩につながる」と、そのセキュリティ上のリスクを指摘する。リスク回避のために、「1通送るたびに、あて先や内容を相当慎重に確認しなければならない」。二つめは、1日に多数のメールを受信するため、重要なメールを見落とす恐れがあること。メーリングリスト（ML）を
What Postfix strict_rfc821_envelopes rejects
▼Postfix の strict_rfc821_envelopes で何が拒否されるのか▼ Postfixにて、spam対策として strict_rfc821_envelopes = yes の設定と、 「出来の悪いメーラを拒否してしまう」という記述はよく見かけます。 が、実際に何が拒否されるのか考察する資料はほとんど見かけません。 RFC821違反のメールアドレスとは 該当RFCの記述確認 考察 Postfix上の実装 なぜ Postfix では <@domain> が root宛に配送されるのか $Keywords: Postfix strict_rfc821_envelopes reject dot-user, dot-domain, excess tokens in MAIL FROM, blank username, domain only $ $Id: postfix821.
僕の楽天SPAM対策 - y-kawazの日記
楽天で年間数十万円使う程度のそこそこヘビーユーザーの僕が、楽天のメルマガ攻勢に耐えぬく為に行っている設定をご紹介します。 ネットでは楽天は結構嫌われているように思います。楽天が嫌われる最大の理由の一つは、一度でも買い物しようものなら大量に届き始めるメールマガジンという名の迷惑メールでしょう*1。 しかもこれ、わざとか知りませんが、楽天本体や楽天内の各ショップから来るメールはFromアドレスやX-何とかヘッダなどによる仕分けが出来るようには全くなっていません、しかも注文確認などの重要なメールは残したいとなると、この仕分け問題は更に困難を極めます。 そこで僕が行っている基本戦略は↓こんな感じです。 楽天専用のメアドを使う メルマガの停止はしない 必要なメールはフィルタで保護 Gmailの迷惑メールフィルタで大虐殺 ネットを見る限り、この戦略をとってる人は少ないようですが…。 解説は以下に続きま
BounceHammer | 国産オープンソースのバウンスメール解析システム
bounceHammer have been downloaded and used by many users and companies since the first release of the software on March 2010, and has been EOL'ed: End Of Life on February 29, 2016. After the EOL of bounceHammer, the software could be continued to use on your system, however, we strongly recommend migrating to Sisimai: The successor of bounceHammer (more faster, more higher precision of analysis).
Outlook以外のメールクライアントでExchangeを利用できる「DavMail」 | OSDN Magazine
メールや予定表の管理にMicrosoft Exchangeを導入している企業は少なくない。中には新バージョンのExchange 2010に移行を進めている部署もあるだろう。だが、Exchangeは基本的にOutlook以外からはアクセスできず、Becky!やThunderbirdといったメールクライアントを使っているユーザーや、MacやLinuxで開発を行っている技術者にとっては非常に不便だった。そこで利用したいのが「DavMail」である。 DavMailは、Exchangeサーバのデータを一般的なメールクライアントから利用可能なように変換するゲートウェイサーバだ。Exchangeサーバには外部からブラウザでメールを読み書きするための「Outlook Web Access」（OWA）というウェブメール機能が用意されている。DavMailは、このOWAに含まれている「WebDAV」機能（E
低消費電力Atomマシンのメールセキュリティアプライアンス「tapirus」を検証 | OSDN Magazine
Postfix付属のsmtp-sourceで受け取り性能を確認 まずはメールサーバーソフトウェアとして代表的なPostfixに含まれるsmtp-sourceを使って、SMTP受信の限界をチェックしてみよう。試験環境は、100BASEのハブ上にtapirus Mi1000、PC2台（MTA1、MTA2）という構成で、MTA1からsmtp-sourceを使ってメールをtapirusに送り、tapirusからもう1台のMTA2にメールが送られ、MTA2上では同じくPostfix付属のsmtp-sinkでメールを受け取り捨てるという構成である。DNSはMTA1上で動作させている。 図5 テストの構成 MTA2でsmtp-sinkを起動させたら、MTA1からMTA2への直接送付の処理を確認しておく。 MTA2でsmtp-sinkを実行 # smtp-sink -v IPアドレス:25 1024 MT
dovecotのantispamプラグインで迷惑メールフィルタの学習をコントロールする : \ay diary
dovecotのantispamプラグインで迷惑メールフィルタの学習をコントロールする 投稿者 akira 2010-08-19 09:03:00 GMT 先日のトラブルでIMAP環境の組み直しになった。それ自体はたいした話ではない。パッケージをいれてデータを戻すだけ。 悩ましいのは迷惑メールの処理。MUAでの判定でも十分ではあるのだが、複数のマシンで読み書きするのでちょっとめんどくさい。トラブル以前は自作ツールをぐるぐるまわしてbsfilterで処理していたのだが、再び自作ツールをぐるぐるまわす気にはなれない。かといってまともにdaemon化するなどさらにいじる元気もない。sieveでなんとかできないものかと思ったけども、やはり振り分けくらいにしか使えないようで、この手の目的には向かない。 そういえばdovecotにプラグインがあったのだったっけ。探してみたらそれらしいプラグインが見付か
port 25のメールは撲滅されるべき | おごちゃんの雑文
ここ数年、表題のようなことを思っている。 「廃止」でも「移行」でもなく、「撲滅」という表現を使っているのは、なるべく早い時期に消え去って欲しいからだ。「互換ゲートウェイ」みたいなものもなくなって、ある日を境にport 25のトラフィックは全部止められてしまう的な。 ところが、「次世代メール」との声のあったGoogle Waveは提供中止になるようだ。 さらば、Google Wave ちょっと前までは、「メールがイマイチ使いものにならないんで、mixiのメッセージで」ってのが周囲で流行っていたのだが、 「mixiが落ちたようだな」「クックック、ヤツは我ら四天王の中でも最弱…」 「夏休みごときに耐えられんとはSNSの面汚しよ！」(音声は変えてあります) なことになっている。twitterは「鯨が出てこそ正常」とまで言える状態だ。他方、 今どきの小中高生はメール使わない→10年後「メールで仕事」
NetBSD 絹の日記 .procmailrc の続き (一致した文字列から一部削りたい)
06/12 の日記 に書いた続きだけれど、 hoge-bounces+bar=example.com@.... の hoge の部分だけを拾う、というのはちょっと工夫が必要だった。 つまり -bounces がある時が条件だけれど、それを 言ってしまうと、その文字の部分も拾ってしまう。 それは後から削る必要があった。 * ^Return-Path: .*-bounces\+makoto=myhost.example.com@example.com { :0 * ^Return-Path: <\/.*-bounces { :0 h FILE=|echo "$MATCH"|sed s/-bounces// :0 emacs/$FILE/. } :0 emacs/others/. } :0 h を使って、次の行で pipe (|) 印を使って shell を実行する ようにする。それを sed
NetBSD 絹の日記 .procmailrc で中央部分の一致を拾う ($MATCH)
.procmailrc の手順を書くくらいだったら、 自分で振分けプログラムを書いた方が早い という気持 は分らないでもないが、(結局自分で書く度量もないので) やはり .procmailrc で何とかする訳で、 さて、実は、最近まで、 * ^Subject: [a-zA-Z0-9]+ (daily|weekly|monthly) の、この最初の正規表現部分に一致したものは拾えないと思っていた (行の最後の方に一致がある場合には \/hoge -> $MATCH で簡単に拾える)。 このような「中間の部分の一致を拾う」問題でも、 次のようにすれば書けるということに気が付いた。 :0 * ^From: (root|Charlie Root) { :0 * ^Subject: [a-zA-Z0-9]+ (daily|weekly|monthly) { :0 * ^Subject: \/[a-z
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
強化された@i.softbank.jpの迷惑メールブロック機能、設定方法を解説いたします！ | AppBank
＜この記事の公開期間は終了しました＞
http://www.flcl.org/~yoh/diary/20110101.html