New nnimap error with Gcc

New nnimap error with Gcc

[Steven E. Harris]

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

I'm running a Gnus built fresh from CVS on the Cygwin XEmacs 21.4.20
build. When I send a mail message and attempt to Gcc my "sent mail"
folder on an IMAP server, the outgoing message gets sent, the copy gets
stored in my IMAP folder, but Gnus then reports the following error and
leaves the message composition window open:


Debugger entered--Lisp error: (error "format specifier %d doesn't match argument type")
  format("%d" nil)
  #<compiled-function (item) "...(17)" [item format "%d:%d" "%d"] 4>(nil)
  mapconcat(#<compiled-function (item) "...(17)" [item format "%d:%d" "%d"] 4> (nil) ",")
  imap-range-to-message-set((nil))
  nnimap-request-set-mark("INBOX.sent-mail" (((nil) del (read))) "panix")
  gnus-request-set-mark("nnimap+panix:INBOX.sent-mail" (((nil) del (read))))
  gnus-agent-synchronize-group-flags("nnimap+panix:INBOX.sent-mail" (((nil) del (read))) (nnimap "panix" (nnimap-address "mail.panix.com") (nnimap-stream starttls) (nnimap-need-unselect-to-notice-new-mail t) (nnimap-list-pattern ("INBOX" "INBOX.*"))))
  gnus-agent-regenerate-group("nnimap+panix:INBOX.sent-mail" (nil))
  gnus-request-accept-article("nnimap+panix:INBOX.sent-mail" "nnimap:panix" t t)
  gnus-inews-do-gcc()
  gnus-agent-possibly-do-gcc()
  run-hooks(gnus-agent-possibly-do-gcc)
  message-send(nil)
  message-send-and-exit(nil)
  call-interactively(message-send-and-exit)


I activated imap-log and will include the entire transaction here:



[-- Attachment #2: gnus-send-error-imap-log.txt --]
[-- Type: text/plain, Size: 3317 bytes --]

68 SELECT "INBOX.sent-mail"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward gnus-expire)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward gnus-expire \*)] Flags permitted.
* 126 EXISTS
* 0 RECENT
* OK [UNSEEN 125] First unseen.
* OK [UIDVALIDITY 1067273722] UIDs valid
* OK [UIDNEXT 978] Predicted next UID
68 OK [READ-WRITE] Select completed.
69 UID SEARCH UNSEEN UNDELETED
* SEARCH 976 977
69 OK Search completed.
70 UID SEARCH SEEN
* SEARCH 44 50 67 76 78 81 113 159 177 211 213 247 257 268 270 282 285 286 290 295 296 299 315 321 324 325 356 364 410 425 429 438 439 440 448 469 471 493 495 499 508 525 534 562 572 576 577 595 596 597 600 604 606 620 629 633 638 642 645 664 665 667 674 679 682 693 695 715 733 775 786 787 789 797 799 802 803 805 812 819 820 835 837 838 840 860 862 863 865 868 870 872 874 881 891 893 894 895 917 921 922 923 924 925 926 928 929 930 937 938 940 943 944 945 947 950 958 960 962 963 967 973 974 975
70 OK Search completed.
71 UID SEARCH FLAGGED
* SEARCH
71 OK Search completed.
72 UID SEARCH ANSWERED
* SEARCH 282 620 868 874 943 944
72 OK Search completed.
73 UID SEARCH KEYWORD gnus-expire
* SEARCH 975
73 OK Search completed.
74 UID SEARCH KEYWORD gnus-forward
* SEARCH 693 891 917 921 922 923
74 OK Search completed.
75 UID SEARCH RECENT
* SEARCH
75 OK Search completed.
76 EXAMINE "INBOX.sent-mail"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward gnus-expire)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 126 EXISTS
* 0 RECENT
* OK [UNSEEN 125] First unseen.
* OK [UIDVALIDITY 1067273722] UIDs valid
* OK [UIDNEXT 978] Predicted next UID
76 OK [READ-ONLY] Select completed.
77 CLOSE
77 OK Close completed.
78 EXAMINE "INBOX.sent-mail"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward gnus-expire)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 126 EXISTS
* 0 RECENT
* OK [UNSEEN 125] First unseen.
* OK [UIDVALIDITY 1067273722] UIDs valid
* OK [UIDNEXT 978] Predicted next UID
78 OK [READ-ONLY] Select completed.
79 FETCH 1,* UID
* 1 FETCH (UID 44)
* 126 FETCH (UID 977)
79 OK Fetch completed.
80 EXAMINE "INBOX.sent-mail"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward gnus-expire)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 126 EXISTS
* 0 RECENT
* OK [UNSEEN 125] First unseen.
* OK [UIDVALIDITY 1067273722] UIDs valid
* OK [UIDNEXT 978] Predicted next UID
80 OK [READ-ONLY] Select completed.
81 CLOSE
81 OK Close completed.
82 APPEND "INBOX.sent-mail" {426}
+ OK
From: "Steven E. Harris" <seh@panix.com>
To: Steven Elliot Harris <seh@panix.com>
Subject: Gcc test
Organization: SEH Labs
X-Draft-From: ("nnimap+panix:INBOX")
Date: Sat, 30 Jun 2007 10:30:37 -0700
Message-ID: <83ir95tkn6.fsf@torus.sehlabs.com>
User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.20 (cygwin32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Here's a test.

-- 
Steven E. Harris
82 OK Append completed.
83 SELECT "INBOX.sent-mail"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward gnus-expire)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward gnus-expire \*)] Flags permitted.
* 127 EXISTS
* 1 RECENT
* OK [UNSEEN 125] First unseen.
* OK [UIDVALIDITY 1067273722] UIDs valid
* OK [UIDNEXT 979] Predicted next UID
83 OK [READ-WRITE] Select completed.

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



