How to read e-mail via IMAP+SSL with Gnus

Mon, 27 Jun 2005 12:41:40 +0000

!!! Introduction

This page is a rant that documents my efforts in getting going with Gnus as an IMAP+SSL mail reader. It has been written in the hopes that ''no one'' will ''ever'' need to find all this stuff again.

By the way, when asking in the gnu.emacs.gnus newsgroup for comments about this article, I was pointed to a tutorial-in-progress, http://my.gnus.org/Tutorial/ ... http://my.gnus.org/ is definitely a place to check anyway.

!!! Setting up

The Gnus documentation encourages you to set gnus-secondary-select-methods if you want to set up an IMAP+SSL (imaps) connection. That would be great were the secondary select methods not so disruptive. Especially for sysadmins (like me), using secondary select methods is not feasible, because after a server has been entered in the list, Gnus will always try to connect to it upon startup, even if the user never subscribes and never will subscribe to any group from the server (say, most of our users only use Gnus for reading news).

Now, the `B' command (browse foreign server) would be the right solution, but surprise surprise, its `(interactive)' definition won't allow us to specify to use ssl in the connection. Which is pretty bad, because ssl is the only imap streaming method that Gnus refuses to auto-detect.

Of course, one solution (probably the neatest one) is to call gnus-group-browse-foreign-server noninteractively. I wish you good luck; here is a sample invocation:

