Hi Randall (and all),
I uninstalled qpopper 4.0.5 and installed qpopper 4.0.8 today. It's working
fine. You asked me to post to the list to let you (and others) know if it
solved my problem. To refresh everyone's memory, I'll quote what I
originally posted as being my problem:
I had a mail server crash on Monday of this week so I hurriedly set up
another FreeBSD box I have to accept email in place of the crashed
machine.
The new box already had Sendmail installed but didn't have a POP3 server
so
I installed Qpopper 4.0.5 from the ports.
In the past, I've had occasional problems with pop lock files that, for
one
reason or another, didn't want to go away. And of course, when a customer
attempts to pop mail while a pop lock is present for his mailbox the
customer gets a "password error" on his end and on our end I get logged
the
message "Is another session active?". This is just the way it's always
worked and it's my understanding that this is how it's supposed to work
:-)
That's why I'm perplexed at what I see on this new box I set up on Monday.
Pop locks are staying around, but they are NOT preventing anyone from
being
able to pop their mail. There are some pop locks on this machine now
from
Monday, yet these customers are happily popping their mail today.
Why is this? I must of overlooked something perhaps in my haste to get
this
setup, but it's been awhile since I've set up a new Qpopper and I don't
know
what I've overlooked.
I've now found that what I thought of as a "problem" is not a problem at all
but a feature. And a quite useful one at that. The lock files I was seeing
(.username.pop) files at the top of /var/mail must be the temp drop files
(as you Randall suggested) and not lock files at all which is what I thought
they were. That's why customers with a .username.pop file were still able to
pop mail despite the presence of these files. Which brings up a question:
what does a pop lock look like as opposed to a temp drop? Let me show an
example (which is where my confusion stems from):
I have another mail server running Sendmail/Qpopper on Red Hat linux. When I
set this one up I did not pass --enable-keep-temp-drop as a configuration
option because I was unaware of this particular option. Right now a
customer is popping mail. If I do a ls -al on /var/mail, I see this while
the customer is popping:
-rw-rw---- 1 gwilson mail 0 Mar 3 15:57 gwilson
-rw-rw---- 1 gwilson mail 115869 Mar 3 15:57 .gwilson.pop
Are you saying that the .gwilson.pop file is a temp drop as opposed to a pop
lock? Lets suppose gwilson is using Outlook Express (as a vast majority of
my customers do). Lets also suppose that, for whatever reason, gwilson's pop
session was aborted prematurely. My experience over the past few years is
that in such a scenario the .gwilson.pop file is likely to hang around for
10 to 15 minutes and until this file goes away if gwilson attempts to pop
mail again on his end he gets what appears to him to be a password error, on
my end I get logged:
Mar 3 16:12:09 Raydeus-Dee popper[11648]: gwilson at 64.xx.xx.xx
(64.xx.xx.xx): -ERR [IN-USE] /var/mail/.gwilson.pop lock busy! Is another
session active? (11)
This happens whenever there exists a gwilson file (the mailbox) and a
.gwilson.pop file simultaneously. I have noticed the following in /var/mail
from time to time:
-rw------- 1 hostmast mail 683814 Mar 1 10:02 hostmaster
-rw------- 1 hostmast mail 16 Mar 3 15:57 hostmaster.lock
-rw-rw---- 1 hostmast mail 268934 Mar 3 15:58 .hostmaster.pop
I don't get to see this often because when someone first starts to pop mail
these three files exist together only very briefly, then there is just the
username and the .username.pop file until the pop3 session is over. So the
username.lock file is the pop lock whereas the .username.pop file is a temp
drop? And if I had used --enable-keep-temp-drop when I set up this qpopper
the .username.pop files would not go away but would persist as zero byte
files thus allowing me to see when this user last popped his mail? (Quite
useful, I had been using ls -lut to determine this which may or may not be a
very accurate way of doing it).
So if I see a .username.pop file that is something other than zero byte
size, that user is actively popping mail and if for whatever reason attempts
to pop it again while that file is there, there will be an error, but if a
.username.pop file of zero byte size is present the user can pop his mail
ok? My server logs this error as ERR [IN-USE] /var/mail/.gwilson.pop lock
busy! which is why I thought the .username.pop files were the pop locks.
Am I getting a correct understanding of how this all works now?
Thanks so much.
Lisa Casey
