Aerc: 잘 만들어진 이메일용 TUI

 (blog.sergeantbiggs.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 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을 사용해 기본 웹 브라우저에서 열 수 있음
  • 표시 방식은 커스텀 필터로 구성됨
    • 필터는 메시지를 표시하기 전에 파이프라인으로 통과시키는 *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는 잘 다듬어진 느낌이 강하고, 당분간 계속 사용할 만한 이메일 클라이언트로 보임

함께 보면 좋은 글 β

GN⁺   [-]
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를 깊이 파봤지만, 결국 그래픽 메일 클라이언트가 내 필요에 더 잘 맞는다는 결론에 이름
    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도 괜찮지만 내 키보드 단축키를 못 쓰는 점이 싫음
    • 둘째와 셋째 문제는 각각 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가 맞을 수도 있음. 기본적으로 그래픽 메일 클라이언트지만 Vim 바인딩이 많아서 터미널과 그래픽의 장점을 섞은 형태이고, 이메일용 qutebrowser 같은 느낌임
      다만 유지보수가 멈춘 듯하고 notmuch 백엔드만 지원하는 것 같음
      1: https://github.com/akissinger/dodo
      2: https://qutebrowser.org/
    • 작성자의 정치 성향은 의문스럽지만 mutt-wizard를 쓰고 있고, 그 설정에서는 o 대신 v만 누르면 메일을 열려 있는 웹 브라우저에서 볼 수 있음
      HTML 메일 읽기에는 충분히 괜찮았음. 다만 업무용이 아니라 개인용으로만 써서 사람마다 다를 수 있음

  • Gmail 탭 5개와 비-Gmail 메일 탭 2개를 열어두는 데 질려서 이번 주에 aerc를 설정했고, Notmuch 백엔드와 Gmail용 lieer, 비-Gmail용 mbsync로 메일을 동기화함
    설정하고 흐름에 익숙해지는 데 대략 12시간쯤 걸렸지만, 이전 작업 방식보다 훨씬 즐거움. Firefox에서 Gmail 탭 하나가 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 웹처럼 제3자 서비스로 받아들이게 됨. 이는 통신의 자유와 이메일이 제공하는 힘에 위험한 관점임
    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는 메일을 컴퓨터에 저장하는 쪽이 아니라 클라이언트로 설계됐다는 점에서 꽤 특이함. 그래서 성능상 영향과 제약이 있음
    로컬 메일도 쓸 수는 있지만 내가 봤을 때는 2등 기능처럼 느껴졌고, 다만 오래전에 본 것이라 지금은 다를 수 있음
    그런 설계라면 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”가 뭔지 어디에도 설명이 안 보임. 텍스트 사용자 인터페이스라고 보면 될 것 같음

답변달기