Date: Thu, 18 Jan 2001 21:48:38 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "'Bill Moran'" <wmoran@mail.iowna.com> Cc: "'Huff'" <dwhuff1@home.com>, <freebsd-questions@FreeBSD.ORG> Subject: RE: qpopper Message-ID: <003a01c081db$79259160$1401a8c0@tedm.placo.com> In-Reply-To: <3A66FDCE.ED64D506@mail.iowna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: wmoran@clmboh1-smtp3.columbus.rr.com >[mailto:wmoran@clmboh1-smtp3.columbus.rr.com]On Behalf Of Bill Moran >Sent: Thursday, January 18, 2001 6:30 AM >To: Ted Mittelstaedt >Cc: 'Huff'; freebsd-questions@FreeBSD.ORG >Subject: Re: qpopper > > >Ted Mittelstaedt wrote: > >> Arrg! No, No NO! qpopper rewrites the mailfile in >/var/mail and adds >> a status header to the message that indicates if the message >is read or >> unread. There is not a problem to use pop from multiple mail clients >> AS LONG AS only ONE mail client is configured to DELETE >messages on the >> server when it checks mail, AND the user is sufficiently careful. >> >> For example, it is no problem to have a mailserver at work >in which the >> e-mail client at work is set to NOT leave messages on the >mailserver, (ie" >> it deletes them) and the mail client at home is set to Leave >messages on >> the server. That way if the employee stays home and works for a day >> they can check e-mail and when they come back into the office they >> can still have a copy of the message. Outlook has no problem doing >> this if the mailserver is properly configured. > >Alright, I could be wrong here (it's happened before) and if I am, I'm >guilty of one of the Greatest Crimes Against Humanity: spreading false >information with an air of authority. > Don't worry about that - we all do it! :-) >But I would like some further clarification (if you would). In looking >through RFC-1939 I see nothing that would facilitate the behaviour you >describe above. While it may be true the qpopper tracks which messages >have been downloaded and which haven't - how could the client possibly >know? Perhaps I'm missing something (it wouldn't be the first time). If >you can refer me to a document that describes this I'd be interested to >read it. >I know IMAP is designed to facilitate this, but qpopper isn't an IMAP >server. qpopper doesen't track anything. As you guessed in another posting, all of the monkey business has to be done by the client. When the POP client first connects, it checks to see if the server supports UIDL. Then, it issues LIST and gets all active message numbers. At that point, if UIDL is supported, it issues this against all message numbers, and using the output builds a database of message ID's and message numbers. This database becomes the basis for retrieving messages and issuing delete commands. If UIDL isn't supported the pop client can still build the database but it then has to fetch all messages, parse their headers and get the message ID from the header. Yuck. As you might imagine you want UIDL. When you check the "leave messages on the server" button the pop client simply doesen't issue delete commands back to the server at the close of a pop session. However, it does keep track of when you delete messages in your Inbox on the client in that database. Of course, in subsequent POP sessions the client is still presented with the message numbers when it does the LIST command, but it doesen't allow the user to see those messages (because it knows that those are supposed to be "deleted" If a message gets really deleted on the server by another POP client, then the first client knows about it because it won't see the message number in it's inital LIST/UIDL command. 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. 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. Ted To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003a01c081db$79259160$1401a8c0>