KMail re-downloads POP3 emails that are supposed to be deleted

[MoC]

Hi Ingo,

thanks for the advice! Unfortunately some time needs to elapse before
the re-download occurs so I am still hunting for a re-occurrence. If
there is a way to permanently enable the logging, please let me know.

Is there any way I can look up the UID of a message in KMail? Since I
have re-downloaded some mails multiple times already and the UID is
apparently provided by the server, I could at least verify whether the
UIDs are unique or not.

In the meantime, the number of unread images has increased to
approx. 2300. Does anybody have an idea why the filter for deleting
unread emails I attached in my first email does not work?

Kind regards,
MoC

On Friday, April 11, 2025 9:35:07 PM CEST Ingo Klöcker wrote:
> On Freitag, 11. April 2025 20:14:33 Mitteleuropäische Sommerzeit Kai Bojens 
> wrote:
> > > Am 11.04.2025 um 20:10 schrieb Jörg Schaible <joerg.schaible at gmx.de>:
> > > 
> > > Well, since you said you're using POP3, so I ask myself, how can you ever
> > > re- download emails? This is not how the POP3 protocol works.
> > 
> > No, this is exactly how POP3 works.
> 
> Yes and no.
> 
> > The client can ask the server to delete
> > the mails after the download, but it doesn’t have to. You can of course
> > download a copy and keep them for a specified time on the server.
> 
> The original idea of the POP protocol was to download all emails once and then 
> delete them after successful download. For obvious reasons, that's a problem 
> if you want to read your email on multiple devices. That's why many email 
> clients offer to keep the downloaded mails on the server for some time so that 
> the other email clients have a chance to download the emails as well.
> 
> This hack, because in my opinion that's what it is, a hack, requires that the 
> server provides a unique identifier (UID) for each email that never changes. A 
> possible reason for a re-download of emails is that the server for some reason 
> changed those unique identifiers. (This brings back memories from decades ago 
> when I analyzed such problems.) Another possible reason is that the server 
> doesn't remove the messages although KMail asks it to delete them. KMail will 
> remove the UIDs from its book-keeping when it thinks that the server has 
> deleted them. And then it will redownload them the next time. Without 
> inspecting the communication between KMail and the server we won't know if the 
> server is the culprit or if there's a regression in KMail.
> 
> Running
> ```
> QT_LOGGING_RULES="org.kde.pim.pop3resource.debug=true" akonadictl restart 2>&1 
> | grep org.kde.pim.pop3resource  >pop.log
> ```
> in Konsole should write the communication between KMail (or, more precisely, 
> the POP3 resource that handles the communication) and the server to the file 
> pop.log. WARNING: This file may contain your password in slightly obfuscated 
> form. Don't publish this file as-is, but redact anything that looks like 
> sensitive information.
> 
> The POP3 resource stores the list of UIDs of the downloaded emails and the 
> date/time when those emails were downloaded to the config file of the resource 
> which should be something like ~/.config/akonadi_pop3_resource_0rc for the first 
> configured POP3 account. Compare the list of UIDs stored in the config file with 
> the list of UIDs you should find in the pop.log file.
> 
> Regards,
> Ingo
>