タグ

ブックマーク / ya.maya.st (5)

  • どさにっき

    CVE-2015-{5986,5722} _ また BIND 穴。それも2つも。RFC にもなってない draft 段階の RR type をいちはやく実装し、いちはやく脆弱性になりました。バカじゃねーの。 _ 前回がギリギリ8月に入る前、今回は8月が終わったとたんに公表されて、頑なに8月を避けてるように見えてしかたない。とはいうものの、公表が9月になっただけで、穴の発見から修正の作業は8月中におこなわれていただろうから、穴だらけの bind なのに8月にかぎって脆弱性がこれまで見つからなかったのは ISC の中の人が8月に夏休みを取るために仕事をサボってるんだという説は崩れたようだ。だからどうした。 _ BIND はもう消えなくちゃダメだよ、ほんと。可能なかぎり別のものを使わないと。 _ 権威の方は nsd とか powerdns とか knot とかいろいろ出てきたけど、キャッシュ

    suu-g
    suu-g 2015/09/04
    名言だらけ
  • .local - どさにっき

    2014年6月23日(月) ■ 無題 _ 持ち時間30分で50枚って無理だよね…。まだ何枚か増えるし。 2014年6月26日(木) ■ 無題 _ ひさしぶりに大手町に来たけど、以前といろいろ違いすぎててアレ。再開発やってるのは知ってたけどここまでとは。当時は公庫ビルの職員堂とか日経新聞の社員堂とかよく忍びこんで昼飯ってたけど、ビルどころか、ビルが面していた通りごと消滅しちゃってるし。 _ KDDI とか NTT com とかのビルは変わらぬ姿で安心する。通信設備が入ってるビルはそう簡単に建て替えられんからね。それでも、生活彩家がなんでセブンに変わってるんですかー。 ■ .local _ ということでみなさまおつかれさまでした。今日話題になった、というか話題にした件。 RFC6762。 Any DNS query for a name ending with ".local." MUS

    suu-g
    suu-g 2014/06/27
    don't use .local it uses mDNS not DNS
  • どさにっき - #!/usr/bin/env

    2006年6月21日(水) ■ DomainKeys _ えーと、DomainKeys ってのは要するに電子署名なので、署名された後でヘッダや文が改変されると検証に失敗する。DomainKeys はメーリングリストに弱いと言われる理由のひとつですな。 _ 自宅 postfix に milter を導入したので、DomainKeys を検証できるようにしてこのあたりの動作を注意深く観察してるのだが、このまえはじまった DNSOPS.JPのメーリングリストからのメール。 Authentication-Results: mx.maya.st sender=ロボットによる収集回避@dnsops.jp; domainkeys=pass なんで pass しとんねん。ML が Subject をいじってるんだから fail になるはずなんだが。Subject をいじらないメーリングリストとか、いじっ

    suu-g
    suu-g 2010/10/30
    #!/usr/bin/env の問題について。
  • Sendmail with Maildir

    Sendmail で Maildir を使う 大誤解 「Sendmail が扱えるのは mbox 形式だけで、Maildir は使えない」 大嘘である。sendmail は Maildir を扱うことはできない。それは事実だ。しかし、sendmail は mbox も扱うことができない。なぜならば、sendmail は MDA ではないからだ。 MDA とは何ぞ MTA と MDA MTA (Mail Transfer Agent): SMTP を使ってサーバ間でメールを転送するもの。 MDA (Mail Delivery Agent): ユーザのメールボックスにメールを配信するもの。 sendmail は MTA である。MSA や MSP としての側面もあるが、MDA としての機能は内包していない。sendmail はユーザのメールボックスの形式は関知しない。sendmail がメール

    suu-g
    suu-g 2010/02/10
    getmailにmail.local
  • MTA のアクセス制御

    MTA の各種のアクセス制御手法について思いつくままにメモしたもの。ほとんどは spam 対策だが、こうすれば spam を撃退できる、というガイドではない。絶大な効果があるものから、ほとんど効果がないどころか多大な副作用をもたらすものまで、さまざまな手法をとにかく列挙する。筆者は spam 対策については「やりすぎるぐらいならば何もしない方がマシ」という立場を取っているので、メリットよりもデメリットを重視する。なお、分量はわずかだが DoS 対策や内部ユーザによる abuse を防止する手法についても触れる(この文書は spam 対策技術のメモではなく MTA のアクセス制御手法のメモである)。 ローカル配送された後にユーザごとで選別する方法についてはほとんど取り上げない。携帯電話向け spam についても触れない。特定の MTA や対策ツールにかたよった記述はほとんどしないし、特に必要

    suu-g
    suu-g 2009/11/14
  • 1