From owner-freebsd-questions Fri Jan 19 8:23:16 2001 Delivered-To: freebsd-questions@freebsd.org Received: from clmboh1-smtp3.columbus.rr.com (unknown [65.24.0.112]) by hub.freebsd.org (Postfix) with ESMTP id 868F337B698 for ; Fri, 19 Jan 2001 08:22:56 -0800 (PST) Received: from mail.iowna.com (dhcp065-024-023-038.columbus.rr.com [65.24.23.38]) by clmboh1-smtp3.columbus.rr.com (8.11.2/8.11.2) with ESMTP id f0JGH2701217; Fri, 19 Jan 2001 11:17:02 -0500 (EST) Message-ID: <3A686862.333CD3E4@mail.iowna.com> Date: Fri, 19 Jan 2001 11:16:34 -0500 From: Bill Moran X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ted Mittelstaedt Cc: "'Huff'" , freebsd-questions@FreeBSD.ORG Subject: Re: qpopper References: <003a01c081db$79259160$1401a8c0@tedm.placo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ted Mittelstaedt wrote: > qpopper doesen't track anything. As you guessed in another posting, all of > the monkey business has to be done by the client. > Now, before you start punching holes in this let me say that it's easy to > get the client's internal database out of wack from the messages that are > actually on the server - that is why it's important to regularly delete > messages from the server, and to not do funny things like checking the same > mailbox simultaneously from different clients, and most importantly, not > letting > the modem crap out right when the client is in the middle of a POP session. > But, if you have good networking links, this sort of thing works well enough > for casual sharing use. Well, I'm not going to bother to punch holes in anything. The upshot here is that I was right about the client having to keep track of which message to download and not. > Now, all of this is getting far away from the problem the initial user is > having. His problem (and I mailed him the answer a while ago) is that > qpopper is unable to modify the user's mailbox. He may have a permissions > problem on the directory, or qpopper may not be executing a change userID > command properly, or something like that. As a result, he sends a delete > command, the client assumes it's deleted, the server is unable to delete it, > thus the message is still present. The upshot here is that you're probably right about permissions. One way or the other, thanks for the clarification. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message