■ デカいメールヘッダ _ うーん。→ 【Exchange Onlineに関するお知らせ】 ヘッダー サイズの超過によって Exchange Online からのメール配信に失敗する場合がある _ MS の Office365 はリレーするメールに長大なヘッダを付加するのはよく知られていることなんだけど、最近は肥大化がさらに進んで、受け取り側で headers too large で蹴られるような事態になってるそうで。このお知らせにある例では、32KB が上限だったようなんだけど、32KB って小さすぎる値じゃないよねぇ。 _ 調べてみたところ、sendmail のデフォルトがまさに MaxHeadersLength=32768 だった。つまり、意図してヘッダサイズを小さな値に制限していなくても、sendmail をデフォルトのままで使っていればそれだけで O365 からのメールの受け取り

■ bash の危険な算術式 _ 使ってる人がいちばん多いだろうからタイトルでは bash としてるけど、ここで取り上げることは zsh および ksh 一族(本家 ksh、pdksh、mksh)にも該当する。ash、dash などでは該当しない。 _ 以下のシェルスクリプトには脆弱性がある。わかるだろうか。 #!/bin/bash # "品目,単価,個数" の形式の CSV を読んで、"品目,合計金額" の形式で出力する csv="foo.csv" while IFS=, read item price num; do echo "$item,$((price*num))" done < "$csv" これ、細工された CSV ファイルを食わせることで、任意コードの実行ができてしまう。数ある脆弱性の中でもとくにヤバいやつだ。どこが穴なのかというと、タイトルにもあるとおり算術式なのだが、し

■ 1.1.1.1 いろいろ _ ここのところブロッキングの話を追いかけてたもんだから、そのちょっと前にホットだった cloudflare の public DNS のネタを消化しきれてない。ということで、もうだいぶ遅れ気味だけどまとめて放出。 _ あ、JANOG41.5 でやったブロッキングの話の資料は ここにあります。周回遅れすぎて今さら見る必要ないかと思いますが。 ■ DNS over TLS _ お使いの unbound.conf に以下の設定を追加するだけで、cloudflare に対して DNS over TLS でクエリをやりとりするようになります。ただし最新の 1.7.x 以降のみ。 server: tls-cert-bundle: "/etc/ssl/cert.pem" # ルート証明書束 forward-zone: name: "." forward-tls-upstr

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

■ 通信の秘密 _ ちうことで、ついに 裁判に。 _ 今回の件で痛感したのが、通信の秘密ってぜんぜん理解されてないんだなー、ということ。憲法で定められている基本的人権のひとつなのに。 _ ブロッキングを問題視してない人ってのは、たぶん「ブロックすること」が通秘の侵害だと考えてるんじゃないかなぁ。名指しされたサイトにアクセスしなければブロックされることもなく、ブロックされないのであれば自分自身の通信の秘密は侵害されない。そう考えてるんじゃないかと推測する。 _ この考え方は間違ってるからね。いや、ブロックすることも侵害なんだけど、それ以前に「ブロック対象かどうかチェックすること」が通信の秘密の侵害。名指しされたサイトにアクセスするのではなく、たとえば youtube で動画を見るだけでもブロック対象かどうかチェックされ、そうでなかったからブロックされずに youtube にアクセスできるわけ

■ 1.1.1.1 _ NANOG で話題になってるんだけど、どうやら cloudflare が 1.1.1.1 と 1.0.0.1 というおそろしいアドレスで public dns を始めようとしているっぽい。 % dig +noall +ans 1.1.1.1.in-addr.arpa ptr @1.1.1.1 1.1.1.1.in-addr.arpa. 1735 IN PTR one.cloudflare-dns.com. 今日の夕方ごろは応答に2秒とかかかってたけど、夜になってからは 10ms 以内で返ってくるようになった。anycast への組み込みが完了したのかな？ _ で、なんで cloudflare なの？ 1.1.1.0/24 は 常時かなりのトラフィックが流れていて汚れてるからどっかに割り振りはしないで研究やら何やらの用途のために予約するとか言ってなかったっけ？ いちお

■ memcached フィルタ _ memcached のアクセス制御に関する注意喚起とかまあそんな感じで、本来内部用途でしか使われないはずの memcached が外部におっぴらげになってるサーバが世の中にたくさんあって、認証なしでガバガバだもんだから外から自由にデータを出し入れできて情報流出/改竄できちゃうどころか、UDP でもアクセスできるもんだから増幅率超特大の reflection attack の踏み台に使えて あちこちで大規模 DDoS の被害多発とかそんなヤバい事態になってるそうでマジヤバい。 _ で、それに対する対処は、とーぜんムダに開いてる memcached のポートを閉じることなんだけど、増幅率がハンパなくて踏み台にされると超ヤバい(語彙貧困)ので、個々のホストではなく、ISP とかホスティング屋さんがネットワークのレベルでフィルタを入れてる例があるっぽい。 外部