Does anything look wrong there?

-- 
Steven E. Harris

Re: New nnimap error with Gcc

[Simon Josefsson]

"Steven E. Harris" <seh@panix.com> writes:

> I'm running a Gnus built fresh from CVS on the Cygwin XEmacs 21.4.20
> build. When I send a mail message and attempt to Gcc my "sent mail"
> folder on an IMAP server, the outgoing message gets sent, the copy gets
> stored in my IMAP folder, but Gnus then reports the following error and
> leaves the message composition window open:
>
>
> Debugger entered--Lisp error: (error "format specifier %d doesn't match argument type")
>   format("%d" nil)
>   #<compiled-function (item) "...(17)" [item format "%d:%d" "%d"] 4>(nil)
>   mapconcat(#<compiled-function (item) "...(17)" [item format "%d:%d" "%d"] 4> (nil) ",")
>   imap-range-to-message-set((nil))
>   nnimap-request-set-mark("INBOX.sent-mail" (((nil) del (read))) "panix")
>   gnus-request-set-mark("nnimap+panix:INBOX.sent-mail" (((nil) del (read))))
>   gnus-agent-synchronize-group-flags("nnimap+panix:INBOX.sent-mail" (((nil) del (read))) (nnimap "panix" (nnimap-address "mail.panix.com") (nnimap-stream starttls) (nnimap-need-unselect-to-notice-new-mail t) (nnimap-list-pattern ("INBOX" "INBOX.*"))))
>   gnus-agent-regenerate-group("nnimap+panix:INBOX.sent-mail" (nil))
>   gnus-request-accept-article("nnimap+panix:INBOX.sent-mail" "nnimap:panix" t t)
>   gnus-inews-do-gcc()
>   gnus-agent-possibly-do-gcc()
>   run-hooks(gnus-agent-possibly-do-gcc)
>   message-send(nil)
>   message-send-and-exit(nil)
>   call-interactively(message-send-and-exit)

For some reason, Gnus thinks the article number is nil instead of some
integer.  I don't know why that happens.  Edebuging some of the
functions named above might help.

Re: New nnimap error with Gcc

[Steven E. Harris]

Simon Josefsson <simon@josefsson.org> writes:

> For some reason, Gnus thinks the article number is nil instead of some
> integer.  I don't know why that happens.  Edebuging some of the
> functions named above might help.

gnus-request-accept-article calls on nnimap-request-accept-article
around line 620 in gnus-int.el. nnimap-request-accept-article returns
nil, because its last form is a call to nnheader-report, which always
returns nil.

This returned nil is captured in the "result" binding in
gnus-request-accept-article. The cdr of this nil value is then passed in
to gnus-agent-regenerate-group, where the nil result gets bound to the
optional "reread" argument. The nil value counts as a list on line 4071
in gnus-agent.el, so the nil is combined with 'del and '(read) and
passed on to gnus-agent-synchronize-group-flags, where it's bound to the
"actions" parameter.

This "actions" list makes it down to nnimap-request-set-mark, which
pulls apart each member into "range", "what", and "cmdmarks" around line
1245 in nnimap.el.

Given the "actions" list of

  (((nil) del (read)))

the car is

  ((nil) del (read))

of which (nth 0 *) yields

  (nil)

for the "range" binding. Down on line 1271 in nnimap.el, we test "range"
and find it non-nil, so we continue to try to pass it off to
imap-range-to-message-set, which fails.

I see a conflict here. There's an assumption that
nnimap-request-accept-article won't return nil, but I don't see how it
can return anything but nil, given that it returns with nnheader-report.

Does any of this help?

-- 
Steven E. Harris

Courier-IMAP and UIDPLUS problem (was: New nnimap error with Gcc)

[Steven E. Harris]

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

"Steven E. Harris" <seh@panix.com> writes:

> What more can I do to assist in fixing this problem?

I just sent this message to my ISP regarding their mail servers:


[-- Attachment #2: Type: message/rfc822, Size: 1613 bytes --]

From: "Steven E. Harris" <seh@panix.com>
Subject: Courier-IMAP support for UIDPLUS (RFC 2359)
Date: Wed, 29 Aug 2007 11:45:33 -0700
Message-ID: <7y3ay22n2h.fsf@fillmore.spawar.navy.mil>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1: Type: text/plain, Size: 1227 bytes --]

From: "Steven E. Harris" <seh@panix.com>
Subject: Courier-IMAP support for UIDPLUS (RFC 2359)
Date: Wed, 29 Aug 2007 11:45:33 -0700
Message-ID: <7y3ay22n2h.fsf@fillmore.spawar.navy.mil>

--text follows this line--
The Courier-IMAP server(s) listening at mail.panix.com annouce support
for the UIDPLUS capability described in RFC 2359, but don't support it
in practice.

Here's the Capability string, reformatted for display:

,----
| * OK [CAPABILITY IMAP4rev1
|       UIDPLUS
|       CHILDREN NAMESPACE THREAD=REFERENCES
|       SORT QUOTA IDLE AUTH=PLAIN]
|       Courier-IMAP ready. Copyright 1998-2005 Double Precision, Inc.
|       See COPYING for distribution information.
`----

Note that UIDPLUS is present.

When I issue an APPEND or COPY command, the server responds with a
traditional, non-UIDPLUS-related string:

,----
| 25 APPEND "INBOX.test" {200057}
| ...
| 25 OK Append completed.
`----

Looking in Section 4.2 of the RFC¹, the server should have included an
APPENDUID clause in between "OK" and "Append" above.

My IMAP client is failing when copying and storing messages on the
server because of this false advertisement of UIDPLUS support. Is this a
feature that's been disabled by a configuration directive? Either the
server should not be advertising this capability, or it should actually
support it as advertised.


Footnotes: 
¹ http://www.faqs.org/rfcs/rfc2359.html

-- 
Steven E. Harris

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


Is my interpretation of the UIDPLUS problem correct?

-- 
Steven E. Harris

Re: Courier-IMAP and UIDPLUS problem

[Steven E. Harris]

"Steven E. Harris" <seh@panix.com> writes:

> I just sent this message to my ISP regarding their mail servers:

My ISP corrected the capability string on their IMAP server (which was
apparently a proxy server's misrepresentation of the real IMAP server's
capabilities), and the aforementioned problems with Gcc, copying, and
moving messages went away.

This one falls under "be conservative in what you send, liberal in what
you accept"; nnimap does not fail gracefully when the advertised UIDPLUS
data turns out to be missing from the server responses.

-- 
Steven E. Harris