info-gnus-english
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setup for imap server with many users


From: William Gardella
Subject: Re: setup for imap server with many users
Date: Wed, 16 Jan 2013 21:04:03 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Gour <gour@atmarama.net> writes:

> On Wed, 16 Jan 2013 19:55:09 +0000 William Gardella
> <gardellawg@gmail.com>
> wrote:
>
>> Wow.  Perhaps I'm mistaken, but I've never seen any such setup for
>> auth-source and have no clue how you would support it.
>
> Heh, too bad I do not have time-machine to go in the past to
> demonstrate you. :-)
>
>> All going to your Emacs and Gnus?  It might make more sense to give
>> each of them their own Emacs initfile and system user.
>
> No. They use Claws-mail which is easier for them.

Then what does that have to do with Gnus?  I'm confused.

> Moreover, for their minimal usage of computer, there is no sense to
> create system account for them...and Claws-mail operates normally in
> this setup where I now access mail for each 'user' from corresponding
> dovecot's virtual user...so, don't understand fully why it should be
> problem for Gnus?

It's a problem for Gnus because neither auth-source.el nor Gnus supports
such configurations well, in terms of the semantics/design of the
software.  For auth-source it is expected that there is exactly one set
of authentication secrets for each machine+protocol combination.  For
Gnus it is expected that each "select method" (i.e. server definition)
designates a particular machine to connect to, or other backend; Gnus
defers to auth-source for how to log in to that machine, including which
username to use.  The fact that it works in Claws has nothing to do with
getting it working in Gnus :) Hopefully that clarifies the problem.

> I would like to (again) use Gnus to take advantage of orgmode's
> support for it.
>
>> FTR, the maildir backend isn't particularly buggy these days.
>
> I'm aware some time has passed in between, but posts like this
>
> http://stackoverflow.com/questions/2587291/using-maildir-as-a-backend-for-gnus
>
> has made me think that nnimap is (still) better solution.

a) I've rarely found stackoverflow a reliable source on Emacs stuff,
fwiw.  b) As indicated in the answers to that poster, your
maildir-syncing tool would be responsible for synchronizing flags to the
IMAP server.  Gnus does move stuff in maildir and set flags in a
standard way, though.

>> Also, the local Dovecot hack for Gnus pertains mostly to an era when
>> nnimap was too slow for acceptable use, which is no longer really the
>> case.
>
> Really?
>
> Do you mean latest Gnus or the one coming with Emacs-24 'cause I'm
> running Debian Wheezy and have 23.4.1?

I am using Emacs 24 on Debian Sid now but the performance with Emacs 23
connecting via nnimap to 2 remote IMAP servers was perfectly fine for
me.  Certainly not troublesome enough to justify the additional
complexity of having a local IMAP server in between.

As I mentioned, you can also use nnimap+gnus agent to create a
completely offline mailreader.  This setup can be further enhanced by
using (info "(gnus) Batching Agents") if you wish.

>> Particularly with the Agent and (setq gnus-asynchronous t), its
>> performance is just fine.
>
> Thank you. I was not aware of the above setting.
>
>> If I were you, I'd cut out the Dovecot step entirely and just use
>> Gnus+nnimap directly to the remote hosts.
>
> OK, but this still involves Gnus talking to several IMAP servers and
> fetching mail for several different users? How the setup should look
> in such case?

The setup would have each of the several IMAP servers listed in
`gnus-secondary-select-methods', with the authentication secrets for
each in ~/.netrc or ~/.authinfo or ~/.authinfo.gpg or whatever you use
as your auth-source file.

e.g.

(setq gnus-secondary-select-methods
      '((nnimap "imap.somewhere.edu"
        (nnimap-server-port 993)
        (nnimap-stream ssl))
       ((nnimap "imap.somewhereelse.com"
        ...))))

etc. etc. etc.

Best,

WGG




reply via email to

[Prev in Thread] Current Thread [Next in Thread]