Aerc: よくできたメール用TUI

 (blog.sergeantbiggs.net)
1 ポイント 投稿者 GN⁺ 2024-08-24 | 1件のコメント | WhatsAppで共有
  • Aerc は Pine・Mutt よりはるかに新しい TUI メールクライアントだが、日常利用向けにあらためて検討できるだけの 成熟度と機能 を備えている
  • :help や aerc-tutorial (7) のような man page ベースのヘルプ により、外部ドキュメントなしで設定やキーバインドをすばやく習得できる
  • アカウントはウィザードと ~/.config/aerc/accounts.conf の INI 設定ファイル で管理し、サーバーごとに異なるフォルダー構造も一貫して整理できる
  • TUI では扱いにくい HTML メール は、w3m、dante、:open、MIME・ヘッダーベースのカスタムフィルターで表示方法を調整する
  • Vim での作成、外部アドレス帳、PGP、署名、テンプレート、添付忘れ通知を組み合わせて、ターミナル中心のメールワークフロー を柔軟に構築できる

Aercの位置づけと第一印象

  • Aerc は TUI メールクライアント で、最初のリリースは約4年前
  • Pine は 1992 年、Mutt は 1995 年にリリースされているため、Aerc は既存のターミナル向けメールクライアントと比べると非常に新しい部類に入る
  • 当初は Thunderbird に比較的満足しており、Aerc はやや基本的なツールに見えたため使わなかったが、最近あらためて見直すと日常用クライアントとして使えるだけの成熟度と機能を備えているように見えた
  • neomutt を何度も試してはすぐ挫折して諦めていた経験から、Aerc にもほとんど期待していなかったが、実際の使い心地は期待を上回り、これまで使ったメールクライアントの中でも最も楽しい部類だった
  • まだ他のメールクライアントより 優れている と判断するには早いが、数日使った結果は非常に好印象だった

ドキュメントと内蔵ヘルプ

  • Aerc には :help コマンドでアクセスできる 内蔵ヘルプ がある
  • チュートリアルでは、初期設定に必要な主要機能やキーバインドを簡潔に案内している
  • ほかのヘルプページもアプリケーションの各部分を短く明確に扱っており、外部資料なしでも機能を覚えやすい
  • ヘルプ文書は less にパイプされる man page 形式になっている
    • 例: aerc-tutorial (7)
    • TUI アプリケーション内に移植性の高いヘルプシステムを組み込む方式になっている

アカウント設定とフォルダー管理

  • アカウントはシンプルで直感的なウィザードで追加できる
  • ウィザードは ~/.config/aerc/accounts.conf に新しいアカウント項目を作成する
  • このファイルは INI 構文 を使っており、読みやすく編集もしやすい
  • アカウント設定には IMAP/SMTP アドレス、既定フォルダー、送信者、送信済みメールのコピー先、ヘッダーキャッシュ、フォルダー並び順、アーカイブ、メール確認間隔、フォルダーマッピングファイルなどを含められる

  • folders-sort

    • folders-sort は特定フォルダーの自動ソートを上書きするオプション
    • 指定したフォルダーは与えた順番のまま一覧の先頭に表示され、残りはアルファベット順に並ぶ
    • Thunderbird や Outlook のようなグラフィカルクライアントでは見たことがないが、すべてのメールクライアントにあってほしい機能に思える

  • folder-map

    • folder-map はメールプロバイダーごとに異なる サーバーフォルダー構造 を、表示用のフォルダー名へマッピングする
    • Gmail はすべての項目を [Gmail] フォルダー配下に置き、一部のプロバイダーは Sent と Drafts を INBOX 配下に置くが、そうでないプロバイダーもある
    • サーバーが提供するフォルダー構造は、メールサーバーを自分で管理していない限り変更しにくい
    • Aerc はマッピングルールファイルによって、サーバーフォルダーを表示用フォルダー名に変換する
      • 単一フォルダーの再マッピングが可能
      • フォルダーとそのすべてのサブフォルダーの再マッピングが可能
      • すべてのサブフォルダーから接頭辞を削除できる
      • フォルダーの衝突を避けながらサブフォルダーを再マッピングできる
    • この機能を使えば、サーバー構造に関係なくすべてのアカウントで 一貫したフォルダー構造 で作業できる
    • GUI より CLI でメールを管理する場合、このような一貫性はとくに重要になる

