Re: Automatically authenticating at local imap server

Re: Automatically authenticating at local imap server

[Gour]

[-- Attachment #1.1: Type: text/plain, Size: 1034 bytes --]

>>>>> "Tassilo" == Tassilo Horn <tassilo@member.fsf.org> writes:

Hi!

Tassilo> Hi all, since a few days I run a local IMAP server that
Tassilo> OfflineIMAP synchronizes with my IMAP account at my email
Tassilo> provider.  That works like a charm, but there's one thing that
Tassilo> doesn't work.

Similar setup here ;)

Tassilo> Everytime I start Gnus it asks me how to logon at the local
Tassilo> IMAP server, but instead I want that it uses the username and
Tassilo> password that are in my ~/.authinfo.

Here is my ~/.authinfo:

machine localhost login gour password xxxxxxxx

and snippet from .gnus:

(setq mail-sources nil)
(setq gnus-select-method '(nntp  "news.gmane.org")
      gnus-secondary-select-methods
        '((nnimap "localhost-IMAP" (nnimap-address "localhost")) 
          (nntp "news.iskon.hr")))

That's all and it works with dovecot server.

Sincerely,
Gour

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
http://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: Automatically authenticating at local imap server

[Tassilo Horn]

Gour <gour@mail.inet.hr> writes:

Hi Gour,

> Tassilo> Everytime I start Gnus it asks me how to logon at the local
> Tassilo> IMAP server, but instead I want that it uses the username and
> Tassilo> password that are in my ~/.authinfo.
>
> Here is my ~/.authinfo:
>
> machine localhost login gour password xxxxxxxx

Hm, reading your config below I would thing that localhost-IMAP would be
the correct machine name.  Else, how would gnus figure out how to login
on i.e. a local newsserver that uses a different user/password.

> and snippet from .gnus:
>
> (setq mail-sources nil)
> (setq gnus-select-method '(nntp  "news.gmane.org")
>       gnus-secondary-select-methods
>         '((nnimap "localhost-IMAP" (nnimap-address "localhost")) 
>           (nntp "news.iskon.hr")))

No big difference to my config.  I only set the stream/authenticator to
use no encryption, because the tls connection broke down several times.
But even if I use exactly your config (with my name for the method) it
won't logon automatically.  Well, I'll try to edebug it as Reiner
suggested.

> That's all and it works with dovecot server.

Yeah, dovecot here, too.  I never tried running a local IMAP server
because I thought it would be quite complex, but in fact it was easy,
basically: emerge dovecot; edit a few lines in the well commented
dovecot.conf, start the server.

Another question about dovecot: When I used nnmaildir I indexed the
mails with mairix and could do very fast searches with the nnmairix
backend.  Currently I use nnir's imap backend to search on the local
imap server, but that takes ages for huge groups.  Is there a way to
teach dovecot to use a mailindexing tool to speed that up?

Bye,
Tassilo
-- 
If you were somehow able to land a punch on Chuck Norris your entire arm
would shatter upon  impact. This is only in theory,  since, come on, who
in their right mind would try this?

Re: Automatically authenticating at local imap server

[David]

Tassilo Horn <tassilo@member.fsf.org> writes:
> Another question about dovecot: When I used nnmaildir I indexed the
> mails with mairix and could do very fast searches with the nnmairix
> backend.  Currently I use nnir's imap backend to search on the local
> imap server, but that takes ages for huge groups.  Is there a way to
> teach dovecot to use a mailindexing tool to speed that up?

I use the same setup here and nnmairix works nicely with nnimap. If you
feel uncomfortable with nnmairix creating/deleting groups on your local
IMAP server, you can also create a nnmaildir secondary select method
exclusively for nnmairix.

-David

Re: Automatically authenticating at local imap server

[Tassilo Horn]

David <de_bb@arcor.de> writes:

Hi David,

>> Another question about dovecot: When I used nnmaildir I indexed the
>> mails with mairix and could do very fast searches with the nnmairix
>> backend.  Currently I use nnir's imap backend to search on the local
>> imap server, but that takes ages for huge groups.  Is there a way to
>> teach dovecot to use a mailindexing tool to speed that up?
>
> I use the same setup here and nnmairix works nicely with nnimap. If
> you feel uncomfortable with nnmairix creating/deleting groups on your
> local IMAP server, you can also create a nnmaildir secondary select
> method exclusively for nnmairix.

