Tim: >> Although you can leave mails on a server with POP3, and just read >> newer ones, it's not designed for that usage pattern. Wolfgang Pfeiffer: > `man fetchmail': > > ------------- > -k | --keep > (Keyword: keep) > Keep retrieved messages on the remote mailserver. Normally, > messages are deleted from the folder on the mailserver after > they have been retrieved. Specifying the keep option causes > retrieved messages to remain in your folder on the mailserver. > This option does not work with ETRN or ODMR. If used with POP3, > it is recommended to also specify the --uidl option or uidl > keyword. > ------------- > > So it seems, leaving messages on the server after reading is not a > problem for fetchmail, be it POP3 or whatever usage. But, and it's a very big but, you're entirely dependent on a POP3 server working in a way that's compatible with that (added) feature. It's a kludge hacked on, always remember that. Even if you have a mail server that doesn't renumber all your messages between mail runs you need to parse a large list (if you keep messages on the inbox), and that gets significantly worse as it increases. On my LAN mail server, using maildir folders accessed with IMAP, I have one mailing list folder with 19,734 messages in it, and it's a snap to work through it (load up the list, search through it, read a message, etc). And there's over a dozen folders with similarly huge numbers of mail in each of them. Trying to deal with a POP3 server with just a few hundred on it is painful, sometimes even just a few dozen, by comparison. So what does happen when a POP3 mail server isn't really compatible with the feature? Ordinarily messages are numbered as message 1 in the mailbox, message 2 in the mailbox, etc, as simply as that. You get sent a list of this each time, your mail client requests the numbers to be sent, the mail server deletes the ones it know it sent at the end of the mail run. If I delete message 4, then everything after it is renumbered. If it receives a new message and inserts it in the middle, rather than tack it on the end, all the other messages get renumbered. If the connection aborts part way through, most will not delete the messages you already downloaded. Suddenly, your mail program can't tell which messages are read, or which are which. You can try using UIDL options, if supported, where the lists note down the message-id headers instead of just message #1, #2, #3, etc. But they're not guaranteed to be unique, permanent, or even present. For instance, your message, that I'm replying to now, has this header > Message-ID: <YgmCpEvNu9eGPe1T@localhost> The mail server is still dealing with message #1, #2, #3, etc., but now your mail client also (potentially) has some unique ID numbers to try and figure out that yesterday's message #14 is today's message #5. You often find some important message gets left on the server and never downloaded. You're not even aware it exists. You may find that you have to fetch and delete all other messages to deal with it. You may find you can't fetch it, and can only delete it. Been there, done that, got the tee shirt. If you've never used IMAP, then the nearest equivalent experience to it is virtually every webmail interface (Hotmail, Yahoo mail, gmail, etc.). Many of them use IMAP, but even if they don't, they work in the same way: Mail is on the server, you have an interface to the lists of it, you fetch individual messages when you click on them, you temporarily cache them locally (quicker to reload the same message, but it's not permanently kept locally). Sometimes going from one message to another is quick, sometimes it's slow either because of networking issues or their server is inefficient. IMAP *can* be tedious, if every new message you read involves reconnecting to the server, negotiating that connection, checking for new messages, issuing fetch instructions, queuing every action one after another (i.e. half-baked software written by people who've not fully thought through how to do it properly, and don't care). But, it doesn't have to be. If they'd done things intelligently, keeping an active connection to the server during your session (only timing out after a long time), simultaneously handling new message additions to the lists, while you do what you do, sending commands in parallel. -- uname -rsvp Linux 3.10.0-1160.53.1.el7.x86_64 #1 SMP Fri Jan 14 13:59:45 UTC 2022 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
