May 2007
May 10, 2007
オフィス移転！ - 羽田寛の徒然草
続きを読む
ちょうど1年弱前におぎゃあと誕生したわが社もあっという間に社員数も40人近く。
手狭になってしまった西麻布オフィスを卒業し、このほど神宮前6丁目にオフィスを移転しました。
続きを読む
さっき気付いた。。
Twitter / Junya Kondo: nipotanのせいだ .
これだけに気付いた時、近藤社長は何をご立腹なのかと悩んだ。
何か近藤社長の逆鱗に触れるようなことでもしただろうか。
確かに、個人的にはてなではサブアカをいくつか持っていて、時々実験的に変なことしたり書いたりはしていますが、ここ最近は、特にはてなを荒らすような行為もしていないし、この頃家で暇な時は Wii で Rimo 見てるぐらいはてな愛好家の私。
だのに、一体何があったのか。とても悩んだ。
あ、ちなみに私の Wii 番号は 7648 8579 7957 6203 です。
次にこの発言の直前の近藤社長の発言を見てみた。
Twitter / Junya Kondo: gtalkブロックしたらtwitterみなくなった .
解釈すると、「近藤社長は Twitter の notification を Google Talk に送っていたのだが、nipotan のせいでブロックした」ということだろう。
発言の書き込みは、
嗚呼、そんな時間に Twitter 見てない。。。
近藤社長のこの発言の前、私が Twitter で何を言ったかと言うと、このおよそ 4 時間前に
Twitter / nipotan: Twitter で LDR の未読数うｐするのやめる
と書いていた。
そう、この直前までの発言は、
Twitter / nipotan: 現在の LDR 未読数: 1,133
Twitter / nipotan: 現在の LDR 未読数: 1,106
Twitter / nipotan: 現在の LDR 未読数: 1,075
Twitter / nipotan: 現在の LDR 未読数: 1,068
Twitter / nipotan: 現在の LDR 未読数: 1,052
Twitter / nipotan: 現在の LDR 未読数: 1,029
と、このように livedoor Reader の未読数を 30 分に一回 Twitter にうｐしていた。
それが近藤社長の逆鱗に触れたのだ。
何しろ、
Twitter / nipotan: 現在の LDR 未読数: 9,668
朝起きてから、久々に Twitter を見たら「Twitter で LDR の未読数うｐするのやめる」とか書いてあって、「ちょｗｗｗ藻前のアレのせいで Twitter ウザくなって見なくなったんだからなｗｗｗｗ」と教えて下さっていたにもかかわらず、恐らくその時刻にはすっかりオフラインになった俺は、翌朝、会社に来て、Twitter を見て、呑気に
Twitter / nipotan: 櫛井のOK
とか更新していた。
近藤社長からの言及にも気付かずに。
そう、その頃、friends の発言を含めた With Friends のページを辿って見た場合に 16 ページも先で、完全に埋もれてしまっている近藤社長の「nipotanのせいだ .」の発言を見付けることが出来る。
chat とはまた違う、リアルタイムコミュニケーションに特化した Twitter というサービスは、太平洋を超えると時差の関係からコミュニケーションが取りづらいということがよくわかりました。
近藤社長すみません。もうしません。
しかし、同じ太平洋標準時のこの人には、あまり時差を感じない。
不思議だ。
実は日本にいるんじゃないのかとか疑ってしまう。
後の宮川達彦国内滞在説である。
Twitter / Junya Kondo: nipotanのせいだ .
これだけに気付いた時、近藤社長は何をご立腹なのかと悩んだ。
何か近藤社長の逆鱗に触れるようなことでもしただろうか。
確かに、個人的にはてなではサブアカをいくつか持っていて、時々実験的に変なことしたり書いたりはしていますが、ここ最近は、特にはてなを荒らすような行為もしていないし、この頃家で暇な時は Wii で Rimo 見てるぐらいはてな愛好家の私。
だのに、一体何があったのか。とても悩んだ。
あ、ちなみに私の Wii 番号は 7648 8579 7957 6203 です。
次にこの発言の直前の近藤社長の発言を見てみた。
Twitter / Junya Kondo: gtalkブロックしたらtwitterみなくなった .
解釈すると、「近藤社長は Twitter の notification を Google Talk に送っていたのだが、nipotan のせいでブロックした」ということだろう。
発言の書き込みは、
08:38 AM May 08, 2007となっているが、これは恐らく太平洋標準時 (PST) で、かつ夏時間の表記なので、日本時間にすると
00:38 AM May 09, 2007であったかと思われる。
嗚呼、そんな時間に Twitter 見てない。。。
近藤社長のこの発言の前、私が Twitter で何を言ったかと言うと、このおよそ 4 時間前に
Twitter / nipotan: Twitter で LDR の未読数うｐするのやめる
と書いていた。
そう、この直前までの発言は、
Twitter / nipotan: 現在の LDR 未読数: 1,133
Twitter / nipotan: 現在の LDR 未読数: 1,106
Twitter / nipotan: 現在の LDR 未読数: 1,075
Twitter / nipotan: 現在の LDR 未読数: 1,068
Twitter / nipotan: 現在の LDR 未読数: 1,052
Twitter / nipotan: 現在の LDR 未読数: 1,029
と、このように livedoor Reader の未読数を 30 分に一回 Twitter にうｐしていた。
それが近藤社長の逆鱗に触れたのだ。
何しろ、
Twitter / nipotan: 現在の LDR 未読数: 9,668
11:00 AM May 02, 2007このあたりから、6 日間以上、未読数ばっかりをうｐし続けた上、
11 Friendsと、friend の数がとても少ない近藤社長にとって、未読数をうｐしはじめたとたんに、今まで静かだったのに突如日夜問わず俺の無益な発言ばかりが 30 分おきに Google Talk であがってきて、鬱陶しくてたまらなくなったのだろう。
298 Followers
朝起きてから、久々に Twitter を見たら「Twitter で LDR の未読数うｐするのやめる」とか書いてあって、「ちょｗｗｗ藻前のアレのせいで Twitter ウザくなって見なくなったんだからなｗｗｗｗ」と教えて下さっていたにもかかわらず、恐らくその時刻にはすっかりオフラインになった俺は、翌朝、会社に来て、Twitter を見て、呑気に
Twitter / nipotan: 櫛井のOK
とか更新していた。
近藤社長からの言及にも気付かずに。
そう、その頃、friends の発言を含めた With Friends のページを辿って見た場合に 16 ページも先で、完全に埋もれてしまっている近藤社長の「nipotanのせいだ .」の発言を見付けることが出来る。
chat とはまた違う、リアルタイムコミュニケーションに特化した Twitter というサービスは、太平洋を超えると時差の関係からコミュニケーションが取りづらいということがよくわかりました。
近藤社長すみません。もうしません。
しかし、同じ太平洋標準時のこの人には、あまり時差を感じない。
不思議だ。
実は日本にいるんじゃないのかとか疑ってしまう。
後の宮川達彦国内滞在説である。
Justin Gehtland Ben Galbraith Dion Almaer 宮川 達彦 加藤 慶彦
オライリー・ジャパン (2006/10/05)
オライリー・ジャパン (2006/10/05)
May 04, 2007
元来国際通信に長けている某大手電気通信事業者が運営している、某個人向け ISP に加入しています。
昨年個人情報流出事件があり、それ以来、何故か SPAM 等の迷惑メールが大量に増えました。
※ ISP 発表によると調査した結果メールアドレスは流出していないので、因果関係は不明。
迷惑メールなんて、会社のメールを含めれば一日 1,000 通以上は受信しているので、個人的には割とどうでもいいんですが、その某 ISP が迷惑メール対策をしてくれているのかどうか、一日に 3 〜 5 通程度、本文の無いメール、厳密に言うと、ヘッダが終わって直後に本文とのデリミタ行 (空行) が無く、ドットのみの行が来るメールが届いてます。
自力で SMTP を喋って中身を見てみると、
これは実際に届いていたメールの一部 (ところどころ伏せ字にしてある) だが、決まって Subject ヘッダ (件名) とか From ヘッダ (送信者) が存在しない。
そして、かなり簡素。
Received ヘッダとかが異様に少ない。
最後のドットのみの行は、RFC 2821 の section 4.1.1.4 に書かれている
つまり、メッセージの終端を表現する行。
で、ヘッダと本文のデリミタ行 (空行) が無く、すぐにメッセージの終端 (ドットのみの行) をむかえるメールを、個人的にいつも利用している MUA "Becky! Internet Mail" で受信すると、こんな風になってしまい、受信出来なくなってしまう。
個人的にまず使うことはないが、多くの人が使っているであろう MUA "Outlook Express" とかで受信しても、こんな風になってしまって、同様に受信が出来ない。
で、自分の場合も結局数日間 (あるいは数週間) 後に、これが原因で全然受信出来なくなっているという状態に気付いて、以前は慌てて Becky! についている "リモートメールボックス" の機能を使い、それと思しきメール (Subject が "(no subject)" になっていて、From が無いメール) を削除してから受信を行ないます。
別にこの ISP が悪いとは言いません。流出した情報にメールアドレスは含まれなかったそうですし。
もしかしたら MUA 自体が悪い (本文が無いメールを想定していない設計) という見方も出来ます。
でも、どうしてこういうメールが普通に届いてしまっている状態を ISP が放置しているのかは個人的には理解出来ません。
ちなみに、こうなってしまうことについて、ISP の web サイトの FAQ ページにある、「メールの受信ができないのですが。」という質問を見ても、それに対しての回答は、この状況については全く想定していない、このケースにあてはめて見てしまうと完全にピントのズレた回答。
同じ ISP で、「突如メールが受信出来なくなった」と、個人 Blog 等に書かれている方もかなり多く見受けられますが、実際に ISP のカスタマーサポートに連絡した結果、「一度アカウントの再設定をして下さい」と、的はずれな回答をされた後、やはりダメでもう一度問い合わせると「サーバーにあるメール自体が壊れていてそれが原因かもしれないので、web 上のカスタマーサイトで web メールに入り、一旦全てのメールを削除しては」(某 Blog より編集して引用) と回答されるそうな。
つまりは、その ISP はこの事象の原因を正確には把握していないと思われます。
しかし、自分のように、意図的に全てのメールを削除しないようにしているユーザもいれば、そうでなくとも、まだ受信していないメールも大量に残っているユーザもいるだろうに、そんなの構わずそこで削除するように指示するなんてかなり乱暴だなと感じました。
どうして 11 ヶ月近くこういう状態がずっと続いているのに、調査出来る能力を持った人がちゃんと調査して解決しようとしないのでしょうか。。
恐らく、もう数ヶ月もメールが受信出来なくなってしまっている状態で、意味がわからず、完全に諦めている人もいるんだろうなと思います。
この ISP はそろそろ解約しようと思うので、置き土産なんぞをと思います。
個人的には、こんなスクリプトを数分おきとか定期的に動かし、MUA で受信出来なくなってしまうメールを削除するようにして回避しています。
同じような状況に悩まされていて、Perl が使えて、Net::POP3 を入れられるという環境をお持ちのかたは、どうぞお試しください。
昨年個人情報流出事件があり、それ以来、何故か SPAM 等の迷惑メールが大量に増えました。
※ ISP 発表によると調査した結果メールアドレスは流出していないので、因果関係は不明。
迷惑メールなんて、会社のメールを含めれば一日 1,000 通以上は受信しているので、個人的には割とどうでもいいんですが、その某 ISP が迷惑メール対策をしてくれているのかどうか、一日に 3 〜 5 通程度、本文の無いメール、厳密に言うと、ヘッダが終わって直後に本文とのデリミタ行 (空行) が無く、ドットのみの行が来るメールが届いてます。
自力で SMTP を喋って中身を見てみると、
Return-Path: <itukamiwo@example.co.jp>
Received: from example.com ([220.96.28.15x])
by nm06mta.example.ne.jp
id <20070504034111321.MAC0.81C37A8@nm06mta.example.ne.jp>;
Fri, 4 May 2007 03:41:11 +0900
Message-ID: <200705031841113518590006MAC0@nm06mta.example.ne.jp>
Date: Fri, 4 May 2007 03:41:11 +0900
.
こんなかんじ。これは実際に届いていたメールの一部 (ところどころ伏せ字にしてある) だが、決まって Subject ヘッダ (件名) とか From ヘッダ (送信者) が存在しない。
そして、かなり簡素。
Received ヘッダとかが異様に少ない。
最後のドットのみの行は、RFC 2821 の section 4.1.1.4 に書かれている
The mail data is terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2). This is the end of mail data indication.あたりに書かれているもの。
つまり、メッセージの終端を表現する行。
で、ヘッダと本文のデリミタ行 (空行) が無く、すぐにメッセージの終端 (ドットのみの行) をむかえるメールを、個人的にいつも利用している MUA "Becky! Internet Mail" で受信すると、こんな風になってしまい、受信出来なくなってしまう。
個人的にまず使うことはないが、多くの人が使っているであろう MUA "Outlook Express" とかで受信しても、こんな風になってしまって、同様に受信が出来ない。
で、自分の場合も結局数日間 (あるいは数週間) 後に、これが原因で全然受信出来なくなっているという状態に気付いて、以前は慌てて Becky! についている "リモートメールボックス" の機能を使い、それと思しきメール (Subject が "(no subject)" になっていて、From が無いメール) を削除してから受信を行ないます。
別にこの ISP が悪いとは言いません。流出した情報にメールアドレスは含まれなかったそうですし。
もしかしたら MUA 自体が悪い (本文が無いメールを想定していない設計) という見方も出来ます。
でも、どうしてこういうメールが普通に届いてしまっている状態を ISP が放置しているのかは個人的には理解出来ません。
ちなみに、こうなってしまうことについて、ISP の web サイトの FAQ ページにある、「メールの受信ができないのですが。」という質問を見ても、それに対しての回答は、この状況については全く想定していない、このケースにあてはめて見てしまうと完全にピントのズレた回答。
同じ ISP で、「突如メールが受信出来なくなった」と、個人 Blog 等に書かれている方もかなり多く見受けられますが、実際に ISP のカスタマーサポートに連絡した結果、「一度アカウントの再設定をして下さい」と、的はずれな回答をされた後、やはりダメでもう一度問い合わせると「サーバーにあるメール自体が壊れていてそれが原因かもしれないので、web 上のカスタマーサイトで web メールに入り、一旦全てのメールを削除しては」(某 Blog より編集して引用) と回答されるそうな。
つまりは、その ISP はこの事象の原因を正確には把握していないと思われます。
しかし、自分のように、意図的に全てのメールを削除しないようにしているユーザもいれば、そうでなくとも、まだ受信していないメールも大量に残っているユーザもいるだろうに、そんなの構わずそこで削除するように指示するなんてかなり乱暴だなと感じました。
どうして 11 ヶ月近くこういう状態がずっと続いているのに、調査出来る能力を持った人がちゃんと調査して解決しようとしないのでしょうか。。
恐らく、もう数ヶ月もメールが受信出来なくなってしまっている状態で、意味がわからず、完全に諦めている人もいるんだろうなと思います。
この ISP はそろそろ解約しようと思うので、置き土産なんぞをと思います。
個人的には、こんなスクリプトを数分おきとか定期的に動かし、MUA で受信出来なくなってしまうメールを削除するようにして回避しています。
同じような状況に悩まされていて、Perl が使えて、Net::POP3 を入れられるという環境をお持ちのかたは、どうぞお試しください。
#!/usr/local/bin/perl
use strict;
use Net::POP3;
use constant POP3_HOSTNAME => 'pop.k5.example.ne.jp';
use constant POP3_USERNAME => 'a123456789';
use constant POP3_PASSWORD => 'pAssWorD';
my $pop = Net::POP3->new(POP3_HOSTNAME, Timeout => 10);
exit unless $pop->login(POP3_USERNAME, POP3_PASSWORD) > 0;
my $stored = $pop->list;
for my $num (sort { $b <=> $a } keys %$stored) {
my $msg = $pop->top($num, 0);
my $has_delimiter = 0;
for my $line (@$msg) {
next if $line =~ /[^\r\n]/;
$has_delimiter = 1;
last;
}
$pop->delete($num) unless $has_delimiter;
}
$pop->quit;