{{{ M-: (gnus-group-browse-foreign-server '(nnimap "mymail" (nnimap-address "imap.mymail.com") (nnimap-stream ssl))) }}}

The good thing is, once you've browsed the list there and subscribed to even one folder (say, your inbox) (which is done with the command `u'=unsubscribe, now isn't that very intuitive), you can always get back there with `^' from the group buffer. Which is nice.

However, for those bad and stupid users that don't like to write multiple lines of elisp and to deal with their syntax mistakes, I dare offer this function which, in my opinion, should be included in the Gnus distribution unless they come up with some more general way to pass parameters to `B':

{{{ (defun gnus-browse-imaps-server (server) "Browse a mail server in Gnus via IMAP-SSL." (interactive "sServer name: ") (gnus-group-browse-foreign-server (list 'nnimap server (list 'nnimap-address server) '(nnimap-stream ssl) '(nnimap-list-pattern ("INBOX" "mail/*" "Mail/*" "INBOX.*")) '(nnimap-expunge-on-close ask)))) }}}

I didn't care to check whether elisp supports quasiquoting. Using that is left as an exercise to the reader.

Now, Gnus uses the OpenSSL command line program, openssl, to connect to the server by default. This is good and fine. If it doesn't work out of the box, you might want to try something like: {{{(setq imap-ssl-program "openssl s_client -tls1 -connect %s:%p") }}}

You can also use stunnel to connect. For me, the magic incantation is: {{{(setq imap-ssl-program "/usr/sbin/stunnel -c -r %s:%p") }}}

'''Update''':

I just found out (by browsing gnus defvars, how else) that you can set imap-default-stream to ssl to have ''all'' imap connections made over ssl by default. Haven't tested that, though.

If you contact numerous imaps servers (as I do), you'll find it valuable to be able to set a default user name for a server. You can do that by setting the (undocumented) variable imap-username in the connection parameters, alongside nnimap-stream & friends. This way, you can also use multiple imaps accounts on the same server.

Also, if you like Lisp but don't like M-:, you can enter the server buffer by '^' and use 'a' (add server) together with 'e' (edit server) from there.

It seems that Gnus groups maintain separate information about their server (they don't just use the server name but save the server parameters also), so if you change server parameters, it seems you sometimes have to kill all groups on that server and subscribe them again from the server with new parameters. Have fun.

!!! The important ssl.el file

Now, here comes the best part. Gnus uses open-ssl-stream from ssl.el to connect (even though what it does is practically just run the program given by ssl-program-name) which is not delivered with all emacsen (at least, on my debian/stable system it isn't). Better yet, the call to open-ssl-stream is within (ignore-errors) for reasons unbeknownst to me, which causes the connection to fail mysteriously with the error messages "failed" and "Server denied". Yay!

It suffices to drop ssl.el into /usr/share/emacs/site-lisp. You can get ssl.el from here: http://quimby.gnus.org/cgi-bin/cvsweb.cgi/gnus/contrib/ssl.el

Actually, it seems ssl.el is part of w3 (the web browser for emacs), so if you are lucky, you'll get by by installing w3.

!!! Semantic differences

As explained very well in the Gnus info document, Gnus makes mail reading very news-like. This, in my opinion, is the ''best'' part about using Gnus as a mail reader: at last, you have proper support for dealing with all those ****ing mailing lists.

The biggest question comes from deleting mail. You seldom delete news. What you can delete from news is your own postings, and that's called "canceling", works by sending a request for cancellation of the article throughout the usenet, and isn't particularly reliable. This is not something like deleting already-read mail from your inbox.

Actually, Gnus does have a concept of "Deleted", which is exactly what you'd expect it to mean for mail messages. And, Gnus has a concept of "Expirable", which means an article that Gnus thinks it has every right to delete after some time (a week) has passed. These are documented in different parts of the info document, neither of which is the same place where imap (or mail folders in general, for that matter) is discussed.

Now, as a result of this and Gnus' default behavior of now showing read articles, we actually have ''five'' (count it!) levels of "deletedness":

# unread articles # read articles # expirable articles # expired (deleted) articles # articles that are actually deleted

The reason for this last category is that, imap servers do not delete articles directly, they require you to first flag them as deleted and then expunge them. Because Gnus already has this quite extensive expiry scheme, this imap behavior feels really really unnecessary.

The next problem is, if you can't see your read mail but it only gets deleted if marked for expiration, how will you ever get rid of mail that you read but forgot to mark for expiration? That is, how do you list your read messages? Most news readers have a "show unread / show all" toggle, so that should be the answer? Right? Right?

'''Wrong.''' It took me two hours to find this functionality from the documentation, and in the meanwhile, I saw at least one web page (http://www.cs.berkeley.edu/~smcpeak/gnus.html) which taught people to deal with Gnus but explicitly mentions that the author hasn't yet been able to find this functionality. This is because showing all articles is implemented as a flag to ''entering'' a group (even though the limiting system, i.e. gnus-summary-limit-to-unread provides the exact same functionality once we have all articles), and, in a very emacs-ish way, is available by giving a prefix argument to gnus-select-group. Woohoo!

This means that, to list all articles in the current mail folder, you leave it with `q' and re-select it with `C-u ' or `C-u '.

Oh, I just found this has its own key binding - yet in another place in the documentation. Go on, it's `C-u Z R'.

!!! Summary of keystrokes

C-u Z R - show also read messages from the group // E - mark for expiry (think of this as "deleting") // B C-M-e - delete all articles marked for expiry (in groups without auto-expiry, this is not as dire as the forewarnings suggest) // B ~~- directly delete an article // B m - move a message into another folder~~

I would like to note, that the node "Mail Group Commands" is indispensable to you if you use Gnus as a mail reader.

!!! Handling of multiple personalities, categorising incoming mail

I haven't had much time to play with these, yet. I'll just document which features are probably appropriate for dealing with these.

Multiple personalities (from addresses etc) are very well handled by posting styles, which are controlled by the gnus-posting-styles variable. This variable is relatively well documented, even though I don't understand the difference between 'address' and 'From'.

Categorisation of incoming mail is called "splitting". For some weird reason, splitting is implemented separately for nnimap mail and other mail backends (which work by fetching the mail), and works within the server. It also makes opening of big inboxes very slow.

I'm not quite sure whether you can split onto another server. Doing so will be flaky, at least, because Gnus seems to log in into imap servers one at a time.

{{{ (setq nnimap-split-inbox "INBOX") (setq nnimap-split-rule '(("nnimap+saveserver:mail.\\1" "^To: .* \\([a-z.|]\\)@"))) }}}

Because splitting is fragile and slow, you might want to try kibozed groups instead. If I understand correctly, they provide the exact same functionality but are more ephemeral - no actual moving of mail takes place.

!!! Archiving and saving

"Archiving" is the act of saving copies of an article you have sent. "Saving" is the act of saving a copy of somebody else's article.

The Gnus archiving and saving systems are clearly designed for local archiving and saving. I don't like that, because I read my mail from many places and I would like to have my archives available over IMAP. That's the point of IMAP.

As far as I know, you can't give a directory name for an nnimap archive server (in gnus-message-archive-method) for saving archived postings. Instead, you have to shift that into gnus-message-archive-group. (Why, by the way, do we have all these variables that sort messages into groups on different criteria, have slightly different syntaxes and don't seem to agree about the order of group and criteria in this alist that is not an alist?) In fact, gnus-message-archive-method stinks anyway because you typically want to use one of your incoming imap servers as an archive host, so better just use long group paths ("nnimap+server...:group") in gnus-message-archive-group.

Gnus' default article saving functions don't work with anything else than files at all - they don't use backends. (Why, I might ask. And I might not get an answer.) So those are quite worthless. Instead, you use 'B m', the "move" command. Too bad it doesn't seem to work between servers. Might this be because Gnus only holds one IMAP connection open at a time?

[kategoria: ty�kalut] (category: tools)