Ah, right.  Now I let mairix index the maildirs in /var/mail/heimdall/.
Those are the maildirs dovecot serves.  The search results go into
groups of a separate nnml backend.  This works very nice. :-)

But one thing is left: Is there a way to jump from a message in the
search result group to the original nnimap group?  I often do a search
to find a message I want to reply to and the reply has to be done from
the original group so that posting styles and group parameters are
considered.

(If there's no builtin way, I'm happy with a dirty hack or a suggestion
for a dirty hack, too.)

Bye,
Tassilo

Re: Automatically authenticating at local imap server

[David]

Tassilo Horn <tassilo@member.fsf.org> writes:
> But one thing is left: Is there a way to jump from a message in the
> search result group to the original nnimap group?  I often do a search
> to find a message I want to reply to and the reply has to be done from
> the original group so that posting styles and group parameters are
> considered.

That's on the TODO list - I always wanted a function that jumps to the
original message in the original group, but it's not trivial to do. My
idea was to call mairix with "m:<MID>", where MID is the message-id of
the article. Using the "-r" option, we get the full path of the mail
file and it should be possible to uniquely identify the group from the
path (the problem here is that the user might index several different
mail back ends with one mairix installation). Jumping to the original
message in this group is another problem since we only know the
message-id but not the article number. nnmaildir and nnml support
fetching articles by message-id, but AFAIK nnimap does not. Maybe it is
somehow possible to apply the correct posting style even when replying
from the nnmairix group, then we wouldn't have to get the original
article in the first place.

-David

Re: Automatically authenticating at local imap server

[Tassilo Horn]

David <de_bb@arcor.de> writes:

Hi David,

> That's on the TODO list -

Good to hear.

> I always wanted a function that jumps to the original message in the
> original group, but it's not trivial to do. My idea was to call mairix
> with "m:<MID>", where MID is the message-id of the article. Using the
> "-r" option, we get the full path of the mail file and it should be
> possible to uniquely identify the group from the path

Sounds promising.

> (the problem here is that the user might index several different mail
> back ends with one mairix installation).

Well, those could split their indexing stuff in a per-backend basis
using several mairixrcs and databases.  Then they probably need some
wrappers around the nnmairix interface functions so that they use the
correct mairixrc/database for the current backend.

> Jumping to the original message in this group is another problem since
> we only know the message-id but not the article number. nnmaildir and
> nnml support fetching articles by message-id, but AFAIK nnimap does
> not.

It does, but only on a per-group basis.  But because we already know the
group from the path mairix gives us, we can enter the group and use

,----[ C-h f gnus-summary-refer-article RET ]
| gnus-summary-refer-article is an interactive compiled Lisp function in `gnus-sum.el'.
| (gnus-summary-refer-article message-id)
| 
| Fetch an article specified by message-id.
`----

,----[ (info "(gnus)Finding the Parent") ]
|    Most of the mail back ends support fetching by `Message-ID', but do
| not do a particularly excellent job at it.  That is, `nnmbox',
| `nnbabyl', `nnmaildir', `nnml', are able to locate articles from any
| groups, while `nnfolder', and `nnimap' are only able to locate articles
| that have been posted to the current group.  (Anything else would be
| too time consuming.)  `nnmh' does not support this at all.
`----

> Maybe it is somehow possible to apply the correct posting style even
> when replying from the nnmairix group, then we wouldn't have to get
> the original article in the first place.

Maybe.  But how about group parameters?  I use a lot gcc-self and stuff,
so jumping to the original group seems to be the better approach.  And
of course there's the case where the user himself doesn't know the
original group from memory.

Bye,
Tassilo

Re: Automatically authenticating at local imap server

[David]

Tassilo Horn <tassilo@member.fsf.org> writes:
>> (the problem here is that the user might index several different mail
>> back ends with one mairix installation).
>
> Well, those could split their indexing stuff in a per-backend basis
> using several mairixrcs and databases.  

They could, but they shouldn't have to. ;-) It should also be possible
to identify the backend from the path through the server variables, at
least for nnml and nnmaildir (and therefore for nnimap as the remaining
choice).

> Then they probably need some wrappers around the nnmairix interface
> functions so that they use the correct mairixrc/database for the
> current backend.

Actually, nnmairix does that already. If it cannot be determined which
mairix installation is "responsible" for the current backend, the user
is asked and this information is saved in the group parameters.

