Office 365 から通知されてくる iCalendar を mutt でいい感じに表示させる

【IIJ 2018 TECHアドベントカレンダー 12/12（水）の記事です】

今年を振り返ってみると、多くの企業で Office 365 の導入が進んだ年だったように思えます。
IIJ も Office 365 を活用していますし、お客様にも「Office 365 導入ソリューション」を提供している一方で、今年 2度あった Office 365 の認証系の障害^(※1)(※2)で業務が停止してしまった、といった声も聞こえてきました。海外のニュースサイトには Office 362 だとか、とりわけアジア圏は(タイムゾーンの関係で) Office 359 だった とも報道されていました。

IIJ がサービス提供している IIJ セキュア MX では、Office 365 とセットで利用することで柔軟にメールセキュリティを強化できることがセールスポイントですが、障害や災害時でもセキュリティを維持しつつ最低限メールの送受信手段を確保できる「スペアメール」というオプションサービスがあります。じつは 2015年にリリースしてから今まで、正直、あまりお引き合いをいただかなかった地味なオプションだったのですが、今年は特にこのオプションが注目を浴びる年でもあったのも、こうした背景があったものと推測されます。

スケジューラとしての予定表

さて、少し話が逸れましたが、Office 365 でも代表的な機能の一つが予定表です。
予定が登録されると自分宛に通知してくれるので、プライベートで活用している方もいらっしゃるかもしれません。

また予定が登録されると、その通知メールには iCalendar と呼ばれる RFC5545 形式のファイルが添付されています。大抵のメーラーではこれをうまく解釈して表示してくれて、自分のスケジューラと連動してくれたりしますので便利です。例えば、私が使っている KMail はこんな感じです。

しかし、我々は運用エンジニア。

障害対応などで、いつなんどきでもリモートからログインしてサービス復旧に全力をあげ、その合間や報告にメールを読み書きすることも少なくありません。困ったことに iCalendar 形式を解釈できない CUI のメーラーを使っていると、予定の通知は空メールが送られてくるように見え、予定が入ったことはなんとなく察することができるものの、具体的な日付や内容が分からず役に立たないのです。困りました。

iCalendar を parse する

この iCalendar 形式のファイルですが、開いてみると分かるように、ただのテキストファイルです。そして多くの CUI のメーラーは $HOME/.mailcap に MIME ごとのヘルパーアプリケーションを書いて渡すことができます^(※3)。私が使っている mutt は、設定で指定した MIME パートを優先的に表示することが可能なので、iCalendar 形式のファイルをいい感じに parse して表示してくれるものがあれば良さそうですが^(※4)、出席者の情報を一緒に表示してくれないなど、なかなかしっくりくるものがなかったので雑に書くことにしました。
https://github.com/ikoga/bin/blob/master/ical2txt.sh

設定ファイルにはこんな感じのものを追加します。

• $HOME/.muttrc

# HTML メール, icalendar を見やすくする
auto_view text/calendar text/html
alternative_order text/calendar text/html

• $HOME/.mailcap

text/plain; cat %s; copiousoutput
text/html; w3m -I %{charset} -T text/html; copiousoutput
text/calendar; /home/koga/bin/ical2txt.sh %s; copiousoutput

ところでちょっと余談なのですが、予定表の「出席者」の部分、Office 365 では本名を表示するようになっていますが、これは同姓同名を区別できないという点でナンセンスです。また、企業のメールアドレスに本名を用いているケースをよく見かけますが、これをしてはいけない理由が古くからあるメールサーバの sendmail パッケージ中に含まれる cf/README に 20年以上も前から書いてあります。

• 最新の cf/README (3605行目付近の抜粋)

As a general rule, it is an extremely bad idea to using full names
as e-mail addresses, since they are not in any sense unique. For
example, the Unix software-development community has at least two
well-known Peter Deutsches, and at one time Bell Labs had two
Stephen R. Bournes with offices along the same hallway. Which one
will be forced to suffer the indignity of being Stephen_R_Bourne_2?
The less famous of the two, or the one that was hired later?

Finger should handle full names (and be fuzzy). Mail should use
handles, and not be fuzzy.

意訳すると、こんな感じでしょうか。

一般論としてメールアドレスに本名(フルネーム)を使うのは、一意にならないという点で極めて良くない方法です。

例えば、UNIX ソフトウエア開発者のコミュニティには少なくとも 2人の Peter Deutsches がいます。
また、ベル研究所には 2人の Stephen R. Bournes が同じ廊下に面したオフィスにいます。

どちらの Stephen を屈辱的とも言える Stephen_R_Bourne_2 とするのでしょうか?
有名でないほう? それとも後から雇われたほう?

finger サービスは本名を返すべきですが、メールアドレスはハンドルネームを用いるのが望ましく 2つ以上の解釈の余地があってはいけません。

以上の理由から、社内の出席者はメールアドレスの local-part、社外の人はメールアドレスの全てを表示することにします。こんな感じです。

これでバッチリ見えるようになりましたね！

まとめ

通信回線が大容量化し、スマートフォンがあれば大抵のことができるようになった昨今、リモートホストにログインして CUI なメーラーでパケットをケチケチするのは今どきの方法ではないかもしれません。しかし、出張などで海外のインターネットに触れると、未だに通信事情の良くない地域もあり、そんなときに CUI は大いに活躍しますので、道具の一つとして知っておくのはエンジニアとして悪いことではないでしょう。

おっと、また何やら予定表から通知がきましたね、なんでしょう。

 

 

 

 

 

 

 

あぶないあぶない、iCalendar をちゃんと見えるようにしておいて良かった。^(※5)
早速、お花買って帰ります！

注意: iCalendar ファイルに登場する人物・団体は架空のものであり、仮に実在したとしても筆者および IIJ は一切関係ありません。

注釈