メールの閲覧とHTML処理

  • メール閲覧の体験自体はおおむね普通だったが、不便さの主な原因は Aerc 自体というより HTML メール にある
  • ほとんどの multipart メールでは、プレーンテキスト版のほうが HTML 版より読みにくい
  • 概ね意味は把握できるが、ときには内容が入り混じって見えることもある
  • Aerc はこの問題を軽減するためのいくつかの選択肢を提供している
    • w3m と dante の組み合わせで、HTML パーサー・ブラウザー経由で閲覧できる
    • 一部のメールでは、生成された出力がプレーンテキスト版より良い
    • 最後の手段として :open を使い、既定の Web ブラウザーで開ける
  • 表示方法は カスタムフィルター で構成される
    • フィルターは、メッセージを表示する前に通す *nix パイプライン
    • 標準フィルターはプレーンテキストの色付け、カレンダー項目、HTML メールをサポートする
    • フィルターは MIME タイプごとに設定でき、特定ヘッダーにもマッチさせられる
    • 設定例には text/plain=colorize, text/calendar=calendar, text/html=html | colorize のような項目が含まれる

メール作成とアドレス帳

  • メール作成体験は非常に良く、Vim でメールを書ける 点が大きな利点

  • アドレス帳連携

    • アドレス帳は Aerc 内で直接管理するのではなく、外部プログラムに委ねる設計になっている
    • ユーザーがアドレス帳プログラムに送る検索クエリを指定すると、その結果が該当ヘッダーフィールドの自動補完に使われる
    • 既定のプログラムは abook
    • テスト時点では abook は非 ASCII 文字を含む名前をサポートしておらず、ドイツ語話者と頻繁にメールをやり取りする場合、この制限は致命的
    • メール全体からアドレスを解析して abook に簡単に取り込む方法もなかった
    • aercbook も試したが、非 ASCII 文字の問題は同じだった
    • 一方で aercbook は、すべてのヘッダーフィールドからメールアドレスを解析する機能をサポートしている
    • emailbook-janet は aercbook の書き直し版
      • 性能はやや劣るが、ASCII 問題を解決している
      • キーバインドでメールを選択して解析し、すべてのアドレスをアドレス帳に自動追加できる
    • emailbook-janet と aercbook は完全なアドレス帳というより、名前とメールアドレスだけを保存して自動補完を可能にするツール
    • より強力なアドレス帳が必要なら、khard や類似ソリューション、LDAP サーバーのような選択肢も検討できる

PGP、署名、テンプレート、通知

  • Thunderbird の PGP/GPG サポートで最も不便だった点は、別個のキーチェーンを使うことだった
  • Aerc にも独自のキーチェーンはあるが、必須ではない
  • 既定の動作は GPG キーチェーンをそのまま使う方式
  • メッセージ署名に使う特定のキー ID を指定することも、Aerc にメールアドレスからキーを探させることもできる
  • すべてのメールに自動署名するオプションと opportunistic encryption オプションもある
  • GPG の設定が正しければ、PGP サポートは問題なく動作する

  • 一般設定機能

    • Aerc はアカウントごとに signature-file= でテキストファイルを読み込む 署名 をサポートする
    • 外部コマンドを実行して署名を生成することもできる
    • メールテンプレートもサポートしているが、詳しく見たわけではない
    • メール件名の Re: の繰り返しを複数言語で賢く取り除こうとしており、そのために正規表現を使っている
    • この正規表現は上書きや拡張が可能
    • 件名空欄の確認と添付ファイル通知にも対応している
      • 件名空欄の確認は、件名が空かどうかを検査する
      • 添付通知は正規表現ベースなので簡単に拡張できる
      • 既定の正規表現は ^[^>]*attach(ed|ment)
      • > で始まる行を除外し、他人が添付について言及した引用文を弾く
      • ドイツ語メール向けに an(ge)?h[aä]ngt? を含むよう正規表現を拡張できる
    • 数日使った Aerc は よく磨き込まれている 印象が強く、しばらく使い続ける価値のあるメールクライアントに思える

