The strange thing is that the problem only shows up when 2 or more
messages are in the POP3 box And only the first 2 messages are sent and
archived, the rest is ignored

One thing that may help is to explicitly destroy the list settings
and list archive objects in the archive() subroutine of
dada_bridge pl - ala place:

 undef $ls;
 undef $la;

At the end of the archive() subroutine

destroying these objects should unlock the lock file for you; so the
next time you archive a message, a new object has to be created They
should be removed automatically, because they're out of scope after
the subroutine is done - but, perhaps not?

The smarter idea would be to cache these objects for later use - I
think I'm doing this in the bounce handler but that's more of a
tuning thing - both ideas may help in fixing this problem

Although I still do not know what the relation is between $pop and
system calls, I am pretty sure now that when the archivesdb lock file
problem is solved, the undeleted POP3 messages problem will not show up
anymore also

Well, messages on the pop server will not get removed when you call
$pop->delete() - the message only gets flagged to be removed when
you disconnect If the pop server does not disconnect correctly,
these flags will not be honored, because they're lost One way to
disconnect incorrectly would be to have the program die() on you

One safety net we could make is to catch the signal for the program
to die, and tell dada_bridge pl to disconnect from the pop server
properly - I don't think there's a really good way to do this - all
the literature I've read says to only print something out when
catching the die'ing signal, but it's worth a shot, I guess

Doing some research on this, here's what I'm talking about:

 http://www
unix
org
ua/orelly/perl/cookbook/ch16_16
htm

here's a little bit on how to make Exceptions in Perl:

 http://mailman
anu
edu
au/pipermail/perl
sig/2005-April/000006
html

May be a good idea, in this instance

Justin Simoni