>> Jumping to the original message in this group is another problem since
>> we only know the message-id but not the article number. nnmaildir and
>> nnml support fetching articles by message-id, but AFAIK nnimap does
>> not.
>
> It does, but only on a per-group basis.  But because we already know the
> group from the path mairix gives us, we can enter the group and use
>
> ,----[ C-h f gnus-summary-refer-article RET ]
> | gnus-summary-refer-article is an interactive compiled Lisp function in `gnus-sum.el'.
> | (gnus-summary-refer-article message-id)
> | 
> | Fetch an article specified by message-id.
> `----

Ah, OK. I only tried nnimap-retrieve-headers with a message-id and it
didn't work.

> But how about group parameters?  I use a lot gcc-self and stuff, so
> jumping to the original group seems to be the better approach. 

Yes, I haven't thought of that.

-David

Re: Automatically authenticating at local imap server

[Tassilo Horn]

David <de_bb@arcor.de> writes:

Hi David,

>> ,----[ C-h f gnus-summary-refer-article RET ]
>> | gnus-summary-refer-article is an interactive compiled Lisp function in `gnus-sum.el'.
>> | (gnus-summary-refer-article message-id)
>> | 
>> | Fetch an article specified by message-id.
>> `----
>
> Ah, OK. I only tried nnimap-retrieve-headers with a message-id and it
> didn't work.

BTW, I have tested this with my rather large (10000+ messages)
emacs-devel group, and it's quite fast.  I enter the summary buffer with
`C-u 0 RET' so that no articles are displayed and then do `M-x
gnus-summary-refer-article RET <message-id>'.  Even with m-ids of
ancient articles I don't get a noticable delay.  Maybe dovecot does some
indexing to make that possible.  At least the feature list says:

  Dovecot's indexes are self-optimizing. They contain exactly what the
  user's client commonly needs, no more and no less.

Seems the message-id is included there.

Bye,
Tassilo
-- 
Chuck  Norris  doesn't  daydream.  He's  too busy  giving  other  people
nightmares.

Re: Automatically authenticating at local imap server

[Ted Zlatanov]

On Mon, 04 Feb 2008 23:22:38 +0100 David <de_bb@arcor.de> wrote: 

D> Tassilo Horn <tassilo@member.fsf.org> writes:
>> But one thing is left: Is there a way to jump from a message in the
>> search result group to the original nnimap group?  I often do a search
>> to find a message I want to reply to and the reply has to be done from
>> the original group so that posting styles and group parameters are
>> considered.

D> That's on the TODO list - I always wanted a function that jumps to the
D> original message in the original group, but it's not trivial to do. My
D> idea was to call mairix with "m:<MID>", where MID is the message-id of
D> the article. Using the "-r" option, we get the full path of the mail
D> file and it should be possible to uniquely identify the group from the
D> path (the problem here is that the user might index several different
D> mail back ends with one mairix installation). Jumping to the original
D> message in this group is another problem since we only know the
D> message-id but not the article number. nnmaildir and nnml support
D> fetching articles by message-id, but AFAIK nnimap does not. Maybe it is
D> somehow possible to apply the correct posting style even when replying
D> from the nnmairix group, then we wouldn't have to get the original
D> article in the first place.

You could use the Gnus registry if it's loaded.  It will tell you the
last place a message ID was seen (it learns this by looking at the
visible messages every time you enter a group, and by hooking into
spool/move/copy/delete on each backend).  It may not know the location
for various reasons, e.g. the user limits the size of the registry or
the message hasn't been seen yet, but when the location is available
it's a very quick lookup in a hashtable, probably much faster than
calling mairix to do a search.

The registry doesn't currently record the article number, but it could.
Currently a group name is always a string and anything not a string is
extra (non-location) data, so this is not a trivial change.  Since
article numbers are stable in some backends and not in others, this may
be quite a bit of work to do properly.

Ted

Re: Automatically authenticating at local imap server

[David]

Ted Zlatanov <tzz@lifelogs.com> writes:
> D> Jumping to the original message in this group is another problem
> D> since we only know the message-id but not the article
> D> number. 
>
> You could use the Gnus registry if it's loaded.  It will tell you the
> last place a message ID was seen (it learns this by looking at the
> visible messages every time you enter a group, and by hooking into
> spool/move/copy/delete on each backend).  

Yes, I guess the best way would be to first check the registry for the
group and do the additional mairix search only if the registry is not
loaded or does not know the location of the message. I don't want to
rely solely on the registry though, because of the limitations you
describe:

> It may not know the location for various reasons, e.g. the user limits
> the size of the registry or the message hasn't been seen yet, 

