nnimap problem with current cvs

nnimap problem with current cvs

[Josh Huber]

I'm having this fairly odd problem with IMAP.  I'm connecting to a
Cyrus IMAP server (v2.1.x), which is working great.

After some time (havne't figured out how much yet...), every time I
check for new mail on the server ('g' in *Group*), I see the messages
about negotiating a new STARTTLS session.  Sure enough, looking in the
logs, I see this from the imap server:

Sep 17 17:32:46 hostname cyrus/imapd[14541]: starttls: TLSv1 with
cipher AES256-SHA (256/256 bits new) no authentication
Sep 17 17:32:46 hostname cyrus/imapd[14541]: login:
hostname.domain.net[192.168.0.10] huber CRAM-MD5+TLS User logged in

Another odd thing about this is, when I look in the server buffer, I
see TWO entries for my imap server.

Restarting Gnus (as I just did), brings back the old, correct,
behavior.  Hitting 'g' in the Group buffer does not open a new
connection, responds very quickly, and there is only one entry for my
imap server in the server buffer.

Here's what I've got for select methods:

(setq gnus-secondary-select-methods
      '(
	;; private domain.net IMAP server	
	(nnimap "hostname"
		(nnimap-server-address "hostname.domain.net")
		(nnimap-stream starttls))
	;; public IMAP server @ CMU with a bunch of archived lists
	(nnimap "cmu"
		(nnimap-authenticator anonymous)
		(nnimap-list-pattern "archive.*")
		(nnimap-stream network)
		(nnimap-server-address "cyrus.andrew.cmu.edu"))))

Any ideas?  Anyone else seen this behavior before?

-- 
Josh Huber

Re: nnimap problem with current cvs

[Simon Josefsson]

Josh Huber <huber@alum.wpi.edu> writes:

> I'm having this fairly odd problem with IMAP.  I'm connecting to a
> Cyrus IMAP server (v2.1.x), which is working great.
>
> After some time (havne't figured out how much yet...), every time I
> check for new mail on the server ('g' in *Group*), I see the messages
> about negotiating a new STARTTLS session.  Sure enough, looking in the
> logs, I see this from the imap server:
>
> Sep 17 17:32:46 hostname cyrus/imapd[14541]: starttls: TLSv1 with
> cipher AES256-SHA (256/256 bits new) no authentication
> Sep 17 17:32:46 hostname cyrus/imapd[14541]: login:
> hostname.domain.net[192.168.0.10] huber CRAM-MD5+TLS User logged in
>
> Another odd thing about this is, when I look in the server buffer, I
> see TWO entries for my imap server.
>
> Restarting Gnus (as I just did), brings back the old, correct,
> behavior.  Hitting 'g' in the Group buffer does not open a new
> connection, responds very quickly, and there is only one entry for my
> imap server in the server buffer.
>
> Here's what I've got for select methods:
>
> (setq gnus-secondary-select-methods
>       '(
> 	;; private domain.net IMAP server	
> 	(nnimap "hostname"
> 		(nnimap-server-address "hostname.domain.net")
> 		(nnimap-stream starttls))
> 	;; public IMAP server @ CMU with a bunch of archived lists
> 	(nnimap "cmu"
> 		(nnimap-authenticator anonymous)
> 		(nnimap-list-pattern "archive.*")
> 		(nnimap-stream network)
> 		(nnimap-server-address "cyrus.andrew.cmu.edu"))))
>
> Any ideas?  Anyone else seen this behavior before?

Press G e on groups on the starttls server and make sure they either
is "nnimap:hostname" or contain the entire select method _exactly_ as
typed in .gnus.  Perhaps you have some group that uses a old version
of the select method, and since Gnus notice that they are different,
it opens a new server for it.  If you know how to reproduce getting
the non-referral (i.e., non-"nnimap:hostname" version) select method
in the group buffer, please tell.  Gnus should, IMHO, use the
"nnimap:hostname" syntax, so you can modify the g-s-s-m without
re-subscribing to all groups on the old server.  I'm not sure why you
don't get this problem on direct startup though.

Re: nnimap problem with current cvs

[Josh Huber]

Simon Josefsson <jas@extundo.com> writes:

> Press G e on groups on the starttls server and make sure they either
> is "nnimap:hostname" or contain the entire select method _exactly_
> as typed in .gnus.  Perhaps you have some group that uses a old
> version of the select method, and since Gnus notice that they are
> different, it opens a new server for it.  If you know how to
> reproduce getting the non-referral (i.e., non-"nnimap:hostname"
> version) select method in the group buffer, please tell.  Gnus
> should, IMHO, use the "nnimap:hostname" syntax, so you can modify
> the g-s-s-m without re-subscribing to all groups on the old server.
> I'm not sure why you don't get this problem on direct startup
> though.

Well, when it started happening every time I posted a message via
nntp, I really started to get suspicious.  Sending mail didn't trigger
the issue...looking at my Gcc setup, I do sort sent mail and new into
different imap mailboxes...

I fixed this by subscribing to the sent-news mailbox (for some reason,
I had forgotton to do this).  This seems to have fixed the problem,
even though I see messages from Gnus indicating it's re-doing a
STARTTLS session while in the middle of posting to nntp.

We'll see what the logs say after this post...

-- 
Josh Huber

Re: nnimap problem with current cvs

[Josh Huber]

Josh Huber <huber@alum.wpi.edu> writes:

