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

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=C3=B6cker wrote:
> On Freitag, 11. April 2025 20:14:33 Mitteleurop=C3=A4ische Sommerzeit Kai=
 Bojens=20
> wrote:
> > > Am 11.04.2025 um 20:10 schrieb J=C3=B6rg Schaible <joerg.schaible@gmx=
=2Ede>:
> > >=20
> > > 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.
> >=20
> > No, this is exactly how POP3 works.
>=20
> Yes and no.
>=20
> > The client can ask the server to delete
> > the mails after the download, but it doesn=E2=80=99t have to. You can o=
f course
> > download a copy and keep them for a specified time on the server.
>=20
> The original idea of the POP protocol was to download all emails once and=
 then=20
> delete them after successful download. For obvious reasons, that's a prob=
lem=20
> if you want to read your email on multiple devices. That's why many email=
=20
> clients offer to keep the downloaded mails on the server for some time so=
 that=20
> the other email clients have a chance to download the emails as well.
>=20
> This hack, because in my opinion that's what it is, a hack, requires that=
 the=20
> server provides a unique identifier (UID) for each email that never chang=
es. A=20
> possible reason for a re-download of emails is that the server for some r=
eason=20
> changed those unique identifiers. (This brings back memories from decades=
 ago=20
> when I analyzed such problems.) Another possible reason is that the serve=
r=20
> doesn't remove the messages although KMail asks it to delete them. KMail =
will=20
> remove the UIDs from its book-keeping when it thinks that the server has=
=20
> deleted them. And then it will redownload them the next time. Without=20
> inspecting the communication between KMail and the server we won't know i=
f the=20
> server is the culprit or if there's a regression in KMail.
>=20
> Running
> ```
> QT_LOGGING_RULES=3D"org.kde.pim.pop3resource.debug=3Dtrue" akonadictl res=
tart 2>&1=20
> | grep org.kde.pim.pop3resource  >pop.log
> ```
> in Konsole should write the communication between KMail (or, more precise=
ly,=20
> the POP3 resource that handles the communication) and the server to the f=
ile=20
> pop.log. WARNING: This file may contain your password in slightly obfusca=
ted=20
> form. Don't publish this file as-is, but redact anything that looks like=
=20
> sensitive information.
>=20
> The POP3 resource stores the list of UIDs of the downloaded emails and th=
e=20
> date/time when those emails were downloaded to the config file of the res=
ource=20
> which should be something like ~/.config/akonadi_pop3_resource_0rc for th=
e first=20
> configured POP3 account. Compare the list of UIDs stored in the config fi=
le with=20
> the list of UIDs you should find in the pop.log file.
>=20
> Regards,
> Ingo
>=20