The qpopper list archive ending on 4 Aug 2000
Topics covered in this issue include:
1. Re: qpopper <-> OpenLDAP?
"Kenneth Porter" <shiva at well dot com>
Sun, 30 Jul 2000 14:34:01 -0700
2. How can I disable FreeBsd Users
"Ganizani Phiri" <ganizani at malawi dot net>
Mon, 31 Jul 2000 09:30:10 +0200
3. Re: How can I disable FreeBsd Users
Alan Brown <alan at manawatu.gen dot nz>
Mon, 31 Jul 2000 21:04:02 +1200 (NZST)
4. Re: qpopper <-> OpenLDAP?
"Jack Barnett" <jbarnett at axil.netmate dot com>
Mon, 31 Jul 2000 08:02:24 -0500
5. Re: Qpopper 3.0.x on NFS ?
Dan Scoggins <dan.scoggins at gsfc.nasa dot gov>
Mon, 31 Jul 2000 10:41:10 -0400
6. Re: qpopper <-> OpenLDAP?
Dan Scoggins <dan.scoggins at gsfc.nasa dot gov>
Mon, 31 Jul 2000 14:08:37 -0400
7. Odd Undefined errors in latest beta
Forrest Aldrich <forrie at forrie dot com>
Mon, 31 Jul 2000 16:21:17 -0400
8. Re: How can I disable FreeBsd Users
"Lisa Casey" <lisa at jellico dot com>
Mon, 31 Jul 2000 19:56:53 -0400
9. Re: How can I disable FreeBsd Users
Alan Brown <alan at manawatu.gen dot nz>
Tue, 1 Aug 2000 12:51:24 +1200 (NZST)
10. Re: How can I disable FreeBsd Users
"Jeremy C. Reed" <reed at wcug.wwu dot edu>
Mon, 31 Jul 2000 18:08:55 -0700 (PDT)
11. Re: Odd Undefined errors in latest beta
Randall Gellens <randy at qualcomm dot com>
Mon, 31 Jul 2000 22:06:28 -0400
12. Re: Further APOP and OpenBSD
Randall Gellens <randy at qualcomm dot com>
Mon, 31 Jul 2000 22:21:05 -0400
13. Re: Odd Undefined errors in latest beta
Forrest Aldrich <forrie at forrie dot com>
Mon, 31 Jul 2000 22:40:53 -0400
14. RE: How can I disable FreeBsd Users
"=?iso-8859-1?Q?Philipp_Gaschütz?=" <philipp at gng dot de>
Tue, 1 Aug 2000 09:12:41 +0200
15. qmail logs?
"Jack Barnett" <jbarnett at axil.netmate dot com>
Tue, 1 Aug 2000 08:21:54 -0500
16. Re: qmail logs?
Fergal Daly <fergal at esatclear dot ie>
Tue, 01 Aug 2000 14:39:22 +0100
17. Re: qmail logs?
"Mitch Vincent" <mitch at venux dot net>
Tue, 1 Aug 2000 09:46:24 -0400
18. Re: qmail logs?
"Jack Barnett" <jbarnett at axil.netmate dot com>
Tue, 1 Aug 2000 08:26:14 -0500
19. RE: How can I disable FreeBsd Users
Randall Gellens <randy at qualcomm dot com>
Tue, 1 Aug 2000 10:25:54 -0400
20. Qpopper on busy server
Chris Szilagyi <chris at mail.esphere dot net>
Wed, 2 Aug 2000 00:13:35 -0500
21. Re: Qpopper on busy server
"Ganizani Phiri" <ganizani at malawi dot net>
Wed, 2 Aug 2000 07:40:32 +0200
22. Re: qpopper& nis
"James Raftery" <jrtest at spec.ch.man.ac dot uk>
Wed, 2 Aug 2000 14:20:06 +0100
23. Need an Outgoing Mail Archive
"Keith D'Atrio" <kdatrio at hotmail dot com>
Wed, 02 Aug 2000 14:09:41 GMT
24. Re: Need an Outgoing Mail Archive
"Jack Barnett" <jbarnett at axil.netmate dot com>
Wed, 2 Aug 2000 09:23:25 -0500
25. qpopper bad performance
Luc Amouriaux <lamouriaux at atos-group dot com>
Wed, 02 Aug 2000 17:04:23 +0100
26. Re: qpopper bad performance
Jochen Erwied <Jochen.Erwied at mbs-software dot de>
Wed, 2 Aug 2000 17:40:17 +0200
27. Re: qpopper bad performance
Peter Evans <peter at gol dot com>
Thu, 3 Aug 2000 09:57:42 +0900
28. qpopper on large systems
"Tedd Hansen" <tedd.hansen at fastweb dot no>
Thu, 3 Aug 2000 18:01:03 +0200
29. Re: qpopper bad performance
Jens Schleusener <Jens.Schleusener at dlr dot de>
Thu, 3 Aug 2000 17:58:30 +0200 (DFT)
30. Re: qpopper on large systems
"Joseph W. Breu" <breu at cfu dot net>
Thu, 3 Aug 2000 11:02:43 -0500 (CDT)
31. Re: qpopper on large systems
"Jack Barnett" <jbarnett at axil.netmate dot com>
Thu, 3 Aug 2000 11:01:33 -0500
32. Re: qpopper bad performance
Carrer Yuri <yurj at alfa dot it>
Thu, 3 Aug 2000 18:18:32 +0200 (MET DST)
33. SUMMARY: qpopper bad performance
Luc Amouriaux <lamouriaux at atos-group dot com>
Thu, 03 Aug 2000 18:31:56 +0100
34. Re: qpopper on large systems
Carrer Yuri <yurj at alfa dot it>
Thu, 3 Aug 2000 18:33:11 +0200 (MET DST)
35. Re: qpopper on large systems
"Joseph W. Breu" <breu at cfu dot net>
Thu, 3 Aug 2000 11:49:19 -0500 (CDT)
36. Re: SUMMARY: qpopper bad performance
Carrer Yuri <yurj at alfa dot it>
Thu, 3 Aug 2000 19:30:10 +0200 (MET DST)
37. Re: qpopper on large systems
"Jack Barnett" <jbarnett at axil.netmate dot com>
Thu, 3 Aug 2000 14:23:22 -0500
38. Qpopper on busy server - SUMMARY
Chris Szilagyi <chris at mail.esphere dot net>
Thu, 3 Aug 2000 14:24:29 -0500
39. Re: Qpopper on busy server - SUMMARY
Carrer Yuri <yurj at alfa dot it>
Thu, 3 Aug 2000 23:12:48 +0200 (MET DST)
40. outlook express problem
Ben Inkoo Kim <ben9 at ee.tamu dot edu>
Thu, 3 Aug 2000 17:53:21 -0500 (CDT)
41. Re: outlook express problem
"Kenneth Porter" <shiva at well dot com>
Thu, 03 Aug 2000 17:37:26 -0700
42. Re: outlook express problem
Ben Inkoo Kim <ben9 at ee.tamu dot edu>
Thu, 3 Aug 2000 20:24:24 -0500 (CDT)
43. Re: outlook express problem
"Jeff A. Earickson" <jaearick at colby dot edu>
Thu, 3 Aug 2000 21:45:08 -0400 (EDT)
44. Re: SUMMARY: qpopper bad performance
Alan Brown <alan at manawatu.gen dot nz>
Fri, 4 Aug 2000 15:21:54 +1200 (NZST)
45. Re: outlook express problem
Byron Jones <byron at vianet.net dot au>
Fri, 04 Aug 2000 11:45:41 +0800
46. Re: outlook express problem
Alan Brown <alan at manawatu.gen dot nz>
Fri, 4 Aug 2000 17:32:31 +1200 (NZST)
47. Re: outlook express problem
mike miller <mikem at ndtel dot com>
Fri, 04 Aug 2000 08:03:25 -0500
48. scripts to clean out old email
"Jeff A. Earickson" <jaearick at colby dot edu>
Fri, 4 Aug 2000 09:51:42 -0400 (EDT)
49. timeout ?
=?iso-8859-1?Q?Ramón?= Alvarez Rayo <ralvarez at tmx.com dot ni>
Fri, 04 Aug 2000 11:34:49 -0600
50. LDAP
Kevin Cochran <kcochra at arroyodcs dot net>
Fri, 04 Aug 2000 13:24:26 -0500
From: "Kenneth Porter" <shiva at well dot com>
Date: Sun, 30 Jul 2000 14:34:01 -0700
Subject: Re: qpopper <-> OpenLDAP?
On Fri, 28 Jul 2000 19:42:23 +0100, Nuno Teixeira wrote:
>Can you tell me what is OpenLDAP and why should we use it?
FWIW, I believe Microsoft's Active Directory (part of Win00) is based
on LDAP. OTOH, I wouldn't be surprised if, as with Kerberos, it was
extended in a proprietary way to make it incompatible with other
LDAP-based directories.
OpenLDAP is an Open Source reference implementation of an LDAP server.
My question: What kinds of things would qpopper store/fetch with LDAP?
(I expect this would include user authentication tokens, location of
the mailbox (or the mailbox itself could be in the LDAP directory), and
format of the mailbox.) Would not any such implementation need a more
granular customization to configure which things to store/fetch? Some
admins might want to use LDAP only for authentication, while others
might also use it for the kitchen sink.
Ken
mailto:shiva at well dot com
http://www.sewingwitch.com/ken/
http://www.harrybrowne2000.org/
Kill the Carnivore! http://www.lp.org/action/carnivore/
From: "Ganizani Phiri" <ganizani at malawi dot net>
Subject: How can I disable FreeBsd Users
Date: Mon, 31 Jul 2000 09:30:10 +0200
I want to carry out a disconnection of my users.How do I go about it.
Can somebody please provide me with a script to disable and enable
a group of users.
I want to do it like this. Have all the users in a file. A script will read
from this
file and then disable the user in whatever file say password file.
Thanks in advance.
Ganizani
MalawiNet Limited
Date: Mon, 31 Jul 2000 21:04:02 +1200 (NZST)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: How can I disable FreeBsd Users
Remove or just suspend?
passwd -l will suspend a user. It's trivial to make a script to handle
bulk suspensions.
AB
From: "Jack Barnett" <jbarnett at axil.netmate dot com>
Subject: Re: qpopper <-> OpenLDAP?
Date: Mon, 31 Jul 2000 08:02:24 -0500
----- Original Message -----
From: "Kenneth Porter" <shiva at well dot com>
To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
Sent: Sunday, July 30, 2000 4:34 PM
Subject: Re: qpopper <-> OpenLDAP?
> On Fri, 28 Jul 2000 19:42:23 +0100, Nuno Teixeira wrote:
>
> >Can you tell me what is OpenLDAP and why should we use it?
>
> FWIW, I believe Microsoft's Active Directory (part of Win00) is based
> on LDAP. OTOH, I wouldn't be surprised if, as with Kerberos, it was
> extended in a proprietary way to make it incompatible with other
> LDAP-based directories.
I heard it was based off LDAP, I even seen articles on OpenLDAP.org and
Sendmail.net tell how to get OpenLDAP to work with it (for now atleast).
Microsoft is well known for the "Embace and Extentend" and they do require
the rootdn to be `dc=doamin, dc=com`, if you have anything else it won't
work with Microsoft's version, now what fun is that? I use that format for
my root DN, but won't think about forcing it on others.
> OpenLDAP is an Open Source reference implementation of an LDAP server.
>
> My question: What kinds of things would qpopper store/fetch with LDAP?
> (I expect this would include user authentication tokens, location of
> the mailbox (or the mailbox itself could be in the LDAP directory), and
> format of the mailbox.) Would not any such implementation need a more
> granular customization to configure which things to store/fetch? Some
> admins might want to use LDAP only for authentication, while others
> might also use it for the kitchen sink.
>
> Ken
> mailto:shiva at well dot com
> http://www.sewingwitch.com/ken/
> http://www.harrybrowne2000.org/
> Kill the Carnivore! http://www.lp.org/action/carnivore/
>
The only real thing you would need is username and password. I guess it
would be up to the person runnning qpopper/ldap to decide what goes in. For
example, say you have a "mail directory" option, if they don't put it in it
takes the default of what qpopper is set at, if it is set it takes that
value instead. For the people that don't need it, just leave it out or
blank, and the people that want ""/var/mail"" spread across more then one
disk (cheap mans performance tweak) they set what ever seems logically to
the design of there mail server for that user. That would be pretty cool.
Jack
Date: Mon, 31 Jul 2000 10:41:10 -0400
From: Dan Scoggins <dan.scoggins at gsfc.nasa dot gov>
Subject: Re: Qpopper 3.0.x on NFS ?
A follow-on question: how is pop mail retrieval performance effected by the
latency added by NFS?
Dan Scoggins
Infrastructure Support
Goddard Space Flight Center
NASA
--
At 09:47 AM 7/28/00 +0200, Carles Xavier Munyoz Baldó wrote:
>qpopper-list at tiscali dot be wrote:
>> Does someone had used qpopper 3.0.2 (or 3.0.1) with the spool mounted in
>> NFS (2 or 3) ?
>
>Yes, I'm using qpopper 3.0.2 with the spool mounted using a NFS server.
>For do it I have had to make changes in the source code of QPopper.
>
>Greetings.
>---
>Carles Xavier Munyoz Baldó / carles.munyoz at ctv-jet dot com
>Wanadoo España
>Dpto. Sistemas / System Department
>Tel: +34 96 5040000 Ext. 40046 - Fax: +34 96 5040047
>http://www.wanadoo.es/
>---
Date: Mon, 31 Jul 2000 14:08:37 -0400
From: Dan Scoggins <dan.scoggins at gsfc.nasa dot gov>
Subject: Re: qpopper <-> OpenLDAP?
Peter Evans writes:
SNIP!
>> It is a 20 minute user/admin tweak or a 20 minute intense programers hack?
>
> 200 lines of sparse, commented code for my pop-proxy.
> the openldap has libraries for the gruesome stuff. ^^!
>
> P
I would be interested to know, has anyone on the list has tried using a
radius3 service as a form of popper authentication?
DanS
--
Date: Mon, 31 Jul 2000 16:21:17 -0400
From: Forrest Aldrich <forrie at forrie dot com>
Subject: Odd Undefined errors in latest beta
We are seeing an influx of these error messages with the latest beta of
qpopper:
Jul 31 16:13:22 machine popper[28009]: foobar at pptp-73-5.ourdomain.net
(xx.xx.xx.xx):
+-ERR POP EOF or I/O Error: 13 (Permission denied); 0 (Undefined error: 0)
What is this.
_F
From: "Lisa Casey" <lisa at jellico dot com>
Subject: Re: How can I disable FreeBsd Users
Date: Mon, 31 Jul 2000 19:56:53 -0400
Hi Alan,
> Remove or just suspend?
>
> passwd -l will suspend a user. It's trivial to make a script to handle
> bulk suspensions.
According to man passwd:
-l This option causes the password to be updated only in the local
password file, and not with the Kerberos database. When changing
only the local password, pwd_mkdb(8) is used to update the
password
databases.
Can you help me understand how I could use this to suspend a user? Not sure
I understand...
Thanks,
Lisa Casey
Interstate 2000, Inc.
lisa at jellico dot com
Date: Tue, 1 Aug 2000 12:51:24 +1200 (NZST)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: How can I disable FreeBsd Users
On Mon, 31 Jul 2000, Lisa Casey wrote:
> -l This option causes the password to be updated only in the local
> password file, and not with the Kerberos database. When changing
> only the local password, pwd_mkdb(8) is used to update the
> password
> databases.
If you're using Kerberos, then you'll need to use the kerberos utilities
to suspend a login.
Date: Mon, 31 Jul 2000 18:08:55 -0700 (PDT)
From: "Jeremy C. Reed" <reed at wcug.wwu dot edu>
Subject: Re: How can I disable FreeBsd Users
On Mon, 31 Jul 2000, Lisa Casey wrote:
> According to man passwd:
>
> -l This option causes the password to be updated only in the local
> password file, and not with the Kerberos database. When changing
> only the local password, pwd_mkdb(8) is used to update the
> password
> databases.
BSD passwd is different than GNU passwd. For your info, GNU passwd(1)
says:
User accounts may be locked and unlocked with the -l and
-u flags. The -l option disables an account by changing
the password to a value which matches no possible
encrypted value. The -u option re-enables an account by
changing the password back to its previous value.
You want to disable a user? You could add some character to their
encrypted password. (Then remove the character when you want to enable
again.)
Jeremy C. Reed
http://www.reedmedia.net/
http://bsd.reedmedia.net/
Date: Mon, 31 Jul 2000 22:06:28 -0400
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Odd Undefined errors in latest beta
At 4:21 PM -0400 7/31/00, Forrest Aldrich wrote:
> We are seeing an influx of these error messages with the latest
> beta of qpopper:
>
> Jul 31 16:13:22 machine popper[28009]: foobar at
> pptp-73-5.ourdomain.net (xx.xx.xx.xx):
> +-ERR POP EOF or I/O Error: 13 (Permission denied); 0 (Undefined error: 0)
>
> What is this.
>
>
> _F
Your clients are disconnecting without sending QUIT, or their network
connection is getting dropped.
Date: Mon, 31 Jul 2000 22:21:05 -0400
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Further APOP and OpenBSD
At 9:34 PM -0700 7/26/00, Rickie Kerndt wrote:
> but now i remember that i built 3.1b4 with kerberos support and
> had to patch pop_user.c to allow cleartext with kerberos
> authentication when cleartext is otherwise forbidden. i was
> building with apop as well so user could authenticate with either.
> Looking at 3.1b6 pop_user.c this same problem still exists. I've
> been testing 3.1b5 and 3.1b6 on an OpenBSD system without kerberos
> support so haven't bothered incorperating these changes there.
> Maybe somthing that should be fixed? Patch below:
>
> --- pop_user.c.orig Tue Jul 4 12:39:42 2000
> +++ pop_user.c Tue Jul 4 14:17:40 2000
> @@ -182,7 +182,7 @@
>
> #ifdef AUTHON
>
> - if ( p->AllowClearText == ClearTextDefault ) {
> + if ( p->AllowClearText == ClearTextDefault && (p->AuthType !=
> kerberos)) {
Why not just set AllowClearText to be what you want, instead of
leaving it default and then patching the code?
Date: Mon, 31 Jul 2000 22:40:53 -0400
From: Forrest Aldrich <forrie at forrie dot com>
Subject: Re: Odd Undefined errors in latest beta
Thanks for the info. If this is the case, can there not be a more specific
error message?
_F
At 10:06 PM 7/31/00 -0400, you wrote:
>At 4:21 PM -0400 7/31/00, Forrest Aldrich wrote:
>
>> We are seeing an influx of these error messages with the latest beta of
>> qpopper:
>>
>> Jul 31 16:13:22 machine popper[28009]: foobar at
>> pptp-73-5.ourdomain.net (xx.xx.xx.xx):
>> +-ERR POP EOF or I/O Error: 13 (Permission denied); 0 (Undefined error: 0)
>>
>> What is this.
>>
>>
>> _F
>
>Your clients are disconnecting without sending QUIT, or their network
>connection is getting dropped.
From: "=?iso-8859-1?Q?Philipp_Gaschütz?=" <philipp at gng dot de>
Subject: RE: How can I disable FreeBsd Users
Date: Tue, 1 Aug 2000 09:12:41 +0200
Hey,
I think it's far more easy to go via the shell. Have a look into - i
think - pop_pass.c. There is a function which checks whether the user's
shell is a valid shell. Now, if you are giving all users that you want to
disable a shell such as popper.shell (which is a symlink to i.e. bash or
false) and you add a couple of lines of code into pop_pass.c where you
compare the shell retrieved by popper with "popper.shell", you are able
to lock those out...
hope this helps,
-p
> -----Original Message-----
> From: Ganizani Phiri [mailto:ganizani at malawi dot net]
> Sent: Montag, 31. Juli 2000 09:30
> To: Enno Davids
> Cc: freebsd-isp at FreeBSD dot ORG; randy at qualcomm dot com;
> freebsd-questions at FreeBSD.ORG; qpopper at lists dot pensive dot org
> Subject: How can I disable FreeBsd Users
>
>
> I want to carry out a disconnection of my users.How do I go about it.
> Can somebody please provide me with a script to disable and enable
> a group of users.
>
> I want to do it like this. Have all the users in a file. A
> script will read
> from this
> file and then disable the user in whatever file say password file.
>
> Thanks in advance.
>
> Ganizani
> MalawiNet Limited
>
>
From: "Jack Barnett" <jbarnett at axil.netmate dot com>
Subject: qmail logs?
Date: Tue, 1 Aug 2000 08:21:54 -0500
Holy crap. I changed over from sendmail to qmail recently and qmail was
working prefect for about a day or so till something went wrong. It lost
about a nights worth of mail (2000+ messages!!) and reported _nothing_ in
the logs files. Is there a way to force qmail to log everything no matter
what? If something, anything even if it is tiny, it should be logged. Any
documents explain how to do extentive logging getting statics on the
servers?
Date: Tue, 01 Aug 2000 14:39:22 +0100
From: Fergal Daly <fergal at esatclear dot ie>
Subject: Re: qmail logs?
At 14:21 01/08/00, Jack Barnett wrote:
>Holy crap. I changed over from sendmail to qmail recently and qmail was
>working prefect for about a day or so till something went wrong. It lost
>about a nights worth of mail (2000+ messages!!) and reported _nothing_ in
>the logs files. Is there a way to force qmail to log everything no matter
>what? If something, anything even if it is tiny, it should be logged. Any
>documents explain how to do extentive logging getting statics on the
>servers?
Probably best to ask this on a qmail list... especially since you seem to
have hit a rather serious bug
Fergal
From: "Mitch Vincent" <mitch at venux dot net>
Subject: Re: qmail logs?
Date: Tue, 1 Aug 2000 09:46:24 -0400
Jack, get on a qmail list and ask this!
----- Original Message -----
From: "Jack Barnett" <jbarnett at axil.netmate dot com>
To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
Sent: Tuesday, August 01, 2000 9:21 AM
Subject: qmail logs?
>
> Holy crap. I changed over from sendmail to qmail recently and qmail was
> working prefect for about a day or so till something went wrong. It lost
> about a nights worth of mail (2000+ messages!!) and reported _nothing_ in
> the logs files. Is there a way to force qmail to log everything no matter
> what? If something, anything even if it is tiny, it should be logged.
Any
> documents explain how to do extentive logging getting statics on the
> servers?
>
>
From: "Jack Barnett" <jbarnett at axil.netmate dot com>
Subject: Re: qmail logs?
Date: Tue, 1 Aug 2000 08:26:14 -0500
>
> Holy crap. I changed over from sendmail to qmail recently and qmail was
> working prefect for about a day or so till something went wrong. It lost
> about a nights worth of mail (2000+ messages!!) and reported _nothing_ in
> the logs files. Is there a way to force qmail to log everything no matter
> what? If something, anything even if it is tiny, it should be logged.
Any
> documents explain how to do extentive logging getting statics on the
> servers?
>
>
Sorry about this, I posted it to the wrong mailing list, please delete. I
got to many mail servers that start with "q" :)
Date: Tue, 1 Aug 2000 10:25:54 -0400
From: Randall Gellens <randy at qualcomm dot com>
Subject: RE: How can I disable FreeBsd Users
At 9:12 AM +0200 8/1/00, Philipp Gaschütz wrote:
> Hey,
>
> I think it's far more easy to go via the shell. Have a look into - i
> think - pop_pass.c. There is a function which checks whether the user's
> shell is a valid shell. Now, if you are giving all users that you want to
> disable a shell such as popper.shell (which is a symlink to i.e. bash or
> false) and you add a couple of lines of code into pop_pass.c where you
> compare the shell retrieved by popper with "popper.shell", you are able
> to lock those out...
If you want to disable access via the shell, just add '#define
CHECK_SHELL 1' to the top of config.h and recompile Qpopper. If the
user's shell is not valid, the user will be unable to access the
system. If you want to prevent the user from telneting in but still
permit POP access, use a shell value of /POPPER/ANY/SHELL/.
Date: Wed, 2 Aug 2000 00:13:35 -0500
From: Chris Szilagyi <chris at mail.esphere dot net>
Subject: Qpopper on busy server
Hi, I am looking for suggestions on running Qpopper 3.0.1 on a very busy
server. We currently have a server set up (Red Hat 6.2) with Qpopper
3.0.1. It runs pretty well, but every once in a while the qpopper daemon
will die somehow, and when I try to restart it, it gives the error
"Unable to obtain socket and address of client: Socket operation on
non-socket".
Basically the only solution I have found for this is to reboot the server.
My entry in inetd.conf looks like:
pop-3 stream tcp nowait root /usr/sbin/tcpd in.qpopper -R -T 15
If anybody has any suggestions on running Qpopper on a very busy server
and/or recommended settings to use, I would be very appreciative.
Thanks in advance!
--
Chris Szilagyi
Network Administrator
Esphere Technologies, LLC
From: "Ganizani Phiri" <ganizani at malawi dot net>
Subject: Re: Qpopper on busy server
Date: Wed, 2 Aug 2000 07:40:32 +0200
Another trick is to got into the inetd.conf and comment out the line that
starts Qpopper.
Then do 'killall -HUP inetd
After this get back to the inetd.conf and reactivate the line that starts
Qpopper. Then
redo 'killall -HUP inetd
One other trick is to start Qpopper using the tcpserver. Find more from
http://cr.yp.to/ucspi-tcp.html
Ganizani Phiri
Systems Admin.
MalawiNet Limited
From: "James Raftery" <jrtest at spec.ch.man.ac dot uk>
Date: Wed, 2 Aug 2000 14:20:06 +0100
Subject: Re: qpopper& nis
To get nis to work have to ensure that in the compilation where there are
duplication definitions available to popper that those provided by libc take
priority:
cc ... -o popper -lc ...
Jim
--
James Raftery
Structural Chemistry Department|E-Mail:jrtest at spec.ch.man.ac dot uk
Manchester University | FAX:0161-275-4734
Manchester M13 9PL | Tel.:0161-275-4700
From: "Keith D'Atrio" <kdatrio at hotmail dot com>
Subject: Need an Outgoing Mail Archive
Date: Wed, 02 Aug 2000 14:09:41 GMT
I just installed qpopper on a Redhat Linux Machine. I work for a local city
government and we archive all mail for three years. I set up an incoming
mail archive system but also need to archive the outgoing mail as well. I
would appreciate anyone's help in this problem. I am looking for a solution
at the server level but would accept a solution on the workstation level. I
am sending all mail to a archive address.
Thank you in advance
Keith D'Atrio ICIS
-----------------------------------------------------------------------
Intel - We put the 'UM in Pentium
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
From: "Jack Barnett" <jbarnett at axil.netmate dot com>
Subject: Re: Need an Outgoing Mail Archive
Date: Wed, 2 Aug 2000 09:23:25 -0500
> I just installed qpopper on a Redhat Linux Machine. I work for a local
city
> government and we archive all mail for three years. I set up an incoming
> mail archive system but also need to archive the outgoing mail as well. I
> would appreciate anyone's help in this problem. I am looking for a
solution
> at the server level but would accept a solution on the workstation level.
I
> am sending all mail to a archive address.
>
> Thank you in advance
> Keith D'Atrio ICIS
>
> -----------------------------------------------------------------------
> Intel - We put the 'UM in Pentium
This would probably been done on the smtp mail server side, since pop3
doesn't touch outgoing mail. What are you running sendmail, postfix, qmail?
I don't know how to do this, but it would be better if you checked with your
smtp website/faq/mail list it would probably turn up more hints.
Jack
Date: Wed, 02 Aug 2000 17:04:23 +0100
From: Luc Amouriaux <lamouriaux at atos-group dot com>
Subject: qpopper bad performance
Bonjour
I'm experiencing performance problems on qpopper (now 3.02, but it was the
same on 2.53) on Solaris 2.6:
qpopper hang seconds, sometimes minutes, before responding to the pop3
"PASS xxx" command.
And a lot (10-20) of qpopper process appears owned by root.
(For info: I've got 1900 entries in /etc/passwd.
#grep pop /etc/inetd.conf:
pop3 stream tcp nowait root /usr/local/etc/qpopper-3_02 qpopper-3_02
-Rsd -T120
)
Any idea?
__________________________________________________________
Luc Amouriaux tel. 01 46 25 52 21
Services Réseaux à Valeur Ajoutée Atos Infogerance
Date: Wed, 2 Aug 2000 17:40:17 +0200
From: Jochen Erwied <Jochen.Erwied at mbs-software dot de>
Subject: Re: qpopper bad performance
Hello Luc,
Wednesday, August 02, 2000, 6:04:23 PM, you wrote:
> Bonjour
> qpopper hang seconds, sometimes minutes, before responding to the pop3
> "PASS xxx" command.
How large is the mailbox you try to access?
--
Jochen Erwied <Jochen.Erwied at mbs-software dot de> Phone: +49-2151-7294-24
mbs GmbH, Roemerstr. 15, 47809 Krefeld FAX: +49-2151-7294-50
Date: Thu, 3 Aug 2000 09:57:42 +0900
From: Peter Evans <peter at gol dot com>
Subject: Re: qpopper bad performance
Luc Amouriaux (lamouriaux at atos-group dot com) wrote:
> I'm experiencing performance problems on qpopper (now 3.02, but it was the
> same on 2.53) on Solaris 2.6:
> qpopper hang seconds, sometimes minutes, before responding to the pop3
> "PASS xxx" command.
> And a lot (10-20) of qpopper process appears owned by root.
This sounds like you have a password lookup problem,
the process being root is simply the fact that it hasnt
found the new UID from the getpwent yet.
try trussing a pop process ^_^;
> (For info: I've got 1900 entries in /etc/passwd.
> #grep pop /etc/inetd.conf:
> pop3 stream tcp nowait root /usr/local/etc/qpopper-3_02 qpopper-3_02
> -Rsd -T120
> )
--
Remember The 5 K's.
The Justified Agents of Munya-munya-muuuu ...
From: "Tedd Hansen" <tedd.hansen at fastweb dot no>
Subject: qpopper on large systems
Date: Thu, 3 Aug 2000 18:01:03 +0200
Qpopper shouldn't have any problem running on Linux with 5000 users (in
/etc/passwd) ?
Med vennlig hilsen
Tedd Hansen
Freeweb visittkort:
http://www.freeweb.no/tedd
Date: Thu, 3 Aug 2000 17:58:30 +0200 (DFT)
From: Jens Schleusener <Jens.Schleusener at dlr dot de>
Subject: Re: qpopper bad performance
On Thu, 3 Aug 2000, Peter Evans wrote:
> Luc Amouriaux (lamouriaux at atos-group dot com) wrote:
> > I'm experiencing performance problems on qpopper (now 3.02, but it was the
> > same on 2.53) on Solaris 2.6:
> > qpopper hang seconds, sometimes minutes, before responding to the pop3
> > "PASS xxx" command.
> > And a lot (10-20) of qpopper process appears owned by root.
>
> This sounds like you have a password lookup problem,
> the process being root is simply the fact that it hasnt
> found the new UID from the getpwent yet.
>
> try trussing a pop process ^_^;
>
I have the experience that the "+OK" after the "PASS xxx" command is only
given from the server after the temporary .user.pop file is generated
respectively copied (non server mode). So poor disk performance, large
mail spool files or many concurrent POP server accesses may lead to your
performance problems respectively the seeming authentication problems.
Greetings
Jens
--
Dr. Jens Schleusener debis Systemhaus
phone: +49 (551) 709-2493 Solutions for Research
fax: +49 (551) 709-2169 Bunsenstr.10
mail: Jens.Schleusener at dlr dot de D-37073 Goettingen
Date: Thu, 3 Aug 2000 11:02:43 -0500 (CDT)
From: "Joseph W. Breu" <breu at cfu dot net>
Subject: Re: qpopper on large systems
On Thu, 3 Aug 2000, Tedd Hansen wrote:
> Qpopper shouldn't have any problem running on Linux with 5000 users (in
> /etc/passwd) ?
I have qpopper running on a machine with 12,500 users on it. It handles
it just fine.
I did have to hash my mail spool and home dir as well as move the temp
file creation to another directory.
--
Thanks,
-Joseph W. Breu
-----------------------------------------------------------------------
Joseph W. Breu Systems Administrator / Cedar Falls Utilities
phone: (319) 268-5228 Utility Parkway, Cedar Falls, Iowa 50613
NIC: jwb96 free minds - free software breu at cfu.net
---- Al Gore: "...I took the initiative in creating the Internet. -----
PGP Public Key Available at http://www.breu.org/~breu/pgp_key.asc
From: "Jack Barnett" <jbarnett at axil.netmate dot com>
Subject: Re: qpopper on large systems
Date: Thu, 3 Aug 2000 11:01:33 -0500
> Qpopper shouldn't have any problem running on Linux with 5000 users (in
> /etc/passwd) ?
>
>
> Med vennlig hilsen
> Tedd Hansen
> Freeweb visittkort:
> http://www.freeweb.no/tedd
>
>
What type of proc, how much ram? What else will the system be doing, will
it be dedicated to pop3?
Probably your biggest bottle neck will be the i/o on your hard drives.
Date: Thu, 3 Aug 2000 18:18:32 +0200 (MET DST)
From: Carrer Yuri <yurj at alfa dot it>
Subject: Re: qpopper bad performance
> I have the experience that the "+OK" after the "PASS xxx" command is only
> given from the server after the temporary .user.pop file is generated
> respectively copied (non server mode). So poor disk performance, large
> mail spool files or many concurrent POP server accesses may lead to your
> performance problems respectively the seeming authentication problems.
I bet it doesn't happen with other popper deamons. :)
Yuri
Date: Thu, 03 Aug 2000 18:31:56 +0100
From: Luc Amouriaux <lamouriaux at atos-group dot com>
Subject: SUMMARY: qpopper bad performance
Bonjour
The low throughput of my qpopper 3.02 was caused by the Bulletins Database
reading/updating. For some reasons, we've choose to use Bulletins with the
database option. Debugging mode showed that too many user were trying to
read this bulldb at the same time, so they had to wait ("sleep" in the
source!) to open this file.
Compiling without the "--enable-bulletins=/var/bulls" option resolved the
problem.
Thanks to Ken and Jochen for responding. Here my original posting:
>I'm experiencing performance problems on qpopper (now 3.02, but it was the
>same on 2.53) on Solaris 2.6:
>qpopper hang seconds, sometimes minutes, before responding to the pop3
>"PASS xxx" command.
>And a lot (10-20) of qpopper process appears owned by root.
__________________________________________________________
Luc Amouriaux tel. 01 46 25 52 21
Services Réseaux à Valeur Ajoutée Atos Infogerance
Date: Thu, 3 Aug 2000 18:33:11 +0200 (MET DST)
From: Carrer Yuri <yurj at alfa dot it>
Subject: Re: qpopper on large systems
> On Thu, 3 Aug 2000, Tedd Hansen wrote:
>
> > Qpopper shouldn't have any problem running on Linux with 5000 users (in
> > /etc/passwd) ?
>
> I have qpopper running on a machine with 12,500 users on it. It handles
> it just fine.
>
> I did have to hash my mail spool and home dir as well as move the temp
> file creation to another directory.
>
why the home ?:-)
Date: Thu, 3 Aug 2000 11:49:19 -0500 (CDT)
From: "Joseph W. Breu" <breu at cfu dot net>
Subject: Re: qpopper on large systems
On Thu, 3 Aug 2000, Carrer Yuri wrote:
> > I have qpopper running on a machine with 12,500 users on it. It handles
> > it just fine.
> >
> > I did have to hash my mail spool and home dir as well as move the temp
> > file creation to another directory.
> >
>
> why the home ?:-)
Figured I was at it, might as well do it as well. Plus, if you use
bulletins, it increases the speed at which qpopper updates the .bull file.
--
Thanks,
-Joseph W. Breu
-----------------------------------------------------------------------
Joseph W. Breu Systems Administrator / Cedar Falls Utilities
phone: (319) 268-5228 Utility Parkway, Cedar Falls, Iowa 50613
NIC: jwb96 free minds - free software breu at cfu.net
---- Al Gore: "...I took the initiative in creating the Internet. -----
PGP Public Key Available at http://www.breu.org/~breu/pgp_key.asc
Date: Thu, 3 Aug 2000 19:30:10 +0200 (MET DST)
From: Carrer Yuri <yurj at alfa dot it>
Subject: Re: SUMMARY: qpopper bad performance
>
> Compiling without the "--enable-bulletins=/var/bulls" option resolved the
> problem.
>
> Thanks to Ken and Jochen for responding. Here my original posting:
What are the switch to make it as fast as possible (only pop, no
bullettins, no hostname lookups for example) with about 1000 mailbox
and 2-3 users to 10-20 at time popping? :) That would be a good entry
in a FAQ.
Yuri
From: "Jack Barnett" <jbarnett at axil.netmate dot com>
Subject: Re: qpopper on large systems
Date: Thu, 3 Aug 2000 14:23:22 -0500
Your procs and ram will be able to handle it easily. The thing to watch out
for is hard drive performance. One way to get a little better i/o on your
disk subsystem is to go with scsi and split the data between the drives, if
possiable put everything you can on separate disk. Like for example give
each one of these it's own scsi drive
/var/spool/mail
/var/spool/mqueue
/var/spool/dropbox
where dropbox is the temporary directory qpopper copies everything over to
(compile time option IIRC). You might not need this, or you might need
something faster it is kinda hard to tell
> 2xPIII 500 MHz processor
> 512 MB RAM
> It's running both Sendmail and POP3, but nothing else
> Upgrading to reiser file system, but currently running with all files in
one
> directory :/
>
> -----Original Message-----
> From: Jack Barnett [mailto:jbarnett at axil.netmate dot com]
> Sent: Thursday, August 03, 2000 6:02 PM
> To: Tedd Hansen; Subscribers of Qpopper
> Subject: Re: qpopper on large systems
>
>
>
> > Qpopper shouldn't have any problem running on Linux with 5000 users (in
> > /etc/passwd) ?
> >
> >
> > Med vennlig hilsen
> > Tedd Hansen
> > Freeweb visittkort:
> > http://www.freeweb.no/tedd
> >
> >
>
> What type of proc, how much ram? What else will the system be doing, will
> it be dedicated to pop3?
>
> Probably your biggest bottle neck will be the i/o on your hard drives.
>
>
>
Date: Thu, 3 Aug 2000 14:24:29 -0500
From: Chris Szilagyi <chris at mail.esphere dot net>
Subject: Qpopper on busy server - SUMMARY
I have found the solution to my problem with Qpopper going down when too
many requests were coming in. Basically the problem was with inetd and
it's default of 40 connections per minute was being exceeded (by looking
in
/var/log/messages). By editing /etc/inetd.conf to show the following
pop-3 stream tcp nowait.160 root /usr/sbin/tcpd in.qpopper -R
-T 30
this solved the problem. The nowait.160 allows 160 connections per
minute.
-R disables reverse lookups for incoming clients, which we also did so it
doesn't have to do nslookups all the time. A combination of these two has
greatly improved our performance... no problems whatsoever. BTW, we are
using the patched version of Qpopper for use with the drac daemon. This
system works perfectly in an environment with roaming users to completely
stop open relaying.
--
Chris Szilagyi
Network Administrator
Esphere Technologies, LLC
Chris Szilagyi wrote:
> Hi, I am looking for suggestions on running Qpopper 3.0.1 on a very busy
> server. We currently have a server set up (Red Hat 6.2) with Qpopper
> 3.0.1. It runs pretty well, but every once in a while the qpopper
daemon
> will die somehow, and when I try to restart it, it gives the error
>
> "Unable to obtain socket and address of client: Socket operation on
> non-socket".
>
> Basically the only solution I have found for this is to reboot the
server.
> My entry in inetd.conf looks like:
>
> pop-3 stream tcp nowait root /usr/sbin/tcpd in.qpopper -R -T
15
>
> If anybody has any suggestions on running Qpopper on a very busy server
> and/or recommended settings to use, I would be very appreciative.
>
> Thanks in advance!
>
> --
> Chris Szilagyi
> Network Administrator
> Esphere Technologies, LLC
Date: Thu, 3 Aug 2000 23:12:48 +0200 (MET DST)
From: Carrer Yuri <yurj at alfa dot it>
Subject: Re: Qpopper on busy server - SUMMARY
> I have found the solution to my problem with Qpopper going down when too
> many requests were coming in. Basically the problem was with inetd and
> it's default of 40 connections per minute was being exceeded (by looking
> in
> /var/log/messages). By editing /etc/inetd.conf to show the following
>
> pop-3 stream tcp nowait.160 root /usr/sbin/tcpd in.qpopper -R
> -T 30
I love the -R. The problem is if tcpd isn't doing the reverse itself :-)
Yuri
Date: Thu, 3 Aug 2000 17:53:21 -0500 (CDT)
From: Ben Inkoo Kim <ben9 at ee.tamu dot edu>
Subject: outlook express problem
Hello people,
I hope this question is relevant here, and guess perhaps an old question,
but the situation seems special and I would appreciate a help.
My question is about the mechanism of qpopper reading the user
quota. I have some users who cannot read using outlook express but can
read using pine. What is creating this difference?
The error message is as follows. (Grabbed from outlook express )
There was a problem logging onto your mail server. Your Password was
rejected. Account: 'ee.tamu.edu', Server: 'ee.tamu.edu', Protocol: POP3,
Server Response: '-ERR Unable to copy mail spool file, quota exceeded
(49)', Port: 110, Secure(SSL): No, Server Error: 0x800CCC90, Error
Number: 0x800CCC92
In /var/log/local0 I see the following messages:
Aug 3 09:57:36 popper[10435]: gdh at gdh.tamu dot edu: -ERR Unable to copy mail
spool file, quota exceeded (49)
Also I have a temp file of size 0 under the spool directory.
-rw------- 1 gasdh mail 0 Aug 3 16:38 .gasdh.pop
Initially he was over mail quota, but I increased it enough, and even ran
quotacheck on /var/mail to see if it helps. And the quota -v shows the
correct information after the update. (I mean, the mails in the spool were
delivered correctly to the mailbox in the /var/mail directory.)
It seems the password is correct. I have only 2 users reporting this
problem.
Thanks.
Ben Inkoo Kim [845-7530 / Zach 30B]
From: "Kenneth Porter" <shiva at well dot com>
Date: Thu, 03 Aug 2000 17:37:26 -0700
Subject: Re: outlook express problem
On Thu, 3 Aug 2000 17:53:21 -0500 (CDT), Ben Inkoo Kim wrote:
>Initially he was over mail quota, but I increased it enough, and even ran
>quotacheck on /var/mail to see if it helps. And the quota -v shows the
>correct information after the update. (I mean, the mails in the spool were
>delivered correctly to the mailbox in the /var/mail directory.)
>
>It seems the password is correct. I have only 2 users reporting this
>problem.
If the dropcopy is on the same filesystem as the spool, then you need
2X the quota of the expected mailbox size, to make room for copying the
mailbox. Another approach is to put the dropcopy on another partition
so that it doesn't count against the user's quota.
Ken
mailto:shiva at well dot com
http://www.sewingwitch.com/ken/
http://www.harrybrowne2000.org/
Kill the Carnivore! http://www.lp.org/action/carnivore/
Date: Thu, 3 Aug 2000 20:24:24 -0500 (CDT)
From: Ben Inkoo Kim <ben9 at ee.tamu dot edu>
Subject: Re: outlook express problem
> If the dropcopy is on the same filesystem as the spool, then you need
> 2X the quota of the expected mailbox size, to make room for copying the
> mailbox. Another approach is to put the dropcopy on another partition
> so that it doesn't count against the user's quota.
The temporary pop file (on another file system) has already moved to the
mail file system. So it doesn't seem applicable to my situation.
Thank you, though.
Regards,
Ben Inkoo Kim [845-7530 / Zach 30B]
Date: Thu, 3 Aug 2000 21:45:08 -0400 (EDT)
From: "Jeff A. Earickson" <jaearick at colby dot edu>
Subject: Re: outlook express problem
My two cents worth here... Why punish your users with disk quotas,
just because some fool sent them a large message? My advice:
a) Set MaxMessageSize (in sendmail, or equivalent in other mailers)
so that sendmail rejects overly large messages.
b) Buy more disk and boost the size of your mail spool space.
c) Clean out old email. I use a perl script that I found on the net
to clean out old messages once a week. It deletes out anything more
than 30 days old that has been opened (marked "read") in my case.
The script can clean out email in several ways, according to taste.
d) Be draconian and turn on the qpopper feature AUTO_DELETE,
but warn your users first or you will make them mad.
I do a-c (but not d) at my site, and I also go after people who let
their mailboxes fill up. And I watch my spool space like a hawk.
Better than using quotas IMHO.
--- Jeff Earickson
On Thu, 3 Aug 2000, Ben Inkoo Kim wrote:
> Date: Thu, 3 Aug 2000 20:24:24 -0500 (CDT)
> From: Ben Inkoo Kim <ben9 at ee.tamu dot edu>
> To: Kenneth Porter <shiva at well dot com>
> Cc: Subscribers of Qpopper <qpopper at lists.pensive dot org>
> Subject: Re: outlook express problem
>
> > If the dropcopy is on the same filesystem as the spool, then you need
> > 2X the quota of the expected mailbox size, to make room for copying the
> > mailbox. Another approach is to put the dropcopy on another partition
> > so that it doesn't count against the user's quota.
>
> The temporary pop file (on another file system) has already moved to the
> mail file system. So it doesn't seem applicable to my situation.
>
> Thank you, though.
>
>
> Regards,
>
> Ben Inkoo Kim [845-7530 / Zach 30B]
>
>
Date: Fri, 4 Aug 2000 15:21:54 +1200 (NZST)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: SUMMARY: qpopper bad performance
On Thu, 3 Aug 2000, Luc Amouriaux wrote:
> Debugging mode showed that too many user were trying to
> read this bulldb at the same time, so they had to wait ("sleep" in the
> source!) to open this file.
I think that "sleep" is better than the old behaviour, which was to exit
with an error.
AB
Date: Fri, 04 Aug 2000 11:45:41 +0800
From: Byron Jones <byron at vianet.net dot au>
Subject: Re: outlook express problem
>My two cents worth here... Why punish your users with disk quotas,
>just because some fool sent them a large message? My advice:
>
>a) Set MaxMessageSize (in sendmail, or equivalent in other mailers)
> so that sendmail rejects overly large messages.
>b) Buy more disk and boost the size of your mail spool space.
>c) Clean out old email. I use a perl script that I found on the net
>to clean out old messages once a week. It deletes out anything more
>than 30 days old that has been opened (marked "read") in my case.
>The script can clean out email in several ways, according to taste.
>d) Be draconian and turn on the qpopper feature AUTO_DELETE,
>but warn your users first or you will make them mad.
>
>I do a-c (but not d) at my site, and I also go after people who let
>their mailboxes fill up. And I watch my spool space like a hawk.
>Better than using quotas IMHO.
i've got 2 cents as well..
i think that it's important to place hard limits on the size of a mailbox
to stop mailbomb attacks against your users.
i use a cronned perl script that builds the sendmail 'access' file (the
sendmail access file allows you to block, at the smtp connection, email for
any user with an error message you define).
i like this solution because it avoids quotas, and it stops emails *before*
they are accepted by out server. with quotas, the email needs to be
accepted and delivered before failure can occur.
-- byron jones ----------------------
systems administrator
vianet australia
http://www.vianet.net.au/~byron
Date: Fri, 4 Aug 2000 17:32:31 +1200 (NZST)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: outlook express problem
On Fri, 4 Aug 2000, Byron Jones wrote:
> >My two cents worth here... Why punish your users with disk quotas,
> >just because some fool sent them a large message? My advice:
> i think that it's important to place hard limits on the size of a mailbox
> to stop mailbomb attacks against your users.
And to prevent DoS attacks against all users by filling the spool.
AB
Date: Fri, 04 Aug 2000 08:03:25 -0500
From: mike miller <mikem at ndtel dot com>
Subject: Re: outlook express problem
The script sounds like a nice way to handle the mailbox size. Would you
be interested in sharing it?
Mike Miller
NDTC
Byron Jones wrote:
>
> >My two cents worth here... Why punish your users with disk quotas,
> >just because some fool sent them a large message? My advice:
> >
> >a) Set MaxMessageSize (in sendmail, or equivalent in other mailers)
> > so that sendmail rejects overly large messages.
> >b) Buy more disk and boost the size of your mail spool space.
> >c) Clean out old email. I use a perl script that I found on the net
> >to clean out old messages once a week. It deletes out anything more
> >than 30 days old that has been opened (marked "read") in my case.
> >The script can clean out email in several ways, according to taste.
> >d) Be draconian and turn on the qpopper feature AUTO_DELETE,
> >but warn your users first or you will make them mad.
> >
> >I do a-c (but not d) at my site, and I also go after people who let
> >their mailboxes fill up. And I watch my spool space like a hawk.
> >Better than using quotas IMHO.
>
> i've got 2 cents as well..
>
> i think that it's important to place hard limits on the size of a mailbox
> to stop mailbomb attacks against your users.
>
> i use a cronned perl script that builds the sendmail 'access' file (the
> sendmail access file allows you to block, at the smtp connection, email for
> any user with an error message you define).
>
> i like this solution because it avoids quotas, and it stops emails *before*
> they are accepted by out server. with quotas, the email needs to be
> accepted and delivered before failure can occur.
>
> -- byron jones ----------------------
> systems administrator
> vianet australia
> http://www.vianet.net.au/~byron
Date: Fri, 4 Aug 2000 09:51:42 -0400 (EDT)
From: "Jeff A. Earickson" <jaearick at colby dot edu>
Subject: scripts to clean out old email
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime at docserver.cac.washington dot edu for more info.
--1482305291-1903590565-965397102=:27156
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
Several people asked about the perl script that I use to clean out
old email. The perl script "expire_mail" is attached, along with
my shell script "do.expire_mail" that I use to march thru our mail
spool file every Sunday morning in the wee hours. We use a hashed
spool directory, hence all those subdirectories in the "do" script.
The "do" script takes the precaution of turning off sendmail and pop
while the it runs (though I don't think it is necessary), and it
notes how many bytes of junk it zapped.
Note: when the perl script deletes mail via the "older than x days"
method, it uses the delivery date, not the date read. This can lead
to the situation where the user has been gone 3 months, reads his
email when he comes back, then has all those messages greater than
30 days old zapped. But the user didn't have 30 days to mull over
the email, so he is mad that his mail got zapped. Beware.
The perl script is also useful for finding out if a user is actually
reading their email, or just letting it stack up. I do
expire_mail -d -S read mailbox
ie run it in debug mode to find out what messages have been marked as
read, but not to change the mailbox.
** Jeff A. Earickson, Ph.D PHONE: 207-872-3659
** Senior UNIX Sysadmin, Information Technology EMAIL: jaearick at colby dot edu
** Colby College, 4214 Mayflower Hill, FAX: 207-872-3555
** Waterville ME, 04901-8842
----------------------------------------------------------------------------
I came, I saw, I applied duct-tape to it.
----------------------------------------------------------------------------
--1482305291-1903590565-965397102=:27156
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=expire_mail
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.HPX.4.21.0008040951410.27156 at host-06.colby dot edu>
Content-Description:
Content-Disposition: attachment; filename=expire_mail
IyEvb3B0L3Blcmw1LmRlYnVnL2Jpbi9wZXJsIC0tCQkJCQkgICAgIC0qLXBl
cmwtKi0NCiMNCiMhL3Vzci9iaW4vcGVybCAtLQkJCQkJICAgICAtKi1wZXJs
LSotDQojDQojIENvcHlyaWdodCAoYykgSW5mb3JtYXRpb24gU3lzdGVtcywg
VGhlIFByZXNzIEFzc29jaWF0aW9uIExpbWl0ZWQgMTk5Mw0KIyBQb3J0aW9u
cyBDb3B5cmlnaHQgKGMpIENvbXB1dGVyIE5ld3NwYXBlciBTZXJ2aWNlcyBM
aW1pdGVkIDE5OTMNCiMgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiMgDQojIExp
Y2Vuc2UgdG8gdXNlLCBjb3B5LCBtb2RpZnksIGFuZCBkaXN0cmlidXRlIHRo
aXMgd29yayBhbmQgaXRzDQojIGRvY3VtZW50YXRpb24gZm9yIGFueSBwdXJw
b3NlIGFuZCB3aXRob3V0IGZlZSBpcyBoZXJlYnkgZ3JhbnRlZCwNCiMgcHJv
dmlkZWQgdGhhdCB5b3UgYWxzbyBlbnN1cmUgbW9kaWZpZWQgZmlsZXMgY2Fy
cnkgcHJvbWluZW50IG5vdGljZXMNCiMgc3RhdGluZyB0aGF0IHlvdSBjaGFu
Z2VkIHRoZSBmaWxlcyBhbmQgdGhlIGRhdGUgb2YgYW55IGNoYW5nZSwgZW5z
dXJlDQojIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYXBwZWFy
IGluIGFsbCBjb3BpZXMsIHRoYXQgYm90aCB0aGUNCiMgY29weXJpZ2h0IG5v
dGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBhcHBlYXIgaW4gc3Vw
cG9ydGluZw0KIyBkb2N1bWVudGF0aW9uLCBhbmQgdGhhdCB0aGUgbmFtZSBv
ZiBDb21wdXRlciBOZXdzcGFwZXIgU2VydmljZXMgbm90DQojIGJlIHVzZWQg
aW4gYWR2ZXJ0aXNpbmcgb3IgcHVibGljaXR5IHBlcnRhaW5pbmcgdG8gZGlz
dHJpYnV0aW9uIG9yIHVzZQ0KIyBvZiB0aGUgd29yayB3aXRob3V0IHNwZWNp
ZmljLCB3cml0dGVuIHByaW9yIHBlcm1pc3Npb24gZnJvbSBDb21wdXRlcg0K
IyBOZXdzcGFwZXIgU2VydmljZXMuDQojIA0KIyBCeSBjb3B5aW5nLCBkaXN0
cmlidXRpbmcgb3IgbW9kaWZ5aW5nIHRoaXMgd29yayAob3IgYW55IGRlcml2
ZWQgd29yaykNCiMgeW91IGluZGljYXRlIHlvdXIgYWNjZXB0YW5jZSBvZiB0
aGlzIGxpY2Vuc2UgYW5kIGFsbCBpdHMgdGVybXMgYW5kDQojIGNvbmRpdGlv
bnMuDQojIA0KIyBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJUyIs
IFdJVEhPVVQgQU5ZIFdBUlJBTlRJRVMgT0YgQU5ZIEtJTkQsDQojIEVJVEhF
UiBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORywgQlVUIE5PVCBMSU1J
VEVEIFRPIEFOWSBJTVBMSUVEDQojIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB
QklMSVRZLCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSwgQU5E
DQojIE5PTklORlJJTkdFTUVOVCBPRiBUSElSRCBQQVJUWSBSSUdIVFMuICBU
SEUgRU5USVJFIFJJU0sgQVMgVE8gVEhFIFFVQUxJVFkNCiMgQU5EIFBFUkZP
Uk1BTkNFIE9GIFRIRSBTT0ZUV0FSRSwgSU5DTFVESU5HIEFOWSBEVVRZIFRP
IFNVUFBPUlQgT1INCiMgTUFJTlRBSU4sIEJFTE9OR1MgVE8gVEhFIExJQ0VO
U0VFLiAgU0hPVUxEIEFOWSBQT1JUSU9OIE9GIFRIRSBTT0ZUV0FSRQ0KIyBQ
Uk9WRSBERUZFQ1RJVkUsIFRIRSBMSUNFTlNFRSAoTk9UIFRIRSBDT1BZUklH
SFQgT1dORVIpIEFTU1VNRVMgVEhFDQojIEVOVElSRSBDT1NUIE9GIEFMTCBT
RVJWSUNJTkcsIFJFUEFJUiBBTkQgQ09SUkVDVElPTi4gIElOIE5PIEVWRU5U
IFNIQUxMDQojIFRIRSBDT1BZUklHSFQgT1dORVIgQkUgTElBQkxFIEZPUiBB
TlkgU1BFQ0lBTCwgSU5ESVJFQ1QgT1IgQ09OU0VRVUVOVElBTA0KIyBEQU1B
R0VTIE9SIEFOWSBEQU1BR0VTIFdIQVRTT0VWRVIgUkVTVUxUSU5HIEZST00g
TE9TUyBPRiBVU0UsIERBVEEgT1INCiMgUFJPRklUUywgV0hFVEhFUiBJTiBB
TiBBQ1RJT04gT0YgQ09OVFJBQ1QsIE5FR0xJR0VOQ0UgT1IgT1RIRVIgVE9S
VElPVVMNCiMgQUNUSU9OLCBBUklTSU5HIE9VVCBPRiBPUiBJTiBDT05ORUNU
SU9OIFdJVEggVEhFIFVTRSBPUiBQRVJGT1JNQU5DRSBPRg0KIyBUSElTIFNP
RlRXQVJFLg0KIw0KIw0KIyAkSWQ6IGV4cGlyZV9tYWlsLHYgMS4xIDE5OTMv
MDYvMDMgMTA6NDM6MjYgcGhpbCBFeHAgJA0KIw0KDQojDQojIEluZm9ybWF0
aW9uIFN5c3RlbXMgRW5naW5lZXJpbmcgR3JvdXANCiMgUGhpbCBNYWxlDQoj
DQoNCmxvY2FsKCRfZXhwaXJlX21haWxfcmNzaWQpID0gJyRJZDogZXhwaXJl
X21haWwsdiAxLjEgMTk5My8wNi8wMyAxMDo0MzoyNiBwaGlsIEV4cCAkJzsN
CmxvY2FsKCRfY29weXJpZ2h0KSA9ICdDb3B5cmlnaHQgKGMpIEluZm9ybWF0
aW9uIFN5c3RlbXMsIFRoZSBQcmVzcyBBc3NvY2lhdGlvbiBMaW1pdGVkIDE5
OTMnOw0KDQpyZXF1aXJlICJnZXRvcHRzLnBsIjsJCQkjIG9wdGlvbiBoYW5k
bGluZw0KcmVxdWlyZSAidGltZWxvY2FsLnBsIjsJCQkjIHRpbWUgY29udmVy
c2lvbg0KcmVxdWlyZSAiY3RpbWUucGwiOwkJCSMgY3RpbWUgZm9yIHBzZXVk
by1tYWlsaW5nDQpyZXF1aXJlICJzdGF0LnBsIjsJCQkjIGZpbGUgc3RhdHVz
DQoNCiMgUGVybCBtYWlsIGV4cGlyZS4NCiMgVGhpcyBwcm9ncmFtIHJlbW92
ZXMgb2xkIG1lc3NhZ2VzIGZyb20gc3lzdGVtIG1haWxib3hlcy4NCiMgSXQg
YXNzdW1lcyB0aGUgZm9ybWF0IG9mIG1haWxib3hlcyB0byBiZSBzdGFuZGFy
ZA0KIyBzZW5kbWFpbCBmb3JtYXQgbWFpbCB3aXRoIGEgYmxhbmsgbGluZSBm
b2xsb3dlZCBieSBhIGBGcm9tICcgbGluZQ0KIyBzdGFydGluZyBlYWNoIGFu
ZCBldmVyeSBtZXNzYWdlLiBNYWlsYm94IGxvY2tpbmcgaXMgdmlhIGZsb2Nr
Lg0KIyBXb3JrcyB1bmRlciBTdW5PUy4NCiMNCiMgT3B0aW9ucyBhcyBmb2xs
b3dzOg0KIyAtdiAJCQl2ZXJib3NlIG91dHB1dA0KIyAtVgkJCWRpc3BsYXkg
dmVyc2lvbiBpbmZvcm1hdGlvbiBhbmQgcXVpdA0KIyAtZCAJCQlkZWJ1ZyBt
b2RlIChubyBjaGFuZ2UgdG8gbWFpbGJveCkNCiMgLWwJCQlkaXNwbGF5IG1l
c3NhZ2VzIGZvciBjcm9udGFiIG91dHB1dA0KIyAtegkJCWRvIG5vdCBkZWxl
dGUgemVybyBsZW5ndGggbWFpbGJveGVzDQojIC10CQkJZG8gbm90IHJlc2V0
IGFjY2VzcyBhbmQgbW9kaWZpY2F0aW9uIHRpbWVzIG9uIG1haWxib3gNCiMg
LW8gCQkJYWx3YXlzIG9wZW4gbWFpbGJveCwgbmV2ZXIganVzdCB0ZXN0IG1v
ZGlmaWNhdGlvbiBkYXRlDQojIC1NCQkJYXBwZW5kIGEgbWVzc2FnZSBkZXRh
aWxpbmcgZGVsZXRlZCBtZXNzYWdlcyBmb3IgdGhlIHVzZXINCiMgLVQJCQlk
byBub3QgcmVjb3JkIGRlbGl2ZXJ5IG9mIG1haWwgc3VtbWFyeSBvbiBtYWls
Ym94IGRhdGUNCiMgLVcJCQlhcHBlbmQgd2FybmluZyBhYm91dCB3aGF0IHdv
dWxkIGJlIGRlbGV0ZWQgKGltcGxlcyBkZWJ1ZykNCiMgLWEgZGF5cwkJbWVz
c2FnZXMgd2hvc2UgYWdlIGlzIGdyZWF0ZXIgdGhhbiBkYXlzIGFyZSBleHBp
cmVkDQojIC1PIGRheXMJCW1lc3NhZ2VzIHdob3NlIGFnZSBpcyBncmVhdGVy
IHRoYW4gZGF5cyBhcmUgZXhwaXJlZA0KIyAtdSB1c2VyCQlvbmx5IGNvbnNp
ZGVyIG1lc3NhZ2VzIGZyb20gdXNlciAocmVnZXhwKQ0KIyAtUyByZWFkfG9s
ZAkJb25seSBjb25zaWRlciBtZXNzYWdlcyB3aXRoIHN0YXR1cyBgb2xkJyBv
ciBgcmVhZCcNCiMgLXMgc3ViamVjdAkJb25seSBjb25zaWRlciBtZXNzYWdl
cyB3aXRoIHN1YmplY3QgKHJlZ2V4cCkNCiMNCiMgQmFzZWQgb24gZXhwaXJl
X21haWwgYnkgU3RldmUgTWl0Y2hlbGwgKHN0ZXZlX21pdGNoZWxsQGNzdWZy
ZXNuby5lZHUpDQojDQoNCiMjIyMjDQojDQojIERlZmluaXRpb25zDQojDQoj
IyMjIw0KDQojIHNpdGUgcG9zdG1hc3RlciAtIFhYWCBjaGFuZ2UgdGhpcyBh
cyByZXF1aXJlZA0KJHBvc3RtYXN0ZXIgPSAicG9zdG1hc3RlclxAY29sYnku
ZWR1IjsNCg0KIyBjdXJyZW50IHVzZXINCiRtZSA9IGdldGxvZ2luIHx8IChn
ZXRwd3VpZCgkPCkpWzBdIHx8ICJ1bmtub3duIjsNCiRob21lID0gJEVOVnsn
SE9NRSd9Ow0KDQojIGRlZmF1bHQgbWFpbGJveCBmb3IgYSB1c2VyIC0gWFhY
IGNoYW5nZSB0aGlzIGFzIHJlcXVpcmVkDQokZGVmYXVsdF9tYWlsYm94ID0g
JEVOVnsnTUFJTEJPWCd9IHx8ICIvdmFyL21haWwvJG1lIjsNCg0KIy0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMgbm90aWNlIHRvIGFwcGVuZCB0byBs
aXN0IG9mIGRlbGV0ZWQgbWVzc2FnZXMNCiMtLS1tb2RpZmllZCBmb3IgQ29s
YnkNCiRub3RpY2UgPSAiDQpIZWxsbywNCg0KVGhlIG1lc3NhZ2VzIGxpc3Rl
ZCBiZWxvdywgd2hpY2ggeW91IGhhZCBwcmV2aW91c2x5IHJlYWQgYW5kIHdo
aWNoIHdlcmUNCm1vcmUgdGhhbiAzMCBkYXlzIG9sZCwgaGF2ZSBiZWVuIGRl
bGV0ZWQgZnJvbSB5b3VyIHN5c3RlbSBtYWlsYm94IA0Kb24gQ29sYnkncyBt
YWlsIHNlcnZlciBieSB0aGUgc3lzdGVtJ3MgbWFpbCBleHBpcnkgYWdlbnQu
ICBGb3IgaW5mb3JtYXRpb24NCmFib3V0IENvbGJ5J3MgcG9saWN5IG9uIG9s
ZCBlbWFpbCwgcGxlYXNlIHNlZSB0aGUgd2VicGFnZToNCg0KICAgaHR0cDov
L3d3dy5jb2xieS5lZHUvaW5mby50ZWNoL25ld3MvZW1haWxjaGFuZ2UuaHRt
bA0KDQpJZiB5b3UgYXJlIGEgRXVkb3JhIHVzZXIsIHRoaXMgd2VicGFnZSB3
aWxsIGV4cGxhaW4gd2h5IG1lc3NhZ2VzIHlvdQ0KdGhvdWdodCB0aGF0IHlv
dSBoYWQgYWxyZWFkeSBkZWxldGVkIGFyZSBsaXN0ZWQgYmVsb3cuICBQbGVh
c2Ugbm90ZSB0aGUNCmRpc2N1c3Npb24gYWJvdXQgdGhlIFwiTGVhdmUgTWFp
bCBvbiBTZXJ2ZXJcIiBvcHRpb247IHR1cm4gdGhpcyBvcHRpb24gb2ZmDQpp
ZiB5b3UgZG8gbm90IG5lZWQgaXQuDQoNCklmIHlvdSByZWFkIHlvdXIgbWFp
bCBvbiBjb2xieTAsIHBsZWFzZSBkZWxldGUgb2xkIG1haWwgb3IgZmlsZSBp
dCBpbiANCnlvdXIgcGVyc29uYWwgbWFpbCBmb2xkZXJzLiAgQW5kIHBsZWFz
ZSByZWFkIHlvdXIgZS1tYWlsIG9uIGEgcmVndWxhcg0KYmFzaXMgc28gaXQg
ZG9lc24ndCBzdGFjayB1cC4NCg0KICAgVGhhbmsgWW91LCANCiAgIFRoZSBG
b2xrcyBpbiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5IFNlcnZpY2VzIjsNCg0K
Iy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMgd2FybmluZyBhYm91dCBv
bGQgbWFpbCBtZXNzYWdlcw0KIy0tLW1vZGlmaWVkIGZvciBDb2xieQ0KJHdh
cm5pbmc9ICINCkhlbGxvLA0KDQpUaGUgbWVzc2FnZXMgbGlzdGVkIGJlbG93
LCB3aGljaCB5b3UgaGF2ZSBwcmV2aW91c2x5IHJlYWQgYW5kIHdoaWNoIGhh
dmUNCmRlbGl2ZXJ5IGRhdGVzIG1vcmUgdGhhbiAzMCBkYXlzIG9sZCwgc2hv
dWxkIGJlIGRlbGV0ZWQgZnJvbSB5b3VyIHN5c3RlbSANCm1haWxib3ggb24g
Q29sYnkncyBtYWlsIHNlcnZlci4NCg0KQWZ0ZXIgSmFudWFyeSAxLCAxOTk5
LCBhbnkgbWFpbCBtZXNzYWdlIG9uIHRoZSBDb2xieSBtYWlsIHNlcnZlcg0K
cHJldmlvdXNseSBtYXJrZWQgYXMgXCJyZWFkXCIgYnkgdGhlIG1haWxlciBz
b2Z0d2FyZSwgYW5kIGdyZWF0ZXIgdGhhbiANCjMwIGRheXMgb2xkIHdpbGwg
YmUgYXV0b21hdGljYWxseSBkZWxldGVkIGZyb20geW91ciBzeXN0ZW0gbWFp
bGJveC4gIA0KQSBjb3B5IHdpbGwgKm5vdCogYmUgc2F2ZWQgYW55d2hlcmUg
LS0gdGhlIG1lc3NhZ2Ugd2lsbCBiZSBHT05FLiAgDQpVbnJlYWQgbWVzc2Fn
ZXMsIG5vIG1hdHRlciBob3cgb2xkLCB3aWxsIG5vdCBiZSBkZWxldGVkLg0K
DQpQbGVhc2Ugc2VlIHRoZSB3ZWJwYWdlOg0KDQogICBodHRwOi8vd3d3LmNv
bGJ5LmVkdS9pbmZvLnRlY2gvbmV3cy9lbWFpbGNoYW5nZS5odG1sDQoNCmZv
ciBmdXJ0aGVyIGluZm9ybWF0aW9uIGFib3V0IENvbGJ5J3MgcG9saWN5IG9u
IG9sZCBlbWFpbC4gIElmIHlvdSBhcmUgYSANCkV1ZG9yYSB1c2VyLCB0aGlz
IHdlYnBhZ2Ugd2lsbCBleHBsYWluIHdoeSBtZXNzYWdlcyB5b3UgdGhvdWdo
dCB0aGF0IHlvdSANCmhhZCBhbHJlYWR5IGRlbGV0ZWQgYXJlIGxpc3RlZCBi
ZWxvdy4gIFBsZWFzZSBub3RlIHRoZSBkaXNjdXNzaW9uIGFib3V0IHRoZSAN
ClwiTGVhdmUgTWFpbCBvbiBTZXJ2ZXJcIiBvcHRpb247IHR1cm4gdGhpcyBv
cHRpb24gb2ZmIGlmIHlvdSBkbyBub3QgbmVlZCBpdC4NCg0KSWYgeW91IHJl
YWQgeW91ciBtYWlsIG9uIGNvbGJ5MCwgcGxlYXNlIGRlbGV0ZSBvbGQgbWFp
bCBvciBmaWxlIGl0IGluIA0KeW91ciBwZXJzb25hbCBtYWlsIGZvbGRlcnMu
ICBBbmQgcGxlYXNlIHJlYWQgeW91ciBlLW1haWwgb24gYSByZWd1bGFyDQpi
YXNpcyBzbyBpdCBkb2Vzbid0IHN0YWNrIHVwLg0KDQogICBUaGFuayBZb3Us
IA0KICAgVGhlIEZvbGtzIGluIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kgU2Vy
dmljZXMiOw0KDQojLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQojIHNl
dCB0aGUgdW1hc2sgZm9yIHRlbXAgZmlsZXMNCnVtYXNrKCAwNzAwICk7DQoN
CiMgbWFrZSBzdGRvdXQgdW5idWZmZXJlZA0Kc2VsZWN0KFNURE9VVCk7ICR8
ID0gMTsNCg0KJExPQ0tfRVggPSAyOwkJCQkjIGxvY2sNCiRMT0NLX1VOID0g
ODsJCQkJIyB1bmxvY2sNCiRTVEFSVF9USU1FID0gdGltZTsJCQkjIHRpbWUg
cmlnaHQgbm93DQokU0VDX1BFUl9EQVkgPSAyNCAqIDYwICogNjA7CQkjIHNl
Y29uZHMgaW4gYSBkYXkNCiRsaW5lX2J1ZmZlciA9ICIiOwkJCSMgZW1wdHkg
bGluZSBidWZmZXINCg0KIyBtb250aCBudW1iZXJzDQokbW9uX251bXsnSmFu
J30gPSAwOw0KJG1vbl9udW17J0ZlYid9ID0gMTsNCiRtb25fbnVteydNYXIn
fSA9IDI7DQokbW9uX251bXsnQXByJ30gPSAzOw0KJG1vbl9udW17J01heSd9
ID0gNDsNCiRtb25fbnVteydKdW4nfSA9IDU7DQokbW9uX251bXsnSnVsJ30g
PSA2Ow0KJG1vbl9udW17J0F1Zyd9ID0gNzsNCiRtb25fbnVteydTZXAnfSA9
IDg7DQokbW9uX251bXsnT2N0J30gPSA5Ow0KJG1vbl9udW17J05vdid9ID0g
MTA7DQokbW9uX251bXsnRGVjJ30gPSAxMTsNCg0KIyMjIyMNCiMNCiMgU3Vw
cG9ydA0KIw0KIyMjIyMNCg0KIyBsaW5lIGJ1ZmZlciBmb3IgbG9vay1haGVh
ZA0KDQpzdWIgZ2V0X2xpbmUNCnsNCglsb2NhbCggJGxpbmUgKSA9ICIiOwkJ
CSMgbGluZSB0byByZXR1cm4NCg0KCWlmKCAhICgkbGluZV9idWZmZXIgZXEg
IiIpICkgew0KCQkkbGluZSA9ICRsaW5lX2J1ZmZlcjsNCgkJJGxpbmVfYnVm
ZmVyID0gIiI7DQoJfSBlbHNlIHsNCgkJJGxpbmUgPSA8TUJPWD47DQoJfQ0K
CXJldHVybiAkbGluZTsNCn0NCg0KIyByZWFkIG1lc3NhZ2UgZnJvbSBtYWls
Ym94DQoNCnN1YiByZWFkX21lc3NhZ2UNCnsNCglsb2NhbCggJG1zZyApID0g
IiI7CQkJIyBtZXNzYWdlIHRvIHNlbmQgYmFjaw0KCWxvY2FsKCAkcHJldl9i
bGFuayApID0gMTsJCSMgYXNzdW1lIHByZXZpb3VzIGxpbmUgYmxhbmsNCgls
b2NhbCggJHNlZW5fZnJvbSApID0gMDsJCSMgc2VlbiBhIGZyb20gbGluZQ0K
CWxvY2FsKCAkbGluZSApID0gIiI7CQkJIyBjdXJyZW50IGxpbmUNCg0KCSMg
cmVzZXQgc29tZSBnbG9iYWxzDQoJJG1zZ19zdGF0dXMgPSAiIjsNCgkkbXNn
X3N1YmplY3QgPSAiIjsNCgkkbXNnX2RhdGUgPSAiIjsNCg0KCXdoaWxlKCAk
bGluZSA9ICZnZXRfbGluZSApIHsNCiAgICANCgkJaWYoICRsaW5lID1+IC9e
RnJvbVxzKyhbXlxzXSspXHMrKC4qKSQvICkgew0KCQkJIyBpZiBwcmV2aW91
cyBsaW5lIHdhcyBibGFuaywgdGhlbiBsZWdhbCBmcm9tIGxpbmUNCgkJCWlm
KCAkcHJldl9ibGFuayApIHsNCgkJCQkjIGlmIGFscmVhZHkgc2VlbiBhIGxl
Z2FsIGZyb20gbGluZSwgdGhlbiB0aGlzIGlzIG5leHQgbWVzc2FnZQ0KCQkJ
CWlmKCAkc2Vlbl9mcm9tICkgew0KCQkJCQkjIHB1c2hiYWNrIHRoaXMgZnJv
bSBsaW5lDQoJCQkJCSRsaW5lX2J1ZmZlciA9ICRsaW5lOw0KCQkJCQlyZXR1
cm4gJG1zZzsNCgkJCQl9DQoJCQkJJHNlZW5fZnJvbSsrOw0KCQkJCSMgRnJv
bSBsaW5lIGZvdW5kLCBleHRyYWN0IGluZm9ybWF0aW9uDQoJCQkJKCAkbXNn
X2Zyb20sICRtc2dfZGF0ZSApID0gKCAkMSwgJDIgKTsNCgkJCQkkbXNnX3N0
YW1wID0gJnJjdGltZSggJG1zZ19kYXRlICk7DQoJCQkJJG1zZ19hZ2UgPSAm
ZGF5c19vbGQoICRtc2dfc3RhbXAgKTsNCgkJCX0NCgkJfSBlbHNpZiggJGxp
bmUgPX4gL15bU3NddGF0dXM6IChbQS1aYS16XSspLyApIHsNCgkJCSggJG1z
Z19zdGF0dXMgKSA9ICggJDEgKTsNCgkJfSBlbHNpZiggJGxpbmUgPX4gL15b
U3NddWJqZWN0OiAoLiopJC8gKSB7DQoJCQkoICRtc2dfc3ViamVjdCApID0g
KCAkMSApOw0KCQl9DQoNCgkJIyBzZXQgcHJldmlvdXMgbGluZQ0KCQlpZigg
JGxpbmUgPX4gL14kLyApIHsNCgkJCSRwcmV2X2JsYW5rID0gMTsNCgkJfSBl
bHNlIHsNCgkJCSRwcmV2X2JsYW5rID0gMDsNCgkJfQ0KDQoJCSRtc2cgLj0g
JGxpbmU7DQoJfQ0KDQoJcmV0dXJuICRtc2c7DQp9DQoNCiMgd3JpdGUgYSBt
ZXNzYWdlIGludG8gYSBtYWlsYm94DQpzdWIgd3JpdGVfbWVzc2FnZQ0Kew0K
CXByaW50IFRNUEYgIkBfIjsNCn0NCg0KIyBwYXJzZSB0aGUgY3RpbWUgc3Ry
aW5nIGludG8gYSB0aW1lIHZhbHVlDQojIEZyb20gbGluZSBjb250YWlucyBs
b2NhbCB0aW1lDQoNCnN1YiByY3RpbWUNCnsNCglsb2NhbCggJHB0ICkgPSBA
XzsJCQkjIHRpbWUgdG8gY29udmVydA0KCWxvY2FsKCAkY3QgKSA9IC0xOwkJ
CSMgY29udmVydGVkIHRpbWUNCg0KCWlmKCRwdCA9fiAvXihbQS1aYS16XSsp
XHMrKFtBLVphLXpdKylccysoWzAtOV0rKVxzKyhbMC05Ol0rKVxzKyhbMC05
XSspLyApIHsNCgkJKCAkZGF5LCAkbW9uLCAkbWRheSwgJHRpbWUsICR5ZWFy
ICkgPSAoICQxLCAkMiwgJDMsICQ0LCAkNSApOw0KCQkoICRob3VyLCAkbWlu
LCAkc2VjICkgPSBzcGxpdCggJzonLCAkdGltZSApOw0KCQlpZiggJHllYXIg
PiAxOTAwICkgeyAkeWVhciAtPSAxOTAwOyB9DQoJCSRjdCA9ICZ0aW1lbG9j
YWwoJHNlYywkbWluLCRob3VyLCRtZGF5LCRtb25fbnVteyRtb259LCR5ZWFy
KTsNCgl9DQoJcmV0dXJuICRjdDsNCn0NCg0KIyBhZ2UgaW4gZGF5cw0Kc3Vi
IGRheXNfb2xkDQp7DQoJbG9jYWwoICRhZ2V2ICkgPSBAXzsJCQkjIHRpbWUg
dG8gY29udmVydA0KDQoJcmV0dXJuKCAoICRTVEFSVF9USU1FIC0gJGFnZXYg
KSAvICRTRUNfUEVSX0RBWSApOw0KfQ0KDQojIGJhc2VuYW1lDQpzdWIgYmFz
ZW5hbWUNCnsNCglsb2NhbCggJHBhdGggKSA9IEBfOwkJCSMgcGF0aCB0byBm
aW5kIHRoZSBiYXNlIG9mDQoJbG9jYWwoICRiYXNlICkgPSByaW5kZXgoICRw
YXRoLCAiLyIgKTsNCg0KCWlmKCAkYmFzZSA8IDAgKSB7DQoJCSRiYXNlID0g
JHBhdGg7DQoJfSBlbHNlIHsNCgkJJGJhc2UgPSBzdWJzdHIoJHBhdGgsICRi
YXNlICsgMSk7DQoJfQ0KDQoJcmV0dXJuICRiYXNlOw0KfQ0KDQojIHVzYWdl
IG1lc3NhZ2UNCnN1YiB1c2FnZQ0Kew0KCXByaW50IFNUREVSUiAidXNhZ2U6
IGV4cGlyZV9tYWlsIFstdmxWXSBbLXpvdFRNV10gWy1kXSB7IFstTyBkYXlz
XSBbLXUgdXNlcl0gWy1TIHJlYWR8b2xkXSBbLXMgc3ViamVjdF0gfSBtYWls
Ym94Li4uXG4iOw0KCWV4aXQgMDsNCn0NCg0KIyMjIyMNCiMNCiMgTWFpbg0K
Iw0KIyMjIyMNCg0KJkdldG9wdHMoICdWdk86YTpvdTp6ZFM6czpNdFRsVycg
KSB8fCAmdXNhZ2U7DQoNCiMgY29tcGF0DQokb3B0X2EgPSAkb3B0X08gaWYg
KCRvcHRfTyAmJiAhJG9wdF9hKTsNCg0KIyBjaGVjayB2ZXJzaW9uDQppZigg
JG9wdF9WICkgew0KCXByaW50ICJleHBpcmVfbWFpbDogbWFpbCBleHBpcnkg
YWdlbnRcbiI7DQoJcHJpbnQgImV4cGlyZV9tYWlsOiAkX2V4cGlyZV9tYWls
X3Jjc2lkXG4iOw0KCSZ1c2FnZTsNCn0NCg0KIyB1c2UgZGVmYXVsdCBtYWls
Ym94IGlmIG5vbiBzdXBwbGllZA0KaWYoICQjQVJHViA8ICRbICkgew0KCSRB
UkdWWzBdID0gIiRkZWZhdWx0X21haWxib3giOw0KfQ0KDQojIGRlY29kZSBz
dGF0dXMgb3B0aW9uDQppZiggJG9wdF9TICkgew0KCWlmKCAkb3B0X1MgZXEg
Im9sZCIgKSB7DQoJCSRvcHRfUyA9ICJPIjsNCgl9IGVsc2lmKCAkb3B0X1Mg
ZXEgInJlYWQiICkgew0KCQkkb3B0X1MgPSAiUiI7DQoJfSBlbHNlIHsNCgkJ
cHJpbnQgU1RERVJSICJleHBpcmVfbWFpbDogc3RhdHVzIG1heSBvbmx5IGJl
IG9uZSBvZiBgb2xkJyBvciBgdW5yZWFkJ1xuIjsNCgkJJnVzYWdlOw0KCX0N
Cn0NCg0KIyBjaGVjayB3ZSBhcmUgYWN0dWFsbHkgZG9pbmcgc29tZSBwcm9j
ZXNzaW5nDQppZiggISRvcHRfYSAmJiAhJG9wdF91ICYmICEkb3B0X1MgJiYg
ISRvcHRfcyApIHsNCglwcmludCBTVERFUlIgImV4cGlyZV9tYWlsOiBtdXN0
IHNwZWNpZnkgYXQgbGVhc3Qgb25lIG9mIC1PLCAtdSwgLVMgb3IgLXNcbiI7
DQoJJnVzYWdlOw0KfQ0KDQojIHdhcm5pbmcgbW9kZSBpbXBsZXMgZGVidWcg
bW9kZQ0KaWYoICRvcHRfVyApIHsgJG9wdF9kID0gMTsgfQ0KDQojIGRlYnVn
IG1vZGUgaW1wbGllcyB2ZXJib3NlIG1vZGUNCmlmKCAkb3B0X2QgKSB7ICRv
cHRfdiA9IDE7IH0NCg0KIyBmb3JlYWNoIG1haWxib3guLi4NCndoaWxlKCAk
bWFpbGJveCA9IHNoaWZ0ICkgew0KDQoJaWYoICRvcHRfdiAmJiAhJG9wdF9X
ICkgeyBwcmludCBTVERPVVQgIkNoZWNraW5nIG1haWxib3ggJG1haWxib3hc
biI7IH0NCg0KCSMgZG9lcyBtYWlsYm94IGV4aXN0DQoJaWYoICEgLWYgJG1h
aWxib3ggKSB7IG5leHQ7IH0NCg0KCSMgc3RhdCB0aGUgbWFpbGJveA0KCUBz
YiA9ICZTdGF0KCRtYWlsYm94KTsNCg0KCSMgY2FuIGl0IGJlIGRlbGV0ZWQg
bm93Pw0KCWlmKCAhJG9wdF9vICYmICRvcHRfYSApIHsNCgkJIyBjaGVjayB0
aGUgbW9kaWZpY2F0aW9uIGRhdGUNCgkJJGFnZSA9ICZkYXlzX29sZChAc2Jb
JFNUX01USU1FXSk7DQoJCWlmKCAkYWdlID4gJG9wdF9hICkgew0KCQkJaWYo
ICRvcHRfdiApIHsgcHJpbnQgU1RET1VUICJFeHBpcmluZyBtYWlsYm94ICRt
YWlsYm94XG4iOyB9DQoJCQlpZiggISRvcHRfZCApIHsNCgkJCQlpZiggJG9w
dF96ICkgew0KCQkJCQlvcGVuKCBNQk9YLCAiPiRtYWlsYm94IiApIHx8IA0K
CQkJCQlwcmludCBTVERFUlIgImV4cGlyZV9tYWlsOiBmYWlsZWQgdG8gdHJ1
bmNhdGUgJG1haWxib3hcbiI7DQoJCQkJCWNsb3NlKCBNQk9YICk7DQoJCQkJ
fSBlbHNlIHsNCgkJCQkJdW5saW5rKCAkbWFpbGJveCApIHx8DQoJCQkJCXBy
aW50IFNUREVSUiAiZXhwaXJlX21haWw6IGZhaWxlZCB0byByZW1vdmUgJG1h
aWxib3hcbiI7DQoJCQkJfQ0KCQkJfQ0KCQkJbmV4dDsNCgkJfQ0KCX0NCg0K
CSMgb3BlbiB0aGUgbWFpbGJveA0KCWlmKCAhb3BlbiggTUJPWCwgIis8JG1h
aWxib3giICkgKSB7DQoJCXByaW50IFNUREVSUiAiZXhwaXJlX21haWw6IHVu
YWJsZSB0byBvcGVuICRtYWlsYm94XG4iOw0KCQluZXh0Ow0KCX0NCg0KCSMg
bG9jayB0aGUgbWFpbGJveA0KCWlmKCAhZmxvY2soIE1CT1gsICRMT0NLX0VY
ICkgKSB7DQoJCXByaW50IFNUREVSUiAiZXhwaXJlX21haWw6IHVuYWJsZSB0
byBsb2NrICRtYWlsYm94XG4iOw0KCQljbG9zZSggTUJPWCApOw0KCQluZXh0
Ow0KCX0NCg0KCSMgb3BlbiB0aGUgdGVtcG9yYXJ5IGZpbGUNCgkkdG1wbmFt
ZSA9ICIkbWFpbGJveC5leHAkJCI7DQoJaWYoICFvcGVuKCBUTVBGLCAiKz4k
dG1wbmFtZSIgKSApIHsNCgkJcHJpbnQgU1RERVJSICJleHBpcmVfbWFpbDog
dW5hYmxlIHRvIGNyZWF0ZSB0ZW1wb3JhcnkgZmlsZSBmb3IgJG1haWxib3hc
biI7DQoJCWNsb3NlKCBNQk9YICk7DQoJCW5leHQ7DQoJfQ0KCXVubGluaygg
JHRtcG5hbWUgKTsNCg0KCSMgaW5pdCBjb3VudGVycw0KCSRjb3VudCA9IDA7
DQoJJGV4cCA9IDA7DQoNCgkjIHJlYWQgZWFjaCBtZXNzYWdlIGluIHR1cm4N
Cgl3aGlsZSggJG1zZyA9ICZyZWFkX21lc3NhZ2UgKSB7DQoNCgkJJGNvdW50
Kys7DQoNCgkJIyBsb29raW5nIGZvciBzcGVjaWZpYyBmcm9tIHVzZXJzDQoJ
CWlmKCAkb3B0X3UgKSB7DQoJCQlpZiggISAoJG1zZ19mcm9tID1+IC8kb3B0
X3UvKSApIHsNCgkJCQlpZiggJG9wdF92ICYmICEkb3B0X1cgKSB7DQoJCQkJ
CSNwcmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IGZyb20gICBcciI7DQoJ
CQkJCXByaW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogZnJvbSAgIFxuIjsN
CgkJCQl9DQoJCQkmd3JpdGVfbWVzc2FnZSggJG1zZyApOw0KCQkJbmV4dDsN
CgkJCX0NCgkJfQ0KDQoJCSMgY2hlY2sgbWVzc2FnZSBzdGF0dXMNCgkJaWYo
ICRvcHRfUyApIHsNCgkJCWlmKCAhKCRtc2dfc3RhdHVzID1+IC8kb3B0X1Mv
KSApIHsNCgkJCQlpZiggJG9wdF92ICYmICEkb3B0X1cgKSB7DQoJCQkJCSNw
cmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IHN0YXR1cyAgIFxyIjsNCgkJ
CQkJcHJpbnQgU1RET1VUICJcdE1zZyAjJGNvdW50OiBzdGF0dXMgICBcbiI7
DQoJCQkJfQ0KCQkJCSZ3cml0ZV9tZXNzYWdlKCAkbXNnICk7DQoJCQkJbmV4
dDsNCgkJCX0NCgkJfQ0KDQoJCSMgY2hlY2sgbWVzc2FnZSBzdWJqZWN0DQoJ
CWlmKCAkb3B0X3MgKSB7DQoJCQlpZiggISAoJG1zZ19zdWJqZWN0ID1+IC8k
b3B0X3MvKSApIHsNCgkJCQlpZiggJG9wdF92ICYmICEkb3B0X1cgKSB7DQoJ
CQkJCSNwcmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IHN1YmplY3QgICBc
ciI7DQoJCQkJCXByaW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogc3ViamVj
dCAgIFxuIjsNCgkJCQl9DQoJCQkmd3JpdGVfbWVzc2FnZSggJG1zZyApOw0K
CQkJbmV4dDsNCgkJCX0NCgkJfQ0KDQoJCSMgb25seSBvdGhlciB0aGluZyB0
byBjaGVjayBpcyBtZXNzYWdlIGFnZQ0KCQlpZiggJG9wdF9hICkgew0KCQkJ
aWYoICRtc2dfYWdlIDw9ICRvcHRfYSApIHsNCgkJCQlpZiggJG9wdF92ICYm
ICEkb3B0X1cgKSB7DQoJCQkJCSNwcmludCBTVERPVVQgIlx0TXNnICMkY291
bnQ6IG5ld2VyICAgXHIiOw0KCQkJCQlwcmludCBTVERPVVQgIlx0TXNnICMk
Y291bnQ6IG5ld2VyICAgXG4iOw0KCQkJCX0NCgkJCQkmd3JpdGVfbWVzc2Fn
ZSggJG1zZyApOw0KCQkJCW5leHQ7DQoJCQl9DQoJCX0NCg0KCQkjIGxvZyB0
aGUgZXhwaXJ5DQoJCWlmKCAkb3B0X3YgJiYgISRvcHRfVyApIHsNCgkJCSNw
cmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IGV4cGlyZWQgICBcciI7DQoJ
CQlwcmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IGV4cGlyZWQgICBcbiI7
DQoJCX0NCg0KCQkjIGNvcHkgbWVzc2FnZSBhY3Jvc3MgaWYgaW4gZGVidWcN
CgkJaWYoICRvcHRfZCApIHsNCgkJCSZ3cml0ZV9tZXNzYWdlKCAkbXNnICk7
DQoJCQlpZigkb3B0X1cpIHsNCgkJCQkjIHJlY29yZCB0aGUgbWFpbCBtZXNz
YWdlIGZyb20gYW5kIHN1YmplY3QgbGluZQ0KCQkJCSRwYWQgPSAnICcgeCAo
MjUgLSBsZW5ndGgoJG1zZ19mcm9tKSApOw0KCQkJCSRucGFkID0gJyAnIHgg
KCA0IC0gbGVuZ3RoKCRjb3VudCkgKTsNCgkJCQkkc3ViamVjdHNbJGV4cF0g
PSAiJG5wYWQkY291bnQgJG1zZ19mcm9tJHBhZCAkbXNnX2RhdGVcbiAgICAg
JG1zZ19zdWJqZWN0XG4iOw0KCQkJfQ0KCQl9IGVsc2Ugew0KCQkJIyByZWNv
cmQgdGhlIG1haWwgbWVzc2FnZSBmcm9tIGFuZCBzdWJqZWN0IGxpbmUNCgkJ
CSRwYWQgPSAnICcgeCAoMjUgLSBsZW5ndGgoJG1zZ19mcm9tKSApOw0KCQkJ
JG5wYWQgPSAnICcgeCAoIDQgLSBsZW5ndGgoJGNvdW50KSApOw0KCQkJJHN1
YmplY3RzWyRleHBdID0gIiRucGFkJGNvdW50ICRtc2dfZnJvbSRwYWQgJG1z
Z19kYXRlXG4gICAgICRtc2dfc3ViamVjdFxuIjsNCgkJfQ0KDQoJCSMgaW5j
cmVtZW50IHRoZSBleHBpcmVkIG1lc3NhZ2UgY291bnQNCgkJJGV4cCsrOw0K
CX0NCg0KCWlmKCAhJG9wdF9kICkgew0KDQoJCSMgaWYgc2VuZGluZyBtYWls
IHRvIHRoZSBvd25lciBvZiB0aGUgbWFpbGJveCwgYXBwZW5kIG1lc3NhZ2Ug
b24gdGhlIGVuZA0KCQlpZiggJG9wdF9NICYmICRleHAgPiAwICkgew0KCQkJ
Y2hvcCggJGN0ID0gJmN0aW1lKHRpbWUpICk7DQoJCQkkdG8gPSAmYmFzZW5h
bWUoICRtYWlsYm94ICk7DQoJCQljaG9wKCAkZnJvbWRhdGUgPSBgZGF0ZSAr
XCIlYSAlYiAlZCAlWCAlWVwiYCApOw0KCQkJcHJpbnQgVE1QRiAiRnJvbSAk
cG9zdG1hc3RlciAgJGZyb21kYXRlXG4iOw0KCQkJcHJpbnQgVE1QRiAiRGF0
ZTogJGN0XG4iOw0KCQkJcHJpbnQgVE1QRiAiRnJvbTogJHBvc3RtYXN0ZXIg
KE1haWwgRXhwaXJ5IEFnZW50KVxuIjsNCgkJCXByaW50IFRNUEYgIlJlcGx5
LVRvOiAkcG9zdG1hc3RlclxuIjsNCgkJCXByaW50IFRNUEYgIlRvOiAkdG9c
biI7DQoJCQlwcmludCBUTVBGICJTdWJqZWN0OiBFeHBpcmVkIE1haWwgU3Vt
bWFyeVxuXG4iOw0KCQkJcHJpbnQgVE1QRiAiJG5vdGljZVxuXG4iOw0KCQkJ
IyBmaXR0ZWQgdG8gJHN1YmplY3RzIGxheW91dA0KCQkJcHJpbnQgVE1QRiAi
IE1zZyBGcm9tICYgU3ViamVjdCAgICAgICAgICAgIERhdGVkXG5cbiI7DQoJ
CQlmb3JlYWNoICRtc2cgKCBAc3ViamVjdHMgKSB7DQoJCQkJcHJpbnQgVE1Q
RiAiJG1zZ1xuIjsNCgkJCX0NCg0KCQkJaWYoICEkb3B0X1QgKSB7DQoJCQkJ
IyBzZXQgdGhlIG1vZGlmaWNhdGlvbiB0aW1lIGZvciB0aGUgbWFpbGJveCB0
byBiZSBub3cNCgkJCQlAc2JbJFNUX01USU1FXSA9IHRpbWU7DQoJCQl9DQoJ
CX0NCg0KCQkjIGNvcHkgZGF0YSBiYWNrIGludG8gbWFpbGJveCB0byBwcmVz
ZXJ2ZSBwZXJtaXNzaW9ucywgY3JlYXRpb24gdGltZQ0KCQkjIGFuZCB1c2Vy
IGFuZCBncm91cCBpZA0KDQoJCSMgemVybyBsZW5ndGggdGhlIG1haWxib3gN
CgkJdHJ1bmNhdGUoIE1CT1gsIDAgKTsNCgkJIyAqKiogU1RBUlQgQ3JpdGlj
YWwNCgkJIyBhbnkgZGF0YSB0byBjb3B5Pw0KCQlpZiggJGV4cCA8PSAkY291
bnQgKSB7DQoJCQkjIHJlc3RhcnQgYm90aCBmaWxlcw0KCQkJc2VlayhNQk9Y
LCAwLCAwKTsNCgkJCXNlZWsoVE1QRiwgMCwgMCk7DQoJCQkjIGNvcHkgZmls
ZSBpbnRvIG1haWxib3gsIGJldHRlciB3aXRoIHN5c3JlYWQvc3lzd3JpdGU/
DQoJCQl3aGlsZSggPFRNUEY+ICkgew0KCQkJCXByaW50IE1CT1ggJF87DQoJ
CQl9DQoJCX0gZWxzaWYoICEkb3B0X3ogKSB7DQoJCQl1bmxpbmsoICRtYWls
Ym94ICk7DQoJCX0NCgkJIyAqKiogRU5EIENyaXRpY2FsDQoNCgl9IGVsc2Ug
ew0KCQkjIGlmIHNlbmRpbmcgd2FybmluZyB0byB0aGUgb3duZXIgb2YgdGhl
IG1haWxib3gsIGFwcGVuZCB3YXJuaW5nDQoJCWlmKCAkb3B0X1cgJiYgJGV4
cCA+IDAgKSB7DQoJCQljaG9wKCAkY3QgPSAmY3RpbWUodGltZSkgKTsNCgkJ
CSR0byA9ICZiYXNlbmFtZSggJG1haWxib3ggKTsNCgkJCWNob3AoICRmcm9t
ZGF0ZSA9IGBkYXRlICtcIiVhICViICVkICVYICVZXCJgICk7DQpwcmludGYo
ImZyb21kYXRlID0gJGZyb21kYXRlXG4iKTsNCgkJCXByaW50IFRNUEYgIkZy
b20gJHBvc3RtYXN0ZXIgICRmcm9tZGF0ZVxuIjsNCgkJCXByaW50IFRNUEYg
IkRhdGU6ICRjdFxuIjsNCgkJCXByaW50IFRNUEYgIkZyb206ICRwb3N0bWFz
dGVyIChNYWlsIEV4cGlyeSBBZ2VudClcbiI7DQoJCQlwcmludCBUTVBGICJS
ZXBseS1UbzogJHBvc3RtYXN0ZXJcbiI7DQoJCQlwcmludCBUTVBGICJUbzog
JHRvXG4iOw0KCQkJcHJpbnQgVE1QRiAiU3ViamVjdDogUGxlYXNlIGRlbGV0
ZSBvbGQgbWFpbCBmcm9tIHN5c3RlbSBtYWlsYm94XG5cbiI7DQoJCQlwcmlu
dCBUTVBGICIkd2FybmluZ1xuXG4iOw0KCQkJIyBmaXR0ZWQgdG8gJHN1Ympl
Y3RzIGxheW91dA0KCQkJcHJpbnQgVE1QRiAiIE1zZyBGcm9tICYgU3ViamVj
dCAgICAgICAgICAgIERhdGVkXG5cbiI7DQoJCQlmb3JlYWNoICRtc2cgKCBA
c3ViamVjdHMgKSB7DQoJCQkJcHJpbnQgVE1QRiAiJG1zZ1xuIjsNCgkJCX0N
Cg0KCQkJaWYoICEkb3B0X1QgKSB7DQoJCQkJIyBzZXQgdGhlIG1vZGlmaWNh
dGlvbiB0aW1lIGZvciB0aGUgbWFpbGJveCB0byBiZSBub3cNCgkJCQlAc2Jb
JFNUX01USU1FXSA9IHRpbWU7DQoJCQl9DQoNCgkJCSMgY29weSBkYXRhIGJh
Y2sgaW50byBtYWlsYm94IHRvIHByZXNlcnZlIHBlcm1pc3Npb25zLCBjcmVh
dGlvbiB0aW1lDQoJCQkjIGFuZCB1c2VyIGFuZCBncm91cCBpZA0KCQ0KCQkJ
IyB6ZXJvIGxlbmd0aCB0aGUgbWFpbGJveA0KCQkJdHJ1bmNhdGUoIE1CT1gs
IDAgKTsNCgkJCSMgKioqIFNUQVJUIENyaXRpY2FsDQoJCQkjIGFueSBkYXRh
IHRvIGNvcHk/DQoJCQlpZiggJGV4cCA8PSAkY291bnQgKSB7DQoJCQkJIyBy
ZXN0YXJ0IGJvdGggZmlsZXMNCgkJCQlzZWVrKE1CT1gsIDAsIDApOw0KCQkJ
CXNlZWsoVE1QRiwgMCwgMCk7DQoJCQkJIyBjb3B5IGZpbGUgaW50byBtYWls
Ym94LCBiZXR0ZXIgd2l0aCBzeXNyZWFkL3N5c3dyaXRlPw0KCQkJCXdoaWxl
KCA8VE1QRj4gKSB7DQoJCQkJCXByaW50IE1CT1ggJF87DQoJCQkJfQ0KCQkJ
fSBlbHNpZiggISRvcHRfeiApIHsNCgkJCQl1bmxpbmsoICRtYWlsYm94ICk7
DQoJCQl9DQoJCQkjICoqKiBFTkQgQ3JpdGljYWwNCgkJfQ0KCX0NCg0KCSMg
dW5sb2NrIG1haWxib3gNCglmbG9jayggTUJPWCwgJExPQ0tfVU4gKTsNCg0K
CSMgY2xvc2UgZmlsZXMNCgljbG9zZSggTUJPWCApOw0KCWNsb3NlKCBUTVBG
ICk7DQoNCgkjIHJlc2V0IGFjY2VzcyBhbmQgbW9kaWZpY2F0aW9uIGRhdGVz
DQoJIyBpZiB3ZSBoYXZlIHNlbnQgbWFpbCwgdGhlbiB0aGUgbW9kaWZpY2F0
aW9uIHRpbWUgaXMgdGhlIHRpbWUgb2YgdGhlIG1haWwNCglpZiggISRvcHRf
dCApIHsNCgkJdXRpbWUoIEBzYlskU1RfQVRJTUVdLCBAc2JbJFNUX01USU1F
XSwgJG1haWxib3ggKTsNCgl9DQoNCgkjIHNob3cgY291bnRlcnMNCglpZigg
JG9wdF92IHx8ICggJG9wdF9sICYmICRleHAgKSApIHsNCgkJcHJpbnQgIiRt
YWlsYm94IGNvbnRhaW5lZCAkY291bnQgbWVzc2FnZXMsIGV4cGlyZWQgJGV4
cCBtZXNzYWdlc1xuIjsNCgl9DQp9DQo=
--1482305291-1903590565-965397102=:27156
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="do.expire_mail"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.HPX.4.21.0008040951420.27156 at host-06.colby dot edu>
Content-Description:
Content-Disposition: attachment; filename="do.expire_mail"
IyEvdXNyL2Jpbi9zaA0KDQpURVNUTU9ERT0wDQpXQVJOTU9ERT0wDQpFWFBJ
UkVfTUFJTD0vdXNyL2xvY2FsL2FkbS9leHBpcmVfbWFpbA0KRElSPS92YXIv
bWFpbA0KVEFCSUZZPScvdXNyL2Jpbi90ciAtcyAiXDA0MCIgIlwwMTEiJw0K
DQojLS0tc2h1dCBkb3duIHNlbmRtYWlsIGFuZCBwb3ANCmlmIFsgJFRFU1RN
T0RFIC1lcSAwIF07IHRoZW4NCgkvc2Jpbi9pbml0LmQvc2VuZG1haWwgc3Rv
cA0KCS91c3IvYmluL2NwIC1wIC9ldGMvaW5ldGQuY29uZiAvZXRjL2luZXRk
LmNvbmYud2l0aHBvcA0KCS91c3IvYmluL3NlZCAtZSAncy9ecG9wMy8jIyNw
b3AzLycgL2V0Yy9pbmV0ZC5jb25mID4gL3RtcC9pbmV0ZC5jb25mLm5vcG9w
DQoJL3Vzci9iaW4vY3AgL3RtcC9pbmV0ZC5jb25mLm5vcG9wIC9ldGMvaW5l
dGQuY29uZg0KCS91c3Ivc2Jpbi9pbmV0ZCAtYw0KCS91c3IvYmluL3NsZWVw
IDEwDQoJcHJpbnQgIj09PXNlbmRtYWlsIGFuZCBwb3Agc2hvdWxkIGJlIHNo
dXQgZG93biwgY2hlY2tpbmcuLi4iDQoJL3Vzci9iaW4vcHMgLWVmIHwgL3Vz
ci9iaW4vZ3JlcCBzZW5kbWFpbCB8IC91c3IvYmluL2dyZXAgLXYgZ3JlcA0K
CS91c3IvYmluL3BzIC1lZiB8IC91c3IvYmluL2dyZXAgcG9wcGVyIHwgL3Vz
ci9iaW4vZ3JlcCAtdiBncmVwDQpmaQ0KDQpjZCAkRElSDQp0b3RhbGJ5dGVz
PTANCmZvciBzdWJkaXIgaW4gYSBiIGMgZCBlIGYgZyBoIGkgaiBrIGwgbSBu
IG8gcCBxIHIgcyB0IHUgdiB3IHggeSB6DQpkbw0KCWNkICRzdWJkaXINCgkj
LS0tdGhpcyB1bmZvcnR1bmF0ZWx5IHRyYXZlcnNlcyBwb3Agc3ViZGlycyB0
b28NCglmb3IgZmlsZSBpbiBgZmluZCAuIC10eXBlIGYgLXNpemUgKzAgLXBy
aW50YA0KCWRvDQoNCgkJIy0tLWlmIHdlIHN0dW1ibGVkIHVwb24gYSBub256
ZXJvIHBvcCBmaWxlLCBza2lwIGl0DQoJCXByaW50ICRmaWxlIHwgZ3JlcCAt
cSAnL3BvcC8nDQoJCWlmIFsgJD8gLWVxIDAgXTsgdGhlbg0KCQkJY29udGlu
dWUNCgkJZWxzZQ0KCQkJbWFpbGJveD1gYmFzZW5hbWUgJGZpbGVgDQoJCWZp
DQoNCgkJI3ByaW50ICI9PT09PT0gJG1haWxib3ggIg0KCQlpZiBbIC1zICRt
YWlsYm94IF07IHRoZW4NCgkJCWlmIFsgJFRFU1RNT0RFIC1lcSAxIF07IHRo
ZW4NCgkJCQljcCAtcCAkbWFpbGJveCAvdG1wLyRtYWlsYm94DQoJCQkJYmVm
b3JlYnl0ZXM9YC91c3IvYmluL2xzIC1sIC90bXAvJG1haWxib3ggfCAkVEFC
SUZZIHwgY3V0IC1mNWANCgkJCQkkRVhQSVJFX01BSUwgLWwgLXQgLU0gLXog
LVMgcmVhZCAtTyAzMCAvdG1wLyRtYWlsYm94DQoJCQkJYWZ0ZXJieXRlcz1g
L3Vzci9iaW4vbHMgLWwgL3RtcC8kbWFpbGJveCB8ICRUQUJJRlkgfCBjdXQg
LWY1YA0KCQkJCWJ5dGVzY2hhbmdlZD1gZXhwciAkYmVmb3JlYnl0ZXMgLSAk
YWZ0ZXJieXRlc2ANCgkJCQlpZiBbICRieXRlc2NoYW5nZWQgLW5lIDAgXTsg
dGhlbg0KCQkJCQlwcmludCAibWFpbGJveCAkbWFpbGJveCByZWR1Y2VkICRi
eXRlc2NoYW5nZWQgYnl0ZXMiDQoJCQkJCXRvdGFsYnl0ZXM9YGV4cHIgJHRv
dGFsYnl0ZXMgKyAkYnl0ZXNjaGFuZ2VkYA0KCQkJCWZpDQoJCQkJcm0gL3Rt
cC8kbWFpbGJveA0KCQkJZWxzZQ0KCQkJCWlmIFsgJFdBUk5NT0RFIC1lcSAx
IF07IHRoZW4NCgkJCQkJJEVYUElSRV9NQUlMIC1sIC10IC1XIC16IC1TIHJl
YWQgLU8gMzAgJG1haWxib3gNCgkJCQllbHNlDQoJCQkJCSNwcmludCAiZG8g
cmVhbCBleHBpcmVfbWFpbCBvbiAkbWFpbGJveCINCgkJCQkJYmVmb3JlYnl0
ZXM9YC91c3IvYmluL2xzIC1sICRtYWlsYm94IHwgJFRBQklGWSB8IGN1dCAt
ZjVgDQoJCQkJCSRFWFBJUkVfTUFJTCAtbCAtdCAtTSAteiAtUyByZWFkIC1P
IDMwICRtYWlsYm94DQoJCQkJCWFmdGVyYnl0ZXM9YC91c3IvYmluL2xzIC1s
ICRtYWlsYm94IHwgJFRBQklGWSB8IGN1dCAtZjVgDQoJCQkJCWJ5dGVzY2hh
bmdlZD1gZXhwciAkYmVmb3JlYnl0ZXMgLSAkYWZ0ZXJieXRlc2ANCgkJCQkJ
aWYgWyAkYnl0ZXNjaGFuZ2VkIC1uZSAwIF07IHRoZW4NCgkJCQkJCXByaW50
ICJtYWlsYm94ICRtYWlsYm94IHJlZHVjZWQgJGJ5dGVzY2hhbmdlZCBieXRl
cyINCgkJCQkJCXRvdGFsYnl0ZXM9YGV4cHIgJHRvdGFsYnl0ZXMgKyAkYnl0
ZXNjaGFuZ2VkYA0KCQkJCQlmaQ0KCQkJCWZpDQoJCQlmaQ0KCQllbHNlDQoJ
CQlwcmludCAic2tpcHBpbmcgbWFpbGJveCAkbWFpbGJveCAoaW4gdXNlKSIN
CgkJZmkNCglkb25lDQoJY2QgLi4NCmRvbmUNCnByaW50ICI9PT09ICR0b3Rh
bGJ5dGVzIGJ5dGVzIG9mIG1haWwgZGVsZXRlZCINCg0KIy0tLXJlc3RhcnQg
c2VuZG1haWwgYW5kIHBvcA0KaWYgWyAkVEVTVE1PREUgLWVxIDAgXTsgdGhl
bg0KCS9zYmluL2luaXQuZC9zZW5kbWFpbCBzdGFydA0KCS91c3IvYmluL2Nw
IC1wIC9ldGMvaW5ldGQuY29uZi53aXRocG9wIC9ldGMvaW5ldGQuY29uZg0K
CS91c3Ivc2Jpbi9pbmV0ZCAtYw0KCS91c3IvYmluL3JtIC9ldGMvaW5ldGQu
Y29uZi53aXRocG9wIC90bXAvaW5ldGQuY29uZi5ub3BvcA0KCS91c3IvYmlu
L3NsZWVwIDEwDQoJcHJpbnQgIj09PXNlbmRtYWlsIGFuZCBwb3Agc2hvdWxk
IGJlIHJ1bm5pbmcsIGNoZWNraW5nLi4uIg0KCS91c3IvYmluL3BzIC1lZiB8
IC91c3IvYmluL2dyZXAgc2VuZG1haWwgfCAvdXNyL2Jpbi9ncmVwIC12IGdy
ZXANCgkvdXNyL2Jpbi9wcyAtZWYgfCAvdXNyL2Jpbi9ncmVwIHBvcHBlciB8
IC91c3IvYmluL2dyZXAgLXYgZ3JlcA0KZmkNCg0KZXhpdCAwDQo=
--1482305291-1903590565-965397102=:27156--
Date: Fri, 04 Aug 2000 11:34:49 -0600
From: =?iso-8859-1?Q?Ramón?= Alvarez Rayo <ralvarez at tmx.com dot ni>
Subject: timeout ?
hello,
this is my first mail in this list, my server is Solaris 2.6/sparc, i have=
problem with qpopper 3.0.2, my dialup user are receving this messages:
timeout connection
they begins to download mail but it's stop after 60 seconds.
my questions is:
1. are there something flags to be enable ?
2. where is the problem ?
3. how can i do to make popper process more critical for the S.O
thanks
Saludos Fraternos,
********************************************************************
Ramón Alvarez Rayo Telefono: (505)2785523
Administrador de Sistemas Telefax : (505) 2784012
Telematix e-mail: ralvarez at tmx.com dot ni
********************************************************************
Date: Fri, 04 Aug 2000 13:24:26 -0500
From: Kevin Cochran <kcochra at arroyodcs dot net>
Subject: LDAP
Hello all,
Is there any hope for LDAP-enabled qpopper? I've look all over for a
patch, but found none. I did find MySQL patches, but I'm not interested
in MySQL.
Thanks.