I guess the latter would be a problem for users with big archive groups
which they rarely open.

> The registry doesn't currently record the article number, but it could.

The article number won't be necessary as Tassilo already mentioned. The
lookup through gnus-read-header works just fine.

-David

Re: Automatically authenticating at local imap server

[Tassilo Horn]

David <de_bb@arcor.de> writes:

Hi David, hi Ted,

>> You could use the Gnus registry if it's loaded.  It will tell you the
>> last place a message ID was seen (it learns this by looking at the
>> visible messages every time you enter a group, and by hooking into
>> spool/move/copy/delete on each backend).
>
> Yes, I guess the best way would be to first check the registry for the
> group and do the additional mairix search only if the registry is not
> loaded or does not know the location of the message. I don't want to
> rely solely on the registry though, because of the limitations you
> describe:

Here's a works-for-me draft:

--8<---------------cut here---------------start------------->8---
(setq gnus-registry-max-entries 10000
      gnus-registry-use-long-group-names t)

(gnus-registry-initialize)

;;;; Select an article by message-id with the registry

(defun th-gnus-registry-select-article (message-id)
  (interactive "sMessage-ID: ")
  (let ((group-buffer (get-buffer gnus-group-buffer))
        (group (gnus-registry-fetch-group message-id)))
    (pop-to-buffer group-buffer)
    (gnus-group-list-all-groups)
    (gnus-group-goto-group group t)
    (gnus-group-select-group 1)
    (gnus-summary-refer-article message-id)))

(defun th-gnus-select-article-in-original-group (header)
  (interactive (gnus-interactive "H"))
  (th-gnus-registry-select-article
   (mail-header-message-id header)))
--8<---------------cut here---------------end--------------->8---

I've bound th-gnus-select-article-in-original-group to "M-^" in nnmairix
groups to get fast access to it.

One annoying thing is that it seems I must use (gnus-group-select-group
1), if I provide 0 or nil, the group won't be selected.  So you'll have
another message in the group after you press "M-^" in the nnmairix
group.

Improvements welcome.

Bye,
Tassilo

Re: Automatically authenticating at local imap server

[David]

Tassilo Horn <tassilo@member.fsf.org> writes:
> One annoying thing is that it seems I must use (gnus-group-select-group
> 1), if I provide 0 or nil, the group won't be selected.  So you'll have
> another message in the group after you press "M-^" in the nnmairix
> group.

Yes, but you can limit the summary buffer to the message containing the
message-id. I'd suggest the following:

(defun th-gnus-registry-select-article (message-id)
  (interactive "sMessage-ID: ")
  (let ((group-buffer (get-buffer gnus-group-buffer))
        (group (gnus-registry-fetch-group message-id)))
    (pop-to-buffer group-buffer)
    (gnus-group-jump-to-group group)
    (gnus-summary-read-group group 1 t nil nil nil nil)	
    (gnus-summary-refer-article message-id)
    (gnus-summary-limit-to-headers (format "message-id: %s" message-id))
    (gnus-summary-select-article)))

I'm currently working on the code that finds the original group based on
the message file path. As soon as this is ready I'll post an update to
nnmairix also containing the registry code.

Thanks for your input,
David

new version of nnmairix.el (was: Automatically authenticating at local imap server)

[David]

David <de_bb@arcor.de> writes:
> I'm currently working on the code that finds the original group based on
> the message file path. As soon as this is ready I'll post an update to
> nnmairix also containing the registry code.

The new version of nnmairix.el is released:

http://www.emacswiki.org/cgi-bin/emacs/nnmairix.el

It now contains a function nnmairix-goto-original-article which, given a
found message in a nnmairix group, tries to determine the original group
this message came from. It will then display the message in this
original group. The function will use the registry if available, but can
also parse the file path as a fallback method. 

Please note that the key bindings for the summary mode have changed
(prefix is now '$' instead of 'S') since the old bindings were already
taken. You can of course edit these bindings to your likings in
nnmairix-summary-mode-hook. 

For further documentation see

http://www.emacswiki.org/cgi-bin/emacs/GnusMairix

-David

Re: Automatically authenticating at local imap server

[Ted Zlatanov]

On Tue, 05 Feb 2008 22:58:49 +0100 David <de_bb@arcor.de> wrote: 

D> Yes, I guess the best way would be to first check the registry for the
D> group and do the additional mairix search only if the registry is not
D> loaded or does not know the location of the message. I don't want to
D> rely solely on the registry though, because of the limitations you
D> describe: [...]