■ 正当なメールアドレスが使えないのは不当か _ Jリーグチケットは正当なメールアドレスを受け付けないという話。 _ 自分も y@ という1文字ローカルパートなメールアドレスを使ってるのでときどき同じ罠にひっかかるけど、まあそういうもんだと思うけどね。イラッとすることは否定しないけど。RFC で制限されてないからといって、アプリケーションが独自に制限をかけてはいけないなんてルールはないんだし。あるならちゃんとその旨明示されている。 _ たとえば、URL の長さに制限はない。1TB のファイルを data URL schemeで 1.4TB の長さの URL に変換してもかまわない。が、そんなクソ長い URL を扱えるツールが存在するかどうかはまた別の話。あたりまえのこと。 _ 長いのは短いのとは話が違う、というわけでもない。以前、トンガの ccTLD である .to が TLD 自体に A

■ root KSK ロールオーバー _ 新聞はそっち方面の専門家でない人にもニュースを届ける必要があるので、難しい内容も噛み砕いて説明する必要があって、その結果まわりくどい説明になっちゃうことがあるのは理解している。事情はわかってるので、ふだんはそういう記事を見つけても記者さん苦心したんだろうな、とあたたかい目で見るようにしている。が、いくらなんでも これはひどい。噛み砕いて説明するのに苦心したのはすごくよく伝わってくる。しかしその挑戦にもかかわらず素人さんが理解できる内容になっているとは到底思えないし、わかりやすい説明のために専門用語を使っていないため、そっち方面を理解している人に対してさえ意味不明。この記事の内容を事前に知っていた人(=記事を読む必要がない人)が何度か読み直して「ああ、あのことか」と気がつくのがやっと。誰に対しても存在する価値のない記事になっちゃってる。もうすこし何と

■ デカいメールヘッダ _ うーん。→ 【Exchange Onlineに関するお知らせ】 ヘッダー サイズの超過によって Exchange Online からのメール配信に失敗する場合がある _ MS の Office365 はリレーするメールに長大なヘッダを付加するのはよく知られていることなんだけど、最近は肥大化がさらに進んで、受け取り側で headers too large で蹴られるような事態になってるそうで。このお知らせにある例では、32KB が上限だったようなんだけど、32KB って小さすぎる値じゃないよねぇ。 _ 調べてみたところ、sendmail のデフォルトがまさに MaxHeadersLength=32768 だった。つまり、意図してヘッダサイズを小さな値に制限していなくても、sendmail をデフォルトのままで使っていればそれだけで O365 からのメールの受け取り

■ PHP の mail() 関数で FizzBuzz _ といってもループはできないので数値は生のリストで与えるんだけど。 $ php -r 'mail("","","","","-be \${tr{\${map{1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23:24:25:26:27:28:29:30:31:32:33:34:35:36:37:38:39:40:41:42:43:44:45:46:47:48:49:50}{\${if={\${eval:\$item%15}}{0}{FizzBuzz}{\${if={\${eval:\$item%3}}{0}{Fizz}{\${if={\${eval:\$item%5}}{0}{Buzz}{\$item}}}}}}}}}{:}{\\n}}");' 1 2 Fizz 4

■ サブドメイン管理者が親ドメインの SSL 証明書を取得する _ 中国最大級の認証局「WoSign」がニセの証明書を発行していたことが判明。サブドメインの管理権限がある人が親ドメインの SSL 証明書が取得できちゃったんだって。この問題、他の CA でもあるんだよね、実は。 _ 具体的に言うと Let's Encrypt がそれ。 この記述。example.com ドメインの所有者かどうか判断する方法のひとつとして、_acme-challenge.example.com の TXT レコードに指定のトークンを記述せよ、というのが挙げられている。ということで、ユーザが自由にサブドメインを作れるサービス上で _acme-challenge というサブドメインを作成すれば親ドメインの証明書を発行してもらえる。今回の WoSign の件のように任意のサブドメインでいけるわけではなく、ラベルにアン

2008年8月21日(木) ■ smtp_bind_address を変えてメールを送る _ その昔、postfix-jp に こんなメールを投げた。複数の IP アドレスを持っているホストが送信元のアドレスによって src ip を使いわけるにはどうすればいいか、という話。 _ 今さらながらやってみた。 _ master.cf smtp-a unix - - n - - smtp -o smtp_bind_address=192.168.1.1 smtp-b unix - - n - - smtp -o smtp_bind_address=192.168.1.2 main.cf smtpd_sender_restrictions = check_sender_access hash:sender_filter sender_filter example.com FILTER smtp-a

