The qpopper list archive ending on 16 Mar 2006
Topics covered in this issue include:
1. Re: getting poppassd on fedora 3 to work?
Tim Tyler <tyler at beloit dot edu>
Mon, 21 Nov 2005 09:58:54 -0600
2. qpopper and quotas
Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Mon, 21 Nov 2005 20:06:46 +0200
3. Re: getting poppassd on fedora 3 to work?
Mon, 21 Nov 2005 16:23:29 -0300
4. Re: getting poppassd on fedora 3 to work?
Clifton Royston <cliftonr at lava dot net>
Mon, 21 Nov 2005 11:05:52 -1000
5. Re: getting poppassd on fedora 3 to work?
Tim Tyler <tyler at beloit dot edu>
Mon, 21 Nov 2005 15:53:26 -0600
6. Re: getting poppassd on fedora 3 to work?
Mon, 21 Nov 2005 19:18:40 -0300
7. Re: getting poppassd on fedora 3 to work?
Daniel Senie <dts at senie dot com>
Mon, 21 Nov 2005 17:47:42 -0500
8. Re: getting poppassd on fedora 3 to work?
Tim Tyler <tyler at beloit dot edu>
Mon, 21 Nov 2005 16:25:51 -0600
9. Re: getting poppassd on fedora 3 to work?
Mon, 21 Nov 2005 19:44:22 -0300
10. Re: getting poppassd on fedora 3 to work?
Alan Brown <alanb at digistar dot com>
Tue, 22 Nov 2005 07:21:52 -0500 (EST)
11. Re: I/O error in SSL.
Randall Gellens <randy at qualcomm dot com>
Tue, 22 Nov 2005 18:14:51 -0800
12. SASL (was "Re: qpopper 4.0.8 + mysql")
Randall Gellens <randy at qualcomm dot com>
Tue, 22 Nov 2005 18:20:32 -0800
13. qpopper4.1a2 ?
Ken A <ka at pacific dot net>
Thu, 01 Dec 2005 09:06:41 -0800
14. Unable to process spool options file?
Ken A <ka at pacific dot net>
Thu, 01 Dec 2005 09:31:31 -0800
15. qpopper4.1a2: Error in popper/Makefile.in ?
Jens Schleusener <Jens dot Schleusener at t-systems-sfr dot com>
Tue, 6 Dec 2005 11:02:31 +0100 (NFT)
16. long running qpopper processes
Brian Parent <bparent at calvin dot ucsd dot edu>
Fri, 16 Dec 2005 12:48:53 -0800
17. Re: long running qpopper processes
Jerry K <qpopper at oryx dot cc>
Fri, 16 Dec 2005 17:05:01 -0600
18. [PATCH] statistics-read log number of read messages
Joe Maimon <jmaimon at ttec dot com>
Tue, 27 Dec 2005 10:09:19 -0500
19. Re: qpopper4.1a2 ?
Randall Gellens <randy at qualcomm dot com>
Wed, 28 Dec 2005 12:10:06 -0800
20. Weird pop lock problems
"Lisa Casey" <lisa at jellico dot net>
Wed, 8 Feb 2006 11:44:26 -0500
21. Re: Weird pop lock problems
Ken A <ka at pacific dot net>
Wed, 08 Feb 2006 10:38:55 -0800
22. Puzzling pop lock files
"Lisa Casey" <lisa at jellico dot net>
Wed, 1 Mar 2006 09:59:39 -0500
23. Re: Puzzling pop lock files
Randall Gellens <randy at qualcomm dot com>
Thu, 2 Mar 2006 14:30:53 -0800
24. Re: Puzzling pop lock files
Randall Gellens <randy at qualcomm dot com>
Thu, 2 Mar 2006 15:28:47 -0800
25. Re: Puzzling pop lock files
"Lisa Casey" <lisa at jellico dot net>
Fri, 3 Mar 2006 16:22:36 -0500
26. Re: Puzzling pop lock files
Ken A <ka at pacific dot net>
Fri, 03 Mar 2006 16:28:02 -0800
27. Re: Puzzling pop lock files
Randall Gellens <randy at qualcomm dot com>
Fri, 3 Mar 2006 16:48:35 -0800
28. Qpopper 4.0.9a1 available -- fixes crash
Randall Gellens <randy at qualcomm dot com>
Tue, 7 Mar 2006 18:06:00 -0800
29. Large spool mboxes => slow?
Hugh Sasse <hgs at dmu dot ac dot uk>
Thu, 9 Mar 2006 11:52:56 +0000 (WET)
30. Re: Large spool mboxes => slow?
Gregory Hicks <ghicks at cadence dot com>
Thu, 9 Mar 2006 05:40:27 -0800 (PST)
31. Re: Large spool mboxes => slow?
Hugh Sasse <hgs at dmu dot ac dot uk>
Thu, 9 Mar 2006 15:21:27 +0000 (WET)
32. Re: Large spool mboxes => slow?
Gregory Hicks <ghicks at cadence dot com>
Thu, 9 Mar 2006 08:19:56 -0800 (PST)
33. Re: Large spool mboxes => slow?
David Champion <dgc at uchicago dot edu>
Thu, 9 Mar 2006 10:27:38 -0600
34. Re: Large spool mboxes => slow?
Hugh Sasse <hgs at dmu dot ac dot uk>
Thu, 9 Mar 2006 17:03:27 +0000 (WET)
35. Re: Large spool mboxes => slow?
Hugh Sasse <hgs at dmu dot ac dot uk>
Thu, 9 Mar 2006 17:16:28 +0000 (WET)
36. Re: Large spool mboxes => slow?
Kelson <kelson at speed dot net>
Thu, 09 Mar 2006 10:59:00 -0800
37. Re: Large spool mboxes => slow?
Hugh Sasse <hgs at dmu dot ac dot uk>
Thu, 9 Mar 2006 19:30:07 +0000 (WET)
38. Re: Large spool mboxes => slow?
Joe Maimon <jmaimon at ttec dot com>
Thu, 09 Mar 2006 14:57:13 -0500
39. Re: Large spool mboxes => slow?
Randall Gellens <randy at qualcomm dot com>
Thu, 9 Mar 2006 12:25:05 -0800
40. Re: Large spool mboxes => slow?
Hugh Sasse <hgs at dmu dot ac dot uk>
Thu, 9 Mar 2006 20:36:22 +0000 (WET)
41. Re: Large spool mboxes => slow?
Alan Brown <alanb at digistar dot com>
Thu, 9 Mar 2006 18:35:06 -0500 (EST)
42. Re: Large spool mboxes => slow?
Randall Gellens <randy at qualcomm dot com>
Thu, 9 Mar 2006 16:51:37 -0800
43. Re: Large spool mboxes => slow?
Hugh Sasse <hgs at dmu dot ac dot uk>
Fri, 10 Mar 2006 10:14:58 +0000 (WET)
44. Re: Large spool mboxes => slow?
Joe Maimon <jmaimon at ttec dot com>
Fri, 10 Mar 2006 14:49:42 -0500
45. Re: Large spool mboxes => slow?
Randall Gellens <randy at qualcomm dot com>
Thu, 9 Mar 2006 12:13:20 -0800
46. Lock file permission problem
Lee Terrell <leet at directcon dot net>
Thu, 09 Mar 2006 09:49:54 -0800
47. Re: Large spool mboxes => slow?
Hugh Sasse <hgs at dmu dot ac dot uk>
Fri, 10 Mar 2006 11:38:32 +0000 (WET)
48. Re: Large spool mboxes => slow?
Kelson <kelson at speed dot net>
Fri, 10 Mar 2006 09:17:31 -0800
49. Re: Large spool mboxes => slow?
Jesus Cea <jcea at argo dot es>
Fri, 10 Mar 2006 21:02:12 +0100
50. Re: Large spool mboxes => slow?
Alan Brown <alanb at digistar dot com>
Sat, 11 Mar 2006 09:22:48 -0500 (EST)
Date: Mon, 21 Nov 2005 09:58:54 -0600
From: Tim Tyler <tyler at beloit dot edu>
Subject: Re: getting poppassd on fedora 3 to work?
--=====================_3240421==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Dan, others,
Our web users connect via SSL so the password changes are tunneled in SSL
any ways. Popper works fine. We just can't get poppassd to work. I get
an error with it being busy. I am not sure I guessed at how to properly
set up the xinetd.d file for poppassd. So my first two questions are:
1. Is special_auth required for Fedora?
2. Is the following accurate for a poppassd entry in xinetd.d?
service poppassd
{
port = 106
socket_type = stream
protocol = tcp
user = root
server = /usr/local/bin/poppassd
server_args = poppassd
wait = no
only_from = 127.0.0.1
instances = 4
disable = no
}
Tim
At 03:09 PM 11/18/2005, Daniel Senie wrote:
>Because the POP Password service (poppassd) does not use encryption, I
>generally recommend against its use. Use a web-based password change
>mechanism instead.
>
>As to your issues with special_auth, does popper itself interact
>successfully with user account authentication, or is it just poppassd that
>you have trouble with?
>
>At 03:55 PM 11/18/2005, you wrote:
>> Qualcomm popper and poppassd experts,
>> I recently downloaded 4.08 of qpopper to install on a Fedora core 3
>> server. I compiled qpopper along with poppassd using the special_auth
>> parameter. Correct me if I shouldn't include specail _auth. Popper
>> appears to work just fine. However, get the following error from our
>> webmail pop client from poppassd:
>>
>> Failed to change Password {400 Server busy -- try again later.}
>>
>> I know that it sees the service, but the service is not responding
>> appropriately.
>>
>> I put these entries in /etc/xinetd.d/poppassd
>>
>>service poppassd
>>{
>>port = 106
>>socket_type = stream
>>protocol = tcp
>>user = root
>>server = /usr/local/bin/poppassd
>>server_args = poppassd
>>wait = no
>>only_from = 127.0.0.1
>>instances = 4
>>disable = no
>>}
>> Is the above entry correct? Am I missing something? Can anyone
>> suggest what I might be doing wrong to get the busy error above?
>>
>>
>>Tim Tyler
>>Network Engineer - Beloit College
>>tyler@beloit.edu
>
>Tim Tyler
>Network Engineer - Beloit College
>tyler@beloit.edu
--=====================_3240421==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
Dan, others,<br>
Our web users connect via SSL so the password changes are tunneled
in SSL any ways. Popper works fine. We just can't get
poppassd to work. I get an error with it being busy. I
am not sure I guessed at how to properly set up the xinetd.d file for
poppassd. So my first two questions are:<br><br>
1. Is special_auth required for Fedora?<br><br>
2. Is the following accurate for a poppassd entry in xinetd.d?<br><br>
service poppassd<br>
{<br>
port = 106<br>
socket_type = stream<br>
protocol = tcp<br>
user = root<br>
server = /usr/local/bin/poppassd<br>
server_args = poppassd<br>
wait = no<br>
only_from = 127.0.0.1<br>
instances = 4<br>
disable = no<br>
}<br><br>
Tim<br><br>
At 03:09 PM 11/18/2005, Daniel Senie wrote:<br>
<blockquote type=cite class=cite cite="">Because the POP Password service
(poppassd) does not use encryption, I generally recommend against its
use. Use a web-based password change mechanism instead.<br><br>
As to your issues with special_auth, does popper itself interact
successfully with user account authentication, or is it just poppassd
that you have trouble with?<br><br>
At 03:55 PM 11/18/2005, you wrote:<br>
<blockquote type=cite class=cite cite=""> Qualcomm popper and
poppassd experts,<br>
I recently downloaded 4.08 of qpopper to install on a
Fedora core 3 server. I compiled qpopper along with poppassd using
the special_auth parameter. Correct me if I shouldn't include
specail _auth. Popper appears to work just fine. However, get
the following error from our webmail pop client from poppassd:
<br><br>
<div align="center"> Failed to change Password {400 Server busy --
try again later.}<br><br>
</div>
I know that it sees the service, but the service is not responding
appropriately.<br><br>
I put these entries in /etc/xinetd.d/poppassd<br><br>
service poppassd<br>
{<br>
port = 106<br>
socket_type = stream<br>
protocol = tcp<br>
user = root<br>
server = /usr/local/bin/poppassd<br>
server_args = poppassd<br>
wait = no<br>
only_from = 127.0.0.1<br>
instances = 4<br>
disable = no<br>
}<br>
Is the above entry correct? Am I missing
something? Can anyone suggest what I might be doing wrong to get
the busy error above?<br><br>
<br>
Tim Tyler<br>
Network Engineer - Beloit College<br>
tyler@beloit.edu </blockquote>
<x-sigsep><p></x-sigsep>
Tim Tyler<br>
Network Engineer - Beloit College<br>
tyler@beloit.edu</body>
</html>
--=====================_3240421==.ALT--
Date: Mon, 21 Nov 2005 20:06:46 +0200
From: Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Subject: qpopper and quotas
I have updated our qpopper patches which modify the locking mechanism to make
it work with hard filesystem quotas. The new files for 4.08 are here:
http://www.softlab.ece.ntua.gr/~sivann/popper-ntua.tar.gz
The idea is to maintain the spool lock while mail is on the temp file, to
prevent new mail to be appended to the truncated spool, because the sum of the
spool and the temp spool can exceed the quota limit. New mail to be delivered
should wait at the mailqueue for the spool to be unlocked. (The spool gets
locked while it is being copied to the temp, so the mda has to cope with
locked spools anyway.).
Developers, why not implementing this as an option.
--
Spiros Ioannou
Image, Video and Multimedia Systems Laboratory
National Technical University of Athens
School of Electrical & Computer Engineering
Computer Science Division
Tel: +30-2107722491, +30-6973903808
Date: Mon, 21 Nov 2005 16:23:29 -0300
From:
Subject: Re: getting poppassd on fedora 3 to work?
Hi Tim,
>
> service poppassd
> {
> port = 106
> socket_type = stream
> protocol = tcp
> user = root
> server = /usr/local/bin/poppassd
> server_args = poppassd
> wait = no
> only_from = 127.0.0.1
^^^^^^^^^
> instances = 4
> disable = no
> }
>
> Tim
Your problem is there, most likely. What this line tells xinetd is to
only allow connections from the local host. You should either comment
(or remove) this line out or fix the liste to address to the
address(s) of your internal or DMZ interface(s).
God bless you,
Víctor Rafael Rivarola
--
FANÁTICO
"Por cuanto eres tibio, y no frío ni caliente, te vomitaré de mi boca."
Apocalipsis 3:16
LOCO
"Porque la Palabra de la Cruz es locura para los que se pierden; pero a
los que se salvan, esto es, a nosotros, es poder de Dios."
1 Corintios 1:18
Date: Mon, 21 Nov 2005 11:05:52 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: getting poppassd on fedora 3 to work?
On Mon, Nov 21, 2005 at 04:23:29PM -0300, Victor Rafael Rivarola Soerensen (FANATICO y LOCO por Cristo) wrote:
> Hi Tim,
> > service poppassd
> > {
> > port = 106
> > socket_type = stream
> > protocol = tcp
> > user = root
> > server = /usr/local/bin/poppassd
> > server_args = poppassd
> > wait = no
> > only_from = 127.0.0.1
> ^^^^^^^^^
> > instances = 4
> > disable = no
> > }
> >
> > Tim
>
> Your problem is there, most likely. What this line tells xinetd is to
> only allow connections from the local host. You should either comment
> (or remove) this line out or fix the liste to address to the
> address(s) of your internal or DMZ interface(s).
No, he pointed out this is intentional, because it is only supposed to
allow connections from the webmail software running on the same box.
If there *is* any problem relating to this, it might be that the
webmail software is connecting to a public IP address instead of
localhost.
-- Clifton
--
Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net
President - I and I Computing * http://www.iandicomputing.com/
Custom programming, network design, systems and network consulting services
Date: Mon, 21 Nov 2005 15:53:26 -0600
From: Tim Tyler <tyler at beloit dot edu>
Subject: Re: getting poppassd on fedora 3 to work?
poppassd experts,
I can connect by telneting to port 106 from the local host. However,
the error I get when using this method is "400 Server busy -- try again
later". So I am now thinking that there is some issue with it reading
passwords from Fedora 3. I believe Fedora uses shadow passwords so I
compiled popppassd with the special_auth option. Regardless, I can't
change a password. I might end up moving to a php script if I can't get
this to work soon. Any suggestions are very much welcome!
Tim
At 03:05 PM 11/21/2005, Clifton Royston wrote:
>On Mon, Nov 21, 2005 at 04:23:29PM -0300, Victor Rafael Rivarola Soerensen
>(FANATICO y LOCO por Cristo) wrote:
> > Hi Tim,
> > > service poppassd
> > > {
> > > port = 106
> > > socket_type = stream
> > > protocol = tcp
> > > user = root
> > > server = /usr/local/bin/poppassd
> > > server_args = poppassd
> > > wait = no
> > > only_from = 127.0.0.1
> > ^^^^^^^^^
> > > instances = 4
> > > disable = no
> > > }
> > >
> > > Tim
> >
> > Your problem is there, most likely. What this line tells xinetd is to
> > only allow connections from the local host. You should either comment
> > (or remove) this line out or fix the liste to address to the
> > address(s) of your internal or DMZ interface(s).
>
> No, he pointed out this is intentional, because it is only supposed to
>allow connections from the webmail software running on the same box.
>
> If there *is* any problem relating to this, it might be that the
>webmail software is connecting to a public IP address instead of
>localhost.
>
> -- Clifton
>
>
>--
> Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net
> President - I and I Computing * http://www.iandicomputing.com/
> Custom programming, network design, systems and network consulting services
Tim Tyler
Network Engineer - Beloit College
tyler@beloit.edu
Date: Mon, 21 Nov 2005 19:18:40 -0300
From:
Subject: Re: getting poppassd on fedora 3 to work?
2005/11/21, Clifton Royston <cliftonr@lava.net>:
> On Mon, Nov 21, 2005 at 04:23:29PM -0300, Victor Rafael Rivarola Soerense
n (FANATICO y LOCO por Cristo) wrote:
> > Hi Tim,
> > > service poppassd
> > > {
> > > port = 106
> > > socket_type = stream
> > > protocol = tcp
> > > user = root
> > > server = /usr/local/bin/poppassd
> > > server_args = poppassd
> > > wait = no
> > > only_from = 127.0.0.1
> > ^^^^^^^^^
> > > instances = 4
> > > disable = no
> > > }
> > >
> > > Tim
> >
> > Your problem is there, most likely. What this line tells xinetd is to
> > only allow connections from the local host. You should either comment
> > (or remove) this line out or fix the liste to address to the
> > address(s) of your internal or DMZ interface(s).
>
> No, he pointed out this is intentional, because it is only supposed to
> allow connections from the webmail software running on the same box.
Tim, are your users only connneecting through webmail? The way I
understood you, they where able to connect by webmail and not pops,
hence the problem you where asking aboout. If I read you wronng, I am
sorry.
>
> If there *is* any problem relating to this, it might be that the
> webmail software is connecting to a public IP address instead of
> localhost.
>
> -- Clifton
Uhhmm...yes, this could also be the problem I had not thought about.
God bless you all,
Víctor Rafael Rivarola
--
FANÁTICO
"Por cuanto eres tibio, y no frío ni caliente, te vomitaré de mi boca."
Apocalipsis 3:16
LOCO
"Porque la Palabra de la Cruz es locura para los que se pierden; pero a
los que se salvan, esto es, a nosotros, es poder de Dios."
1 Corintios 1:18
Date: Mon, 21 Nov 2005 17:47:42 -0500
From: Daniel Senie <dts at senie dot com>
Subject: Re: getting poppassd on fedora 3 to work?
At 04:53 PM 11/21/2005, Tim Tyler wrote:
>poppassd experts,
> I can connect by telneting to port 106 from the local
> host. However, the error I get when using this method is "400
> Server busy -- try again later". So I am now thinking that there
> is some issue with it reading passwords from Fedora 3. I believe
> Fedora uses shadow passwords so I compiled popppassd with the
> special_auth option. Regardless, I can't change a password. I
> might end up moving to a php script if I can't get this to work
> soon. Any suggestions are very much welcome!
If you need a web-based password changing capability for your users,
take a look at this one:
http://www.unicom.com/sw/web-chpass/
We use that for our users, and it works well.
If you're not using POPPASSD from Eudora or other clients anyway,
then it's probably not worth messing with.
Dan
> Tim
>
>At 03:05 PM 11/21/2005, Clifton Royston wrote:
>>On Mon, Nov 21, 2005 at 04:23:29PM -0300, Victor Rafael Rivarola
>>Soerensen (FANATICO y LOCO por Cristo) wrote:
>> > Hi Tim,
>> > > service poppassd
>> > > {
>> > > port = 106
>> > > socket_type = stream
>> > > protocol = tcp
>> > > user = root
>> > > server = /usr/local/bin/poppassd
>> > > server_args = poppassd
>> > > wait = no
>> > > only_from = 127.0.0.1
>> > ^^^^^^^^^
>> > > instances = 4
>> > > disable = no
>> > > }
>> > >
>> > > Tim
>> >
>> > Your problem is there, most likely. What this line tells xinetd is to
>> > only allow connections from the local host. You should either comment
>> > (or remove) this line out or fix the liste to address to the
>> > address(s) of your internal or DMZ interface(s).
>>
>> No, he pointed out this is intentional, because it is only supposed to
>>allow connections from the webmail software running on the same box.
>>
>> If there *is* any problem relating to this, it might be that the
>>webmail software is connecting to a public IP address instead of
>>localhost.
>>
>> -- Clifton
>>
>>
>>--
>> Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net
>> President - I and I Computing * http://www.iandicomputing.com/
>> Custom programming, network design, systems and network consulting services
>
>Tim Tyler
>Network Engineer - Beloit College
>tyler@beloit.edu
Date: Mon, 21 Nov 2005 16:25:51 -0600
From: Tim Tyler <tyler at beloit dot edu>
Subject: Re: getting poppassd on fedora 3 to work?
Victor,
Well for now, I am just trying to get my web users working. I may expand
to allow other clients such as Eudora, Outlook to work later. But I can't
even get local connections to work. So I don't think its a host.allow
issue. I actually have no idea what "busy" means. Its peculiar, but I
think its a Fedora compatibility issue that is somehow being over looked.
Tim
At 04:18 PM 11/21/2005, Victor Rafael Rivarola Soerensen (FANATICO y LOCO
por Cristo) wrote:
>2005/11/21, Clifton Royston <cliftonr@lava.net>:
> > On Mon, Nov 21, 2005 at 04:23:29PM -0300, Victor Rafael Rivarola
> Soerensen (FANATICO y LOCO por Cristo) wrote:
> > > Hi Tim,
> > > > service poppassd
> > > > {
> > > > port = 106
> > > > socket_type = stream
> > > > protocol = tcp
> > > > user = root
> > > > server = /usr/local/bin/poppassd
> > > > server_args = poppassd
> > > > wait = no
> > > > only_from = 127.0.0.1
> > > ^^^^^^^^^
> > > > instances = 4
> > > > disable = no
> > > > }
> > > >
> > > > Tim
> > >
> > > Your problem is there, most likely. What this line tells xinetd is to
> > > only allow connections from the local host. You should either comment
> > > (or remove) this line out or fix the liste to address to the
> > > address(s) of your internal or DMZ interface(s).
> >
> > No, he pointed out this is intentional, because it is only supposed to
> > allow connections from the webmail software running on the same box.
>
>Tim, are your users only connneecting through webmail? The way I
>understood you, they where able to connect by webmail and not pops,
>hence the problem you where asking aboout. If I read you wronng, I am
>sorry.
>
> >
> > If there *is* any problem relating to this, it might be that the
> > webmail software is connecting to a public IP address instead of
> > localhost.
> >
> > -- Clifton
>
>Uhhmm...yes, this could also be the problem I had not thought about.
>
>God bless you all,
>
>Víctor Rafael Rivarola
>
>--
>FANÁTICO
>"Por cuanto eres tibio, y no frío ni caliente, te vomitaré de mi boca."
>Apocalipsis 3:16
>
>LOCO
>"Porque la Palabra de la Cruz es locura para los que se pierden; pero a
>los que se salvan, esto es, a nosotros, es poder de Dios."
>1 Corintios 1:18
Tim Tyler
Network Engineer - Beloit College
tyler@beloit.edu
Date: Mon, 21 Nov 2005 19:44:22 -0300
From:
Subject: Re: getting poppassd on fedora 3 to work?
I see. Sorry.
You could change the listening port to something else, and then write
up a proxy for you that would record everything that goes by beefore
silently redirecting to the new port.
Your friends are telnet and script.
This sould allow for a record of the pop3 session which you could
latter post to this list.
By the way, try it with pop3 first, then pop3s. That last s is an
extra complexity layer which you want to avoid at first. One it is
working without encryption, it is time to add encryption.
Sincerely,
Víctor Rafael Rivarola
2005/11/21, Tim Tyler <tyler@beloit.edu>:
> Victor,
> Well for now, I am just trying to get my web users working. I may expan
d
> to allow other clients such as Eudora, Outlook to work later. But I can'
t
> even get local connections to work. So I don't think its a host.allow
> issue. I actually have no idea what "busy" means. Its peculiar, but I
> think its a Fedora compatibility issue that is somehow being over looked.
> Tim
>
> At 04:18 PM 11/21/2005, Victor Rafael Rivarola Soerensen (FANATICO y LOCO
> por Cristo) wrote:
> >2005/11/21, Clifton Royston <cliftonr@lava.net>:
> > > On Mon, Nov 21, 2005 at 04:23:29PM -0300, Victor Rafael Rivarola
> > Soerensen (FANATICO y LOCO por Cristo) wrote:
> > > > Hi Tim,
> > > > > service poppassd
> > > > > {
> > > > > port = 106
> > > > > socket_type = stream
> > > > > protocol = tcp
> > > > > user = root
> > > > > server = /usr/local/bin/poppassd
> > > > > server_args = poppassd
> > > > > wait = no
> > > > > only_from = 127.0.0.1
> > > > ^^^^^^^^^
> > > > > instances = 4
> > > > > disable = no
> > > > > }
> > > > >
> > > > > Tim
> > > >
> > > > Your problem is there, most likely. What this line tells xinetd is
to
> > > > only allow connections from the local host. You should either comme
nt
> > > > (or remove) this line out or fix the liste to address to the
> > > > address(s) of your internal or DMZ interface(s).
> > >
> > > No, he pointed out this is intentional, because it is only supposed
to
> > > allow connections from the webmail software running on the same box.
> >
> >Tim, are your users only connneecting through webmail? The way I
> >understood you, they where able to connect by webmail and not pops,
> >hence the problem you where asking aboout. If I read you wronng, I am
> >sorry.
> >
> > >
> > > If there *is* any problem relating to this, it might be that the
> > > webmail software is connecting to a public IP address instead of
> > > localhost.
> > >
> > > -- Clifton
> >
> >Uhhmm...yes, this could also be the problem I had not thought about.
> >
> >God bless you all,
> >
> >Víctor Rafael Rivarola
> >
> >--
> >FANÁTICO
> >"Por cuanto eres tibio, y no frío ni caliente, te vomitaré de mi boc
a."
> >Apocalipsis 3:16
> >
> >LOCO
> >"Porque la Palabra de la Cruz es locura para los que se pierden; pero a
> >los que se salvan, esto es, a nosotros, es poder de Dios."
> >1 Corintios 1:18
>
> Tim Tyler
> Network Engineer - Beloit College
> tyler@beloit.edu
>
>
>
--
FANÁTICO
"Por cuanto eres tibio, y no frío ni caliente, te vomitaré de mi boca."
Apocalipsis 3:16
LOCO
"Porque la Palabra de la Cruz es locura para los que se pierden; pero a
los que se salvan, esto es, a nosotros, es poder de Dios."
1 Corintios 1:18
Date: Tue, 22 Nov 2005 07:21:52 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: getting poppassd on fedora 3 to work?
On Mon, 21 Nov 2005, Clifton Royston wrote:
> If there *is* any problem relating to this, it might be that the
> webmail software is connecting to a public IP address instead of
> localhost.
poppassd can be tested in local mode simply by "telnet localhost"
I ran mine in this mode (local-only, SSL webserver access) for several
years with no problems.
Date: Tue, 22 Nov 2005 18:14:51 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: I/O error in SSL.
At 6:20 PM -0700 7/23/05, Roy wrote:
> My round tuit finally arrived so I am trying to build 4.0.8 with
> TLS/SSL support. I have it build successfully and tested it on my
> test system. So I moved it to the production system and just
> started the port 995 version. If SSL is enabled (-l 2) then I get
>
> I/O Error
> Error writing to client
>
> when attempting to download any messages. If I turn off SSL (no
> -l) then messages download successfully.
>
> Anyone have any ideas on the problem?
I didn't see any replies, so I thought I'd ask what happened with this?
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Wealth is not only money.
Wealth can be happiness in your sweetheart or your honey.
--(Fortune cookie)
Date: Tue, 22 Nov 2005 18:20:32 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: SASL (was "Re: qpopper 4.0.8 + mysql")
At 1:40 PM +0200 8/15/05, Martin Kellermann wrote:
> another question:
> is there a known way/patch to get qpopper 4.0.8 work with the
> cyrus-sasl2 lib?
Qpopper 4.1 has code to use Cyrus SASL.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Chance that an American cannot name a single right protected by the
First Amendment: 1 in 3. (Harper's Index)
Date: Thu, 01 Dec 2005 09:06:41 -0800
From: Ken A <ka at pacific dot net>
Subject: qpopper4.1a2 ?
Is there a list somewhere of what is new in qpopper4.1a2 ?
I looked at the Changes file.. nothing there.
Thanks,
Ken
Date: Thu, 01 Dec 2005 09:31:31 -0800
From: Ken A <ka at pacific dot net>
Subject: Unable to process spool options file?
What is the correct syntax for auto-delete in a per user
.user.qpopper-options file?
I've tried:
set auto-delete = true
set auto-delete = 1
set auto-delete
I keep getting an error: "Unable to process spool options file"
I'm using latest qpopper 4.0.8
Qpopper does have permission to read the file.
Thanks,
Ken A
Pacific.Net
Date: Tue, 6 Dec 2005 11:02:31 +0100 (NFT)
From: Jens Schleusener <Jens dot Schleusener at t-systems-sfr dot com>
Subject: qpopper4.1a2: Error in popper/Makefile.in ?
Hi,
I just tried to install qpopper4.1a2 under Linux SuSE 9.3 but doing a
"make install" I got an error
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: *** [install] Error 2
make[1]: Leaving directory `/usr/local/src/qpopper4.1a2/popper'
That error didn't occur installing qpopper4.0.8. Comparing the according
Makefile.in files I found a probably missing "fi" statement after line 241
of qpopper4.1a2/popper/Makefile.in.
Greetings
Jens
--
Dr. Jens Schleusener T-Systems Solutions for Research GmbH
Tel: +49 551 709-2493 Bunsenstr.10
Fax: +49 551 709-2169 D-37073 Goettingen
Jens.Schleusener@t-systems.com http://www.t-systems.com/
Date: Fri, 16 Dec 2005 12:48:53 -0800
From: Brian Parent <bparent at calvin dot ucsd dot edu>
Subject: long running qpopper processes
We're seeing some qpopper processes hanging around for months.
They're on Solaris 8 and 10 boxes.
truss shows they're waiting on a read of descriptor zero.
lsof shows descriptor zero is a tcp connection to a remote
system, which is usually not currently on the network.
I've verified that the kernel parameter tcp_keepalive_interval
is set to two hours, but apparently, the qpopper code isn't
using the SO_KEEPALIVE socket option.
A search through the source (qpopper4.0.5), doesn't turn up
any such strings.
A search of archives for this mailling list (qpopper@lists.pensive.org)
turned up some mention of similar issues, and mention of keepalives,
so I expect to find it in the source, but no luck.
The official FAQ
http://www.eudora.com/products/unsupported/qpopper/faq.html
wasn't fruitful either.
Any help appreciated.
Date: Fri, 16 Dec 2005 17:05:01 -0600
From: Jerry K <qpopper at oryx dot cc>
Subject: Re: long running qpopper processes
Brian,
I am running qpopper 4.0.5 on several Sparc Solaris 9 and 10 systems. I am not
currently seeing this issue. This is what I have used for my compile time options:
./configure --disable-apop \
--enable-specialauth \
--enable-uw-kludge \
--disable-check-pwmax \
--enable-log-login \
--without-pam \
--enable-temp-drop-dir=/var/tmp
I don't know if this will help you or not, but it will give you something to
compare with.
Jerry K
Brian Parent wrote:
> We're seeing some qpopper processes hanging around for months.
> They're on Solaris 8 and 10 boxes.
>
> truss shows they're waiting on a read of descriptor zero.
> lsof shows descriptor zero is a tcp connection to a remote
> system, which is usually not currently on the network.
>
> I've verified that the kernel parameter tcp_keepalive_interval
> is set to two hours, but apparently, the qpopper code isn't
> using the SO_KEEPALIVE socket option.
>
> A search through the source (qpopper4.0.5), doesn't turn up
> any such strings.
>
> A search of archives for this mailling list (qpopper@lists.pensive.org)
> turned up some mention of similar issues, and mention of keepalives,
> so I expect to find it in the source, but no luck.
>
> The official FAQ
>
> http://www.eudora.com/products/unsupported/qpopper/faq.html
>
> wasn't fruitful either.
>
> Any help appreciated.
Date: Tue, 27 Dec 2005 10:09:19 -0500
From: Joe Maimon <jmaimon at ttec dot com>
Subject: [PATCH] statistics-read log number of read messages
http://www.jmaimon.com/qpopper/patches/qpopper-stats-read.v1.408.patch
set statistics-read = true
causes qpopper to log messages like this:
Stats: YYYYYYYY 1 3232 1 3232 0 0 YYYYYYYYYYY.YYYYYYYY.covad.net YY.YYY.
46.186
Dec 27 10:06:20 nameserver2 popper[18926]: Stats: XXXXXXX 0 0 0 0 0 0
XXXXXXXXXXXXXXXX.nycmny.east.verizon.net XX.XX.
20.XX
With the numbers being (in order)
Number of messaged downloaded
Number of bytes downloaded
Number of messages deleted
Number of bytes deleted
Number of messages left
Number of bytes left
Date: Wed, 28 Dec 2005 12:10:06 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: qpopper4.1a2 ?
At 9:06 AM -0800 12/1/05, Ken A wrote:
> Is there a list somewhere of what is new in qpopper4.1a2 ?
> I looked at the Changes file.. nothing there.
Sorry about that.
Here's what's new in 4.1:
Support Cyrus SASL libraries
'--with-cyrus-sasl' added to ./configure.
'sasl-log-login', 'sasl-min-ssf', 'sasl-max-ssf',
'sasl-no-plaintext', 'sasl-no-active', 'sasl-no-dictionary',
'sasl-forward-secrecy', and 'sasl-no-anonymous' run-time options added.
Initial Cygwin support
Ability to execute arbitrary programs when users log in
'ext-postauth-cmd' run-time option added,
Initial Sieve support.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
History is strewn thick with evidence that truth is not hard to kill,
but a lie, well told, is immortal.
--Mark Twain
From: "Lisa Casey" <lisa at jellico dot net>
Subject: Weird pop lock problems
Date: Wed, 8 Feb 2006 11:44:26 -0500
Hi,
I'm using Qpopper 4.0.4 with Sendmail 8.12.6 and are using the mbox type of
mail delivery as opposed to maildir. And yes, I've been told about the
advantages of maildir over mbox.
We have one user (among several hundred mail accounts on this box) who is
having a persistent pop lock problem. Our usual advice: "Wait 20 minutes
before you try to pick up mail again" doesn't help in her case because her
pop lock just doesn't go away. When it happens, I've seen the pop lock hang
around for hours. I have had to resort to removing it so as to allow this
user to be able to pop her mail again.
Then a few days later she gets a persistent pop lock again.
I have verified (to the best of my ability) that she isn't continuing to pop
mail during this time (does continuing to attempt to pop mail while there is
a pop lock cause the pop lock to stick around longer? I've wondered about
that).
This particular user sometimes pops mail using Outlook Express, and
sometimes accesses her mailbox while she is at work using our Webmail
interface. But I don't see why that would cause a problem for this one user
as we have quite a few users who use Outlook Express at times and web mail
at times.
At present, her mailbox is completely weird (I've not seen a pop lock quite
like this before:
-rw-rw---- 1 beddy mail 219495 Feb 7 13:53 beddy
-rw------- 1 beddy mail 17 Feb 7 21:45 beddy.lock
-rw-rw---- 1 beddy mail 0 Feb 7 21:45 .beddy.pop
In the past, removing .beddy.pop has restored her ability to pop mail again
(for awhile) although, of course, she lost the mail that was tied up in that
file, but I sauspect now that her mailbox (the beddy file) has become
corrupted somehow, because if I now remove beddy.lock and .beddy.pop, these
files get recreated as soon as she attempts to pop mail again.
What might cause this? Any solutions?
Thanks,
Lisa Casey
Date: Wed, 08 Feb 2006 10:38:55 -0800
From: Ken A <ka at pacific dot net>
Subject: Re: Weird pop lock problems
Lisa,
We have found that killing the pop process for the user and THEN
removing the .pop and .lock files will allow qpopper to cleanup the temp
drop so that the user does not lose mail in the process.
The pop lock itself is probably just a result of a poor connection with
a reconnect & retry, etc. We see this frequently with dialup users in a
rural area on 50 yr old phone lines. If this is the case, usually
forcing the modem to V.34 does more good to fix the issue.
Ken A
Pacific.Net
Lisa Casey wrote:
> Hi,
>
> I'm using Qpopper 4.0.4 with Sendmail 8.12.6 and are using the mbox type
> of mail delivery as opposed to maildir. And yes, I've been told about
> the advantages of maildir over mbox.
>
> We have one user (among several hundred mail accounts on this box) who
> is having a persistent pop lock problem. Our usual advice: "Wait 20
> minutes before you try to pick up mail again" doesn't help in her case
> because her pop lock just doesn't go away. When it happens, I've seen
> the pop lock hang around for hours. I have had to resort to removing it
> so as to allow this user to be able to pop her mail again.
>
> Then a few days later she gets a persistent pop lock again.
>
> I have verified (to the best of my ability) that she isn't continuing to
> pop mail during this time (does continuing to attempt to pop mail while
> there is a pop lock cause the pop lock to stick around longer? I've
> wondered about that).
>
> This particular user sometimes pops mail using Outlook Express, and
> sometimes accesses her mailbox while she is at work using our Webmail
> interface. But I don't see why that would cause a problem for this one
> user as we have quite a few users who use Outlook Express at times and
> web mail at times.
>
> At present, her mailbox is completely weird (I've not seen a pop lock
> quite like this before:
>
> -rw-rw---- 1 beddy mail 219495 Feb 7 13:53 beddy
> -rw------- 1 beddy mail 17 Feb 7 21:45 beddy.lock
> -rw-rw---- 1 beddy mail 0 Feb 7 21:45 .beddy.pop
>
> In the past, removing .beddy.pop has restored her ability to pop mail
> again (for awhile) although, of course, she lost the mail that was tied
> up in that file, but I sauspect now that her mailbox (the beddy file)
> has become corrupted somehow, because if I now remove beddy.lock and
> .beddy.pop, these files get recreated as soon as she attempts to pop
> mail again.
>
> What might cause this? Any solutions?
>
> Thanks,
>
> Lisa Casey
>
>
>
>
From: "Lisa Casey" <lisa at jellico dot net>
Subject: Puzzling pop lock files
Date: Wed, 1 Mar 2006 09:59:39 -0500
Hi,
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.
I've been using Qpopper for several years now on various machines, I have
another mail server now with Qpopper 4.0.4 currently on it.
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.
Thanks,
Lisa Casey
Date: Thu, 2 Mar 2006 14:30:53 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Puzzling pop lock files
At 9:59 AM -0500 3/1/06, Lisa Casey wrote:
> Hi,
>
> 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.
>
> I've been using Qpopper for several years now on various machines, I have
> another mail server now with Qpopper 4.0.4 currently on it.
The current version is 4.0.8. Note that there was a fix in 4.0.6
that might resolve the problem with pop locks you were having:
Worked around problem on some systems causing SIGALRM to be masked,
leaving hung pop processes which should have timed out waiting
for a command from the client.
So I'd suggest upgrading to 4.0.8.
>
> 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
> :-)
No, it's not supposed to work that way. The Qpopper process serving
a user is supposed to notice when the user goes away, and clean up
afterwards, just as if the client entered QUIT. Anything else is a
problem and needs to be fixed.
>
> 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.
Are they lock files or temp drops?
There is an option you can set in ./configure and in your config file
to keep the temp drop files around, so you can see when a user last
checked mail. Perhaps this is set.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
> This is not to say that programming in, say, C++ takes a
> super human effort. What I mean is that it makes sense to
> develop tools that lessen the effort and increase the chance
> for success. C was a step in that direction....
First there was ALGOL... this was a big step in the right
direction, then CPL which was supposed to be practical ALGOL,
was a slight step backwards. BCPL which was Basic CPL was
another step backwards. Then came B, a big step backwards (it
took the Basic and dropped the CPL), and C was a small step
forwards over this. I think in all this C had by the time it
came around lost the plot.
The plot that it really found, which was more by accident than
intention was cross platform development, but that would have
been in ALGOL anyway. C did not prove that OSs could be
written in HLLs: that belonged already to ALGOL on the B5000
(~1964), and this OS survives today as still much better,
fully featured and robust than Unix or any other OS for that
matter.
As C.A.R Hoare said, Algol was a great improvement on most of
its successors.
--from Usenet post by Ian Joyner,
<http://www.mri.mq.edu.au/people/ian.html>
Date: Thu, 2 Mar 2006 15:28:47 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Puzzling pop lock files
At 9:59 AM -0500 3/1/06, Lisa Casey wrote:
> 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
I forgot to mention in my previous reply that Qpopper supports the
RESP-CODES and AUTH-RESP-CODE extensions, which have been around for
some years now. These extensions allow the client to unambiguously
determine which errors during or after authentication are in fact
user credential errors and which are not. Thus, the client can avoid
prompting for the password unless it is likely to help.
The fact that more clients don't support this is unfortunate,
especially given how little work it is likely to be for the client
vendor.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
In the long-run every Government is the exact symbol of its People,
with their wisdom and unwisdom. --Thomas Carlyle, _Past and Present_
From: "Lisa Casey" <lisa at jellico dot net>
Subject: Re: Puzzling pop lock files
Date: Fri, 3 Mar 2006 16:22:36 -0500
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
Date: Fri, 03 Mar 2006 16:28:02 -0800
From: Ken A <ka at pacific dot net>
Subject: Re: Puzzling pop lock files
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
>
>
Date: Fri, 3 Mar 2006 16:48:35 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Puzzling pop lock files
Hi Lisa,
You did a good job of summarizing the situation. Let me try and fill
in a few details, hopefully not making it too confusing.
There are two main kinds of locks that Qpopper uses (with some
potential variances within them):
To make sure that only one process at a time is modifying the mail
spool, a maillock is held only during the start and end of the
session. Qpopper obtains a maillock on the spool, copies the spool
to the temp drop, zeroes the spool, and releases the maillock. Local
delivery agents delay mail delivery while the maillock is held.
At the end of the session, Qpopper again obtains a maillock on the
spool, appends any mail that arrived during the session to the temp
drop, copies the temp drop to the spool, removes or zeroes the temp
drop, and releases the maillock.
Maillocks need to be interoperable between any program that accesses
the spool. It wouldn't be good if Qpopper used one method while the
local delivery agent used another. Not to mention all the other
programs that could be used to modify the spool. Qpopper by default
uses the ".lock" technique, which is compatible with maillock(3) as
implemented on many platforms.
While the session is in use, Qpopper holds an advisory lock on the
temp drop. The advisory lock is only needed to prevent multiple POP
sessions from altering the temp drop.
Maillocks typically are a file which is the name of the spool with
".lock" appended. The modtime of the file must be less than five
minutes, or the lock is considered stale and is discarded. There are
other possible lock mechanisms, and variations in how the lock is
created, that can be selected using obscure options in Qpopper.
Advisory locks use flock(2).
There are differences that depend on server mode and various obscure
options. Server mode is the main and most used option that affects
locking.
The key is that if the spool is maillocked, Qpopper waits a
reasonable amount of time. So under normal circumstances, if a user
checks mail at the exact moment that the local delivery agent (LDA)
is appending new mail, Qpopper waits until the LDA is done, and then
the POP sessions runs normally.
However, if Qpopper is unable to obtain the advisory lock on the temp
drop, it assumes the user has another session active and issues an
[IN-USE] error.
If the user gets an [IN-USE] error, the first thing to check is if
there is an active popper process for that user and if the user is
connected to it. If not, a ktrace(1), truss(1), or similar should be
done to see what it is doing and why it has not gone away. If the
user disconnects, Qpopper should get a signal and will then clean up
and terminate. You can allow the user access by killing the popper
process if it is running and removing the temp drop. Prepending the
temp drop to the spool first should prevent loss of mail. You
shouldn't ever have to do either, and there is always some risk of
corruption or loss if you do either.
In server mode the spool isn't copied to the temp drop at the start
of the session, but is still created and locked. At the end of the
session, any undeleted mail is copied to the temp drop.
The "Performance" section in the Administrator's Guide (the GUIDE.pdf
file) has more information on server mode.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
DEFINITION: Computer -- A device designed to speed and automate errors.
Date: Tue, 7 Mar 2006 18:06:00 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Qpopper 4.0.9a1 available -- fixes crash
Qpopper 4.0.9a1 is available at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta/>.
The full list of changes from one release to the next is on the FTP
site, at <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/Changes>.
Note that this release fixes a potential crash (from authenticated
users). All users of Qpopper are encouraged to upgrade to this
release.
Changes from 4.0.8 to 4.0.9b1:
-----------------------------
1. Fix crash if too many MDEF commands entered.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Every word is like an unnecessary stain on silence and nothingness.
--Beckett
Date: Thu, 9 Mar 2006 11:52:56 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Large spool mboxes => slow?
We have several people who POP their mail fairly frequently, but
they leave mail on the server. These large files seem to be the
main thing impacting the performance of the mail server. Qpopper
has no quota options as such, and some of the policy controls are
dependent on being sure how the client interacts with the serveer,
and I am not familiar with all the clients people use.
The OS (Solaris9) has quotas for disks, but with this being for mail
I'm presently unsure as to how that will impact on users.
So, I have reached the conclusion that the best thing I can do to
improve performance is to use the --enable-temp-drop-dir and point
it to a different partition from /var/spool/mail so that disk seeks
on both partitions may occur in parallel. Does this sound like a
useful thing to do? What if they are on different slices of the same
disk -- would that make things worse (further for the heads to seek)?
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t0d0s7 10525500 9733158 687087 94% /export/home
/dev/dsk/c0t0d0s3 4030014 373130 3616584 10% /var
Is there anything else I can do to qpopper that will help?
Getting users to change their behaviour is another story altogether,
of course :-)
Hugh
Date: Thu, 9 Mar 2006 05:40:27 -0800 (PST)
From: Gregory Hicks <ghicks at cadence dot com>
Subject: Re: Large spool mboxes => slow?
> Date: Thu, 9 Mar 2006 11:52:56 +0000 (WET)
> From: Hugh Sasse <hgs@dmu.ac.uk>
> To: Subscribers of Qpopper <qpopper@lists.pensive.org>
> X-DMU-MailScanner-Information: Please contact the ISP for more
information
> X-DMU-MailScanner: Found to be clean
> Subject: Large spool mboxes => slow?
>
> We have several people who POP their mail fairly frequently, but
> they leave mail on the server. These large files seem to be the
> main thing impacting the performance of the mail server. Qpopper
> has no quota options as such, and some of the policy controls are
> dependent on being sure how the client interacts with the serveer,
> and I am not familiar with all the clients people use.
> The OS (Solaris9) has quotas for disks, but with this being for mail
> I'm presently unsure as to how that will impact on users.
> So, I have reached the conclusion that the best thing I can do to
> improve performance is to use the --enable-temp-drop-dir and point
> it to a different partition from /var/spool/mail so that disk seeks
> on both partitions may occur in parallel. Does this sound like a
Point to different spindles on different I/O channels. You have
c0t0d0s6. Use c1t0d0s6 for the temp-drop-dir. At a minimum, point to
different spindles.
any POP3 daemon is going to have problem is the spool gets too large.
Also enable server mode. enable caching of temp dir
> useful thing to do? What if they are on different slices of the same
> disk -- would that make things worse (further for the heads to seek)?
This WILL make things worse for just the reason you've stated.
> Filesystem kbytes used avail capacity Mounted on
> /dev/dsk/c0t0d0s7 10525500 9733158 687087 94% /export/home
> /dev/dsk/c0t0d0s3 4030014 373130 3616584 10% /var
>
> Is there anything else I can do to qpopper that will help?
>
> Getting users to change their behaviour is another story altogether,
> of course :-)
>
> Hugh
>
>
---------------------------------------------------------------------
Gregory Hicks | Principal Systems Engineer
Cadence Design Systems | Direct: 408.576.3609
555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479
San Jose, CA 95134 | Internet: ghicks@cadence.com
I am perfectly capable of learning from my mistakes. I will surely
learn a great deal today.
"A democracy is a sheep and two wolves deciding on what to have for
lunch. Freedom is a well armed sheep contesting the results of the
decision." - Benjamin Franklin
"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton
Date: Thu, 9 Mar 2006 15:21:27 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Large spool mboxes => slow?
On Thu, 9 Mar 2006, Gregory Hicks wrote:
> [Hugh Sasse wrote]
> > So, I have reached the conclusion that the best thing I can do to
> > improve performance is to use the --enable-temp-drop-dir and point
> > it to a different partition from /var/spool/mail so that disk seeks
> > on both partitions may occur in parallel. Does this sound like a
>
> Point to different spindles on different I/O channels. You have
> c0t0d0s6. Use c1t0d0s6 for the temp-drop-dir. At a minimum, point to
> different spindles.
OK, I think we only have c0t0d0s* on that machine, so I'm a bit stuck.
I thought that might be the case.
>
> any POP3 daemon is going to have problem is the spool gets too large.
>
> Also enable server mode. enable caching of temp dir
Enabling server mode is not possible given some types of client (from
my reading of the docs). I don't know all the clients people use, so
I must err on the side of caution. Or is that paranoid in 2006?
Caching requires server mode....
>
> > useful thing to do? What if they are on different slices of the same
> > disk -- would that make things worse (further for the heads to seek)?
>
> This WILL make things worse for just the reason you've stated.
Thanks. I'm not au fait with disk internals, and thought that some
disks may have many heads, not just to read one cylinder at a time,
but possible several. Access time is a market (selective) pressure
on disks.
>
Thank you
Hugh
Date: Thu, 9 Mar 2006 08:19:56 -0800 (PST)
From: Gregory Hicks <ghicks at cadence dot com>
Subject: Re: Large spool mboxes => slow?
> Date: Thu, 9 Mar 2006 15:21:27 +0000 (WET)
> From: Hugh Sasse <hgs@dmu.ac.uk>
>
> On Thu, 9 Mar 2006, Gregory Hicks wrote:
>
> > [Hugh Sasse wrote]
> > > So, I have reached the conclusion that the best thing I can do to
> > > improve performance is to use the --enable-temp-drop-dir and point
> > > it to a different partition from /var/spool/mail so that disk seeks
> > > on both partitions may occur in parallel. Does this sound like a
> >
> > Point to different spindles on different I/O channels. You have
> > c0t0d0s6. Use c1t0d0s6 for the temp-drop-dir. At a minimum, point to
> > different spindles.
>
> OK, I think we only have c0t0d0s* on that machine, so I'm a bit stuck.
> I thought that might be the case.
Hugh:
If you have the Sun PCI SCSI board, that comes with two SCSI controllers...
In any case, try and get a second drive for the temp drop dir.
> >
> > any POP3 daemon is going to have problem is the spool gets too large.
> >
> > Also enable server mode. enable caching of temp dir
>
> Enabling server mode is not possible given some types of client (from
> my reading of the docs). I don't know all the clients people use, so
> I must err on the side of caution. Or is that paranoid in 2006?
I have to state that this is not the be-all, end-all of clients served,
but we have a quite diverse user population here. I have found - via
the school of hard knocks - that the only client that the current
qpopper does NOT support is the old Z-Mail. (I finally, 10 years after
the fact, got these users to upgrade to a more modern MUA... Z-Mail
went out of business in 1996...)
Now I have to preface this with a "YMMV", but all 'modern' pop3 clients
should work with the current qpopper - including Outlook (even though I
would not wish this client on my worst enemy...)
>
> Caching requires server mode....
> >
> > > useful thing to do? What if they are on different slices of the same
> > > disk -- would that make things worse (further for the heads to seek)?
> >
> > This WILL make things worse for just the reason you've stated.
>
> Thanks. I'm not au fait with disk internals, and thought that some
> disks may have many heads, not just to read one cylinder at a time,
> but possible several. Access time is a market (selective) pressure
> on disks.
Well, they DO have multiple heads, but only one arm that these heads
are mounted on. Best bet is to get multiple spindles.
Oh well...
Regards,
Gregory Hicks
> >
> Thank you
> Hugh
-------------------------------------------------------------------
I am perfectly capable of learning from my mistakes. I will surely
learn a great deal today.
"A democracy is a sheep and two wolves deciding on what to have for
lunch. Freedom is a well armed sheep contesting the results of the
decision." - Benjamin Franklin
"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton
Date: Thu, 9 Mar 2006 10:27:38 -0600
From: David Champion <dgc at uchicago dot edu>
Subject: Re: Large spool mboxes => slow?
* On 2006.03.09, in <054424037431630516322@lists.pensive.org>,
* "Hugh Sasse" <hgs@dmu.ac.uk> wrote:
>
> Getting users to change their behaviour is another story altogether,
> of course :-)
In addition to architectural considerations, you might want to try the
HAPPYMAIL patch I developed to address the problem of changing user
behavior.
http://home.uchicago.edu/~dgc/sw/qpopper/index.html
This page and the software are a bit out of date, as we no longer use
Qpopper in production, but I don't anticipate that adapting the patch to
current Qpopper code would be all that hard. I'd be glad to answer any
questions you have.
--
-D. dgc@uchicago.edu NSIT University of Chicago
Date: Thu, 9 Mar 2006 17:03:27 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Large spool mboxes => slow?
On Thu, 9 Mar 2006, Gregory Hicks wrote:
>
> > [Hugh Sasse wrote:]
> > OK, I think we only have c0t0d0s* on that machine, so I'm a bit stuck.
> > I thought that might be the case.
>
> Hugh:
>
> If you have the Sun PCI SCSI board, that comes with two SCSI controllers...
>
> In any case, try and get a second drive for the temp drop dir.
That's in progress, as far as possible...
>
> > Enabling server mode is not possible given some types of client (from
> > my reading of the docs). I don't know all the clients people use, so
> > I must err on the side of caution. Or is that paranoid in 2006?
>
> I have to state that this is not the be-all, end-all of clients served,
> but we have a quite diverse user population here. I have found - via
> the school of hard knocks - that the only client that the current
> qpopper does NOT support is the old Z-Mail. (I finally, 10 years after
> the fact, got these users to upgrade to a more modern MUA... Z-Mail
> went out of business in 1996...)
that's encouraging. I can't see anything logged about the MUA, but then
IIRC it's not part of the SMTP or POP protocols to declare it, so I wouldn't
see it logged.
>
> Now I have to preface this with a "YMMV", but all 'modern' pop3 clients
> should work with the current qpopper - including Outlook (even though I
> would not wish this client on my worst enemy...)
And if it blows up I tell them we need a new machine to handle the load
with server disabled. ;-)
>
[...]
> > Thanks. I'm not au fait with disk internals, and thought that some
> > disks may have many heads, not just to read one cylinder at a time,
> > but possible several. Access time is a market (selective) pressure
> > on disks.
>
> Well, they DO have multiple heads, but only one arm that these heads
> are mounted on. Best bet is to get multiple spindles.
Agreed. Thanks.
>
> Oh well...
>
> Regards,
> Gregory Hicks
>
Hugh
Date: Thu, 9 Mar 2006 17:16:28 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Large spool mboxes => slow?
On Thu, 9 Mar 2006, David Champion wrote:
> * On 2006.03.09, in <054424037431630516322@lists.pensive.org>,
> * "Hugh Sasse" <hgs@dmu.ac.uk> wrote:
> >
> > Getting users to change their behaviour is another story altogether,
> > of course :-)
>
> In addition to architectural considerations, you might want to try the
> HAPPYMAIL patch I developed to address the problem of changing user
> behavior.
>
> http://home.uchicago.edu/~dgc/sw/qpopper/index.html
To summarize: It rate limits the permitted popping attempts as a
linear function of mailbox size with an initial amount of space for
free, and a minimum time interval between requests.
>
> This page and the software are a bit out of date, as we no longer use
> Qpopper in production, but I don't anticipate that adapting the patch to
> current Qpopper code would be all that hard. I'd be glad to answer any
> questions you have.
Has anyone on the list done that already?
This looks like exactly what I need. Thank you.
Hugh
Date: Thu, 09 Mar 2006 10:59:00 -0800
From: Kelson <kelson at speed dot net>
Subject: Re: Large spool mboxes => slow?
Hugh Sasse wrote:
> Enabling server mode is not possible given some types of client (from
> my reading of the docs). I don't know all the clients people use, so
> I must err on the side of caution. Or is that paranoid in 2006?
I'm not aware of any problems with server mode and particular POP
clients. As I understand it, the only issue is whether any other
programs on the local system are altering the mailbox. If it's just
sendmail and qpopper, it should be OK. But it's entirely possible I've
missed something in the docs.
That said, you *can* enable server mode for specific users.
We have a similar problem where we couldn't turn server mode on for
everyone because some people use webmail and others use POP. However,
our "problem" users -- the ones with the biggest mailboxes who leave
mail on the server and check the most frequently -- only used POP.
We put the following in our qpopper.config:
set spool-options = true
Then we set up .username.qpopper-options files in our spool directory
containing:
set server-mode = true
The server used to have major I/O delays whenever one of these users
connected. After I set this up for just 5 accounts, the problem cleared
up completely.
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
Date: Thu, 9 Mar 2006 19:30:07 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Large spool mboxes => slow?
On Thu, 9 Mar 2006, Kelson wrote:
> Hugh Sasse wrote:
> > Enabling server mode is not possible given some types of client (from my
> > reading of the docs). I don't know all the clients people use, so I must
> > err on the side of caution. Or is that paranoid in 2006?
>
> I'm not aware of any problems with server mode and particular POP clients. As
> I understand it, the only issue is whether any other programs on the local
> system are altering the mailbox. If it's just sendmail and qpopper, it should
> be OK. But it's entirely possible I've missed something in the docs.
>
> That said, you *can* enable server mode for specific users.
I forgot about that. Thank you.
>
> We have a similar problem where we couldn't turn server mode on for everyone
> because some people use webmail and others use POP. However, our "problem"
We have some using webmail too.
> users -- the ones with the biggest mailboxes who leave mail on the server and
> check the most frequently -- only used POP.
>
> We put the following in our qpopper.config:
> set spool-options = true
Which seems to be the same as putting -U in the inetd.conf file...
> Then we set up .username.qpopper-options files in our spool directory
> containing:
> set server-mode = true
And can I add
set fast-update = true
on a per user basis?
Also, if I ./configure with --enable-cache-dir (which, I think I
don't need to write as --enable-cachedir=/var/mail because of the
default - is that right?) then will it only come into play for
users in server mode?
Just trying to figure out how all these things interact :-)
>
> The server used to have major I/O delays whenever one of these users
> connected. After I set this up for just 5 accounts, the problem cleared up
> completely.
that sounds like it would help considerably.
Thank you,
Hugh
Date: Thu, 09 Mar 2006 14:57:13 -0500
From: Joe Maimon <jmaimon at ttec dot com>
Subject: Re: Large spool mboxes => slow?
jmaimon.com/qpopper
Hugh Sasse wrote:
> On Thu, 9 Mar 2006, David Champion wrote:
>
>
>>* On 2006.03.09, in <054424037431630516322@lists.pensive.org>,
>>* "Hugh Sasse" <hgs@dmu.ac.uk> wrote:
>>
>>>Getting users to change their behaviour is another story altogether,
>>>of course :-)
>>
>>In addition to architectural considerations, you might want to try the
>>HAPPYMAIL patch I developed to address the problem of changing user
>>behavior.
>>
>>http://home.uchicago.edu/~dgc/sw/qpopper/index.html
>
>
> To summarize: It rate limits the permitted popping attempts as a
> linear function of mailbox size with an initial amount of space for
> free, and a minimum time interval between requests.
>
>>This page and the software are a bit out of date, as we no longer use
>>Qpopper in production, but I don't anticipate that adapting the patch to
>>current Qpopper code would be all that hard. I'd be glad to answer any
>>questions you have.
>
>
> Has anyone on the list done that already?
>
> This looks like exactly what I need. Thank you.
>
> Hugh
>
>
Date: Thu, 9 Mar 2006 12:25:05 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Large spool mboxes => slow?
At 5:16 PM +0000 3/9/06, Hugh Sasse wrote:
> > In addition to architectural considerations, you might want to try the
>> HAPPYMAIL patch I developed to address the problem of changing user
> > behavior.
The patch looks useful.
The web page says it uses the [AUTH] response code. A quick glance
at the patch shows it using either a [HAPPYMAIL] response code or no
response code.
Were these choices deliberate?
RFC 2449 and 3206 specify that [AUTH] indicates a problem
specifically with the user's credentials, and thus the client should
prompt for a new password.
The [LOGIN-DELAY] response code is specified to inform the client
that the login interval is too short. So, I'd suggest that the patch
include the [LOGIN-DELAY] response code in its error message instead
of [HAPPYMAIL] (which is non-standard) or no response code.
Also, I think it would be very friendly (and way cool) for the patch
to include the LOGIN-DELAY response to the CAPA command. In
authenticated state it can include the specific login-delay that will
be enforced for the user.
You can also set the LOGIN-DELAY response to CAPA using the
announce-login-delay option.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Coding is "90% finished" for half of the total coding time. Debugging
is "99% complete" most of the time. --Fred Brooks
Date: Thu, 9 Mar 2006 20:36:22 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Large spool mboxes => slow?
Off list, as it covers things in a later reply which you may not have
seen. By all means include the list in reply if you wish.
On Thu, 9 Mar 2006, Randall Gellens wrote:
> At 3:21 PM +0000 3/9/06, Hugh Sasse wrote:
>
> > Enabling server mode is not possible given some types of client (from
> > my reading of the docs). I don't know all the clients people use, so
> > I must err on the side of caution. Or is that paranoid in 2006?
> >
> > Caching requires server mode....
>
> Server mode (and caching) should be fine as long as people access their mail
> using any POP client.
>
> If you have any users who have shell accounts, and access their mail directly,
> disable server mode for those users. You can enable and disable server mode
> on a per-user and/or per-group basis.
Per-user would suit us most...
>
> You might also want to think about using the fast-io option, which renames the
> temp-drop to the spool instead of copying it. This only works if the temp
> drop and spool are on the same filesystem.
That's the default, isn't it? See my later mail because I ask how
these things interact. For example, I'm not clear if there are
commands which can be set globally but not on a per user basis,
whether global commands which depend on qpopper being in server mode
will just be switched off for those users not in server mode, or if
that would be anomalous, and would generate an error. Caching can
be set with a global option, but if only some users get server mode,
do the others feel like it is off?
>
> You might also want to think about setting update-status-headers to false.
> This is a trickier option, because some clients use the 'Status:' header, and
> some don't. It also trades I/O for CPU.
We have lots of users and I don't know who uses what when. They are
scattered over the site and it's hard to pin down, and I don't need the
flak of breaking anything... :-) I think I'd best leave that one alone
for now.
>
> See the Performance section of the GUIDE, and also the descriptions of the
> options.
Yes, I've read those, and believe I understand them in isolation.
>
> One thing I've been trying to find time to do is take caching to the next
> step, which is maintaining the cache when new mail has arrived since the last
> mail check. That would make a big difference when users leave mail on the
> server.
>
> There are scripts that have been posted in the past that let you cull old
> mail. Something else to think about.
It's the political consequences of inflicting that on senior academics
that is tricky :-).
Thank you,
Hugh
Date: Thu, 9 Mar 2006 18:35:06 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Large spool mboxes => slow?
On Thu, 9 Mar 2006, Kelson wrote:
> We have a similar problem where we couldn't turn server mode on for
> everyone because some people use webmail and others use POP.
What webmail client do you use?
AFAIK Squirrelmail (the most popular) uses IMAP, so as long as the
locking systems are compatible you can enable server mode.
> The server used to have major I/O delays whenever one of these users
> connected. After I set this up for just 5 accounts, the problem cleared
> up completely.
Making sure such users get _long_ delays when they leave huge amounts of
mail on the server gives them an incentive not to do it....
--
If a person, or organisation, starts to play on your fears
it may be that person or organisation that you should fear.
Date: Thu, 9 Mar 2006 16:51:37 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Large spool mboxes => slow?
At 7:30 PM +0000 3/9/06, Hugh Sasse wrote:
> On Thu, 9 Mar 2006, Kelson wrote:
>
> > We put the following in our qpopper.config:
>> set spool-options = true
>
> Which seems to be the same as putting -U in the inetd.conf file...
>
>> Then we set up .username.qpopper-options files in our spool directory
>> containing:
>> set server-mode = true
> And can I add
> set fast-update = true
> on a per user basis?
Yes, you can set fast-update on a per-user basis.
By the way, you can go either way: make the default to have these
options off, and turn them on for individual users, or, make the
default on, and turn them off for specific users. The latter might
be less work if it only affects a small number of users. You can
also put those users with shell access into their own group, and
disable server mode for users in that group. Then you can make
server mode and fast-update globally on.
>
> Also, if I ./configure with --enable-cache-dir (which, I think I
> don't need to write as --enable-cachedir=/var/mail because of the
> default - is that right?) then will it only come into play for
> users in server mode?
You don't need to use this unless you want to change the cache
directory or cache name (and even then you could use the
configuration file to change it at run time).
The default is to use cache files when in server mode.
By the way, you may want to change the cache directory in order to
put them on a different disk.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
I have made it a rule, whenever in my power, to avoid becoming the
draughtsman of papers to be reviewed by a public body.
--Benjamin Franklin
Date: Fri, 10 Mar 2006 10:14:58 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Large spool mboxes => slow?
On Thu, 9 Mar 2006, Alan Brown wrote:
> On Thu, 9 Mar 2006, Hugh Sasse wrote:
>
> > > Also enable server mode. enable caching of temp dir
> >
> > Enabling server mode is not possible given some types of client (from
> > my reading of the docs). I don't know all the clients people use, so
> > I must err on the side of caution. Or is that paranoid in 2006?
>
> Server mode is only risky under the following circumstrances:
>
> 1: Access is made via POP3 and local disk (or a non-compatible imap3 server)
> which use non-compatible locking methods.
>
> 2: Clients _simultaneously_ access using both methods.
>
> I used server mode for many years in a mixed environment with no
> problemss - by ensuring the lock mechanisms used were compatible.
>
> Even without that, it is highly unusual for users to use both pop3 and
> local disk access methods - those that do are usually technically savvy
> enough to understand the corruption risk and not use both methods
> simultaneously once it is explained to them.
OK, then I will certainly enable it for the large users. It's just
that usage patterns are a "known unknown", and I'm reluctant to get
caught by the "unknown unknowns" :-)
>
> > Thanks. I'm not au fait with disk internals, and thought that some
> > disks may have many heads
>
> They do (one per platter), but....
>
> >, not just to read one cylinder at a time,
>
> Only one head is ever active at one time with current commonly available
> commercial available disk techmology.
>
> The only way to achieve what you want is to use a suitable hardware
> controller capable of simultaneously addressing multiple drive busses
> (despite the other advantages of scsi, only one drive can be addressed
> at a time on any given physical scsi bus.
OK, I thought there might have been developments I'd not kept up with.
Thanks.
>
> Large scale (S)ATA or SASI raid controllers give better results most of
> the time in terms of overall bandwidth. Latencies cannot be redcued
> below seek+rotation times even with fancy controllers.
>
> For ultimate bandwidth andlatencies, suitable solid state arrays are the
> only way to go - but are extremely expensive.
To be nonvolatile and fast they would be. I'm trying to get another
disk for this system, but I doubt they'd stretch to RAID. Thank you
anyway, it's useful stuff to keep in mind.
>
Hugh
Date: Fri, 10 Mar 2006 14:49:42 -0500
From: Joe Maimon <jmaimon at ttec dot com>
Subject: Re: Large spool mboxes => slow?
Randall Gellens wrote:
>
> The patch looks useful.
I use it, along with my own modifications to it. I just posted some
hasty updates attempting to encompass your suggestionss below.
http://www.jmaimon.com/qpopper
http://www.jmaimon.com/qpopper/patches/happymail-sleep-seconds.pl6.408.patch
>
> The web page says it uses the [AUTH] response code. A quick glance at
> the patch shows it using either a [HAPPYMAIL] response code or no
> response code.
>
> Were these choices deliberate?
>
> RFC 2449 and 3206 specify that [AUTH] indicates a problem specifically
> with the user's credentials, and thus the client should prompt for a new
> password.
>
outlook express 6something prompts either way. This is the source of the
real pain.
> The [LOGIN-DELAY] response code is specified to inform the client that
> the login interval is too short. So, I'd suggest that the patch include
> the [LOGIN-DELAY] response code in its error message instead of
> [HAPPYMAIL] (which is non-standard) or no response code.
>
MoZt MAY respect this, initial eyeball test looked encouraging.
> Also, I think it would be very friendly (and way cool) for the patch to
> include the LOGIN-DELAY response to the CAPA command. In authenticated
> state it can include the specific login-delay that will be enforced for
> the user.
I read rfc2449 as stating the unauthenticated CAPA should append USER,
which I have done.
>
> You can also set the LOGIN-DELAY response to CAPA using the
> announce-login-delay option.
But qpopper doesnt support enforcing it, correct? Still its an overlap
in design between it and the patch.
Date: Thu, 9 Mar 2006 12:13:20 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Large spool mboxes => slow?
At 3:21 PM +0000 3/9/06, Hugh Sasse wrote:
> Enabling server mode is not possible given some types of client (from
> my reading of the docs). I don't know all the clients people use, so
> I must err on the side of caution. Or is that paranoid in 2006?
>
> Caching requires server mode....
Server mode (and caching) should be fine as long as people access
their mail using any POP client.
If you have any users who have shell accounts, and access their mail
directly, disable server mode for those users. You can enable and
disable server mode on a per-user and/or per-group basis.
You might also want to think about using the fast-io option, which
renames the temp-drop to the spool instead of copying it. This only
works if the temp drop and spool are on the same filesystem.
You might also want to think about setting update-status-headers to
false. This is a trickier option, because some clients use the
'Status:' header, and some don't. It also trades I/O for CPU.
See the Performance section of the GUIDE, and also the descriptions
of the options.
One thing I've been trying to find time to do is take caching to the
next step, which is maintaining the cache when new mail has arrived
since the last mail check. That would make a big difference when
users leave mail on the server.
There are scripts that have been posted in the past that let you cull
old mail. Something else to think about.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
A long-forgotten loved one will appear soon. Buy the negatives
at any price.
Date: Thu, 09 Mar 2006 09:49:54 -0800
From: Lee Terrell <leet at directcon dot net>
Subject: Lock file permission problem
Hi All,
I recently set up qpopper 4.0.8 on a new machine and I have been seeing
new errors in regards to username.lock files. This problem isn't
affecting every users, but I am getting a fair amount of the following
error message:
-ERR [SYS/TEMP] maillock error 'Unable to create lockfile' (2) on
'/var/spool/mail/u1/u2/user': Permission denied (13)
I do have the enable-temp-drop option active so we can see when users
last popped their mail spool, but it's not a pop.lock error message.
When I check, I can easily see the problem is that the user.lock file is
set to root:root for ownership, so the user's pop session can't
overwrite the lock file.
I've been reading past posts from the list to try and get a handle on
the lock file situation. I thought my understanding was that qpopper
makes the lock file at the beginning of the session, and if the user's
session is interrupted, the lock file is removed after a few minutes. I
have found several lock files that are lingering for more than several
hours though, and a few more than a day.
I've been comparing my old server configuration and setup with the new
one, and I don't see any glaring differences. What are some possible
areas I can investigate regarding these errors? I'm going through the
manual performance tuning section again currently to see if anything
sticks out to me.
Thank you and I appreciate any help or leads,
Lee Terrell
Date: Fri, 10 Mar 2006 11:38:32 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Large spool mboxes => slow?
On Thu, 9 Mar 2006, Randall Gellens wrote:
> At 7:30 PM +0000 3/9/06, Hugh Sasse wrote:
>
> > On Thu, 9 Mar 2006, Kelson wrote:
> >
> > > We put the following in our qpopper.config:
> > > set spool-options = true
> >
> > Which seems to be the same as putting -U in the inetd.conf file...
> >
> > > Then we set up .username.qpopper-options files in our spool directory
> > > containing:
> > > set server-mode = true
> > And can I add
> > set fast-update = true
> > on a per user basis?
>
> Yes, you can set fast-update on a per-user basis.
I have done exactly that. I'm not seeing much improvement, but I may
have discovered a bug in the PDF file. In the tables (pages 26, 36)
this file is referred to as "user.qpopper-options" and
"username.qpopper-options" but in the text pages 27, 42 it is
referred to as ".user.qpopper.options". Possibly the use of
"userNAME" [my emphasis] is an error, but is the ".user" form
correct or the "user (with no leading .)" form correct? A search of
the PDF for qpopper-options will turn up what I mean.
The nearest thing I can find to a revision number is
March 2001
PM80-48468-1
if that's any help.
Thank you,
Hugh
Date: Fri, 10 Mar 2006 09:17:31 -0800
From: Kelson <kelson at speed dot net>
Subject: Re: Large spool mboxes => slow?
g.cse.dmu.ac.uk>
In-Reply-To: <Pine.GSO.4.64.0603101126320.1700@brains.eng.cse.dmu.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.56 on 204.212.42.4
Hugh Sasse wrote:
> In the tables (pages 26, 36)
> this file is referred to as "user.qpopper-options" and
> "username.qpopper-options" but in the text pages 27, 42 it is
> referred to as ".user.qpopper.options". Possibly the use of
> "userNAME" [my emphasis] is an error, but is the ".user" form
> correct or the "user (with no leading .)" form correct?
The scheme that works for us is .username.qpopper-options (with the
leading ".")
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
Date: Fri, 10 Mar 2006 21:02:12 +0100
From: Jesus Cea <jcea at argo dot es>
Subject: Re: Large spool mboxes => slow?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregory Hicks wrote:
> any POP3 daemon is going to have problem is the spool gets too large.
Not if the mailbox is keep in an indexed storage. For example, a
BerkeleyDB database, or, even, MAILDIR.
BTW, is anybody using BerkeleyDB as mail storage system?.
- --
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRBHbRJlgi5GaxT1NAQJ/5AP+O+srTzBJRZWbBZTG8Ke7vRyEEfRz0x6a
iafa70nRc9MHkj5mxW2zM43d3q7liVcgZPHD9/PdiS6n57K56l9WoqnONKEHQPk9
fvAQZwJ/w9x75l6w4P/lT3bPjF7GDc0dBDSlapjoOPLllQmOms3duVT5ADUQXsrs
y5CAvEP9V7Q
=45e9
-----END PGP SIGNATURE-----
Date: Sat, 11 Mar 2006 09:22:48 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Large spool mboxes => slow?
On Fri, 10 Mar 2006, Hugh Sasse wrote:
> > Server mode is only risky under the following circumstrances:
> >
> > 1: Access is made via POP3 and local disk (or a non-compatible imap3 server)
> > which use non-compatible locking methods.
> >
> > 2: Clients _simultaneously_ access using both methods.
> OK, then I will certainly enable it for the large users. It's just
> that usage patterns are a "known unknown", and I'm reluctant to get
> caught by the "unknown unknowns" :-)
If your users are using simultaneous POP3 accesses, server mode is safe,
it's only when differing modes are used that the risk is there - such as
when a user has a local login and is running Pine/Elm/whatever in local
disk mode, as well as using a POP3 client.
--
If a person, or organisation, starts to play on your fears
it may be that person or organisation that you should fear.
Last updated on 16 Mar 2006 by Pensive Mailing List Admin