Emails going years back were on Yahoo's mail server. An IMAP account was created to monitor what's kept on the server. A separate POP3 account was also created, and set to remove messages older than 6 months from the server. Sidenote: the "delete after" option is unclear about whether old messages are deleted both locally and from the server, or just from the server. I rolled the dice and luckily nothing was deleted locally. However, apparently messages were not deleted from the remote server either. When I open the IMAP inbox, it shows messages dating back to 2019, when the oldest message shouldn't be older than 6 months.
server issue
I doubt it, because before running C-M I ran fetchmail with "fetchlimit 150", and messages were fetched and removed from the server. I also experimented with getmail with these settings: delete_after=90 max_messages_per_session=5 The oldest messages are grabbed first. I don't recall whether the bulk of my fetch was done by fetchmail or getmail, but mail from 2016 to 2019 was fetched and deleted from the server using one of the two. Then I switched to C-M when I reached 2019 msgs. The user I'm setting this up for is a novice, so the hope was that C-M will do everything they need easily. There is an unrelated server issue where the server would hang at unpredicable points (sometimes after fetching 153 msgs, sometimes after 2009 msgs, and anywhere in between) and because C-M doesn't timeout C-M would fall hostage to that and must be killed. In that case, when restarting C-M & then the POP3 download, it would not pick up where it was when the server hung, but rather at the point that the last successful fetch ended. So if it grabs 153 msgs then hangs, after restarting it would download the same 153 again and then press on further. Then I would cancel the download (I race to cancel the download before C-M hangs again), at which point it would finally process the msgs. Then there would be 153 dupes out of ~500 new msgs, for example, and I would use the dupe deletion feature. Then I would repeat that cycle. It was a lot of babysitting to get tens of thousands of msgs. It's clear from the debug output that the server is hanging b/c C-M it's the server's turn to do something whenever it freezes. But the Yahoo server may be doing this deliberately to regulate the bandwidth as I have a huge number of msgs to grab. If the server were to simply end the session, that enables the client to reconnect and start burdoning the server again. So the server seems to be "tarpitting" the connection and C-M just sits in the tarpit indefinitely. In any case, at every point where I was able to cancel the fetch, C-M then had a chance to do all the necessary processing. It appears that by doing a cancel, the code goes through a path that neglects the "delete after" functionality.
Provide the Network Log and the contents of the corresponding file from ~/.claws-mail/uidl/
Created attachment 2190 [details] UIDL file part 1 of 2 This is the file in the UIDL directory for the account where the bug has manifested. The original tarball was 600k which exceeds upload limits, so it was split into 2 parts. To rejoin, run "cat bug_4437_uidl_data.tar.gz_partA bug_4437_uidl_data.tar.gz_partB > bug_4437_uidl_data.tar.gz"
Created attachment 2191 [details] UIDL file part 2 of 2 This is the file in the UIDL directory for the account where the bug has manifested. The original tarball was 600k which exceeds upload limits, so it was split into 2 parts. To rejoin, run "cat bug_4437_uidl_data.tar.gz_partA bug_4437_uidl_data.tar.gz_partB > bug_4437_uidl_data.tar.gz"
that's uidl file, but not the network log to go with it, and it is not useful by itself.
The UIDL file is 1.2mb, exceeding upload limits. The tarball of that is 600k, also exceeding limits. So I've split the tarball into 2 parts. They can be cat'd together then untar'd. E.g.: cat bug_4437_uidl_data.tar.gz_partA bug_4437_uidl_data.tar.gz_partB | tar xvzf - You also ask for a Network Log. C-M doesn't retain a history on that, so I would have to trigger the bug and capture it at that moment. That could be a long wait since I've stopped using C-M. I might go back to using it at which point I'll capture the net log. Until then, I hope the UIDL file is sufficient to stand on its own.
ok, i'll have to get a net log. It may be months down the line.