2014年8月3日(日) ■ 尾瀬 _ きのう、鳩待峠から入って山の鼻でテント張って、尾瀬ヶ原を散歩。んで、今日、至仏山経由で鳩待峠に戻る。 _ きのう今日と、どちらも朝のうちはよく晴れてたんだけど、そのうちどんどん雲が出てきて午後からは雨で残念な感じ。見るからに雨雲なんで警戒はしていたんだけれど、きのうは降り始めたと思ったら一気に土砂降りになってカッパを着るのが間に合わずにずぶ濡れに。10分もすれば小降りになるんだけれど。まあ、こんな日もあるよね。 _ 燧ヶ岳 至仏山と白い虹。尾瀬でときどき見られるということは知ってたけど、まさか実際に遭遇するとは思わなかった。 小至仏山山頂からの至仏山、燧ヶ岳、尾瀬ヶ原 2014年8月7日(木) ■ 国際化メールアドレス _ Gmail、メールアドレスなどで日本語など非ラテン文字に対応へ。う、うーん、こういう書き方だと、これまではラテン文字には対応して

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

2014年6月19日(木) ■ さよなら greylisting _ MS の Office365 と超絶相性が悪いみたい。word やら excel やらじゃなくて、メールサービスとしての o365 ね。 _ spammer は配送効率を重視して送信失敗しても再送しないことが多いという仮定のもと、いったん 4xx で一時エラーを返してから、再送してきたメールだけを受け取るというのが greylisting。で、再送されてきたメールなのかどうかを判定するのに使われるのが送信元の IP アドレス。from、to、IP アドレスの3つセット(triplet)で判定するとか、IP アドレスだけで判定するとか流儀はあれど、いずれにせよ判定には必須。が、o365 は再送のたびに違う IP アドレスから送信してくるみたい。よって、greylisting をやってるサイトでは o365 からのメールは受

2014年6月5日(木) ■ openssl 祭 _ openssl に また穴。 _ んーと、MITM によって、攻撃者が強制的に強度の弱い暗号を使わせるようにすることができる、という直球ド真ん中のダウングレード攻撃ということかな？ とはいえ、おそらくクライアント/サーバがサポートしない暗号を使わせることまではできないだろうから、平文(eNULL)まで弱くなるということはないような気がする。つまり apache でいえば、SSLCipherSuite HIGH:MEDIUM と設定してある場合、この脆弱性を突いて HIGH じゃなくて MEDIUM な暗号を使わせるようにすることはできても、LOW な暗号にさせることはできないんじゃないかということ。 _ ……あ、いや、違う？ もしかして鍵交換に介入して共通鍵を奪われちゃう？ だとすれば、どんな暗号アルゴリズムでも自由に復号できちゃうから

2013年8月22日(木) ■ gmail の逆引き制限 _ おとといぐらいからちらほら 話に出てたけど、gmail が逆引きのない v6 アドレスからのメールを蹴り始めたらしい。もうめんどくさいので主張は繰り返さないけど、バカですか。 _ 各所の情報を総合すると、gmail がこの制限を入れたのは先週の金曜か土曜日あたりかららしいんだけど、その話を聞いて火曜日に ここを見にいったときには IPv6 向けの追加のガイドライン 送信元 IP には PTR レコード（送信元 IP の逆引き DNS）が必要です。また、PTR レコードで指定されているホスト名の DNS の正引き解決によって取得した IP と一致している必要があります。そうでない場合は、メールに迷惑メール マークが付けられたり、メールが拒否されることがあります。 送信元ドメインは、SPF チェックまたは DKIM チェックにパスす

2013年5月26日(日) ■ 西沢渓谷 _ 眺望で有名なほったらかし温泉から甲府盆地の夜景を見ようと土曜の昼過ぎに出発したら、営業時間内に到着できなかった。アホか。ということで、朝イチでお風呂に。うーん。けっして天気が悪いというわけではないんだが。でも霞がかかったようで遠くが見えない。残念。 _ で、西沢渓谷へ。…なんで雨降ってきますかね。そういう天気予報じゃなかったと思うんだけど。まあ、諦めるほどの強い降りではないので傘をさしててくてくと。思ってたよりもいい感じの渓谷が続いて気持ちがいい。ほとんど陽の射さない森の中なのでかならずしも晴れてなくてもいいんだけど、とはいえやっぱり雨というのはアレだな。途中でちょっとだけ雨がやんで晴れ間が射したりもしたけどやっぱりまた降りだして、っつーか後半は雷鳴に追いたてられた感じなのがやっぱりもったいない。次は紅葉の時期にまた来るか。10km 歩いてるん

2013年5月1日(水) ■ RFC2821 と 5321 の違い _ RFC2821 section 4.1.2 Domain = (sub-domain 1*("." sub-domain)) / address-literal Mailbox = Local-part "@" Domain RFC5321 section 4.1.2 Domain = sub-domain *("." sub-domain) Mailbox = Local-part "@" ( Domain / address-literal ) _ うーん。こんな基本的なところが違ってたのか。RFC2821 の定義では hoge@localhost はメールアドレスとしては認められなかったけど、5321 では許容される。まあ、実際はこのへんを厳密に違いを区別することはあまりないし、2821 では不可といってもたいて