> We'll see what the logs say after this post...

No additional server showed up in the server buffer, and an additional
login was not made to the backend imap server.

As a side note:  all the previous nntp messages got saved into the
sent-news folder, even though this odd behavior was going on.

-- 
Josh Huber

Re: nnimap problem with current cvs

[Josh Huber]

BTW: Sorry to be spamming the list with this stuff :)

Josh Huber <huber@alum.wpi.edu> writes:

> No additional server showed up in the server buffer, and an
> additional login was not made to the backend imap server.

I AM however seeing some additional strange behavior (nothing too bad
though):

1. Open a group on my imap server
2. Close the group
3. Open a group on a different imap or nntp server
4. Close the group
5. Press 'g' in the Group buffer.
6. Note in the imapd server logs that an additional new connection is
   made to the mail server.

It seems like the pattern of "open group on server A, open group on
server B, open group on server A" triggers a new imap connection to be
negotiated.

At least in this case, I don't see the odd duplicate server in the
server buffer, and subsequent gnus-group-get-new-news does not trigger
another connection to be made.

-- 
Josh Huber

Re: nnimap problem with current cvs

[Simon Josefsson]

Josh Huber <huber@alum.wpi.edu> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Press G e on groups on the starttls server and make sure they either
>> is "nnimap:hostname" or contain the entire select method _exactly_
>> as typed in .gnus.  Perhaps you have some group that uses a old
>> version of the select method, and since Gnus notice that they are
>> different, it opens a new server for it.  If you know how to
>> reproduce getting the non-referral (i.e., non-"nnimap:hostname"
>> version) select method in the group buffer, please tell.  Gnus
>> should, IMHO, use the "nnimap:hostname" syntax, so you can modify
>> the g-s-s-m without re-subscribing to all groups on the old server.
>> I'm not sure why you don't get this problem on direct startup
>> though.
>
> Well, when it started happening every time I posted a message via
> nntp, I really started to get suspicious.  Sending mail didn't trigger
> the issue...looking at my Gcc setup, I do sort sent mail and new into
> different imap mailboxes...
>
> I fixed this by subscribing to the sent-news mailbox (for some reason,
> I had forgotton to do this).  This seems to have fixed the problem,
> even though I see messages from Gnus indicating it's re-doing a
> STARTTLS session while in the middle of posting to nntp.

What is the value of gnus-message-archive-group and
gnus-message-archive-method?  Sounds like Gnus doesn't understand that
the archive method is the same as your normal starttls nnimap server.

Re: nnimap problem with current cvs

[Josh Huber]

Simon Josefsson <jas@extundo.com> writes:

> What is the value of gnus-message-archive-group and
> gnus-message-archive-method?  Sounds like Gnus doesn't understand
> that the archive method is the same as your normal starttls nnimap
> server.

Here's my config, including the archiving information:

(setq gnus-secondary-select-methods
      '(
	;; private domain.net IMAP server	
	(nnimap "hostname"
		(nnimap-server-address "hostname.domain.net")
		(nnimap-stream starttls))
	;; public IMAP server @ CMU with a bunch of archived lists
	(nnimap "cmu"
		(nnimap-authenticator anonymous)
		(nnimap-list-pattern "archive.*")
		(nnimap-stream network)
		(nnimap-server-address "cyrus.andrew.cmu.edu"))))

;; sent-mail archiving
(setq gnus-message-archive-method
      '(nnimap "hostname"))

(setq gnus-message-archive-group
      '((if (message-news-p)
	    "sent-news"
	  "sent-mail")))


In all cases, the Gcc header looked correct.

-- 
Josh Huber

Re: nnimap problem with current cvs

[Simon Josefsson]

Josh Huber <huber@alum.wpi.edu> writes:

> (setq gnus-secondary-select-methods
>       '(
> 	;; private domain.net IMAP server	
> 	(nnimap "hostname"
> 		(nnimap-server-address "hostname.domain.net")
> 		(nnimap-stream starttls))
> 	;; public IMAP server @ CMU with a bunch of archived lists
> 	(nnimap "cmu"
> 		(nnimap-authenticator anonymous)
> 		(nnimap-list-pattern "archive.*")
> 		(nnimap-stream network)
> 		(nnimap-server-address "cyrus.andrew.cmu.edu"))))
>
> ;; sent-mail archiving
> (setq gnus-message-archive-method
>       '(nnimap "hostname"))

Aw, this looks wrong.  Use "nnimap:hostname" or (car
gnus-secondary-select-methods) for gnus-message-archive-method.  The
methods must match or else Gnus will open another connection.  I hope
this was it.  You may want to check that your sent-mail group contains
the proper server definition in G e before restarting though.

Re: nnimap problem with current cvs

[Josh Huber]

Simon Josefsson <jas@extundo.com> writes:

> Aw, this looks wrong.  Use "nnimap:hostname" or (car
> gnus-secondary-select-methods) for gnus-message-archive-method.  The
> methods must match or else Gnus will open another connection.  I
> hope this was it.  You may want to check that your sent-mail group
> contains the proper server definition in G e before restarting
> though.

Doh.  All this time, and my archive settings have been wrong. *sigh*

I just put the imap server def in a variable and used that in both
locations.  Thanks for the help... (that other strange thing I posted
about before still happens though -- switch back and forth, and a new
connection is made to the imap server.)

-- 
Josh Huber