_ よーするに指定回数だけ同じ文字を出力しろ、という問題だけど、ループなり再帰なりの繰り返しで実現したら短くならない。perl とか ruby とか、はじめからそういう方法が用意されてる言語はいいよね。
もっと短い解があるみたいだけど、知らない言語なのでわからん。こういう手段がない言語では他の手段で代替できないか考えるしかない。print"g"."o"x<>."gle" puts"g"+"o"*gets.to_i+"gle"_ sh と m4。
やってることはどちらもまったく同じ。ゼロを桁数指定で出力し、その後で別の文字に置換する。ただし、printf(1) は SunOS 4.x にはなかったし、format は GNU m4 だけの拡張機能なのであなごる的にはアリでもわし的には邪道。printf g%0`dd`dgle|tr 0 o translit(format(`g%0'include(/dev/fd/0)dgle),0,o)_ それらを使わないとなると、こうなる。sh。
はじめの \ の後はタブ、ふたつめの \ の後はスペース。expand はタブをスペースに展開するコマンド。8タブだけでなく任意のタブ位置を指定できるので、これを使って欲しいだけのスペースを出力し、後で置換する。n=`dd` echo g\ ogle|expand -t$n|tr \ o_ m4。format を禁じ手にしたら素直に再帰させるしか思いつきません。
define(O,`ifelse($1,0,g,`O(decr($1))o')')O(include(/dev/fd/0))gle_ awk。
かじった程度にしか awk を知らない人にはまったく意味不明だと思うので、perl に直訳。OFS="o"{$$1="gle"}$1="go"空文字列の入ったフィールドを必要なだけ用意し（明示的にはやってないけど）、フィールドセパレータに欲しい文字を入れて結合させる。#!perl -pa $F[$F[0]]="gle";$F[0]="g";$_=join("o",@F)_ おまけ。sed。入力が 2 か 10 か 42 のときしか正しく動かない。
s/4/10101010/ s/10/22222/g s/2/oo/g s/.*/g&gle/
_ 出会い系サイトって通信販売業者になるんだ……。
_ 数週間前に118バイトの答を作って、もうこれ以上縮めるのは無理、と思ってたら、別の人に今日2バイト縮められた。えー、なんでー、と思って自分の答を久しぶりに眺めたら、簡単に縮められるところを見逃してた。なんでこれをそのままにしておいたんだ。時間がたってちょっと忘れかけるぐらいになって見直すぐらいじゃないときっと見つからないんだろうなぁ。
_ ちうことで、それを削って113バイトまで。こんな感じ。
ちなみにこの問題の 元ネタ。++p[$0--]<$0=(A=p[w=p[1]>p[0]])-(B=p[!w]+0)?"Player"w+1(A>6?" wins the set ":" leads ")A" - "B:"Set is tied at "A_ ほかにもマヌケな見落しを発見できるかも、と解いてからだいぶ時間がたったものをいくつかチェックしてみたけど、これ以外ひとつもわからなかった。そんなにうまくはいかないか。
ｈｉ−ｈｏの契約数は、個人と法人合わせて２０万件前後とみられる。となってるけど、うーん、hi-ho ってこんな小さかったっけ？ もっともっと多かったと思うんだけどなぁ。すぐに記事が消えちゃうけど、 NHKでは１６０万人を超える会員を持つインターネット接続サービスの「ｈｉーｈｏ」事業について、となってるから、法人を合わせたら20万じゃなくて200万の間違いだよね？ 4年前の調査では200万人だし。_ NHKや 日経によると、売却額は十数億円らしい。えーと、会員が160万人として、これに情報漏洩の賠償額の相場である500円をかけると8億円。つーことは、売却額の大半が個人情報の値段か:-)。20万が正解だとしたらぜんぜん違うけど。
_ hi-ho のニュースを見て久しぶりに山本正之センセイの歌が聞きたくなった。ぐぐってみたら ここにまとめて置いてあった。こんなにバージョンがあったんか。各地の記述を見ると2000年12月ごろの CM らしい。そんなに昔だったのかぁ。しかし改めて聞くと、メールが飛んだ、という歌詞はイヤン。
会員数は一時、１００万人程度まで拡大したが、その後の競争激化で現在は２０万人前後に減少していた。え、ほんとに20万だったのか。YahooBB が超低価格路線をはじめて以降、接続サービスだけでは収益を上げにくくなり、中小 ISP は淘汰されて体力のあるメガプロバイダへの集約が進んでるんだけど、hi-ho はまだメガだと思ってた。まさかそんなに減ってたとは……。
_ ふつーにインストールしたら bc、dc が入らないのって debian だっけ？ ちょっとした電卓がほしくなったときにこういう計算コマンドがないと困ると思うんだけど、debian ではみんなコマンドラインから perl -e 'print 1+2' とかやってるんだろうか。わしの場合、コマンドラインからだけでなく、sed やら何やらで計算式を作って bc や dc に食わせるなんてスクリプトを日常的に書くから、これが標準ではできない環境は不自由でしかたない。bc を使ったスクリプトをよその環境から持ってくるときに使わないようにいちいち書き換えるのもめんどくさいだろうなー。
_ bc がひじょーに便利に使える例。file1 と file2 が1行にひとつずつ数字が入っているファイルだとして、
はそれぞれのファイルの各行の和を計算して出力する。bc なしでもできないことはないけど、めんどくさい。paste -d+ file1 file2 | bc_ で、あなごるサーバに bc、dc がないんですよっ。 じゃんけんを sh で。わしが作ったいちばん短い答。
49バイト。sed が GNU 版でない場合はtr GRCSP5a-z 002211\ |sed a-2+3%p|dc|tr 012 '><='にしないと動かないけど、とにかくこれは正解を出すはず。が、あなごるサーバでは dc が command not found になってダメ。bc ほどポピュラーじゃないにしろ、dc もふつーは標準装備だよねぇ。最近は違うこともあるけど bc って本来は dc への単なるトランスレータだし。bc を使うように修正してもやっぱり動かない。sed 'a\ -2+3%p'tr \ GRCSP5a-z -002211\ |sed 's/.*/(&+2)%3/'|bc|tr 012 '><='_ しかたないからシェルの arithmetic expansion に書き換える。
70バイト。Bourne shell の仕様の範囲で動くはずのものをわざわざ動かないものに修正したあげくに長くなるってものすごく負けた気分じゃね？ つーか、手元に55バイトの awk の解があるから、tr \ GRCSP5a-z -002211\ |sed 's/.*/echo $(((&+2)%3))/'|sh|tr 012 '><='でいいじゃん (*1)。やらないけど。awk 'gsub(/C|S/,2)gsub(/P|5/,1)<$0=substr("><=><",$1-$2+3,1)'_ もひとつ、 Expression。
これも bc を使ってるのでダメ。式を作って計算しろ、という問題で素直に式を作って計算したらエラーになるなんて……。この場合は、arithmetic expansion に 書き換えても1バイトしか増えないんだけどさ。eval echo `sed 's/ /-/;s/ /{-,+}/g'`|xargs -n1|bc|sort -unbash じゃなくて POSIX sh の場合は $[] から $(()) への変更と、それにともなうメタキャラクタのエスケープが必要。brace expansion を使ってるので Bourne sh ではどっちにしろ不可。eval echo \$[`sed 's/ /-/;s/ /{-,+}/g'`]|xargs -n1|sort -un
(*1): 問題にはパー対パーがないので、ふたつめの gsub は sub でもよくて、さらに1バイト縮められる。やらないけど。
_ まだ入社してねぇよ。
_ 昨年末にインストールだけしてそれからずーーっと放置していた次期自宅サーバ予定マシンをまともに使えるようにそろそろいじりはじめる。放置するにもほどがあるだろ。
_ 仕事で作る場合だと複数のマシンで役割を分担させるから、1台あたりの機能はそれほど複雑じゃないことが多いし、作業がある程度手順化されてるから、構築にかかる作業量はそんなに多くない。ついこの間も1日で10台作ったし。でも、自宅用サーバは1台にあれこれ機能を詰め込んでる上、妙なところにあちこち手が入ってるので移行させるのがすげーめんどうでおっくうなんだよね。自分にとってどうしても必要な改造とほんの思いつきでいじったくだらない改造が相互に依存しあってたりすることもあるからなぁ。
_ そんなわけでぼちぼちと下の方のレイヤからいじる。
_ これまではいらんパケットのほとんどは家庭用ルータの内蔵フィルタで捨てていて、それを補完するためにちょい役で ipfw を使ってた。サーバ側のフィルタはちょい役というのはこれまでどおりだけど、次は ipfw から pf に変更する。ipfw の機能に不満があったわけじゃないんだけど、pf にはおもしろそうな機能がいろいろありそうなので。FreeBSD で pf が使えるようになって何年もたつのに今さら何いってんだ、という気もするが。
_ つーわけで、man を見たりぐぐったりしながら ipfw のルールを pf に移植。pf をいじるのははじめてだけど、文法は IPFilter にわりとよく似てる（IPFilter のライセンスがウザいからという理由で作られたのが pf なので）ので、まあなんとかなりそう。つーても、Solaris で IPFilter を最後にいじったのはもう何年も前のことなのでほとんど覚えてないけど。
_ ipfw は first match win、最初にマッチしたルールが適用されるけど、IPFilter、pf は last match win なので、順番がひっくりかえる。そのくせ、マッチしたら後のルールを無視してそいつを適用しろ(quick)なんてディレクティブがあるので、ipfw に比べるとパケットがどのルールにひっかかったのかちょっとだけわかりにくいような気がする。head を駆使する IPFilter はもっとわかりにくいけど。
_ 文法は IPFilter に似てるけど、マクロ展開とかは pf 独自の機能だね。でもそういうのはあればあったで邪魔にならないけど、なければ外部のマクロプロセッサにやらせりゃいいじゃん、な考えなので、こういうのは別にどうでもいい。つーか、わしが m4 を覚えたのは sendmail.cf を作るためではなく、ipfw のルールを書くためだ。そういえば、何百行もの ipfw のルールに展開される m4 マクロを前いた会社に残していったんだけど、ちゃんと保守できてるのかなぁ。
_ そんなこんなで、見よう見まねでなんとかそれっぽいものができた。ちゃんと理解してやってるわけじゃないのでほんとに意図どおりの動作をするのかあやしいけどな。
_ で、pf のログなんだけど、こいつヘンだ。pflog0 という仮想的なネットワークインターフェースを作って、ログはそのインターフェースに垂れ流すだけ。ログを見たければ tcpdump -i pflog0 を実行すれ、というのはまったく発想の外だ。
_ とはいうものの、それじゃリアルタイムに見るだけで記録はできないので、ログ取り用のデーモンもある。って、こいつも pcap 形式のファイルに保存するだけじゃないかー。tcpdump の引数が -i pflog0 から -r /var/log/pflog に変わっただけ:-)。
_ でも、よく考えてみるとこの仕様は非常に合理的だ。パケットフィルタにどんなパケットがひっかかったかを記録するのなら、もともとそれ用に作られた pcap が最適に決まってる。ログからソース IP やポート番号なんかの条件を絞って抽出するには、テキストを grep するより tcpdump や ethereal を使った方が確実。この方法を思いついた人はひじょーにエラい。
_ そうはいって syslog にテキストで記録されてると便利なことも多い。 こういう方法もあるが、ぱっと見てわかるとおりリアルタイムで sysylog で記録できるわけではない。しかたないので、自分でやっつけで書いた。こういうのをやるから、また数年後の移行で苦しむんだけどな。 このスクリプトを /usr/local/etc/rc.d/ あたりに放りこんで、/etc/rc.conf で pflogger_enable=YES とかやって起動すると、ログをリアルタイムに syslog に吐くようになる。tcpdump の引数やらなんかを rc.conf で指定できるようには作ってないので、必要ならばスクリプトを直接書き換えれ。このスクリプトは pflogd と排他ではないので、tcpdump の引数を変えて両方同時に動かしてもいいかもね。
_ が、わしはこんなことをしたくて pf に乗り換えるわけではない。つづく。
_ pf に乗り換えようつづき。pf にはテーブルってのがあって、新しいルールを追加しなくてもテーブルに値を追加してやることで同じルールをかんたんにほかの IP アドレスにも適用できる。てなわけで、これを積極的に活用したアプリもある。そのひとつが spamd。 この前の記事では紹介しておかなきゃと思ってたんだけど、書きはじめたらすっかり忘れてしまって、思い出したのは校正まで終わってからだったんだよね。
_ pf.conf にこんな設定を追加しておく。
すると、<spamd> というテーブルに列挙されている IP アドレスからの SMTP 接続は、通常の25番ポートではなく 127.0.0.1:8025 にリダイレクトされる。それ以外からはふつーに 25番につながる。というわけで、<spamd> にブラックリストな IP アドレスを入れておいて、127.0.0.1:8025 では対 spammer 専用の MTA を動かしておくと、本来の MTA で spam よけの負荷が軽減される。table <spamd> persist rdr pass on $ext_if proto tcp from <spamd> to port smtp -> 127.0.0.1 port 8025_ で、spamd というのはその pf からリダイレクトされるポートで動かすことが前提の SMTP サーバ（MTA ではない）。ありがちな名前なので pfspamd と呼ばれることも。デフォルトではクライアントに嫌がらせをするだけ。直接お話するとこんな感じ。
すげー失礼なメッセージを出すが、もっとムカつくのはたったこれだけの SMTP トランザクションを完了させるのに5分近くかかるということ。サーバからのレスポンスが1秒あたり1バイトしか返ってこないんだよ。spammer に時間を無駄づかいさせようという戦略を取ってるわけですな。最終的には拒否応答しかせず、メールを受け取ることはないので、RFC の推奨タイムアウトを守らないクライアントを選別しているわけではない。ほんとにただの嫌がらせ。220 hostname ESMTP spamd IP-based SPAM blocker; Thu Mar 29 00:28:06 2007 ehlo hoge 250 Hello, spam sender. Pleased to be wasting your time. mail from: hoge 250 You are about to try to deliver spam. Your time will be spent, for nothing. rcpt to: fuga 451 Temporary failure, please try again later._ 嫌がらせではないマシな動作もできる。pf.conf にさらに以下を追加する。
これは <spamd-white> というテーブルに載っていないクライアントからの接続をリダイレクトする。spamd は -g という引数つきで起動しなおす。table <spamd-white> persist rdr pass on $ext_if proto tcp from !<spamd-white> to port smtp -> 127.0.0.1 port 8025_ spamd は <sapmd-white> に載っていないクライアントからの接続がリダイレクトされてくると、4xx な応答を返すとともに、そのクライアントの IP アドレスを <spamd-white> に追加する。すると、そのクライアントが次回接続してきたときには spamd にリダイレクトされずに本来の MTA につながる。つまり、pf のテーブルを操作することにより greylisting を実現するわけだ。greylisting ってふつーは MTA ごとに異なるプラグインを使って実現する必要があるんだけど、spamd はパケットフィルタの挙動を動的に変更することで MTA に依存せずに greylisting を実現している。なるほど。MTA 側の設定をいじらなくてもいいし、spam 対策の負荷が軽減される。うまいこと考えたな。まあ、実は ipfw でも spamd は使えたりするんだけど。
_ このように pf のテーブルをいじることでおもしろいことをやろう、ってアプリは spamd 以外にも hoststatedってのがある。pf は複数の IP アドレスに対してラウンドロビンとかランダムとかのポリシーでパケットをリダイレクトできる。つまり簡易的なロードバランサとしても使えるわけだが、さらにリダイレクト先の死活監視をおこなって、動的にリダイレクト対象からはずしたり戻したりして、もっと実用的なバランサとして使えるようにするのが hoststated。今のところ、pf の本家 OpenBSD だけでしか使えず、また pf + hoststated で作ったロードバランサ自体の冗長構成を組むことはできないみたいなので、専用機器に比べれば機能はぜんぜん足りないけど、興味深い取り組みだと思う。
_ が、わしはこんなことをしたくて pf に乗り換えるわけではない。まだつづく。
_ pf つづき。
_ いまや spam のほとんどはボットから送られてくる。spam の送信元 IP アドレスを集計してみると、以前は一部のクライアントから大量に送られてきていたが、最近ではひとつの IP アドレスからせいぜい1通しか届かない。グラフにしてみるとまさにはやりのロングテールで、そのしっぽはどんどん長くなる一方。
_ こんな状況じゃ IP アドレスベースのブラックリストではほとんど防げない。もちろん、いまだにひとつの IP アドレスから大量に送りつけてくることもないではないのでそれがまったく無意味というわけではないが、これで拒否できるものの割合はかなり小さくなっているのが現状。だから spam フィルタはメールの本文を解析したりどんどん複雑な方向に進化してる。
_ でもさ、よく考えてみよう。spam のほとんどがボットから送られてくる。ボットの正体はワームに感染した Windows PC である。じゃあ、クライアントの OS が Windows だったら拒否してやればいいんじゃね？
_ ムチャゆーな、と思われるかもしれないけど、実は 検知可能だったりする。接続してきたクライアントのフィンガープリントをチェックして、Windows のものだったら蹴ってやる。そして pf ではそれが可能なのである。すばらしい。
_ pf.conf の man を見ると、例としてこんなのが載ってる。
この例では Win9x からの SMTP 接続をブロックする。ぐれいと。じゃあ、これに Win2k と XP も対象に追加して、なんてことをいうと痛い目にあう。Windows でもボットではない Exchange サーバとかのまともな MTA もあるからね。じゃあどうすればいいだろう。block in on $ext_if proto tcp from any os {"Windows 95", "Windows 98"} to any port smtp_ こうする。
spamd の設定の応用。ブラックリストにあるクライアントか、ホワイトリストにない Win2k、XP は 127.0.0.1:8025 にリダイレクト、Win9x はブロック、それ以外は25に素通しする。25の方には spam はあまり入ってこないので、こちらではゆるめの spam 判定をおこない、127.0.0.1:8025 では厳しめの spam チェックをおこなう MTA を動かしておく。Windows でも spammer ではないちゃんとした送信元であればホワイトリストに追加してやればチェックのゆるい方に素通りするし、Windows 以外でもあやしげなところからならばブラックリストに入れておけばチェックの厳しい方にリダイレクトされる。rdr pass on $ext_if proto tcp from <smtp-black> to port smtp -> 127.0.0.1 port 8025 rdr pass on $ext_if proto tcp from !<smtp-white> os {"Windows 2000", "Windows XP"} to port smtp -> 127.0.0.1 port 8025 block in log on $ext_if proto tcp from any os {"Windows 95", "Windows 98", "Windows ME"} to any port smtp_ 127.0.0.1:8025 の方は、たとえば きのうの spamdを greylisting モードで動かしてもいいし、postfix ではたとえば master.cf で
とするだけでもかなり効果があると思われる。もちろん、SpamAssassin などの重量級 spam フィルタを通してもいい。あ、submission ポートはちゃんと分離してね。127.0.0.1:8025 inet n - n - - smtpd -o smtpd_delay_reject=no -o smtpd_client_restrictions=sleep,30,reject_unauth_pipelining_ 前述したとおり Windows でもボットばかりではなくまともなクライアントもあるので、全面的にブロックするわけにはいかずチェックを通常より厳しくする程度にとどまるだろうし、ボットの出すメールでも Windows 以外のサーバから転送されてくることがあるので完全に防げるわけではない。OS フィンガープリントはあくまで推定にすぎず偽装も可能なので絶対的な信用をおけるわけではないし、既知のフィンガープリントしか防げない（そして現時点では Windows Vista のフィンガープリントはデータベースにない）。だからこれで完全というわけではないが、SMTP 接続してくるクライアントをボットの可能性が高い集団と低い集団に分離するにはこの程度で十分だろう。そして何よりスバラシイのは、使用する MTA にまったく依存しないということ。あの MTA にあるその機能は自分が使ってる MTA にはないんだよなー、とうらやましそうに指をくわえて見ている必要はないのだ。そのかわり激しく OS に依存するけど。これで実際にどの程度効果があるのかは、まだ実戦投入していないので今のところ不明だけど、悪いはずはないと思う。
_ あちこちで指摘されてる（ このへんとか）けど、 find | xargs をやる場合は空白や改行入り、ハイフンではじまるファイル名を安全に扱えるように find -print0 | xargs -0 にしなきゃね、というのが教科書の答。おかしなファイルが存在しないことがはじめからわかってる場合はそんなめんどくさい引数はつけないけどな。
_ でも、find のうしろって、xargs とはかぎらんでしょ。null 区切りの文字列を扱えないコマンドがほとんどだよ。どうすんのよ。\0 ってしょっちゅうセキュリティホールの元になるような別の意味で危険な文字だよ。\0 を安全に扱えないコマンドにうかつに -print0 の出力を渡してしまうとかえっておかしなことが起きるかもしれない。
_ xargs 以外でこれを考慮してるのは知ってるかぎりでは cpio だけだな。find にひっかかったファイルだけをアーカイブしたい、というときに tar を使うのは不適。cpio や pax を使うことになるが、cpio には -0 がある。pax にはないみたい。
find /path -print0 | cpio -o0v -H ustar > hoge.tar_ うしろにスクリプト言語をつなげるときもなんとかなるかも。
あ、perl も ruby もいっしょだ。find /path -print0 | perl -nle 'BEGIN{$/="\0"} .....' find /path -print0 | ruby -nle 'BEGIN{$/="\0"} .....'試してみたら GNU awk でだけ可能だった。それ以外の awk は \0 を扱えない。find /path -print0 | awk -v RS='\0' '.....'_ それ以外は？ ほぼ全滅。find のうしろに xargs がある場合でも、出力の順番をいじりたいからといって find | sort | xargs とかやってしまうと -print0 は使えない。ああ困ったねぇ。どうしようもないねぇ。
_ 間違っているのは「404 を返さないこと」ではなく「200 を返すこと」。
404 ではないけど、ちゃんと意味を理解していずれも正しい使うのならば 404 よりも適切なステータスコードである。引っ越したわけでもないのにリダイレクトしたり、復活する可能性があるのに 410 を返すのはよろしくない。
- その URL はどっかに引っ越したから 301 でリダイレクトする。
- その URL はもう二度と復活しないから 410 を返す。
_ 410 のエラーページはめったに見ないけど、これは単に「存在しない」ではなく、「削除した（リンクが残ってたら消してくれ）」という意思をはっきり示すものなので、むしろ 404 の方が不適切という場合もあるだろう。もっとも、以前数ヶ月にわたって実際に 410 Gone を返し続けたときは Googlebot も Y! Slurp も msnbot もクロールをやめてくれなくて、HTTP 的に正しくても実効的には何の意味もなかったが。
_ ほんとはもっと入念に準備してからのつもりだったんだけど、今日は天気がよくなくて外に遊びに出かけても楽しくなさそうなので、えいやっとうちの自宅サーバを切り替えてしもた。FreeBSD 5.4 から 6.2 へ。Crusoe 700MHz から PentiumM 1GHz へ。メモリ 256MB から 512MB へ。これまでも十分にオーバースペックだったのにさらに強化されてしまった。もったいない。
_ とりあえずは外から見える HTTP、メール、DNS の部分だけ。内部的に使ってるものは後まわしにするつもりでいたら、けっこういろんなところに影響が出て内側もいじったところ多数。
_ えと、ごめんなさい。切り替え直後の15時ちょい前から2時間ほど、外から見える Web コンテンツが1週間ほど昔に巻き戻ってました。旧サーバから新サーバにホームディレクトリだけ移してコンテンツの rsync を忘れてた（←アホ）。ちゃんと自分でアクセスして表示を確認しないとダメです。
_ あと、エイリアスを追加するのを忘れてて自分宛のメールを user unknown で1通バウンスさせたとか（←アホ）。追加したつもりだったんだけどされなかったですよ。ちゃんと確認しろってことだよな。自分が投げたテストメールだから誰にも迷惑はかけてないけど。
_ それ以外にはとくに大きな問題は出てないと思う。たぶん。きっと。そうだといいな。もしおかしなところを見つけたら教えて。
_ で、移行に合わせて dkim-milter のバージョンを 0.6.1 に上げる。ports が DomainKeys verify つきでコンパイルできるようにオプションが追加されてたので、野良ビルドはせずこいつを使ってインストール。BROKEN といって怒られるけど無視した:-)。
_ 切り替えた後でいろいろ試してみたんだけど、どうも動作があやしい。gmail は以前まで DomainKeys だったんだけど、最近になって DKIM と DK の両方のヘッダをつけてくるようになったんだよね。ところが、DKIM の方しか verify が働かない。sa-test @ sendmail.net（送信者認証の公開テストアドレス）に送ったときに返信は両方 verify しようとしてるみたいなんだけどなぁ。DKIM は rsa-sha256 という未知の暗号化形式になってるので DKIM の verify はエラーになって DK の方しかうまく動かないけど、処理しようとした痕跡は見つかる。ports で BROKEN になってるのはこのあたりが原因かしらん。というか、以前のバージョンはどんな動作してたっけ？ つーか、DKIM、DK とも採用してるドメインが少なすぎてまともなテストなんてできないよ。