You can also use the stats feature of qpopper to log stuff like this to
the pop log:
popper[20355]: Stats: username 0 0 23 370462 x.x.x.x x.x.x.x
The stats will tell you a lot more:
messages retrieved
bytes retrieved
messages left
bytes left
See ./configure --help or the qpopper manual.
Ken
Pacific.Net
Lisa Casey wrote:
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
