On Thu, 29 Nov 2001, Randall Gellens wrote: > At 7:29 PM -0600 11/29/01, Ted Hatfield wrote: > > >Here is my situation. > > > >I installed qpopper about a month ago when I migrated my userbase to a new > >mail server. > > > >After the transfer I ran through the expected calls when the UIDL changed on > >the mail spools and some clients began retrieving old mail again. > > > >During this time things were working fine when I received a complaint. > > > >I have a user with a mailbox being shared among 5 people using 4 > >different mail clients. These clients are setup to leave mail on > >server with one client set to delete mail after X many days. > > > >One of the clients "Eudora" was reading the Status header that Qpopper was > >inserting header. This had the effect of the user downloading email that was > >shown as already read. > > Is the desired behavior that each client download a distinct set of > messages, or that each client downloads all the messages? The latter > is easier to deal with for everyone, I'd think, especially using POP. > In that case, it should be no problem that the Eudora client > downloads the message. It's routine for people to have multiple > installations of Eudora on different machines all downloading the > same messages, with one copy deleting them. The presence of the > Status: header shouldn't affect which messages are downloaded. > Eudora uses the UIDs for that. > > Maybe I'm not understanding what the problem was.
The desired behavior is that each client get all the messages. That was happening. Since Qpopper was placing a Status header stating that the message had already been "read", when eudora downloaded the message it sorted the mail by that header and determined that any message which had already been downloaded by other clients were not new to this particular client and therefore not new. > >Consequently I recompiled with the disable-status option to keep Qpopper from > >updating these headers with the understanding that my CPU load would increase > >because UIDL would be recomputed everytime the spool was read. > > (You can set and reset the option using a configuration file, to > avoid the need to recompile. This also allows you to set or reset it > for some users only.) True, My older pop client didn't save UIDL or status and I prefer it that way. My server load is not such that the extra cpu time is a problem. > > > >This solved their problem and they were quite pleased. > > > >Several days later I received another call from the same people. > > > >It seems that several of the messages that one of their users was resending > >using eudora showed up in their mail spool with identical X-UIDL headers. > > > >This had the effect of one of the messages being read by the mail clients but > >the rest of the affected messages as unreadable as the client believe it had > >already downloaded that email. > > > >My theory so far (theory = wild ass guess) is that the user sending the > >messages through Eudora (using the send again option) actually sent a message > >with a X-UIDL header already included in it. Sendmail and procmail left the > >header in the message and Qpopper saw it and reported the bogus UIDL header to > >the mail client when the uidl command was run. > > > >My questions are: > > > >If qpopper sees a X-UIDL header already in the message spool for a particular > >message will it recompute a different UIDL or use the one in the header? > > It uses the X-UIDL header in the spool, as long as the value seems reasonable. > > > > >Does the disable-status option affect the previous question? > > No. > > > > >How does qpopper compute UIDL? > > It generates an MD5 hash of most of the message headers. Some > headers are skipped. Also, and this is very important here, when > disable-status is not set (the default) it includes a random > component, to make sure no two messages have the same UID. When > disable-status is set, there is no random component (since UIDs need > to always be the same for any message), and therefore there is a > chance that two different messages could end up with the same UID. > Well since these messages all had X-UIDL headers in the mail spool one can assume that the message was delivered that wasy because with the disable-status option compiled in it wouldn't save that header. I think that sort of answers my question. Thanks, Ted Hatfield