Cool.  Also note the group could be wrong, e.g. someone modified a
Maildir spool externally and the registry doesn't know.  So it's a bit
like asking a random person for directions: very nice when it works but
don't rely on it :)

Ted

Re: Automatically authenticating at local imap server

[David]

Ted Zlatanov <tzz@lifelogs.com> writes:
> D> Yes, I guess the best way would be to first check the registry for the
> D> group and do the additional mairix search only if the registry is not
> D> loaded or does not know the location of the message. I don't want to
> D> rely solely on the registry though, because of the limitations you
> D> describe: [...]
>
> Cool.  Also note the group could be wrong, e.g. someone modified a
> Maildir spool externally and the registry doesn't know.  So it's a bit
> like asking a random person for directions: very nice when it works but
> don't rely on it :)

When the user notices that the registry is wrong he will be able revert
to the file path method by calling the function with a prefix.

I also noticed that when the same message is in two different groups the
registry will only return the group where it first saw it, right? I
guess it would be quite difficult to extend the registry in a way so
that it can return all groups where a message exists?

-David

Re: Automatically authenticating at local imap server

[Ted Zlatanov]

On Wed, 06 Feb 2008 21:07:31 +0100 David <de_bb@arcor.de> wrote: 

D> I also noticed that when the same message is in two different groups the
D> registry will only return the group where it first saw it, right? I
D> guess it would be quite difficult to extend the registry in a way so
D> that it can return all groups where a message exists?

Fortunately, gnus-registry-fetch-groups already does it :)

Ted

Registry not registering duplicate articles (was: Automatically authenticating at local imap server)

[David]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Wed, 06 Feb 2008 21:07:31 +0100 David <de_bb@arcor.de> wrote: 
>
> D> I also noticed that when the same message is in two different groups the
> D> registry will only return the group where it first saw it, right? I
> D> guess it would be quite difficult to extend the registry in a way so
> D> that it can return all groups where a message exists?
>
> Fortunately, gnus-registry-fetch-groups already does it :)

Oh. I guess I could have found that one. :-)

I was confused since I had some problems with the registry not
registering articles from my sent mail folders. I noticed this is due to

	(unless (gnus-registry-fetch-group id)

in gnus-registry-register-message-ids, so the message is not registered
if it was already seen in any other group. Is there some deeper reason
for this? Maybe this could be changed to something like (untested):

(unless (member gnus-newsgroup-name (gnus-registry-fetch-group id))

Regards,
David

Re: Registry not registering duplicate articles

[Ted Zlatanov]

On Sat, 23 Feb 2008 18:55:44 +0100 David <de_bb@arcor.de> wrote: 

D> I was confused since I had some problems with the registry not
D> registering articles from my sent mail folders. I noticed this is due to

D> 	(unless (gnus-registry-fetch-group id)

D> in gnus-registry-register-message-ids, so the message is not registered
D> if it was already seen in any other group. Is there some deeper reason
D> for this? Maybe this could be changed to something like (untested):

D> (unless (member gnus-newsgroup-name (gnus-registry-fetch-group id))

Yes, I think that's a bug.  I added your bug fix, confirm it's OK if you
can test it.  Also I was not using the id variable in a tight loop,
making an extra function call instead, so I fixed that too.

Ted

Re: Registry not registering duplicate articles

[Ted Zlatanov]

On Tue, 26 Feb 2008 10:54:30 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sat, 23 Feb 2008 18:55:44 +0100 David <de_bb@arcor.de> wrote: 
D> I was confused since I had some problems with the registry not
D> registering articles from my sent mail folders. I noticed this is due to

D> (unless (gnus-registry-fetch-group id)

D> in gnus-registry-register-message-ids, so the message is not registered
D> if it was already seen in any other group. Is there some deeper reason
D> for this? Maybe this could be changed to something like (untested):

D> (unless (member gnus-newsgroup-name (gnus-registry-fetch-group id))

TZ> Yes, I think that's a bug.  I added your bug fix, confirm it's OK if you
TZ> can test it.  Also I was not using the id variable in a tight loop,
TZ> making an extra function call instead, so I fixed that too.

I remembered (after comitting to CVS, so I had to check in another fix)
that gnus-registry-fetch-group returns the first group found as a
string.  You and I want gnus-registry-fetch-groups which returns a
list.  Sorry for any confusion.

Ted