[Bug 279297] Not all new mails are downloaded

[Thomas McGuire]

https://bugs.kde.org/show_bug.cgi?id=279297


Thomas McGuire <mcguire at kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WAITINGFORINFO




--- Comment #4 from Thomas McGuire <mcguire kde org>  2011-09-16 16:21:42 ---
I have never seen this kind of problem. To narrow it down a bit, you need to
provide a few logs. Let me tell you how.
We need to find out where in the Akonadi stack the bug is, if it is in the POP3
resource, the maildir resource, the Akonadi server or KMail itself.

Once you know you have a mail that you can see on the webmail server, but that
is missing in KMail, you can do the following steps. But only do the steps in
that scenario, KMail and the server need to be out of sync for the logs to
provide some useful information.
So once KMail doesn't show a mail that you know is on the server, do the
following:
- Stop KMail, Kontact and every other applications using Akonadi
- Open a console for some commands to type
- type "akonadictl stop" to completely stop Akonadi
- Find the UID of the mail that is on the server, but missing locally. This is
a bit tricky. First, login to arcor with telnet by typing:
"telnet pop3.arcor.de
Connected to pop3.arcor.de.
Escape character is '^]'.
+OK Hello there.
USER <your username>
PASS <your password>"
At this point you should be logged in to the ARCOR pop3 server over command
line. You can see the list of mails on the server with the "LIST" and the
"UIDL" commands. LIST gives a list of IDs and the size of the mail. UIDL gives
a list of IDs and their associated. You can read mails with "RETR <ID>". Try
reading all mails until you find the missing one, and note the ID. Maybe
looking at the mail sizes can help narrowing the result down. Then you can use
the UIDL command to find the associated UID easily. Note down the UID!

KMail keeps a list of UIDs that it has downloaded from the POP3 server, but
that are still left on the server. This list is needed so that KMail doesn't
download the same mail again on the next mail check. The file keeping that list
is in $HOME/.kde4/share/config/akonadi_pop3_resource_7rc. You might have .kde
instead of .kde4, and a different number than 7.

Next, enable debugging for the POP3 resource with kdebugdialog. Make sure
debugging is enabled in general and in specific for anything containing "pop3".

Now, on the console you are using, set the scrollback to unlimit, so we don't
miss anything from the loads of debug output that will follow.
Restart Akonadi with "akonadictl start". Then, start akonadiconsole, and
trigger a mail check with the POP3 resource. On your console, you should see
lots of POP3-related output, especially during the mail check. Copy&Paste that
output to a text file, and attach it here.

In summary, please attach to the bug report:
- The POP3 UID of the missing mail
- the akonadi_pop3_resource_Xrc config file
- the debug output on the console during a POP3 mail check

Remember that the mail needs to be available on the server, but missing in the
KMail, otherwise all this won't be useful.

BTW, it is correct that mail check also happens when neither KMail nor Kontact
are running.

> Would I lose other data apart from the configuration if I wipe out all files
> related to Akonadi (only keep .local/share/local-mail where my mails are
> stored)?

Note that most of your mails are probably in .local/share/.local-mail (notice
the additional dot)! You will loose tags, status flags (read/unread/important
etc), config settings, accounts etc. The mails themselves would survive this
though. If you forget to delete some files, it could cause some inconsistency.
But please lets try to narrow down the problem using the steps described above
first.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.