Hi, On Mon, 21 Jan 2019 at 12:40:47 +0200, Peter Pentchev wrote: > Hmm, as a Perl programmer, I do understand the spirit of "there's more > than one way to do it", so please do not take this as an objection of > any kind, but still I feel curious: what are pullimap's advantages over > fetchmail? I switched from fetchmail to getmail4 some years ago because of fetchmail's relative complexity, and the lack of client state for IMAP: only UNSEEN messages from the server are downloaded, which makes it unreliable if the remote IMAP server is used by another client between fetchmail calls (it won't retrieve new messages read on the other client). getmail and pullimap, on the other hand, retrieve all messages that have not been retrieved in a previous call. What made me move away from getmail is the lack of IDLE support: a new process is spawned, retrieves new messages, and then terminates. This adds some overhead (especially on high latency links such as over Tor) as well as extra latency (when new messages are received one needs to wait for the next getmail run to retrieve them). On the other hand, thanks to its IDLE support, pullimap keep the connection open (one process per mailbox) and downloads new messages immediately. My use-case for pullimap & interimap is when messages are retrieved from one or more third-party IMAP accounts (corporate, etc.), then passed through a local spam filter, and finally replicated to the other devices (each of which having its own IMAP server), not necessarily in a star topology. Thanks to the long-lived connections, IDLE and friends, when a message is delivered to my work mailbox, it appears on my laptop and other devices <2s later (spamassassin being the overhead) and I'm immediately notified. Other advantages are COMPRESS=DEFLATE and native SOCKS support. On the downside, pullimap supports less protocols (only IMAP4rev1 on the fetching end, only SMTP or LMTP on the receiving end) and processes a single mailbox per process (but if multiple mailboxes need to be polled one can start one process for each). Cheers, -- Guilhem.
Description: PGP signature