[ btw, any idea why your subject is truncated? ] Hi,
* Kyle Wheeler wrote: > On Thursday, August 13 at 10:38 AM, quoth Paul Grinberg: > > So, let's say my fetchmail keeps all the mail on the mail server > > after mail download is complete. > Without being rude, let me stop you right there. Fetchmail with the > "leave it on the server" option is PROBABLY a bad setup for you. It > was originally intended for POP3 servers, as a workaround for the fact > that POP3 is phenomenally bad at handling multiple clients. It's a > hack, intended for specific and usually temporary situations (where a > certain amount of hackery is tolerable), not as a long-term solution. It's not bad at it, it was explicitely designed not to support simultaneous clients. If you still attempt it it may fail, of course. > If you have no choice but to use POP3, I highly recommend you use mutt > to access your POP3 server directly. With the message and header > caching, it can be just as fast as a fetchmail-based option, and it > handles things like deleted messages much better. That's only half true, please don't recommend the internal fetchmail function for POP because it is partially broken (http://dev.mutt.org/trac/ticket/1751). Due to mutt's architecture, this isn't as easy to fix as it sounds. > First, you'd need a script that will identify messages on a POP3 > server based on a Message-ID or something similar. The problem, of > course, is that POP3 has no means of "searching" messages other than > by doing it the old fashioned way (download each one). Where IMAP > gives each message a unique, long-term UID number, POP3 does not (it > has UIDs, but they only last as long as the POP3 connection). Not quite I think, otherwise mutt's POP support would be quite poor. Without a persistent ID on the server, there would be no way to identify a message in a later session. POP3 is an old protocol used in times where bandwidth was a sacre resource... so downloading something over and over again just to see if you know it already (like in newsfeeds¹) was avoided. RFC1939 has this on the UIDL command: The unique-id of a message is an arbitrary server-determined string, consisting of one to 70 characters in the range 0x21 to 0x7E, which uniquely identifies a message within a maildrop and which persists across sessions. This persistence is required even if a session ends without entering the UPDATE state. The server should never reuse an unique-id in a given maildrop, for as long as the entity using the unique-id exists. Rocco ¹ okay, news items are updateable, but still it wastes lots of bandwith
pgp21fMSCFSng.pgp
Description: PGP signature
