Fetchmail has a "fetchlimit" option that's quite useful. If you have an inbox with 50,000+ messages, it's a bit crazy to download them all at once. Yet C-M wants to start doing this immediately after adding an account. The immediate download can be inhibited, but eventually users must bite that bullet. Rationale for adding a fetch limit option to the "Receive" config page: 1. A massive download can burdon the network for too long (dial-up users are particularly screwed). 50k msgs would tie up a phone line for days. If Tor is used, Tor circuits sometimes collapse mid-session. I also suspect a heavy download can trigger a defensive mechanism for a Tor node to kill the connection. 2. The session is more likely to get interupted (e.g. network goes down) and recovering can be miserable (some mail clients don't remove from server until everything is downloaded, causing everything that was downloaded before the interuption to be redownloaded, sometimes causing many dupes) 3. Testing-- users don't know if their complex configuration with filters & processing will go well until they actually do a fetch. We need the 1st fetch to be small enough that a bad config isn't a colossal disaster. 4. Working around other bugs, such as this one: https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4307 It might make sense to set a fetch limit to try to prevent a box from exceeding 505. 5. Some email providers will disrupt users who download too much at once, which I think is one of the reasons fetchmail introduced the fetchlimit. 6. Security: a Tor circuit that's running for a long time can be exposed by traffic analysis and timing attacks. Some filters/processing act differently depending on the age of a message. So it would be useful as well if users have a choice in whether the oldest msgs are fetched 1st or last.
Regarding rationale #4, a fetch limit could make bug 4423 more manageable. Note as well from bug 4423 that the ESP (Yahoo) seems to be denying service whenever Claws Mail doesn't fail itself and it makes enough progress for the server to regard the download an excessive burdon (rationale #5).
Another feature request, which could be implemented in addition to (or in lieu of) a fetch limit: Please create a signal handler that will terminate a retrieval mid-session and perform a cleanup that entails processing what was already downloaded. Rationale 1: for situations like bug 4423, where C-M is hung (perhaps do to a badly acting server), C-M is non-responsive to UI input but it's still able to handle signals (specifically the terminate signal). When users are forced to send a kill signal, the msgs downloaded so far in the hung session are lost and must be refetched. Introducing a stop downloading signal will mitigate re-fetches. Rationale 2: even if bug 4423 is fixed, in a bug-free scenario a user might realize that a download is slow and taking absurdly long, or there is for more msgs than a user expected or wanted to download. Resources should not be tied up for a long time without user control.