Problems with reading mail via imap

Problems with reading mail via imap

[Eythan Weg]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]



I am unable to connect to an imap dovecot server
with a recent cvs, while I have no problems with
one a few months old.  I use gnutls.  What changes
could account for this difference?

Here is a snippet of the debug buffer.


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

* OK dovecot ready."
| | | | 5 -> imap-find-next-line: 
| | | | 5 <- imap-find-next-line: nil
| | | 4 <- imap-arrival-filter: nil
| | | 4 -> imap-arrival-filter: proc=#<process imap> string=" CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED NAMESPACE AUTH=PLAIN
1 OK Capability completed.
"
| | | | 5 -> imap-find-next-line: 
| | | | 5 <- imap-find-next-line: 137
| | | | 5 -> imap-parse-response: 
| | | | 5 <- imap-parse-response: (IMAP4REV1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED NAMESPACE AUTH=PLAIN)
| | | | 5 -> imap-find-next-line: 
| | | | 5 <- imap-find-next-line: 29
| | | | 5 -> imap-parse-response: 
| | | | | 6 -> imap-parse-resp-text: 
| | | | | | 7 -> imap-parse-resp-text-code: 
| | | | | | 7 <- imap-parse-resp-text-code: nil
| | | | | 6 <- imap-parse-resp-text: nil
| | | | 5 <- imap-parse-response: nil
| | | | 5 -> imap-find-next-line: 
| | | | 5 <- imap-find-next-line: nil
| | | 4 <- imap-arrival-filter: nil
| | 3 <- imap-wait-for-tag: OK
| 2 <- imap-send-command-wait: OK
1 <- imap-capability: nil
======================================================================
1 -> imap-capability: identifier=IMAP4rev1 buffer=" *nnimap* dodgson"
1 <- imap-capability: (IMAP4REV1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED NAMESPACE AUTH=PLAIN)
======================================================================
1 -> imap-arrival-filter: proc=#<process imap> string="*"
| 2 -> imap-find-next-line: 
| 2 <- imap-find-next-line: nil
1 <- imap-arrival-filter: nil
======================================================================
1 -> imap-arrival-filter: proc=#<process imap> string=" BYE Disconnected for inactivity.
*** Fatal error: A TLS packet with unexpected length was received.
*** Server has terminated the connection abnormally.
"
| 2 -> imap-find-next-line: 
| 2 <- imap-find-next-line: 37
| 2 -> imap-parse-response: 
| | 3 -> imap-parse-resp-text: 
| | | 4 -> imap-parse-resp-text-code: 
| | | 4 <- imap-parse-resp-text-code: nil
| | 3 <- imap-parse-resp-text: nil
| 2 <- imap-parse-response: nil
| 2 -> imap-find-next-line: 
| 2 <- imap-find-next-line: nil
1 <- imap-arrival-filter: nil
======================================================================
1 -> imap-sentinel: process=#<process imap> string="finished
"
1 <- imap-sentinel: nil