関連記事

1件のコメント

 
GN⁺ 2024-08-24
Hacker Newsのコメント

  • Aercを長いこと日常使いのメールクライアントとして使っており、IMAP（Gmailなど）で使っているが、ローカルのメールディレクトリでも十分に使える。
    新しいキーバインドを覚えるにはもう年なので、AercのキーマッピングをVim風キーバインドに変えたところ、大量のメールを非常に高速に処理できるようになった。
    GmailとImapfilterがきちんと動くように設定し、従来のメールクライアントではいつも物足りなかったフィルタも作った。たとえば、現在の送信者を基準にしたフィルタ ff = :filter -f "{{index (.From | emails) 0}}"、同じ件名のメールを見る fs = :filter -H subject:"{{.SubjectBase}}"、件名に含まれる語で検索する fS = :filter -H subject: といった具合。
    興味があればGitHubリポジトリを貼る。

    • Gmail連携が気になる。muttでやってみたが、午後いっぱい格闘したくなくて諦めた。
      しかもGmailがIMAPを段階的に廃止するという話も聞いた。
    • この記事を見てaercをまた触ってみたくなった。特に最初のフィルタは、メールクライアントでずっと欲しかった機能だ。
    • https://github.com/rafo/aerc-vim
      添付画像のプレビューも追加した。
    • とくにvimキーバインドに興味がある。それがあれば始めるのがずっと楽になりそう。

  • muttをかなり深く掘ったが、結局のところGUIメールクライアントのほうが自分の必要には合っているという結論になった。
    Mutt/aercは、好みや仕事の都合でよく使うWindowsをサポートしていないし、HTMLメールの表示や送信も弱い。同僚たちは、なぜ自分のメールの見た目がおかしく、返信の書式が消えるのか不思議がっている。
    Betterbirdではメールをフォルダへドラッグ＆ドロップするのが速く、まともな設定が整うまで時間のかかるmuttと違って、すぐ使える。mbsyncやofflineimapはOAuth対応が弱いが、Betterbirdは標準で対応している。
    必要ならShift+クリックでプレーンテキスト返信や作成もできる。普段はほぼターミナルで暮らしているが、この件はここまでで、RSSリーダーとしてnewsboatを使う投資は今のところ悪くなかった。
    1: https://www.betterbird.eu/
    2: https://news.ycombinator.com/item?id=39812124
    3: https://isync.sourceforge.io/mbsync.html
    4: https://www.offlineimap.org/

    • AercはWindowsでもビルドできそうで、Goとmakeさえあればよい。Betterbirdも数週間前まではMacOS対応だけで、最初にMacビルドを提案したときは資金面の問題で断られていた。
      Aercは記事にあるようにHTMLメール表示もできる。メールの移動も、マウスドラッグよりキー入力のほうがずっと速いことがあり、同じフォルダを繰り返し使うならなおさらだ。たとえば pa = :archive flat, pb = :move Brain, pf = :move のように使っている。
      設定はmuttよりずっと複雑ではなく、OAuthもきちんと動く。Betterbirdも悪くないが、自分のキーボードショートカットが使えないのが嫌だ。
    • 2つ目と3つ目の問題は、それぞれ w3m のmailcapエントリや、muttrc の set send_multipart_alternative_filter=markdown2html.py のような設定で緩和できる。
      https://gitlab.com/muttmua/mutt/-/blob/master/contrib/markdown2html
    • 最近のWindowsにはある程度Hyper-Vが入っていて、Linux VMを動かせるし、OpenSSHも標準で入っている。適切な環境を整えるには少し手を入れる必要はあるが、それほど多くはない。
      自分はLinuxしか使わないがGUIを好み、オンプレミスのMS ExchangeにEvolutionをつないで使っている。友人や家族向けの個人ドメインメールも、DovecotやEximなどで運用している。
      Betterbirdは知らなかったが、評価してみようとブックマークしておいた。いつかExchangeサーバーを捨てる必要があるだろうし、M365に行くかどうか議論するのが楽しみだ。25年以上メールシステムを運用してきた立場からすると、結局ExchangeもIMAPD、MTA、カレンダーアプリの組み合わせで置き換え可能だと思う。
    • dodoが合っているかもしれない。基本的にはGUIメールクライアントだが、Vimバインドが多く、ターミナルとGUIの利点を混ぜたような形で、メール向けのqutebrowserのような感じだ。
      ただし、メンテナンスは止まっているようで、notmuchバックエンドしか対応していないようだ。
      1: https://github.com/akissinger/dodo
      2: https://qutebrowser.org/
    • 作者の政治的傾向はともかく、mutt-wizardを使っていて、その設定では o の代わりに v を押すだけで、開いているWebブラウザでメールを表示できる。
      HTMLメールの閲覧には十分使えた。ただし仕事用ではなく個人用でしか使っていないので、人によっては事情が違うかもしれない。

  • Gmailタブを5つ、Gmail以外のメール用タブを2つ開きっぱなしにしておくのにうんざりして、今週 aerc を設定し、Notmuch バックエンドと、Gmail 用の lieer、Gmail 以外用の mbsync でメールを同期した
    設定して流れに慣れるまでおよそ12時間ほどかかったが、以前のやり方よりずっと快適。Firefox で Gmail のタブ1つが 100MB 以上食っていたのに比べて、新しい構成ははるかに軽く、ローカル検索も速くて質が高い

    • Notmuch を使うなら bower を勧める。notmuch と連携するターミナル UI で、SSH 越しでも動くように設定できるので、notmuch DB が別のコンピュータ上にあっても添付ファイルはローカルマシンで開ける
      1: https://github.com/wangp/bower
    • notmuch はぜひ試してほしい。2011年ごろに切り替えて以来、戻ったことがない
      クライアントに Emacs を使う必要はまったくなく、aerc を含めフロントエンドはたくさんある
      https://notmuchmail.org/frontends/
      その中では alot がおそらく最もよく知られている
      https://github.com/pazz/alot

  • ターミナル UI のメールクライアントはいつも魅力的に見えたが、なぜ心のどこかで抵抗を感じるのか分かった気がする
    ターミナルは自分の 瞑想空間 だ。深く集中して、自分が楽しめる本当の作業をしに行く遊び場なんだ
    メールを読んだり書いたりするのは Slack のような雑務なので、それを自分のターミナルの中に持ち込みたくない

    • 私は少し違って見ている。仕事が雑務っぽく感じられるほど、その体験を改善するツールに惹かれる
      そういう作業を切り離しておくのは、むしろその作業へのネガティブな連想を強めるだけだと思う。いつかは全部処理しなければならないのだから、少しでも苦痛を減らすほうがよいし、少なくとも自分の場合はターミナル作業の利点を損なわない
    • 自分も大半をターミナルに大きく依存しているが、ターミナル UI のメール とウェブブラウジングはうまく噛み合ったことがない。なぜなのか、この表現がまさに言い当てている

  • 今メールで起きている問題は、現代的でパーソナルなメールツール の開発が不足していることに由来する
    ここでいうパーソナルとは、他人のメールサーバー上に住むのではなく、リモート IMAP を簡単にダウンロードしたり同期したり、自前で扱えたり、個人ホームサーバーの IMAP を持ち、notmuch-emacs や mu4e のような検索中心のクライアントや MailDrop のようなまともなフィルタリングツールを備えた構成のことだ
    部品はすでに全部そろっている。IMAPFilter と OfflineIMAP で同期したメールを再分類したり、fetchmail と MailDrop で取得したり、Emacs の notmuch や Aerc を使ったりできる。だが、異なる設定、流儀、ドキュメント品質、親切さを持つ別々のプログラムがあるだけで、そこまでオタクではない人や専門家でない人向けのものは何もない
    そのため多くの人がメールをウェブメールと同一視し、ウェブメールを Slack や WhatsApp Web のような第三者サービスとして受け入れるようになる。これは通信の自由と、メールがもたらす力にとって危険な見方だ
    ISP の定期請求書を MailDrop のルールで捕まえてスクリプトを実行し、期限と金額を予定表に追加し、その後ローカル会計ソフトで関連取引があるか確認して、異常なら警告する、といったことは、org-agenda、BeanCount、MailDrop、そしてメールのようなテキストベースのツールなら難しくない。現代のソフトウェアでは非常に難しく、簡単な自動化を学んで実装するには道のりが長すぎるか、そもそもその可能性自体を知らない潜在的パワーユーザーにとって大きな損失だ
    IT は人生を単純化し、人間の認知を拡張するために生まれたのに、ほとんど皆がそれを忘れてしまったのは悲しい
    [1] メールファイル名のせいで、複数マシン間で同期すると未読状態やタグに関する不便、重複メッセージの生成などがしばしば起きる

    • 大文字で書かれた PERSONAL が本当に重要だ。今日では多くの人が Gmail のようなウェブサイトに閉じ込められていて、何が可能かすら知らない
      メールは本来、ワークフロー、フィルタリング、並べ替え、フォルダー分けなどを 100% ユーザーがカスタマイズできるものであるべきだった
      古いツールは今でもちゃんと動くので、その可能性はまだ残っている。ただ、メールを本来意図された形で使うとどれほど素晴らしいか、もっと知られるべきだ。Gmail がメールそのものだと信じていたなら、私もメールを嫌っていただろうが、Gmail はメールそのものではない
      procmail と mutt は今でもよく動く

  • 現代的な テキストベースのプロジェクト が本当に好きだ。ターミナルを生きた意味のあるものとして保ち続けてくれてありがたい

  • ある人が Emacs の mu4e でメールを読む実演を見たが、HTML 部分はそのまま Firefox にパイプして見て、一部は PDF に変換して見ていた
    https://www.youtube.com/watch?v=1uulLBKBMX8

  • aerc はメールをコンピュータに保存する側ではなく、クライアント として設計されている点でかなり珍しい。なので性能面の影響や制約がある
    ローカルメールも使えはするが、自分が見た限りでは二次的な機能のように感じられた。ただ、かなり前に見た話なので今は違うかもしれない
    そういう設計なら IMAP がもっとよく動くべきだと思うが、しょっちゅう接続が切れ、再接続するには再起動が必要だった。neovim と aerc のショートカットの衝突も不便だ
    全体として満足できなかった。設定で何か見落としていたのかもしれないのでまた見直すかもしれないが、今は neomutt のほうに期待している

    • ローカルメールディレクトリと組み合わせて使うほうが確かにずっと良い。たいていのメール用ターミナル UI ユーザーは、体験全体を改善するために mbsync や notmuch のようなユーティリティと一緒に使っていると思う
    • 自分も IMAP 接続切れ を経験している。かなり雑に聞こえるかもしれないが、aerc を while ループの中で実行し、おかしくなったら q で終了して数秒後に再起動している
      それでもなお一番好きなメールクライアントだが、もっと良くなれるのは確かだ
    • neovim と aerc のショートカットの衝突とはどういう意味なのか気になる。Vim はキーボードのほぼすべてのキーを使うのだから、実質的にはどんなプログラムでも起こりうる問題ではないだろうか
    • 最高のメールユーザーエージェントである mutt は、IMAP サーバーへの接続に失敗すると自動で再接続する。ただし、毎回うまくいくわけではないようだ
      https://lwn.net/Articles/837960/
    • それは mutt でも同じではないか?

  • himalaya は有望に見える
    https://github.com/soywod/himalaya
    https://pimalaya.org/himalaya/cli/latest/index.html

  • 「TUI」が何なのか、どこにも説明が見当たらない。テキストユーザーインターフェース のことだと考えればよさそう