[tpop3d-discuss]Outlook Clients - Mail not removed

[Matthew Trent]

On Monday 09 February 2004 03:34 pm, Matthew Trent wrote:
> On Monday 09 February 2004 09:00 am, Joseph wrote:
> > Has there been any resolution the email not being deleted by Outlook
> > clients?
> >
> > Thanks.
>
> An update on this issue:
>
> Our sister company in another state just reported that nearly everybody in
> the office (at least 5 people confirmed) are getting duplicate emails. This
> has happened since we moved them over to tpop3d several weeks ago. They are
> all using MS clients, mostly Outlook. It's interesting that ALL of them are
> experiencing the problem and they're also all in a different state.
> Probably, since this is a timing issue, the extra latency exacerbates the
> it. People on the same network as the mail server rarely experience the
> dups (although it does happen some times).
>
> As an experiment, I've asked them all to do Windows Update and Office
> Update and get all the fixes and service packs and stuff installed (which
> they are quite behind on). Since that'll be a long process, they'll do it
> at the end of the work day. I guess we'll see tomorrow if the service packs
> really fix it.

I have verified that the latest service packs/updates do NOT fix the problem 
in Outlook (and even if it did, that would still leave the Outlook Express 
users hanging...). I've also actually gotten some duplicate emails while 
using Kmail!

So I decided to try the hack mentioned a while ago for netloop.c:
-        if (r && !connection_isfrozen(c)) {
+        if (1) {
-            while (c->cstate == running && (p = connection_parsecommand(c))) 
{
+            while ((p = connection_parsecommand(c))) {

I haven't had a chance to gauge whether this helps, but I am seeing this in 
the logs:
Mar 24 15:40:41 mail2 tpop3d[11552]: quit: signal 11 post_fork = 1
Mar 24 15:40:41 mail2 tpop3d[26360]: net_loop: child process 11552 killed by 
signal 11 (shouldn't happen)

Apparently that change causes each fork of tpop3d to die when the connection 
is closed. It looks like it dies only after finishing everything important, 
and it seems to actually be working like that.

Even so, can anyone suggest a change that would allow it to exit gracefully?

Thanks.
-- 
Matt
Systems Administrator
Local Access Communications
360.330.5535