* On 2004.08.06, in <[EMAIL PROTECTED]>, * "Clifton Royston" <[EMAIL PROTECTED]> wrote: > > Whoa there - unless I am completely brain-dead this morning (always a > possibility) POP doesn't re-upload messages last I looked.
You're right. *I* woke up brain-dead this morning, and when someone mentioned uploads in this thread I got confused, and began merging notions from POP and local UNIX v7 mail file access. > Deleting messages automatically on download is a qpopper option, and > one not in use at the majority of sites. (It's nice if you can make > people think it works that way from the beginning, but once they get > used to "leave-mail-on-server" and checking from multiple PCs it's very > hard to get them to switch.) Mostly messages get deleted via a > specific DELE command in the POP session, as I remember from times doing > telnet-level interactive sessions to debug popper. FTR, I agree with this, except that it is my impression that most users must take specific steps in their applications not to automatically issue DELEs for each RETR. I.e., it's a client app issue more than a protocol or server issue, and I think it's quite common. Certainly I agree that once they're accustomed to it it's hard to break the habit. That's why we had to do Happymail -- precisely to break that habit. :) > I am fairly sure it does not tell you whether that message was actually > downloaded with the RETR command, which I think comes closest to what > was asked. AFAIK there is no guaranteed unique thing that will get set > in a message after the POP RETR command has been executed on that > message. I agree, but I haven't seen many POP (only one) clients that allow individual message retrieval. Most just pull down all that they've never seen before. Maybe this is more common than I realize. -- -D. [EMAIL PROTECTED] NSIT::ENSS The World Wide Web: proof that God exists, and is laughing at us.