[-- Attachment #3: Type: text/plain, Size: 20 bytes --]


Thank you, Eythan 

Re: Problems with reading mail via imap

[Simon Josefsson]

Eythan Weg <weg@indiscrete.org> writes:

> I am unable to connect to an imap dovecot server
> with a recent cvs, while I have no problems with
> one a few months old.  I use gnutls.  What changes
> could account for this difference?
...
> 1 -> imap-arrival-filter: proc=#<process imap> string=" BYE Disconnected for inactivity.
> *** Fatal error: A TLS packet with unexpected length was received.
> *** Server has terminated the connection abnormally.
> "

It seems gnutls-cli dies.  Do you have any firewall or anything that
might modify packets?  I think you should debug this as a gnutls problem.

Re: Problems with reading mail via imap

[Eythan Weg]

Simon Josefsson <jas@extundo.com> writes:

> Eythan Weg <weg@indiscrete.org> writes:
>
>> I am unable to connect to an imap dovecot
>> server with a recent cvs, while I have no
>> problems with one a few months old.  I use
>> gnutls.  What changes could account for this
>> difference?
> ...
>> 1 -> imap-arrival-filter: proc=#<process imap>
>> string=" BYE Disconnected for inactivity.  ***
>> Fatal error: A TLS packet with unexpected
>> length was received.  *** Server has terminated
>> the connection abnormally.  "
>
> It seems gnutls-cli dies.  Do you have any
> firewall or anything that might modify packets?
> I think you should debug this as a gnutls
> problem.

How to reconcile that the same binary (gnutls-cli)
and the same firewall work together nicely with
the slightly older gnus, but not with a recent
one.

Eythan

Re: Problems with reading mail via imap

[Simon Josefsson]

Eythan Weg <weg@indiscrete.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Eythan Weg <weg@indiscrete.org> writes:
>>
>>> I am unable to connect to an imap dovecot
>>> server with a recent cvs, while I have no
>>> problems with one a few months old.  I use
>>> gnutls.  What changes could account for this
>>> difference?
>> ...
>>> 1 -> imap-arrival-filter: proc=#<process imap>
>>> string=" BYE Disconnected for inactivity.  ***
>>> Fatal error: A TLS packet with unexpected
>>> length was received.  *** Server has terminated
>>> the connection abnormally.  "
>>
>> It seems gnutls-cli dies.  Do you have any
>> firewall or anything that might modify packets?
>> I think you should debug this as a gnutls
>> problem.
>
> How to reconcile that the same binary (gnutls-cli)
> and the same firewall work together nicely with
> the slightly older gnus, but not with a recent
> one.

Gnus might do things differently now, that trigger the GnuTLS bug.
Still, if the above error occurs, the problem lies in gnutls-cli, or
some other component (e.g.,firewalls) that modify the network traffic.

Re: Problems with reading mail via imap

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> Eythan Weg <weg@indiscrete.org> writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>> Eythan Weg <weg@indiscrete.org> writes:
>>>
>>>> I am unable to connect to an imap dovecot
>>>> server with a recent cvs, while I have no
>>>> problems with one a few months old.  I use
>>>> gnutls.  What changes could account for this
>>>> difference?
>>> ...
>>>> 1 -> imap-arrival-filter: proc=#<process imap>
>>>> string=" BYE Disconnected for inactivity.  ***
>>>> Fatal error: A TLS packet with unexpected
>>>> length was received.  *** Server has terminated
>>>> the connection abnormally.  "
>>>
>>> It seems gnutls-cli dies.  Do you have any
>>> firewall or anything that might modify packets?
>>> I think you should debug this as a gnutls
>>> problem.
>>
>> How to reconcile that the same binary (gnutls-cli)
>> and the same firewall work together nicely with
>> the slightly older gnus, but not with a recent
>> one.
>
> Gnus might do things differently now, that trigger the GnuTLS bug.
> Still, if the above error occurs, the problem lies in gnutls-cli, or
> some other component (e.g.,firewalls) that modify the network traffic.

However...  I just noticed the "BYE" part of the response, which
suggest that maybe imap.el should recognize that the server
disconnected, even if the TLS connection later failed.

Exactly when did you get the above error?  With the new or old Gnus?
After 30 minutes of inactivity, or immediately when starting Gnus?

Re: Problems with reading mail via imap

[Eythan Weg]

Simon Josefsson <jas@extundo.com> writes:


>>> How to reconcile that the same binary (gnutls-cli)
>>> and the same firewall work together nicely with
>>> the slightly older gnus, but not with a recent
>>> one.
>>
>> Gnus might do things differently now, that trigger the GnuTLS bug.
>> Still, if the above error occurs, the problem lies in gnutls-cli, or
>> some other component (e.g.,firewalls) that modify the network traffic.

I think with neither because openssl is able to
work fine with the same firewall as present for older
gnus.  It fails in the same way as gnustls-cli
with the newer ( a week old cvs) gnus.

>
> However...  I just noticed the "BYE" part of the response, which
> suggest that maybe imap.el should recognize that the server
> disconnected, even if the TLS connection later failed.
>
> Exactly when did you get the above error?  With the new or old Gnus?
> After 30 minutes of inactivity, or immediately when starting Gnus?


The  "BYE" part seems to appear after a wait
period of about 20 secs. Note that gnus says earlier it
cannot open the server and asks whether to go
offline.  It never gets to the authentication
part, i.e never asks for user and password.  This
description relates to the newer gnus.
There is also an earlier line in the debug buffer:

5 <- imap-parse-response: "Garbage: Connecting to '192.168.0.4:993'

It does not seem to affect the older gnus.  
Could it be relevant for the newer?

Could you give me a short recipe of how to manually connect
to the imap server.  

Thank you.

Eythan 

Re: Problems with reading mail via imap

[Simon Josefsson]

Eythan Weg <weg@indiscrete.org> writes:

> Could you give me a short recipe of how to manually connect
> to the imap server.  

jas@latte:~$ gnutls-cli --starttls --port 143 imap.example.com
...
- Simple Client Mode:

* OK yxa-iv Cyrus IMAP4 v2.1.16-IPv6-Debian-2.1.16-10 server ready
. starttls
. OK Begin TLS negotiation now
^D  <- press ctrl-D
...
. login username password
...

Re: Problems with reading mail via imap

[Eythan Weg]

Simon Josefsson <jas@extundo.com> writes:

>
> Gnus might do things differently now, that trigger the GnuTLS bug.
> Still, if the above error occurs, the problem lies in gnutls-cli, or
> some other component (e.g.,firewalls) that modify the network traffic.

The recent cvs fails even  without the firewall
present.  No problem with older one.

Eythan 

Re: Problems with reading mail via imap

[Simon Josefsson]

Eythan Weg <weg@indiscrete.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>>
>> Gnus might do things differently now, that trigger the GnuTLS bug.
>> Still, if the above error occurs, the problem lies in gnutls-cli, or
>> some other component (e.g.,firewalls) that modify the network traffic.
>
> The recent cvs fails even  without the firewall
> present.  No problem with older one.

This is weird, it works fine here.  Could you try 'cvs upd -D
2004-09-01', and other dates, until you pin-point when the breakage
was introduced?

Re: Problems with reading mail via imap

[Eythan Weg]

Simon Josefsson <jas@extundo.com> writes:


> This is weird, it works fine here.  Could you try 'cvs upd -D
> 2004-09-01', and other dates, until you pin-point when the breakage
> was introduced?

The October 14 version works but October 15 fails.
The changed files are netrc, nnimap, pop3 and
spam.  I hope this helps.

Thanks, Eythan

Re: Problems with reading mail via imap

[Simon Josefsson]

Eythan Weg <weg@indiscrete.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>
>> This is weird, it works fine here.  Could you try 'cvs upd -D
>> 2004-09-01', and other dates, until you pin-point when the breakage
>> was introduced?
>
> The October 14 version works but October 15 fails.
> The changed files are netrc, nnimap, pop3 and
> spam.  I hope this helps.

If you use today's CVS, but with nnimap.el from October 14, does it
work?  I suspect this patch:

	* nnimap.el (nnimap-open-connection): use
	netrc-machine-user-or-password

Thanks.

Re: Problems with reading mail via imap

[Eythan Weg]

Simon Josefsson <jas@extundo.com> writes:


> If you use today's CVS, but with nnimap.el from October 14, does it
> work?  I suspect this patch:
>
> 	* nnimap.el (nnimap-open-connection): use
> 	netrc-machine-user-or-password
>
> Thanks.

yes

Re: Problems with reading mail via imap

[Simon Josefsson]

Eythan Weg <weg@indiscrete.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>
>> If you use today's CVS, but with nnimap.el from October 14, does it
>> work?  I suspect this patch:
>>
>> 	* nnimap.el (nnimap-open-connection): use
>> 	netrc-machine-user-or-password
>>
>> Thanks.
>
> yes

Do you have anything in ~/.authinfo for the server?  If so, what?
What are your nnimap related configurations, generally?  The patch
installed on that day (see below) modified reading that file.  Ted, do
you have any ideas?

Index: nnimap.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnimap.el,v
retrieving revision 7.10
retrieving revision 7.11
diff -u -p -u -w -r7.10 -r7.11
--- nnimap.el	19 Sep 2004 20:24:26 -0000	7.10
+++ nnimap.el	14 Oct 2004 17:58:21 -0000	7.11
@@ -763,18 +763,22 @@ If EXAMINE is non-nil the group is selec
 	   (port (if nnimap-server-port
 		     (int-to-string nnimap-server-port)
 		   "imap"))
-	   (alist (or (netrc-machine list server port "imap")
-		      (netrc-machine list
+	   (user (netrc-machine-user-or-password 
+		  "login"
+		  list
+		  (list server
 				     (or nnimap-server-address
-					 nnimap-address)
-				     port "imap")
-		      (netrc-machine list server port "imaps")
-		      (netrc-machine list
+			    nnimap-address))
+		  (list port)
+		  (list "imap" "imaps")))
+	   (passwd (netrc-machine-user-or-password 
+		    "password"
+		    list
+		    (list server
 				     (or nnimap-server-address
-					 nnimap-address)
-				     port "imaps")))
-	   (user (netrc-get alist "login"))
-	   (passwd (netrc-get alist "password")))
+			      nnimap-address))
+		    (list port)
+		    (list "imap" "imaps"))))
       (if (imap-authenticate user passwd nnimap-server-buffer)
 	  (prog1
 	      (push (list server nnimap-server-buffer)

Re: Problems with reading mail via imap

[Eythan Weg]

Simon Josefsson <jas@extundo.com> writes:

> Eythan Weg <weg@indiscrete.org> writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>
>>> If you use today's CVS, but with nnimap.el from October 14, does it
>>> work?  I suspect this patch:
>>>
>>> 	* nnimap.el (nnimap-open-connection): use
>>> 	netrc-machine-user-or-password
>>>
>>> Thanks.
>>
>> yes
>
> Do you have anything in ~/.authinfo for the server?  If so, what?
> What are your nnimap related configurations, generally?  The patch
> installed on that day (see below) modified reading that file.  Ted, do
> you have any ideas?

The October 15 fails with or without .authinfo.
The October 14 and today's cvs with your
suggestion do work with and without .authinfo.

I recall reading that port keyword in that file
should be imap but it did not work with newer cvs
gnus.  So currently I set it to 993 as it was with
my older gnus.

Eythan 

Re: Problems with reading mail via imap

[Eythan Weg]

Eythan Weg <weg@indiscrete.org> writes:
>>
>> Do you have anything in ~/.authinfo for the server?  If so, what?
>> What are your nnimap related configurations, generally?  The patch
>> installed on that day (see below) modified reading that file.  Ted, do
>> you have any ideas?
>
....

>
Sorry, I forgot to list the configuration:
(add-to-list 'gnus-secondary-select-methods
      '(nnimap "dodgson"
          (nnimap-address "dodgson.web")
          (nnimap-server-port 993) 
          (nnimap-stream tls)
           (nnimap-authenticator login)
          ))
Eythan

Re: Problems with reading mail via imap

[Simon Josefsson]

Eythan Weg <weg@indiscrete.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Eythan Weg <weg@indiscrete.org> writes:
>>
>>> Simon Josefsson <jas@extundo.com> writes:
>>>
>>>
>>>> If you use today's CVS, but with nnimap.el from October 14, does it
>>>> work?  I suspect this patch:
>>>>
>>>> 	* nnimap.el (nnimap-open-connection): use
>>>> 	netrc-machine-user-or-password
>>>>
>>>> Thanks.
>>>
>>> yes
>>
>> Do you have anything in ~/.authinfo for the server?  If so, what?
>> What are your nnimap related configurations, generally?  The patch
>> installed on that day (see below) modified reading that file.  Ted, do
>> you have any ideas?
>
> The October 15 fails with or without .authinfo.
> The October 14 and today's cvs with your
> suggestion do work with and without .authinfo.
>
> I recall reading that port keyword in that file
> should be imap but it did not work with newer cvs
> gnus.  So currently I set it to 993 as it was with
> my older gnus.

Ah, I suspect that is the cause.  Hm.  Are you in fact talking to the
server on port 993, or is it only something in .authinfo?

If your server support it, it might be better to use STARTTLS on port
143.

I think you should remove the 'port 993', it isn't necessary.  In
fact, the manual try to make this clear.

Further, if you are only talking to the server on one port, you
shouldn't need to use the "port" token at all.  It should only be
needed if you are talking to a server on a non-standard port (143 and
993 both considered being standard ports).

Finally, before you change anything, can you try to use today's CVS
with the patch below applied to nnimap.el?  Then maybe you (and
others) doesn't have to change .authinfo for things to continue to
work, which would be ideal.

`nnimap-authinfo-file'
     A file containing credentials used to log in on servers.  The
     format is (almost) the same as the `ftp' `~/.netrc' file.  See the
     variable `nntp-authinfo-file' for exact syntax; also see *Note
     NNTP::.  An example of an .authinfo line for an IMAP server, is:

          machine students.uio.no login larsi password geheimnis port imap

     Note that it should be `port imap', or `port 143', if you use a
     `nnimap-stream' of `tls' or `ssl', even if the actual port number
     used is port 993 for secured IMAP.  For convenience, Gnus will
     accept `port imaps' as a synonym of `port imap'.

--- nnimap.el	26 Oct 2004 22:21:08 +0200	7.13
+++ nnimap.el	19 Nov 2004 18:37:58 +0100	
@@ -778,7 +778,7 @@
 			(or nnimap-server-address
 			    nnimap-address))
 		  (list port)
-		  (list "imap" "imaps")))
+		  (list "imap" "imaps" "993")))
 	   (passwd (netrc-machine-user-or-password 
 		    "password"
 		    list
@@ -786,7 +786,7 @@
 			  (or nnimap-server-address
 			      nnimap-address))
 		    (list port)
-		    (list "imap" "imaps"))))
+		    (list "imap" "imaps" "993"))))
       (if (imap-authenticate user passwd nnimap-server-buffer)
 	  (prog2
 	      (setq nnimap-server-buffer-alist

Re: Problems with reading mail via imap

[Eythan Weg]

Simon Josefsson <jas@extundo.com> writes:

> Eythan Weg <weg@indiscrete.org> writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>> Eythan Weg <weg@indiscrete.org> writes:
>>>
>>>> Simon Josefsson <jas@extundo.com> writes:
>>>>
>>>>
>>>>> If you use today's CVS, but with nnimap.el from October 14, does it
>>>>> work?  I suspect this patch:
>>>>>
>>>>> 	* nnimap.el (nnimap-open-connection): use
>>>>> 	netrc-machine-user-or-password
>>>>>
>>>>> Thanks.
>>>>
>>>> yes
>>>
>>> Do you have anything in ~/.authinfo for the server?  If so, what?
>>> What are your nnimap related configurations, generally?  The patch
>>> installed on that day (see below) modified reading that file.  Ted, do
>>> you have any ideas?
>>
>> The October 15 fails with or without .authinfo.
>> The October 14 and today's cvs with your
>> suggestion do work with and without .authinfo.
>>
>> I recall reading that port keyword in that file
>> should be imap but it did not work with newer cvs
>> gnus.  So currently I set it to 993 as it was with
>> my older gnus.
>
> Ah, I suspect that is the cause.  Hm.  Are you in fact talking to the
> server on port 993, or is it only something in .authinfo?
>
> If your server support it, it might be better to use STARTTLS on port
> 143.
>
> I think you should remove the 'port 993', it isn't necessary.  In
> fact, the manual try to make this clear.
>
> Further, if you are only talking to the server on one port, you
> shouldn't need to use the "port" token at all.  It should only be
> needed if you are talking to a server on a non-standard port (143 and
> 993 both considered being standard ports).
>
> Finally, before you change anything, can you try to use today's CVS
> with the patch below applied to nnimap.el?  Then maybe you (and
> others) doesn't have to change .authinfo for things to continue to
> work, which would be ideal.
>
> `nnimap-authinfo-file'
>      A file containing credentials used to log in on servers.  The
>      format is (almost) the same as the `ftp' `~/.netrc' file.  See the
>      variable `nntp-authinfo-file' for exact syntax; also see *Note
>      NNTP::.  An example of an .authinfo line for an IMAP server, is:
>
>           machine students.uio.no login larsi password geheimnis port imap
>
>      Note that it should be `port imap', or `port 143', if you use a
>      `nnimap-stream' of `tls' or `ssl', even if the actual port number
>      used is port 993 for secured IMAP.  For convenience, Gnus will
>      accept `port imaps' as a synonym of `port imap'.
>
> --- nnimap.el	26 Oct 2004 22:21:08 +0200	7.13
> +++ nnimap.el	19 Nov 2004 18:37:58 +0100	
> @@ -778,7 +778,7 @@
>  			(or nnimap-server-address
>  			    nnimap-address))
>  		  (list port)
> -		  (list "imap" "imaps")))
> +		  (list "imap" "imaps" "993")))
>  	   (passwd (netrc-machine-user-or-password 
>  		    "password"
>  		    list
> @@ -786,7 +786,7 @@
>  			  (or nnimap-server-address
>  			      nnimap-address))
>  		    (list port)
> -		    (list "imap" "imaps"))))
> +		    (list "imap" "imaps" "993"))))
>        (if (imap-authenticate user passwd nnimap-server-buffer)
>  	  (prog2
>  	      (setq nnimap-server-buffer-alist

It seems to me that the patch and the discussion
preceding it relates to the .authinfo.  However,
today's cvs fails without an existing .authinfo.  

Am I missing something?

Eythan 

Re: Problems with reading mail via imap

[Simon Josefsson]

Eythan Weg <weg@indiscrete.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Eythan Weg <weg@indiscrete.org> writes:
>>
>>> Simon Josefsson <jas@extundo.com> writes:
>>>
>>>> Eythan Weg <weg@indiscrete.org> writes:
>>>>
>>>>> Simon Josefsson <jas@extundo.com> writes:
>>>>>
>>>>>
>>>>>> If you use today's CVS, but with nnimap.el from October 14, does it
>>>>>> work?  I suspect this patch:
>>>>>>
>>>>>> 	* nnimap.el (nnimap-open-connection): use
>>>>>> 	netrc-machine-user-or-password
>>>>>>
>>>>>> Thanks.
>>>>>
>>>>> yes
>>>>
>>>> Do you have anything in ~/.authinfo for the server?  If so, what?
>>>> What are your nnimap related configurations, generally?  The patch
>>>> installed on that day (see below) modified reading that file.  Ted, do
>>>> you have any ideas?
>>>
>>> The October 15 fails with or without .authinfo.
>>> The October 14 and today's cvs with your
>>> suggestion do work with and without .authinfo.
>>>
>>> I recall reading that port keyword in that file
>>> should be imap but it did not work with newer cvs
>>> gnus.  So currently I set it to 993 as it was with
>>> my older gnus.
>>
>> Ah, I suspect that is the cause.  Hm.  Are you in fact talking to the
>> server on port 993, or is it only something in .authinfo?
>>
>> If your server support it, it might be better to use STARTTLS on port
>> 143.
>>
>> I think you should remove the 'port 993', it isn't necessary.  In
>> fact, the manual try to make this clear.
>>
>> Further, if you are only talking to the server on one port, you
>> shouldn't need to use the "port" token at all.  It should only be
>> needed if you are talking to a server on a non-standard port (143 and
>> 993 both considered being standard ports).
>>
>> Finally, before you change anything, can you try to use today's CVS
>> with the patch below applied to nnimap.el?  Then maybe you (and
>> others) doesn't have to change .authinfo for things to continue to
>> work, which would be ideal.
>>
>> `nnimap-authinfo-file'
>>      A file containing credentials used to log in on servers.  The
>>      format is (almost) the same as the `ftp' `~/.netrc' file.  See the
>>      variable `nntp-authinfo-file' for exact syntax; also see *Note
>>      NNTP::.  An example of an .authinfo line for an IMAP server, is:
>>
>>           machine students.uio.no login larsi password geheimnis port imap
>>
>>      Note that it should be `port imap', or `port 143', if you use a
>>      `nnimap-stream' of `tls' or `ssl', even if the actual port number
>>      used is port 993 for secured IMAP.  For convenience, Gnus will
>>      accept `port imaps' as a synonym of `port imap'.
>>
>> --- nnimap.el	26 Oct 2004 22:21:08 +0200	7.13
>> +++ nnimap.el	19 Nov 2004 18:37:58 +0100	
>> @@ -778,7 +778,7 @@
>>  			(or nnimap-server-address
>>  			    nnimap-address))
>>  		  (list port)
>> -		  (list "imap" "imaps")))
>> +		  (list "imap" "imaps" "993")))
>>  	   (passwd (netrc-machine-user-or-password 
>>  		    "password"
>>  		    list
>> @@ -786,7 +786,7 @@
>>  			  (or nnimap-server-address
>>  			      nnimap-address))
>>  		    (list port)
>> -		    (list "imap" "imaps"))))
>> +		    (list "imap" "imaps" "993"))))
>>        (if (imap-authenticate user passwd nnimap-server-buffer)
>>  	  (prog2
>>  	      (setq nnimap-server-buffer-alist
>
> It seems to me that the patch and the discussion
> preceding it relates to the .authinfo.  However,
> today's cvs fails without an existing .authinfo.  
>
> Am I missing something?

No, I missed that it didn't even work without .authinfo.

Try M-: (setq debug-on-signal t) RET and then connect, and cut'n'paste
any interesting backtraces you get, pressing 'c' on each of them to
continue.

Hm.  You don't have a stale netrc.el somewhere, do you?  M-x
locate-library RET netrc RET will tell, it should point at the
netrc.el in Gnus.

Re: Problems with reading mail via imap

[Eythan Weg]

Simon Josefsson <jas@extundo.com> writes:
>
> Try M-: (setq debug-on-signal t) RET and then connect, and cut'n'paste
> any interesting backtraces you get, pressing 'c' on each of them to
> continue.
>
> Hm.  You don't have a stale netrc.el somewhere, do you?  M-x
> locate-library RET netrc RET will tell, it should point at the
> netrc.el in Gnus.

Netrc.el is in the current Gnus. 

When I try to connect to the nnimap server with
debug-on-signal on it never stop for a backtrace
but suggests to go offline when it cannot open the
server.  However, I never noticed the line
referring to "Symbol's function definition ..." in
the *Messages* buffer as shown here:
  
  imap: Connecting to dodgson.web...
  Opening TLS connection to `dodgson.web'...
  Opening TLS connection with `gnutls-cli -p %p %h'...done
  Opening TLS connection to `dodgson.web'...done
  Waiting for response from dodgson.web...done
  Unable to open server due to: 
       Symbol's function definition is void: netrc-machine-user-or-password
  Unable to open nnimap:dodgson, go offline? (y or n) 
  Please answer y or n.  Unable to open nnimap:dodgson, go offline? (y or n)  
  Couldn't open nnimap:dodgson 

Pretty suspicious.

Eythan 

Re: Problems with reading mail via imap

[Simon Josefsson]

Eythan Weg <weg@indiscrete.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>>
>> Try M-: (setq debug-on-signal t) RET and then connect, and cut'n'paste
>> any interesting backtraces you get, pressing 'c' on each of them to
>> continue.
>>
>> Hm.  You don't have a stale netrc.el somewhere, do you?  M-x
>> locate-library RET netrc RET will tell, it should point at the
>> netrc.el in Gnus.
>
> Netrc.el is in the current Gnus. 
>
> When I try to connect to the nnimap server with
> debug-on-signal on it never stop for a backtrace
> but suggests to go offline when it cannot open the
> server.  However, I never noticed the line
> referring to "Symbol's function definition ..." in
> the *Messages* buffer as shown here:
>   
>   imap: Connecting to dodgson.web...
>   Opening TLS connection to `dodgson.web'...
>   Opening TLS connection with `gnutls-cli -p %p %h'...done
>   Opening TLS connection to `dodgson.web'...done
>   Waiting for response from dodgson.web...done
>   Unable to open server due to: 
>        Symbol's function definition is void: netrc-machine-user-or-password
>   Unable to open nnimap:dodgson, go offline? (y or n) 
>   Please answer y or n.  Unable to open nnimap:dodgson, go offline? (y or n)  
>   Couldn't open nnimap:dodgson 
>
> Pretty suspicious.

Yes.  You don't have a stale netrc.elc around?  M-x locate-library RET
netrc.elc RET.

I think the problem is not with nnimap.el, but that somehow the wrong
netrc.el code is being picked up by your emacs.

Re: Problems with reading mail via imap

[Eythan Weg]

Simon Josefsson <jas@extundo.com> writes:

> I think the problem is not with nnimap.el, but that somehow the wrong
> netrc.el code is being picked up by your emacs.

Yes it WAS true, in a kind of round about way.  I
required gnus-dired which requires gnus-utils
which in turn requires netrc, _before_ my
temporary addition to the load-path of the current
gnus code.  So it picked an older netrc and by the
time I checked for the version of netrc I used
with locate-library, the path has already been
changed to include the new version of gnus.

Thank you for your patience and directions.

Eythan