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

--nextPart2205183.yiUUSuA9gR
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Ingo =?UTF-8?B?S2zDtmNrZXI=?= <[email protected]>
To: [email protected]
Date: Fri, 11 Apr 2025 21:35:07 +0200
Message-ID: <1906356.LH7GnMWURc@daneel>
In-Reply-To: <[email protected]>
MIME-Version: 1.0

On Freitag, 11. April 2025 20:14:33 Mitteleurop=C3=A4ische Sommerzeit Kai B=
ojens=20
wrote:
> > Am 11.04.2025 um 20:10 schrieb J=C3=B6rg Schaible <[email protected]=
e>:
> >=20
> > Well, since you said you're using POP3, so I ask myself, how can you ev=
er
> > re- download emails? This is not how the POP3 protocol works.
>=20
> 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=E2=80=99t 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 t=
hen=20
delete them after successful download. For obvious reasons, that's a proble=
m=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 t=
hat=20
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 t=
he=20
server provides a unique identifier (UID) for each email that never changes=
=2E A=20
possible reason for a re-download of emails is that the server for some rea=
son=20
changed those unique identifiers. (This brings back memories from decades a=
go=20
when I analyzed such problems.) Another possible reason is that the server=
=20
doesn't remove the messages although KMail asks it to delete them. KMail wi=
ll=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 if =
the=20
server is the culprit or if there's a regression in KMail.

Running
```
QT_LOGGING_RULES=3D"org.kde.pim.pop3resource.debug=3Dtrue" akonadictl resta=
rt 2>&1=20
| grep org.kde.pim.pop3resource  >pop.log
```
in Konsole should write the communication between KMail (or, more precisely=
,=20
the POP3 resource that handles the communication) and the server to the fil=
e=20
pop.log. WARNING: This file may contain your password in slightly obfuscate=
d=20
form. Don't publish this file as-is, but redact anything that looks like=20
sensitive information.

The POP3 resource stores the list of UIDs of the downloaded emails and the=
=20
date/time when those emails were downloaded to the config file of the resou=
rce=20
which should be something like ~/.config/akonadi_pop3_resource_0rc for the =
first=20
configured POP3 account. Compare the list of UIDs stored in the config file=
 with=20
the list of UIDs you should find in the pop.log file.

Regards,
Ingo
--nextPart2205183.yiUUSuA9gR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTbjgIOMowwlCBgvyGxb1mVFkdKugUCZ/lu6wAKCRCxb1mVFkdK
uuMeAP9MdKQIcJl247e9bwqxhcgLaw0SbjPMPdveGNPkUODCQwEA/xPJtbV3sAHl
ImgPW72dUaQ/LXGr2rCivPwUds9pAgw=
=Tlsr
-----END PGP SIGNATURE-----

--nextPart2205183.yiUUSuA9gR--