mikegerwitz
/
dotfiles
1
0
Fork 0
Code Releases Activity
dotfiles/emacs.d/mail.org

705 lines
27 KiB
Org Mode
Raw Permalink Blame History

#+TITLE: Mike Gerwitz's Emacs Mail Configuration
#+AUTHOR: Mike Gerwitz
#+EMAIL: mtg@gnu.org
Before beginning on my Emacs-related mail configuration, I want to
shout out to my previous e-mail cl that served me well for so many
years: [[http://www.mutt.org/][Mutt]]. My [[https://gitlab.com/mikegerwitz/dotfiles/blob/master/muttrc][personal Mutt configuration]] is still publicly
available.
The reason that an Emacs MUA won out was because the lure and
flexibility of a client written in a Lisp, and written to be easily
customized and hooked in a Lisp, is powerful. But it's not for
everyone; I still recommend Mutt to others.
As always with my code, I use lexical variable binding:
#+BEGIN_SRC emacs-lisp :padline no
;; -*- lexical-binding: t -*-
#+END_SRC
* Identity
My identity isn't as trivial as it sounds, since I may be sharing this
configuration with multiple environments. But I'm pretty sure my name
won't be changing:
#+BEGIN_SRC emacs-lisp
(setq-default user-full-name "Mike Gerwitz")
#+END_SRC
My e-mail address depends on who I am representing (e.g. myself or my
employer). I therefore defer these configuration options to a
configurable value that specifies a local profile:
#+BEGIN_SRC emacs-lisp
(defcustom mtg/mail-profile
nil
"Function used to perform mail setup
The function should set all necessary mail options."
:type 'function
:group 'mtg)
;;(funcall 'mtg/mail-profile)
#+END_SRC
That said, there are certain settings that are reasonable defaults;
they can be overridden if needed.
#+BEGIN_SRC emacs-lisp
(require 'smtpmail)
(setq send-mail-function 'smtpmail-send-it
message-send-mail-function 'smtpmail-send-it
smtpmail-debug-info t)
#+END_SRC
** GNU Profile
Nearly all of my communications are related to software. As a member
of the GNU Project, I'm both proud and want to do my best to bring
attention to it. Communications using this address do _not_
necessarily mean that I'm speaking on behalf of the GNU Project.
GNU hosts a POP server on =fencepost=. I have a =fetchmail= cronjob running
on my server that periodically fetches mail from fencepost onto my own
mailserver, and an =offlineimap= job that copies all messages to my local
box; all my mail is conveniently mixed into one account, and all GNU mail is
also run through my Sieve rules and any other scripts.
For sending mail, privacy is an important consideration: I really do not
want my home IP Address and hostname appearing in the header of every e-mail
that I send. I have the option if running Emacs using =torify=, but that is
far too slow for receiving the amount of e-mail that I sift through.[fn:Of
course I could set up a local IMAP server that downloads my mail
periodically to avoid this---and I have done that in the past---but for
reasons I do not want to get into right now, I have stopped using it.] The
other option is a SOCKS proxy for SMTP only, but it's not obvious to me how
to do that, so I'll defer further research for another time. This leaves a
SOCKS proxy in general, or tunneling.
I have opted for an SSH tunnel. This has a couple benefits: my normal
network rules will apply for reading mail---for which privacy is not a
concern---and, since I'm connecting to =localhost=, I cannot forget to
invoke Emacs in a special way: the connection will fail if I do not have a
tunnel set up.[fn:For example, running =torify emacs= or =proxychains emacs=
can yield a good result, but if I forget to do so, that's a problem.]
#+BEGIN_SRC emacs-lisp
(defun mtg/mail-prof/gnu ()
"Mail profile for GNU Project"
(setq user-mail-address "mtg@gnu.org"
smtpmail-smtp-server "localhost" ; tunnel
smtpmail-smtp-service 5587
gnus-select-method '(nnimap "localhost"
(nnimap-inbox "INBOX")
(nnimap-record-commands t)
(nnimap-stream network)
(nnimap-authenticator login))))
#+END_SRC
While GNU's SMTP server is usually what I use, life is a little more
complicated. Personal e-mail that really should only be handled by my own
servers needs to be sent out using my own SMTP server; otherwise, replies to
my personal e-mail would have to go out under my GNU address, which isn't
desirable.
This overlaps a little bit with my Gnus configuration below.
#+BEGIN_SRC emacs-lisp
;; default is mtg@gnu.org, so we need only worry about overrides
(setq gnus-posting-styles
'(((header "to" ".+@mikegerwitz.com")
(address "mike@mikegerwitz.com")
(signature-file "~/.signature.mtgcom")
("X-Message-SMTP-Method" "smtp mail.mikegerwitz.com 587"))))
(defun mail-mikegerwitz.com-p ()
)
#+END_SRC
Gnus supports an internal =X-Message-SMTP-Method= header that will direct
mail to the desired SMTP server. [[https://lists.gnu.org/archive/html/help-gnu-emacs/2015-11/msg00031.html][Pretty simple!]] Any mail at my domain will
reach me. Chances are, I want to reply from my main e-mail address
(especially if I want to GPG-sign my message), but I can change that
manually if need be. I often enter unique e-mail addresses for services I
sign up for to track who sells my data to spammers or might have been
compromised.
* <<<Gnus>>>
[[gnus.org][Gnus]] is a popular message reader (that is, newsgroups and the like, in
addition to E-mail) for Emacs. It is highly customizable via user
options and hooks. Given that it is written in Elisp, it is also
customizable through redefining or advising existing functions.
Of course, that's assuming that I know what the hell I'm doing. I'd
like to think that I do.
#+BEGIN_SRC emacs-lisp
;; prevents annoying prompts that try to save your ass from doing
;; something stupid
(setq gnus-novice-user nil
gnus-interactive-exit nil)
#+END_SRC
** Receiving Mail
The notion of a "large" newsgroup (or mailbox) has changed over the
years as network connections have continued to improve. With that
said, some hosts do better than others, some ISPs do better than
others, and some user choices may have an impact. For example, I use
Tor for many communications.
I have found that 500 messages is a decent amount not only for
preventing fetching too much data, but to help grok it as well. More
messages can always be retrieved (using =/ N=).
#+BEGIN_SRC emacs-lisp
(setq-default gnus-large-newsgroup 500)
#+END_SRC
This would be less of a concern if Emacs were not single-threaded, or
if Gnus handled the message retrieval in another process or
thread.
** Writing and Sending Mail
Nearly every conversation I have with someone online is via e-mail; I
do not use any "social media" websites, and any websites that I do use
for communication have, or would do well to have, an e-mail interface.
*** Replying
There are important considerations when replying to
mail. Specifically, when replying, you would do best to provide
proper unambiguous context and a summary reference for both the
recipient and any readers of the message. There are [[https://en.wikipedia.org/wiki/Posting_style][plenty of
opinions on posting style]], but the de-facto standard in technical
discussions (and discussions with reasonable human beings) is the
interleave style, whereby responses follow the appropriate /portion/
of quoted text, followed (potentially) by more quotes and
replies.
The foundation for a good reply is a good quote. I enjoyed Mutt's
default style, which included a timestamp in the quote heading, which
I find important. Further, Gnus adds an empty line after the heading,
which I do not like, as I believe it makes the block quotations more
difficult to grok at first glance.
#+BEGIN_SRC emacs-lisp
(setq message-citation-line-function
'message-insert-formatted-citation-line
message-citation-line-format
"On %a, %b %d, %Y at %H:%M:%S %z, %N wrote:"
gnus-face-9
'gnus-face-tree-marker)
#+END_SRC
A proper reply then involves first placing a greeting, apropos, or
summary above the quote heading, and then inserting replies within
certain parts of the quote block (creating block fragments), and
deleting fragments that are unneeded or inapplicable for the reply.
*** Importing Messages
Some messages may be written externally (e.g. generated by a program,
or even written by another person). I provide functions to import
them as articles into a group.
#+BEGIN_SRC emacs-lisp
(defun gnus-import-article-quick (group file)
"Import FILE as an article into GROUP.
FILE is imported as-is, without any assurances that it constitutes a valid
message.
Return (FILE . article-id) pair."
(interactive "sGroup: \nfImport file: ")
(with-current-buffer (gnus-get-buffer-create " *import file*")
(erase-buffer)
(nnheader-insert-file-contents file)
(let* ((result (gnus-request-accept-article group nil t t))
(article-id (cdr result)))
(kill-buffer (current-buffer))
`(,file . ,article-id))))
(defalias 'gnus-import-draft-quick
(apply-partially 'gnus-import-article-quick "nndraft:drafts"))
#+END_SRC
Git is able to generate a patch series for sending commits via
e-mail. This function helps to import them into Gnus for manual
editing and sending, rather than using its own mail facilities for
sending the messages automatically.
These functions may be buggy; I seldom use them.
#+BEGIN_SRC emacs-lisp
;; TODO: gracefully fail when no wildcard matches
(defun gnus-import-patch-set (path &optional edit patch-ext)
(interactive "DPath: \nP")
(let* ((ext (or patch-ext ".patch"))
(result (mapcar 'gnus-import-draft-quick
(file-expand-wildcards (concat path "/*" ext))))
(root-id (cdar result)))
(gnus-group-read-group t nil "nndraft:drafts")
(gnus-summary-goto-article root-id t t)
(when edit
(gnus-summary-edit-article))
result))
(defun gnus-create-patch-set (repo-path topic mainline)
(interactive "DRepository path: \nsTopic branch: \nsMainline: ")
(cd repo-path)
(call-process "git"
nil
(list (gnus-get-buffer-create " *create-patch-set*") t)
nil
"format-patch"
(concat mainline ".." topic))
(gnus-import-patch-set repo-path t))
#+END_SRC
*** Signing and Encrypting
Every message I sent is cryptographically signed using my GPG key. When I
have my recipients' keys, they're also encrypted.
BEGIN_SRC emacs-lisp
(setq mml-secure-openpgp-signers t)
#+END_SRC
*** Archiving
I archive my sent messages to both reference and reflect upon what I
have said. But I don't want to feel obligated to re-read what I
wrote!
#+BEGIN_SRC
(setq gnus-gcc-mark-as-read 1)
#+END_SRC
When I can---that is, when my recipients support it---I GPG-encrypt my
e-mail. Problem is, I can't read what I sent unless I also encrypt the
message to myself.
#+BEGIN_SRC emacs-lisp
(setq mml-secure-openpgp-encrypt-to-self t)
#+END_SRC
** Reading Mail
The vast majority of my interaction with other human beings is through
my MUA; its presentation is important. I have not customized it as
heavily as have [[https://gitlab.com/mikegerwitz/dotfiles/blob/master/muttrc][I have Mutt]] (yet), but it's a start.
*** Headers
Headers are important: they convey metadata that helps to provide
context and validity to a message. Certain headers I use for
cross-referencing externally, such as =Message-ID=.
#+BEGIN_SRC emacs-lisp
(setq gnus-sorted-header-list '("^From:"
"^Newsgroups:"
"^Subject:"
"^Date:"
"^Envelope-To:"
"^Followup-To:"
"^Reply-To:"
"^Organization:"
"^Summary:"
"^Abstract:"
"^Keywords:"
"^To:"
"^[BGF]?Cc:"
"^Posted-To:"
"^Mail-Copies-To:"
"^Mail-Followup-To:"
"^Apparently-To:"
"^Resent-From:"
"^User-Agent:"
"^X-detected-operating-system:"
"^Message-ID:"
"^References:"
"^List-Id:"
"^Gnus-Warning:")
gnus-visible-headers (mapconcat 'identity
gnus-sorted-header-list
"\\|"))
#+END_SRC
Considering that I just expressed my interest in headers, it would
stand to reason that I would not want them stripped upon saving a
message somewhere:
#+BEGIN_SRC emacs-lisp
(setq gnus-save-all-headers t)
#+END_SRC
*** Signature Verification
Always try to verify GPG/PGP-signed messages when possible. If this fails
because the key is not available, the message conveniently displays the key
id.
#+BEGIN_SRC emacs-lisp
(setq mm-verify-option 'always)
#+END_SRC
Signature verification doesn't really help me if I can't see that it's
signed to begin with. In Gnus, it seems that the easiest way to do this is
to "buttonize" it, which will delimit the part that is signed.
#+BEGIN_SRC emacs-lisp
(setq gnus-buttonized-mime-types
'("multipart/signed"
"multipart/encrypted"))
#+END_SRC
*** Message Formats
I like plain text. It is the universal language: all standard Unix
utilities are made to operate on plain text; they can be manipulated
and piped to other utilities to create sophisticated processes for
operating on it. It also views well on a terminal, on which I live.
I therefore discourage use of HTML e-mails. Gnus is able to render
HTML emails on a terminal fairly well, but that is not what I want; I
don't want to read your HTML e-mails at all.
Some people do send me HTML-only e-mails; in that case, there's the
option of forcing the HTML rendering, or viewing the e-mail in my web
browser. You know---the place where HTML belongs.
#+BEGIN_SRC emacs-lisp
;; >:@
(setq-default mm-discouraged-alternatives '("text/html"))
#+END_SRC
*** Groups
Group lines are displayed as follows:
#+BEGIN_SRC emacs-lisp
(setq gnus-group-line-format
"%M%m%S%5,5y/%-5,5t %*%B%-40,40g %ud\n")
#+END_SRC
**** Sorting
It makes sense for me to have the most read groups appear at the top
of my group list. Ranks will be adjusted and the groups re-sorted
after returning from summary mode.
#+BEGIN_SRC emacs-lisp
(setq gnus-groups-sort-groups
'gnus-group-sort-by-rank)
(add-hook 'gnus-summary-exit-hook
'gnus-summary-bubble-group)
(add-hook 'gnus-summary-exit-hook
'gnus-group-sort-groups-by-rank)
#+END_SRC
**** Topics
I subscribe to a number of mailing lists, and further organize my mail
into a number of groups; it helps to have them organized
hierarchically. Gnus offers a "topic" minor mode that offers this
feature.
#+BEGIN_SRC emacs-lisp
(add-hook 'gnus-group-mode-hook
'gnus-topic-mode)
#+END_SRC
**** Last Visit Timestamp
On a similar note, it's also helpful to know when I last looked at a
group. Sometimes. Not often.
#+BEGIN_SRC emacs-lisp
(add-hook 'gnus-select-group-hook
'gnus-group-set-timestamp)
#+END_SRC
The default timestamp format for =%d= is ISO 8601, which isn't very useful,
because it requires too much effort to visually parse. In the definition of
=gnus-group-line-format= above, there is a format specifier =%ud=, which is
user-defined; I define it here (largely derived from the [[info:gnus][Gnus manual]] Gnus manual):
#+BEGIN_SRC emacs-lisp
(defun gnus-user-format-function-d (headers)
(let ((time (gnus-group-timestamp gnus-tmp-group)))
(if time
(format-time-string "%a %d %b %Y, %T" time)
"")))
#+END_SRC
*** Summary Mode
Gnus' summary mode displays a list of messages. The proper way to
display messages is in threads, which display responses
hierarchically. This is especially important for discussions in
mailing lists, as they can get incredibly lengthy, there can be many
discussions happening concurrently, and it's easy to lose context.
My tree display is inspired by Mutt.
#+BEGIN_SRC emacs-lisp
;; mutt-inspired tree display
(setq gnus-summary-line-format "%U%R%z %d %-23,23f (%4,4L) %*%9{%B%}%s\n"
gnus-sum-thread-tree-root ""
gnus-sum-thread-tree-false-root "──> "
gnus-sum-thread-tree-leaf-with-other "├─> "
gnus-sum-thread-tree-vertical "│ "
gnus-sum-thread-tree-single-leaf "└─> ")
#+END_SRC
When entering summary mode by selecting a group with
=gnus-topic-read-group= (default =SPC=, as opposed to
=gnus-topic-select-group=, which defaults to =RET=), an article
(message) is selected automatically for reading. I want to see any
unseen articles first, otherwise unread (the latter there may be many
of, such as in groups associated with high-volume mailing lists).
#+BEGIN_SRC emacs-lisp
(setq gnus-auto-select-subject
'unseen-or-unread)
#+END_SRC
**** Articles
An /article/ in Gnus terminology, as far as we're concerned here, is a
message. When reading, hitting =SPC= will (by default) scroll down a
page. When reaching the end of an article, the next =SPC= press will
silently move to the next article.
This is a problem, because the previous message may end close to the
bottom of the window, and then it may not be immediately apparent that
you are reading a new message. I've been bitten by this before, and
it can be profoundly confusing. Maybe not for you, but I don't like
it.
#+BEGIN_SRC emacs-lisp
(setq gnus-summary-stop-at-end-of-message t)
#+END_SRC
**** Sparse Threads
I choose to allow Gnus to hide articles that have been read, which
helps keep the groups clean looking and easier to grok new
material. But threads---especially on mailing lists---may be very
long, and may go on for months. The context of the parent thread is
very important.
=A T= can be used to fetch the full thread (the best it can). But
that can be overkill in cases where threads are quite large. Gnus has
a concept of "sparse" threads, in which it will attempt to build
a partial thread of parent messages (even if they are read), and will
even leave gaps where it detects missing messages (e.g. off-list
replies). The latter alone is useful in avoiding confusion.
#+BEGIN_SRC emacs-lisp
(setq gnus-build-sparse-threads 'some)
#+END_SRC
Building threads on its own isn't a trivial task; you'd think that
looking at the =References= header would be enough, but that breaks if
somebody posts a message with a broker MUA or newsreader. And I can
tell you from experience that this is not as infrequent as I would
like, even on technical mailing lists.
So, even though building threads by subject is not always accurate, it
will have to do. This is the default behavior.
#+BEGIN_SRC emacs-lisp
(setq gnus-summary-thread-gathering-function
'gnus-gather-threads-by-subject)
#+END_SRC
*** Window Layout
My display width permits and article view that contains a tree view
beside the summary, with the article rendered below both.
#+BEGIN_SRC emacs-lisp
(gnus-add-configuration
'(article
(horizontal 1.0
(vertical 0.50
(summary 1.0 point)
(tree 0.25))
(article 1.0))))
#+END_SRC
The =tree= mention above refers to the tree buffer:
#+BEGIN_SRC emacs-lisp
(setq gnus-use-trees t
gnus-generate-tree-function 'gnus-generate-vertical-tree
gnus-tree-minimize-window nil)
#+END_SRC
** Keybindings
I come from the land of Mutt, and I appreciate the concise keybindings
that it provides for many operations. I duplicate some of those here.
#+BEGIN_SRC emacs-lisp
(add-hook 'gnus-group-mode-hook
(lambda ()
(local-set-key "j" 'gnus-group-next-unread-group)
(local-set-key "k" 'gnus-group-prev-unread-group)
;; re-bind jump (originally `j')
(local-set-key "\M-j" 'gnus-group-jump-to-group)))
(add-hook 'gnus-summary-mode-hook
(lambda ()
;; `t' by default toggles headers, which we mapped above
(local-set-key "t" 'gnus-summary-toggle-processable)
;; The original keybindings are dangerous for a vim user! They
;; are still accessible, respectively, via `G j'; `M k'; and
;; `TAB' within the article buffer.
(local-set-key "j" 'next-line)
(local-set-key "k" 'previous-line)
(local-set-key "\t" 'gnus-summary-next-unread-subject)
;; mutt uses `s' for "save", which can be used to move between
;; IMAP folders (in this case, groups)
(local-set-key "\C-s" 'gnus-summary-isearch-article)
(local-set-key "s" 'gnus-summary-move-article)
;; the original has other bindings
(local-set-key "d" 'gnus-summary-mark-as-expirable)))
(add-hook 'gnus-article-mode-hook
(lambda ()
;; consistency with summary buffer (and mutt)
(local-set-key "h" 'gnus-summary-toggle-header)
(local-set-key "v" 'gnus-article-view-part)))
#+END_SRC
The =t= keybinding in Mutt toggles marks, but Gnus offers no function
to do so; I provide one via =gnus-summary-toggle-processable=:
#+BEGIN_SRC emacs-lisp
(defun gnus-summary-toggle-processable (n)
"Toggle process mark on the next N articles.
If N is negative, mark backward instead; consistent with behavior of
`gnus-summary-mark-as-processable'."
(interactive "p")
(cl-labels ((next (n direction article)
(when (and (> n 0) article)
;; toggle article (this also updates point, selecting
;; the next article if available)
(funcall
(if (memq article gnus-newsgroup-processable)
'gnus-summary-unmark-as-processable
'gnus-summary-mark-as-processable)
direction)
;; process next (the above call already selected the
;; next article, so we don't have the return value;
;; instead, assume that no other articles are
;; available if the article at point matches the
;; previously processed article)
(let ((next-article (gnus-summary-article-number)))
(unless (eq next-article article)
(next (1- n) direction next-article))))))
(next (abs n)
(if (< n 0) -1 1)
(gnus-summary-article-number)))
n)
#+END_SRC
* Contacts
The majority of my online communication is done via e-mail. Over the
years---especially on mailing lists---it's easy to accumulate a lot of
contacts, and it's easy to forget who people are. So, I need the ability to
not only store names and e-mail addresses (and auto-complete them!), but
also notes about the person, so that I can remember who they are or other
useful information about them.
Emacs comes with BBDB---the "Insidious" Big Brother Database---which keeps a
database of contacts. I won't pretend that I know how to use it very well,
but I'll do by best to learn.
#+BEGIN_SRC emacs-lisp
(bbdb-initialize 'gnus 'message)
;; this is the key for fixing a brokern BBDB3+Gnus integration
(setq bbdb-mua-update-interactive-p
'(query . create))
#+END_SRC
In order to build a comprehensive database, I want contacts to be added with
ease; en masse if need be.
#+BEGIN_SRC emacs-lisp
(bbdb-mua-auto-update-init 'gnus 'message)
;; return more than just the first address of a message
(setq bbdb-message-all-addresses t)
#+END_SRC
BBDB displays a window ("popup") when adding/editing an entry, or visiting
articles with known entries, from Gnus (for any MUA it's initialized for,
for that matter). The default size shares window space evenly with all
others---far too large.
#+BEGIN_SRC emacs-lisp
(setq bbdb-pop-up-window-size 0.15
bbdb-mua-pop-up-window-size 0.15)
#+END_SRC
* Command Line
I generally invoke Gnus in a fresh Emacs process, for various reasons that I
won't get into here right now. To make this a bit easier, I add a =gnus=
command switch that immediately invokes Gnus and then kills Emacs once it's
done.
#+BEGIN_SRC emacs-lisp
(add-to-list
'command-switch-alist
'("gnus" . (lambda (&rest ignore)
(add-hook 'emacs-startup-hook 'gnus-unplugged t)
(add-hook 'gnus-after-exiting-gnus-hook
'save-buffers-kill-emacs))))
#+END_SRC
* Correspondence
** CloudFlare
TODO: CloudFlare rant and rationale.
#+BEGIN_SRC snippet :tangle emacs.d/snippers/message-mode/cloudflare-js
# -*- mode: snippet -*-
# name: Message to webmaster of CloudFlare JS-only verification
# key: cloudflare-js
# --
I recently tried to view ${1:an article} on ${2:your website} at
${3:foo.com}. For reasons of privacy, I and many others use Tor for all
Web traffic; unfortunately, CloudFlare often recognizes Tor exit nodes as a
threat[0], and so invokes its DDoS mitigation.
Normally, the default behavior for CloudFlare---that I've noticed---is
to display a CAPTCHA to the user. This works without JavaScript enabled
and allows the user to pass once it has been answered correctly. This
isn't a pleasant experience, but it's surmountable.
But ${4:$2 has} chosen to enable CloudFlare's JavaScript-only DDoS
protection (which they call a "JavaScript Challenge").
There are a number of reasons why users may choose to disable
JavaScript: There are a host of security concerns (including attacks
that have de-anonymized Tor users; malware distribution; user spying;
and more). There is also the issue of software freedom: most websites
serve proprietary JavaScript programs that deny users the right to study,
share, and modify them.[1] This is antithetical to a free Web and is
used to exert control over users.
I understand that ${5:$2} is likely not willing to disable
CloudFlare's DDoS mitigation services, but would you please consider
using the CAPTCHA-based approach so that all users---including those
that disable JavaScript for privacy, security, and ethical
considerations---have access to the articles and information that
$4 provides? Otherwise, some users may choose to access the web page
without Tor, potentially endangering their anonymity, or may choose to
accept non-free programs that could compromise their freedom and security.
[0]: https://support.cloudflare.com/hc/en-us/articles/203306930
[1]: https://www.gnu.org/philosophy/javascript-trap.html
Please help us work our way back toward a Web that is free for everyone to
access with the software their choose and trust.
Thank you for your consideration,
#+END_SRC
View Git Blame Copy Permalink