Gnus reads my mail

Gnus reads my mail

[Stefan Monnier]

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


To my horror, I found no new mail in my `emacs' imap-folder this morning
(the splitting is done asynchronously by procmail, not by Gnus).

Now, I knew full well that this couldn't be, and I also had a suspicion
something was up with Gnus and my `emacs' folder (yesterday, it told me
I had about 10000 new messages, and although it's normal for Gnus to
overestimate the number of new messages, 10000 is way out of proportion), so
after trying a few things under Gnus, I took a look at that folder via
webmail, and lo and behold I have received messages in that folder since
last time I read it, but they were marked as "seen".

It turns out that it's Gnus that marked those things as "seen".

So in webmail, I marked the last 30 or so messages as "unseen", and then
I did the following:

- .../trunk/src/emacs --eval '(setq imap-debug t nnimap-debug t)' -f gnus
- type in my imap password
- save *imap-debug* to `imap-log-startup'
- enter the `nnimap+diro:emacs' folder (which said "0" new messages)
- save *imap-debug* to `imap-log-enter'
- leave the emacs folder
- save *imap-debug* to `imap-log-leave'
- save *nnimap-debug* to `imap-log-nnimap'

Meanwhile I also checked via webmail the status of my last few messages, and
unsurprisingly it's when I left the `emacs' folder that Gnus marked the
messages as "seen".

I've attached the imap-log-* files, compressed.

It seems the problem is specific to my `nnimap+diro:emacs' folder.
At least it does not affect my other folders `nnimap+diro:diro' and
`nnimap+diro:inbox' where I also received messages and could read them
normally with Gnus.  Maybe other folders are affected, but I didn't
notice it.

My `emacs' folder is about 30MB in size, which is smaller than my
`diro' folder.  OTOH my `emacs' folder is the largest in terms of number of
messages (5415), but that doesn't seem like it has anything to do with the
problem (I at first suspected some kind of msg-nb wrap around or some kind
of emacs-integer overflow, but that doesn't seem very likely).

Although Gnus did not literally *eat* my email, I find this problem to be
very serious since it might make me miss important email messages.


        Stefan


[-- Attachment #2: imap-log-startup.gz --]
[-- Type: application/octet-stream, Size: 7332 bytes --]

[-- Attachment #3: imap-log-enter.gz --]
[-- Type: application/octet-stream, Size: 43078 bytes --]

[-- Attachment #4: imap-log-leave.gz --]
[-- Type: application/octet-stream, Size: 3307 bytes --]

[-- Attachment #5: imap-log-nnimap.gz --]
[-- Type: application/octet-stream, Size: 3806 bytes --]

[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Gnus reads my mail

[Simon Josefsson]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Although Gnus did not literally *eat* my email, I find this problem to be
> very serious since it might make me miss important email messages.

Agreed.

> - .../trunk/src/emacs --eval '(setq imap-debug t nnimap-debug t)' -f gnus
> - type in my imap password
> - save *imap-debug* to `imap-log-startup'

It appears the problem is in this part alone.  It is easier to read if
you only enable `imap-log', and paste the result from the *imap-log*
buffer, but the same information is stored in the debug buffers too,
so I'm trying to read them below:

> | | | | | | 7 -> imap-arrival-filter: proc=#<process imap> string="* STATUS emacs (UNSEEN 35 UIDNEXT 22270 UIDVALIDITY 1062436086)


Ok, here your server reports that there are 35 unseen messages in the
emacs group.  Good.

> | | | | | 6 -> imap-send-command: command="EXAMINE \"emacs\"" buffer=nil

> | | | | | | 7 <- imap-send-command-1: nil
> | | | | | 6 <- imap-send-command: 26
> | | | | | 6 -> imap-wait-for-tag: tag=26 buffer=nil
> | | | | | | 7 -> imap-arrival-filter: proc=#<process imap> string="* 5415 EXISTS

> * 0 RECENT

> * OK [UIDVALIDITY 1062436086] UID validity status

> * OK [UIDNEXT 22270] Predicted next UID

> * FLAGS (gnus-expire gnus-forward \\Answered \\Flagged \\Deleted \\Draft \\Seen)

> * OK [PERMANENTFLAGS ()] Permanent flags

> * OK [UNSEEN 5381] first unseen message in /export/home/mail/monnier/Mail/emacs

> 26 OK [READ-ONLY] EXAMINE completed


And here Gnus enter the group read-only (EXAMINE).

> | | | | 5 -> imap-send-command-1: cmdstr="28 STATUS \"emacs\" (UIDNEXT)"
> | | | | 5 <- imap-send-command-1: nil
> | | | 4 <- imap-send-command: 28
> | | | 4 -> imap-wait-for-tag: tag=28 buffer=nil
> | | | | 5 -> imap-arrival-filter: proc=#<process imap> string="* NO CLIENT BUG DETECTED: STATUS on selected mailbox: emacs

> * STATUS emacs (UIDNEXT 22270)

> 28 OK STATUS completed

> "

Here Gnus asks for the UIDNEXT, which seem fine.

I believe the UoW warning is incorrect, sending STATUS on the
currently selected mailbox is valid according to RFC 2060.  This have
changed in RFC 3501, which say this is a SHOULD NOT operation, but the
justification given and the suggested workarounds aren't applicable to
what Gnus want to do.  Admittedly, Gnus (nnimap) could special-case
the STATUS on a selected mailbox, and return correct data immediately.
(Patches welcome..)

> | | | | | | 7 -> imap-send-command-1: cmdstr="65 SELECT \"emacs\""
> | | | | | | 7 <- imap-send-command-1: nil
> | | | | | 6 <- imap-send-command: 65
> | | | | | 6 -> imap-wait-for-tag: tag=65 buffer=nil
> | | | | | | 7 -> imap-arrival-filter: proc=#<process imap> string="* 5415 EXISTS

> * 0 RECENT

> * OK [UIDVALIDITY 1062436086] UID validity status

> * OK [UIDNEXT 22270] Predicted next UID

> * FLAGS (gnus-expire gnus-forward \\Answered \\Flagged \\Deleted \\Draft \\Seen)

> * OK [PERMANENTFLAGS (gnus-expire gnus-forward \\* \\Answered \\Flagged \\Deleted \\Draft \\Seen)] Permanent flags

> * OK [UNSEEN 5381] first unseen message in /export/home/mail/monnier/Mail/emacs

> 65 OK [READ-WRITE] SELECT completed


Here Gnus select the group read-write.

> | | | | 5 -> imap-send-command-1: cmdstr="68 STATUS \"emacs\" (UNSEEN)"
> | | | | 5 <- imap-send-command-1: nil
> | | | 4 <- imap-send-command: 68
> | | | 4 -> imap-wait-for-tag: tag=68 buffer=nil
> | | | | 5 -> imap-arrival-filter: proc=#<process imap> string="* NO CLIENT BUG DETECTED: STATUS on selected mailbox: emacs

> * STATUS emacs (UNSEEN 0)

> 68 OK STATUS completed


And here Gnus asks for the number of UNSEEN messages in the group.  It
is now 0.  I didn't remove any operation on your emacs folder above,
and Gnus didn't remove any SEEN flags in the group, so something other
than Gnus must have reset the unseen count.

I suspect the UoW implementation of the STATUS command on a currently
selected mailbox is buggy.

The STATUS value is used by Gnus in the group buffer, that's why it
reads 0 there.