The qpopper list archive ending on 2 Jul 2001
Topics covered in this issue include:
1. TLS/SSL
"Desmond Lim" <ddl76 at singnet.com dot sg>
Thu, 28 Jun 2001 13:19:35 +0800
2. Qpopper authentication.
Mark Weisman <mweisman at gci dot net>
Wed, 27 Jun 2001 22:28:25 -0800
3. Qpopper 4.03
"Alexander Utkin" <sasha at un.minsk dot by>
Thu, 28 Jun 2001 17:34:49 +0400
4. Re: Tools/methods for deleting old email?
Tim Olson <tolson at unionsemiconductor dot com>
Thu, 28 Jun 2001 09:13:45 -0500
5. Re: .user.pop files in RAM disk, how faster?
"Michael D. Sofka" <sofkam at rpi dot edu>
Thu, 28 Jun 2001 10:12:43 -0400
6. Re: Tools/methods for deleting old email?
"Michael D. Sofka" <sofkam at rpi dot edu>
Thu, 28 Jun 2001 09:56:04 -0400
7. Re: .user.pop files in RAM disk, how faster?
peter at netlink.com dot au
Fri, 29 Jun 2001 00:28:11 +1000 (EST)
8. APOP client
"Hanke Penning" <hanke.penning at iap dot de>
Thu, 28 Jun 2001 16:28:21 +0200
9. Re: Tools/methods for deleting old email?
Eric Luyten <Eric.Luyten at vub.ac dot be>
Thu, 28 Jun 2001 16:27:31 +0200 (MET DST)
10. Re: Tools/methods for deleting old email?
Gregory Hicks <ghicks at cadence dot com>
Thu, 28 Jun 2001 07:49:12 -0700 (PDT)
11. Re: Tools/methods for deleting old email?
Admin Mailing Lists <mlist at intergrafix dot net>
Thu, 28 Jun 2001 10:56:05 -0400 (EDT)
12. Re: Tools/methods for deleting old email?
Admin Mailing Lists <mlist at intergrafix dot net>
Thu, 28 Jun 2001 10:58:10 -0400 (EDT)
13. Re: Tools/methods for deleting old email?
Jeff Earickson <jaearick at colby dot edu>
Thu, 28 Jun 2001 10:39:56 -0400 (EDT)
14. Re: Tools/methods for deleting old email?
Daniel Senie <dts at senie dot com>
Thu, 28 Jun 2001 13:15:52 -0400
15. Re: Tools/methods for deleting old email?
Homer Wilson Smith <homer at lightlink dot com>
Thu, 28 Jun 2001 12:10:49 -0400 (EDT)
16. Re: Qpopper 4.03
"Alex M" <alex at myzona dot net>
Thu, 28 Jun 2001 11:44:03 -0700
17. Re: Tools/methods for deleting old email?
Daniel Senie <dts at senie dot com>
Thu, 28 Jun 2001 13:17:26 -0400
18. Re: Qpopper authentication.
"Alex M" <alex at myzona dot net>
Thu, 28 Jun 2001 11:50:57 -0700
19. Re: Tools/methods for deleting old email?
Admin Mailing Lists <mlist at intergrafix dot net>
Thu, 28 Jun 2001 16:11:12 -0400 (EDT)
20. Compiling QPopper 4.0.3
"Kent Morris" <gaunt at cophq dot org>
Thu, 28 Jun 2001 15:58:45 -0400
21. Questions about authentication.
Mark Weisman <mweisman at gci dot net>
Thu, 28 Jun 2001 14:04:51 -0800
22. Re: Tools/methods for deleting old email?
Homer Wilson Smith <homer at lightlink dot com>
Thu, 28 Jun 2001 19:40:24 -0400 (EDT)
23. Re: Questions about authentication.
Tim Olson <tolson at unionsemiconductor dot com>
Thu, 28 Jun 2001 20:19:38 -0500
24. Inetd won't run
"Joseph Lee Pereira" <joseph at jpereira dot com>
Thu, 28 Jun 2001 20:26:43 -0600
25. about option fast-update in ver4
PM WONG <pmwong at power25t.hkbu.edu dot hk>
Fri, 29 Jun 2001 12:28:23 +0800 (HKT)
26. runtime options in config file NOT user-specific?
PM WONG <pmwong at power25t.hkbu.edu dot hk>
Fri, 29 Jun 2001 12:34:53 +0800 (HKT)
27. RE: Inetd won't run
"Dan Trainor" <dan at concept-factory dot com>
Thu, 28 Jun 2001 22:44:15 -0700
28. Re: web interface
Robert Brewer <rbrewer at lava dot net>
Thu, 28 Jun 2001 20:04:13 -1000
29. Re: about option fast-update in ver4
Clifton Royston <cliftonr at lava dot net>
Thu, 28 Jun 2001 21:46:56 -1000
30. Message unknown command: "xsender"
"Megias Sanchez, Jose Manuel" <JMegias at caja-granada dot es>
Fri, 29 Jun 2001 10:41:13 +0200
31. Re: Message unknown command: "xsender"
"Kenneth Porter" <shiva at well dot com>
Fri, 29 Jun 2001 03:01:56 -0700
32. Re: Questions about authentication.
Gustavo Viscaino <g_viscaino at yahoo dot com>
Fri, 29 Jun 2001 05:24:59 -0700 (PDT)
33. Re: Tools/methods for deleting old email?
Eric Luyten <Eric.Luyten at vub.ac dot be>
Fri, 29 Jun 2001 15:53:58 +0200 (MET DST)
34. Re: Tools/methods for deleting old email?
Clifton Royston <cliftonr at lava dot net>
Fri, 29 Jun 2001 08:34:03 -1000
35. define server mode for user without telling him
PM WONG <pmwong at power25t.hkbu.edu dot hk>
Sat, 30 Jun 2001 16:14:43 +0800 (HKT)
36. Config File eror message please help
"Mark Steil" <msteil at trvnet dot net>
Sat, 30 Jun 2001 09:38:22 -0500
37. Re: Config File eror message please help
Homer Wilson Smith <homer at lightlink dot com>
Sat, 30 Jun 2001 15:49:07 -0400 (EDT)
38. Re: Config File eror message please help
Clifton Royston <cliftonr at lava dot net>
Sat, 30 Jun 2001 12:44:20 -1000
39. unix netscape messenger don't delete mail from server
PM WONG <pmwong at power25t.hkbu.edu dot hk>
Sun, 1 Jul 2001 17:31:18 +0800 (HKT)
40. Re: unix netscape messenger don't delete mail from server
Gregory Hicks <ghicks at cadence dot com>
Sun, 1 Jul 2001 05:08:08 -0700 (PDT)
41. Re: unix netscape messenger don't delete mail from server
PM WONG <pmwong at power25t.hkbu.edu dot hk>
Mon, 2 Jul 2001 01:41:20 +0800 (HKT)
42. Re: Tools/methods for deleting old email?
Chuck Yerkes <chuck+qpopper at yerkes dot com>
Sun, 1 Jul 2001 21:09:27 -0700
43. RE: Tools/methods for deleting old email?
"Desmond Lim" <ddl76 at singnet.com dot sg>
Mon, 2 Jul 2001 13:15:24 +0800
44. QPopper and SSL
"koriun@ipia" <koriun at ipia dot sci dot am>
Mon, 2 Jul 2001 11:40:18 +0400
45. setting server-mode for individual user,how?
PM WONG <pmwong at power25t.hkbu.edu dot hk>
Mon, 2 Jul 2001 15:16:07 +0800 (HKT)
46. RE: Message unknown command: "xsender"
"Megias Sanchez, Jose Manuel" <JMegias at caja-granada dot es>
Mon, 2 Jul 2001 10:32:06 +0200
47. RE: Message unknown command: "xsender"
Gregory Hicks <ghicks at cadence dot com>
Mon, 2 Jul 2001 06:45:48 -0700 (PDT)
48. Re: setting server-mode for individual user,how?
Scott McDermott <mcdermot at questra dot com>
Mon, 2 Jul 2001 11:04:46 -0400
49. Cancel
"Crawford, Ray" <CrawfordRL at navair.navy dot mil>
Mon, 2 Jul 2001 08:23:25 -0700
50. Re: Cancel
Peter Evans <peter at gol dot com>
Tue, 3 Jul 2001 00:36:46 +0900
From: "Desmond Lim" <ddl76 at singnet.com dot sg>
Subject: TLS/SSL
Date: Thu, 28 Jun 2001 13:19:35 +0800
Hi all,
How do I send the certificate signing request file to the Certificate
Authority as stated in the Qpopper4 administrator guide?
Thanks
Date: Wed, 27 Jun 2001 22:28:25 -0800
Subject: Qpopper authentication.
From: Mark Weisman <mweisman at gci dot net>
Excuse all,
I've got a really dumb question. I've recently setup Qpopper again, and
for some reason it refuses to see what I've set for user passwords. I did
not configure qpopper with any specauth or md5 password validation? What
gives? Any help would be greatly appreciated.
I did do a "make clean" prior to running this configure and make, my
sendmail is working but the transistion between the two is not(however I
don't really know that cause I can't log in). Any help??
In Christ,
Mark
From: "Alexander Utkin" <sasha at un.minsk dot by>
Subject: Qpopper 4.03
Date: Thu, 28 Jun 2001 17:34:49 +0400
Dear Colleagues,
I use popper 2.53 on old 2.1 FreeBSD box. I need to disable reverse DNS
lookups to decrease client connection time. So i decided to shift to
qpopper 4.0.2 (my first try) and 4.0.3 (the second one). From qpopper manual
i found out that i have to use crypt library to compile uner FreeBSD. As far
as i could understand (although i am not sure) i should compile
with --enable-specialauth. On that process Qpopper.4.0.2 and 4.0.3 on
FreeBSD 2.1 and 3.4 give me while making:
pop_pass.c: In function `auth_user':
pop_pass.c:1170: warning: assignment makes pointer from integer without a
cast
pop_pass.c:1177: dereferencing pointer to incomplete type
*** Error code 1
Stop.
Can you advise me wether my corse of action for FreeBSD is correct and if so
what i can do with that. Ver. 2.53 doesn't have such problems but doesn't
allow to disable lookups as well.
Thank you very much for your help.
Sasha
Date: Thu, 28 Jun 2001 09:13:45 -0500
From: Tim Olson <tolson at unionsemiconductor dot com>
Subject: Re: Tools/methods for deleting old email?
Boy do I ever 2nd this motion. ;)
Maybe we should add it to Qpoppers wish list?
I suppose someone's going to tell us next that it's a procmail issue.
Tim Olson
Daniel Senie wrote:
>
> I'd like to find some tools to go through mailboxes (mbox format, in
> /var/spool/mail) and delete anything that's been read, and which is more
> than 30 days old. I've got some users who just won't set the "delete from
> server" switch, and it's time to take action. I really don't want to do
> quotas enforcement at this point, though.
>
> Anyone know of tools to do this? I'd love it if Qpopper had an option for
> this and would just perform the trim while it was doing its processing, but
> the only switch I find there is auto-delete.
>
> An alternative would be to add auto-delete on a per-user basis, targetting
> the abusive users only.
>
> Any thoughts or pointers to tools would be greatly appreciated.
>
> Dan
> -----------------------------------------------------------------
> Daniel Senie dts at senie dot com
> Amaranth Networks Inc. http://www.amaranth.com
Date: Thu, 28 Jun 2001 10:12:43 -0400
From: "Michael D. Sofka" <sofkam at rpi dot edu>
Subject: Re: .user.pop files in RAM disk, how faster?
At 11:20 AM 6/28/2001 +0800, PM WONG wrote:
>We run qpopper 3.0.2 on an AIX unix box. As most users choose
>to keep mails on server, hence it becomes quite slow when plenty
>users are reading their mail at the same time (though i've
>placed the .pop files directory separate from their /var/spool/mail
>mailboxes).
>Now since the newest version of AIX OS has this feature of
>using part of the RAM as disk (using a command called mkramdisk)
>, i wonder will it improve things much ( i did a simple test
>on a test machine for 1 mailbox, but the difference is not significant)
>for qpopper. Could it be that the reading of the mail from /var/spool/mail
>to create the .pop files is also the bottleneck.
>Any comments?
If you can run in server mode, that avoids copying the spool file
when there is no new email. If you update to 4.0.x you can avoid
even reading the spool file in the case of no email.
On AIX you can make mirrored and distributed disks. This speeds
up mail reading iff the temporary drop spool is also distributed. Otherwise,
the temp spool becomes a bottleneck when many large mail boxes are
being read at once (all those copies have a single disk destination, and can
quickly become IO bound). I eventually moved the temp files to back to the
mail spool, since that was a faster disk (mirrored and distributed).
And, again, under 4.0.x a move will be used instead
of a copy if the spool and lock are on the same disk, speeding things up
again.
I have not experimented with ram disks, but if you have the memory, making
your temp drop a ram disk should be faster. There will still be a reading
bottleneck. Qpopper 3 reads the spool file from beginning to end during
each pop. But at least the temp file write will be faster. A mirrored mail
spool will speed up the mailbox scan since the reading can come from
either of the disk mirrors.
Finally, we went to SSA disks for our spool. And, on the new machine I'll
be setting up a RAID01 using SSA, instead of using the logical volume
manager. I've been using the SSA RAID on our webmail server, and it's
been very very good to us. :-) SSA costs more, but they pay for themselves
in performance and time saved.
Mike
--
Michael D. Sofka sofkam at rpi dot edu
CIS/SSS Sr. Systems Programmer email, webmail, listproc, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
Date: Thu, 28 Jun 2001 09:56:04 -0400
From: "Michael D. Sofka" <sofkam at rpi dot edu>
Subject: Re: Tools/methods for deleting old email?
I use:
ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/
(You may have to specify the componants in separate ftp lines.
In qhich case:
ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/preenmail.pl
ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/preenstats.pl
ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/lockmbox.pl
ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/README
It depends on if your ftp client makes call backs.)
It will need adjustment and testing for your site. Particularly, make
sure you local delivery agent honors the locking mechanism.
Mike
,At 12:11 AM 6/28/2001 -0400, Daniel Senie wrote:
>I'd like to find some tools to go through mailboxes (mbox format, in
>/var/spool/mail) and delete anything that's been read, and which is more
>than 30 days old. I've got some users who just won't set the "delete from
>server" switch, and it's time to take action. I really don't want to do
>quotas enforcement at this point, though.
>
>Anyone know of tools to do this? I'd love it if Qpopper had an option for
>this and would just perform the trim while it was doing its processing, but
>the only switch I find there is auto-delete.
>
>An alternative would be to add auto-delete on a per-user basis, targetting
>the abusive users only.
>
>Any thoughts or pointers to tools would be greatly appreciated.
>
>Dan
>-----------------------------------------------------------------
>Daniel Senie dts at senie dot com
>Amaranth Networks Inc. http://www.amaranth.com
--
Michael D. Sofka sofkam at rpi dot edu
CIS/SSS Sr. Systems Programmer email, webmail, listproc, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
From: peter at netlink.com dot au
Subject: Re: .user.pop files in RAM disk, how faster?
Date: Fri, 29 Jun 2001 00:28:11 +1000 (EST)
Hi,
>
> We run qpopper 3.0.2 on an AIX unix box. As most users choose
> to keep mails on server, hence it becomes quite slow when plenty
> users are reading their mail at the same time (though i've
> placed the .pop files directory separate from their /var/spool/mail
> mailboxes).
> Now since the newest version of AIX OS has this feature of
> using part of the RAM as disk (using a command called mkramdisk)
> , i wonder will it improve things much ( i did a simple test
> on a test machine for 1 mailbox, but the difference is not significant)
> for qpopper. Could it be that the reading of the mail from /var/spool/mail
> to create the .pop files is also the bottleneck.
I don't know specifically about AIX but in our experience the bottlenecks
are: a) in mail handling generally - the type of mail spool.
Your case of having all mailboxes in the one directory means that
various programs (including qpopper) have to search sequentially
through a very large index for every i/o operation
b) for qpopper and similar pop3 servers - having to copy the user's
mailbox to and from the temp file (much worse if they are leaving
mail on the server as has been discussed on this list before).
The solutions which have improved mail server performance dramatically
for us were to use the ~user/Mailbox format for mail spools and installing
qpopper 4.0.3 to use server mode (although not for shell users!).
In answer to your question, I personally doubt that much performance
would be improved by using the ram disk in that way - just having more
ram would be just as beneficial, imho...
To me it also seems a somewhat risky idea. Admittedly you are likely to
get corrupted mail spools if the server fails/dies under normal circumstances
- but if using the ram disk those mail spools will just disappear in the
event of a catastrophic failure.
'Hope this helps,
Peter Vaskess
Netlink Connect, Australia
From: "Hanke Penning" <hanke.penning at iap dot de>
Date: Thu, 28 Jun 2001 16:28:21 +0200
Subject: APOP client
Hi!
> Also what other mail clients support Apop, i've only found 3, these
> are Eudora, The Bat and Pegasus.
There is a list at http://www.sendmail.org/~ca/email/mel/SASL_ClientRef.html
I do not know, if it is complete or outdated...
Mit freundlichen Gruessen
Hanke Penning
IAP GmbH -- Moerkenstrasse 9 -- 22767 Hamburg
Tel.: 040 / 306803-14 -- Fax: 040 / 306803-10
http://www.iap.de --- E-Mail: info at iap dot de
Subject: Re: Tools/methods for deleting old email?
Date: Thu, 28 Jun 2001 16:27:31 +0200 (MET DST)
From: Eric Luyten <Eric.Luyten at vub.ac dot be>
> Boy do I ever 2nd this motion. ;)
> Maybe we should add it to Qpoppers wish list?
> I suppose someone's going to tell us next that it's a procmail issue.
No, we'll tell you to search the list archives.
The question gets asked every six months or so :-)
Eric Luyten, Computing Centre VUB/ULB,
running 'em' for mailbox expiration here.
Date: Thu, 28 Jun 2001 07:49:12 -0700 (PDT)
From: Gregory Hicks <ghicks at cadence dot com>
Subject: Re: Tools/methods for deleting old email?
Actually, the setting is on the email client. Eudora, for example, has
a setting where the user can specify whether or not to download the
message. There is also a setting to delete mail after x days (x is
user specified).
Of course, with Eudora, there are other problems. For instance, if the
user sets the option "Do not download any email more than xKB", once
the user downloads the first xKB of the email, Eudora (or Popper, I'm
not sure which is at fault here) thinks the mail has been read. What
the user really wanted to do was to defer downloading until they get to
a faster connection. What happens is that Eudora *never* downloads the
message again.
The only fix I have found is to log in to the mail server and use some
command line client ('pine' seems to work best), resend the message to
the user and delete the original message.
Another effect of this problem is that the "not downloaded" messages
cannot be deleted by the user. As far as the GUI is concerned, the
message is moved to the trash, but when the trash is "emptied", the
message is not deleted. It also never shows up in the "Inbox" pane
again... The user is happy. They got rid of a superflous message.
It's us admins that get unhappy because the user's spool keeps
growing.
Oh well, my own $0.02 worth.
Gregory Hicks
---------------------------------------------------------------------
A Cadence Postmaster | 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 at cadence dot com
> Date: Thu, 28 Jun 2001 09:13:45 -0500
> From: Tim Olson <tolson at unionsemiconductor dot com>
>
> Boy do I ever 2nd this motion. ;)
> Maybe we should add it to Qpoppers wish list?
> I suppose someone's going to tell us next that it's a procmail issue.
>
> Tim Olson
>
> Daniel Senie wrote:
> >
> > I'd like to find some tools to go through mailboxes (mbox format, in
> > /var/spool/mail) and delete anything that's been read, and which is
more
> > than 30 days old. I've got some users who just won't set the "delete
from
> > server" switch, and it's time to take action. I really don't want to
do
> > quotas enforcement at this point, though.
> >
> > Anyone know of tools to do this? I'd love it if Qpopper had an
option for
> > this and would just perform the trim while it was doing its
processing, but
> > the only switch I find there is auto-delete.
> >
> > An alternative would be to add auto-delete on a per-user basis,
targetting
> > the abusive users only.
> >
> > Any thoughts or pointers to tools would be greatly appreciated.
> >
> > Dan
> > -----------------------------------------------------------------
> > Daniel Senie dts at senie dot com
> > Amaranth Networks Inc. http://www.amaranth.com
Date: Thu, 28 Jun 2001 10:56:05 -0400 (EDT)
From: Admin Mailing Lists <mlist at intergrafix dot net>
Subject: Re: Tools/methods for deleting old email?
off the top of my head, can't you first check for a ctime older than 30
days..and then of those, to check whether it was read,
check that the atime is newer than the ctime?
ctime being creation time
atime being last access time
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>
#include <sys/stat.h>
#include <dirent.h>
#define MAILSPOOL "/var/spool/mail"
#define DAYS_OLD 30
int main(void) {
char filename[256];
time_t tm;
struct stat fileinfo;
struct dirent *dp;
DIR *dirp;
dirp=opendir(MAILSPOOL);
if (dirp == NULL) {
printf("Can't open MAILSPOOL!\n");
exit(0);
}
while ((dp = readdir(dirp)) != NULL) {
if (dp->d_name[0]=='.') continue;
snprintf(filename,256,"%s/%s",MAILSPOOL,dp->d_name);
if (stat(filename,&fileinfo) == -1) continue;
if (!S_ISREG(fileinfo.st_mode)) continue;
time(&tm);
if ( ((tm-(86400*DAYS_OLD)) >= fileinfo.st_ctime) &&
(fileinfo.st_atime > fileinfo.st_ctime)) {
unlink(filename);
}
} /* while */
closedir(dirp);
return 1;
}
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
thelittleprince at asteroid-b612 dot org Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.org http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
On Thu, 28 Jun 2001, Tim Olson wrote:
> Boy do I ever 2nd this motion. ;)
> Maybe we should add it to Qpoppers wish list?
> I suppose someone's going to tell us next that it's a procmail issue.
>
> Tim Olson
>
> Daniel Senie wrote:
> >
> > I'd like to find some tools to go through mailboxes (mbox format, in
> > /var/spool/mail) and delete anything that's been read, and which is more
> > than 30 days old. I've got some users who just won't set the "delete from
> > server" switch, and it's time to take action. I really don't want to do
> > quotas enforcement at this point, though.
> >
> > Anyone know of tools to do this? I'd love it if Qpopper had an option for
> > this and would just perform the trim while it was doing its processing, but
> > the only switch I find there is auto-delete.
> >
> > An alternative would be to add auto-delete on a per-user basis, targetting
> > the abusive users only.
> >
> > Any thoughts or pointers to tools would be greatly appreciated.
> >
> > Dan
> > -----------------------------------------------------------------
> > Daniel Senie dts at senie dot com
> > Amaranth Networks Inc. http://www.amaranth.com
>
Date: Thu, 28 Jun 2001 10:58:10 -0400 (EDT)
From: Admin Mailing Lists <mlist at intergrafix dot net>
Subject: Re: Tools/methods for deleting old email?
oh, wait, you might want to disregard my code snippet, i misunderstood the
request. I thought he wanted to delete the whole mailbox, not scan the
mailbox and delete the MESSAGES INSIDE older than 30 days.
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
thelittleprince at asteroid-b612 dot org Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.org http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
On Thu, 28 Jun 2001, Michael D. Sofka wrote:
> I use:
>
> ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/
>
> (You may have to specify the componants in separate ftp lines.
> In qhich case:
>
> ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/preenmail.pl
> ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/preenstats.pl
> ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/lockmbox.pl
> ftp://ftp.rpi.edu/campus/rpi/mail/preenmail/1.0/distrib/src/README
>
> It depends on if your ftp client makes call backs.)
>
> It will need adjustment and testing for your site. Particularly, make
> sure you local delivery agent honors the locking mechanism.
>
> Mike
>
> ,At 12:11 AM 6/28/2001 -0400, Daniel Senie wrote:
> >I'd like to find some tools to go through mailboxes (mbox format, in
> >/var/spool/mail) and delete anything that's been read, and which is more
> >than 30 days old. I've got some users who just won't set the "delete from
> >server" switch, and it's time to take action. I really don't want to do
> >quotas enforcement at this point, though.
> >
> >Anyone know of tools to do this? I'd love it if Qpopper had an option for
> >this and would just perform the trim while it was doing its processing, but
> >the only switch I find there is auto-delete.
> >
> >An alternative would be to add auto-delete on a per-user basis, targetting
> >the abusive users only.
> >
> >Any thoughts or pointers to tools would be greatly appreciated.
> >
> >Dan
> >-----------------------------------------------------------------
> >Daniel Senie dts at senie dot com
> >Amaranth Networks Inc. http://www.amaranth.com
>
> --
> Michael D. Sofka sofkam at rpi dot edu
> CIS/SSS Sr. Systems Programmer email, webmail, listproc, TeX, epistemology.
> Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
>
>
Date: Thu, 28 Jun 2001 10:39:56 -0400 (EDT)
From: Jeff Earickson <jaearick at colby dot edu>
Subject: Re: Tools/methods for deleting 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.
---559023410-1483920592-993739196=:375
Content-Type: TEXT/PLAIN; charset=US-ASCII
Y'all,
Attached is a perl script that will clean out an mbox format mail
mailbox based on various criteria. I snagged it on the net a long
time ago; it has served me well since then (I made a few mods for our
site, hack to your own tastes). It has proved to be incrediably
useful. The one and only thing I don't like about it is that it
directly appends messages to the mailbox if you use the "tell the
user what you did to him" mode. I would rather that it use sendmail
to send the message instead of working directly on the mailbox. But
this has not ever proved to be a problem.
To clean out all mailboxes, simply write a shell script that runs
expire_mail on each mailbox in turn. I do this in the dead of night
on Sundays.
--- Jeff Earickson
On Thu, 28 Jun 2001, Tim Olson wrote:
> Date: Thu, 28 Jun 2001 09:13:45 -0500
> From: Tim Olson <tolson at unionsemiconductor dot com>
> To: Daniel Senie <dts at senie dot com>
> Cc: Subscribers of Qpopper <qpopper at lists.pensive dot org>
> Subject: Re: Tools/methods for deleting old email?
>
> Boy do I ever 2nd this motion. ;)
> Maybe we should add it to Qpoppers wish list?
> I suppose someone's going to tell us next that it's a procmail issue.
>
> Tim Olson
>
> Daniel Senie wrote:
> >
> > I'd like to find some tools to go through mailboxes (mbox format, in
> > /var/spool/mail) and delete anything that's been read, and which is more
> > than 30 days old. I've got some users who just won't set the "delete from
> > server" switch, and it's time to take action. I really don't want to do
> > quotas enforcement at this point, though.
> >
> > Anyone know of tools to do this? I'd love it if Qpopper had an option for
> > this and would just perform the trim while it was doing its processing, but
> > the only switch I find there is auto-delete.
> >
> > An alternative would be to add auto-delete on a per-user basis, targetting
> > the abusive users only.
> >
> > Any thoughts or pointers to tools would be greatly appreciated.
> >
> > Dan
> > -----------------------------------------------------------------
> > Daniel Senie dts at senie dot com
> > Amaranth Networks Inc. http://www.amaranth.com
>
---559023410-1483920592-993739196=:375
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=expire_mail
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.33.0106281039560.375 at cayuga.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
ZGF5c19vbGQoICRtc2dfc3RhbXAgKTsNCgkJCQkjcHJpbnQgU1RERVJSICJt
c2dfZGF0ZSA9ICRtc2dfZGF0ZSwgbXNnX3N0YW1wID0gJG1zZ19zdGFtcCwg
bXNnX2FnZSA9ICRtc2dfYWdlXG4iOw0KCQkJfQ0KCQl9IGVsc2lmKCAkbGlu
ZSA9fiAvXltTc110YXR1czogKFtBLVphLXpdKykvICkgew0KCQkJKCAkbXNn
X3N0YXR1cyApID0gKCAkMSApOw0KCQl9IGVsc2lmKCAkbGluZSA9fiAvXltT
c111YmplY3Q6ICguKikkLyApIHsNCgkJCSggJG1zZ19zdWJqZWN0ICkgPSAo
ICQxICk7DQoJCX0NCg0KCQkjIHNldCBwcmV2aW91cyBsaW5lDQoJCWlmKCAk
bGluZSA9fiAvXiQvICkgew0KCQkJJHByZXZfYmxhbmsgPSAxOw0KCQl9IGVs
c2Ugew0KCQkJJHByZXZfYmxhbmsgPSAwOw0KCQl9DQoNCgkJJG1zZyAuPSAk
bGluZTsNCgl9DQoNCglyZXR1cm4gJG1zZzsNCn0NCg0KIyB3cml0ZSBhIG1l
c3NhZ2UgaW50byBhIG1haWxib3gNCnN1YiB3cml0ZV9tZXNzYWdlDQp7DQoJ
cHJpbnQgVE1QRiAiQF8iOw0KfQ0KDQojIHBhcnNlIHRoZSBjdGltZSBzdHJp
bmcgaW50byBhIHRpbWUgdmFsdWUNCiMgRnJvbSBsaW5lIGNvbnRhaW5zIGxv
Y2FsIHRpbWUNCg0Kc3ViIHJjdGltZQ0Kew0KCWxvY2FsKCAkcHQgKSA9IEBf
OwkJCSMgdGltZSB0byBjb252ZXJ0DQoJbG9jYWwoICRjdCApID0gLTE7CQkJ
IyBjb252ZXJ0ZWQgdGltZQ0KDQoJaWYoJHB0ID1+IC9eKFtBLVphLXpdKylc
cysoW0EtWmEtel0rKVxzKyhbMC05XSspXHMrKFswLTk6XSspXHMrKFswLTld
KykvICkgew0KCQkoICRkYXksICRtb24sICRtZGF5LCAkdGltZSwgJHllYXIg
KSA9ICggJDEsICQyLCAkMywgJDQsICQ1ICk7DQoJCSggJGhvdXIsICRtaW4s
ICRzZWMgKSA9IHNwbGl0KCAnOicsICR0aW1lICk7DQoJCWlmKCAkeWVhciA+
IDE5MDAgKSB7ICR5ZWFyIC09IDE5MDA7IH0NCgkJJGN0ID0gJnRpbWVsb2Nh
bCgkc2VjLCRtaW4sJGhvdXIsJG1kYXksJG1vbl9udW17JG1vbn0sJHllYXIp
Ow0KCX0NCglyZXR1cm4gJGN0Ow0KfQ0KDQojIGFnZSBpbiBkYXlzDQpzdWIg
ZGF5c19vbGQNCnsNCglsb2NhbCggJGFnZXYgKSA9IEBfOwkJCSMgdGltZSB0
byBjb252ZXJ0DQoNCglyZXR1cm4oICggJFNUQVJUX1RJTUUgLSAkYWdldiAp
IC8gJFNFQ19QRVJfREFZICk7DQp9DQoNCiMgYmFzZW5hbWUNCnN1YiBiYXNl
bmFtZQ0Kew0KCWxvY2FsKCAkcGF0aCApID0gQF87CQkJIyBwYXRoIHRvIGZp
bmQgdGhlIGJhc2Ugb2YNCglsb2NhbCggJGJhc2UgKSA9IHJpbmRleCggJHBh
dGgsICIvIiApOw0KDQoJaWYoICRiYXNlIDwgMCApIHsNCgkJJGJhc2UgPSAk
cGF0aDsNCgl9IGVsc2Ugew0KCQkkYmFzZSA9IHN1YnN0cigkcGF0aCwgJGJh
c2UgKyAxKTsNCgl9DQoNCglyZXR1cm4gJGJhc2U7DQp9DQoNCiMgdXNhZ2Ug
bWVzc2FnZQ0Kc3ViIHVzYWdlDQp7DQoJcHJpbnQgU1RERVJSICJ1c2FnZTog
ZXhwaXJlX21haWwgWy12bFZdIFstem90VE1XXSBbLWRdIHsgWy1PIGRheXNd
IFstdSB1c2VyXSBbLVMgcmVhZHxvbGRdIFstcyBzdWJqZWN0XSB9IG1haWxi
b3guLi5cbiI7DQoJZXhpdCAwOw0KfQ0KDQojIyMjIw0KIw0KIyBNYWluDQoj
DQojIyMjIw0KDQomR2V0b3B0cyggJ1Z2TzphOm91OnpkUzpzOk10VGxXJyAp
IHx8ICZ1c2FnZTsNCg0KIyBjb21wYXQNCiRvcHRfYSA9ICRvcHRfTyBpZiAo
JG9wdF9PICYmICEkb3B0X2EpOw0KDQojIGNoZWNrIHZlcnNpb24NCmlmKCAk
b3B0X1YgKSB7DQoJcHJpbnQgImV4cGlyZV9tYWlsOiBtYWlsIGV4cGlyeSBh
Z2VudFxuIjsNCglwcmludCAiZXhwaXJlX21haWw6ICRfZXhwaXJlX21haWxf
cmNzaWRcbiI7DQoJJnVzYWdlOw0KfQ0KDQojIHVzZSBkZWZhdWx0IG1haWxi
b3ggaWYgbm9uIHN1cHBsaWVkDQppZiggJCNBUkdWIDwgJFsgKSB7DQoJJEFS
R1ZbMF0gPSAiJGRlZmF1bHRfbWFpbGJveCI7DQp9DQoNCiMgZGVjb2RlIHN0
YXR1cyBvcHRpb24NCmlmKCAkb3B0X1MgKSB7DQoJaWYoICRvcHRfUyBlcSAi
b2xkIiApIHsNCgkJJG9wdF9TID0gIk8iOw0KCX0gZWxzaWYoICRvcHRfUyBl
cSAicmVhZCIgKSB7DQoJCSRvcHRfUyA9ICJSIjsNCgl9IGVsc2Ugew0KCQlw
cmludCBTVERFUlIgImV4cGlyZV9tYWlsOiBzdGF0dXMgbWF5IG9ubHkgYmUg
b25lIG9mIGBvbGQnIG9yIGB1bnJlYWQnXG4iOw0KCQkmdXNhZ2U7DQoJfQ0K
fQ0KDQojIGNoZWNrIHdlIGFyZSBhY3R1YWxseSBkb2luZyBzb21lIHByb2Nl
c3NpbmcNCmlmKCAhJG9wdF9hICYmICEkb3B0X3UgJiYgISRvcHRfUyAmJiAh
JG9wdF9zICkgew0KCXByaW50IFNUREVSUiAiZXhwaXJlX21haWw6IG11c3Qg
c3BlY2lmeSBhdCBsZWFzdCBvbmUgb2YgLU8sIC11LCAtUyBvciAtc1xuIjsN
CgkmdXNhZ2U7DQp9DQoNCiMgd2FybmluZyBtb2RlIGltcGxlcyBkZWJ1ZyBt
b2RlDQppZiggJG9wdF9XICkgeyAkb3B0X2QgPSAxOyB9DQoNCiMgZGVidWcg
bW9kZSBpbXBsaWVzIHZlcmJvc2UgbW9kZQ0KaWYoICRvcHRfZCApIHsgJG9w
dF92ID0gMTsgfQ0KDQojIGZvcmVhY2ggbWFpbGJveC4uLg0Kd2hpbGUoICRt
YWlsYm94ID0gc2hpZnQgKSB7DQoNCglpZiggJG9wdF92ICYmICEkb3B0X1cg
KSB7IHByaW50IFNURE9VVCAiQ2hlY2tpbmcgbWFpbGJveCAkbWFpbGJveFxu
IjsgfQ0KDQoJIyBkb2VzIG1haWxib3ggZXhpc3QNCglpZiggISAtZiAkbWFp
bGJveCApIHsgbmV4dDsgfQ0KDQoJIyBzdGF0IHRoZSBtYWlsYm94DQoJQHNi
ID0gJlN0YXQoJG1haWxib3gpOw0KDQoJIyBjYW4gaXQgYmUgZGVsZXRlZCBu
b3c/DQoJaWYoICEkb3B0X28gJiYgJG9wdF9hICkgew0KCQkjIGNoZWNrIHRo
ZSBtb2RpZmljYXRpb24gZGF0ZQ0KCQkkYWdlID0gJmRheXNfb2xkKEBzYlsk
U1RfTVRJTUVdKTsNCgkJaWYoICRhZ2UgPiAkb3B0X2EgKSB7DQoJCQlpZigg
JG9wdF92ICkgeyBwcmludCBTVERPVVQgIkV4cGlyaW5nIG1haWxib3ggJG1h
aWxib3hcbiI7IH0NCgkJCWlmKCAhJG9wdF9kICkgew0KCQkJCWlmKCAkb3B0
X3ogKSB7DQoJCQkJCW9wZW4oIE1CT1gsICI+JG1haWxib3giICkgfHwgDQoJ
CQkJCXByaW50IFNUREVSUiAiZXhwaXJlX21haWw6IGZhaWxlZCB0byB0cnVu
Y2F0ZSAkbWFpbGJveFxuIjsNCgkJCQkJY2xvc2UoIE1CT1ggKTsNCgkJCQl9
IGVsc2Ugew0KCQkJCQl1bmxpbmsoICRtYWlsYm94ICkgfHwNCgkJCQkJcHJp
bnQgU1RERVJSICJleHBpcmVfbWFpbDogZmFpbGVkIHRvIHJlbW92ZSAkbWFp
bGJveFxuIjsNCgkJCQl9DQoJCQl9DQoJCQluZXh0Ow0KCQl9DQoJfQ0KDQoJ
IyBvcGVuIHRoZSBtYWlsYm94DQoJaWYoICFvcGVuKCBNQk9YLCAiKzwkbWFp
bGJveCIgKSApIHsNCgkJcHJpbnQgU1RERVJSICJleHBpcmVfbWFpbDogdW5h
YmxlIHRvIG9wZW4gJG1haWxib3hcbiI7DQoJCW5leHQ7DQoJfQ0KDQoJIyBs
b2NrIHRoZSBtYWlsYm94DQoJaWYoICFmbG9jayggTUJPWCwgJExPQ0tfRVgg
KSApIHsNCgkJcHJpbnQgU1RERVJSICJleHBpcmVfbWFpbDogdW5hYmxlIHRv
IGxvY2sgJG1haWxib3hcbiI7DQoJCWNsb3NlKCBNQk9YICk7DQoJCW5leHQ7
DQoJfQ0KDQoJIyBvcGVuIHRoZSB0ZW1wb3JhcnkgZmlsZQ0KCSR0bXBuYW1l
ID0gIiRtYWlsYm94LmV4cCQkIjsNCglpZiggIW9wZW4oIFRNUEYsICIrPiR0
bXBuYW1lIiApICkgew0KCQlwcmludCBTVERFUlIgImV4cGlyZV9tYWlsOiB1
bmFibGUgdG8gY3JlYXRlIHRlbXBvcmFyeSBmaWxlIGZvciAkbWFpbGJveFxu
IjsNCgkJY2xvc2UoIE1CT1ggKTsNCgkJbmV4dDsNCgl9DQoJdW5saW5rKCAk
dG1wbmFtZSApOw0KDQoJIyBpbml0IGNvdW50ZXJzDQoJJGNvdW50ID0gMDsN
CgkkZXhwID0gMDsNCg0KCSMgcmVhZCBlYWNoIG1lc3NhZ2UgaW4gdHVybg0K
CXdoaWxlKCAkbXNnID0gJnJlYWRfbWVzc2FnZSApIHsNCg0KCQkkY291bnQr
KzsNCg0KCQkjIGxvb2tpbmcgZm9yIHNwZWNpZmljIGZyb20gdXNlcnMNCgkJ
aWYoICRvcHRfdSApIHsNCgkJCWlmKCAhICgkbXNnX2Zyb20gPX4gLyRvcHRf
dS8pICkgew0KCQkJCWlmKCAkb3B0X3YgJiYgISRvcHRfVyApIHsNCgkJCQkJ
I3ByaW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogZnJvbSAgIFxyIjsNCgkJ
CQkJcHJpbnQgU1RET1VUICJcdE1zZyAjJGNvdW50OiBmcm9tICAgXG4iOw0K
CQkJCX0NCgkJCSZ3cml0ZV9tZXNzYWdlKCAkbXNnICk7DQoJCQluZXh0Ow0K
CQkJfQ0KCQl9DQoNCgkJIyBjaGVjayBtZXNzYWdlIHN0YXR1cw0KCQlpZigg
JG9wdF9TICkgew0KCQkJaWYoICEoJG1zZ19zdGF0dXMgPX4gLyRvcHRfUy8p
ICkgew0KCQkJCWlmKCAkb3B0X3YgJiYgISRvcHRfVyApIHsNCgkJCQkJI3By
aW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogc3RhdHVzICAgXHIiOw0KCQkJ
CQlwcmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IHN0YXR1cyAgIFxuIjsN
CgkJCQl9DQoJCQkJJndyaXRlX21lc3NhZ2UoICRtc2cgKTsNCgkJCQluZXh0
Ow0KCQkJfQ0KCQl9DQoNCgkJIyBjaGVjayBtZXNzYWdlIHN1YmplY3QNCgkJ
aWYoICRvcHRfcyApIHsNCgkJCWlmKCAhICgkbXNnX3N1YmplY3QgPX4gLyRv
cHRfcy8pICkgew0KCQkJCWlmKCAkb3B0X3YgJiYgISRvcHRfVyApIHsNCgkJ
CQkJI3ByaW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogc3ViamVjdCAgIFxy
IjsNCgkJCQkJcHJpbnQgU1RET1VUICJcdE1zZyAjJGNvdW50OiBzdWJqZWN0
ICAgXG4iOw0KCQkJCX0NCgkJCSZ3cml0ZV9tZXNzYWdlKCAkbXNnICk7DQoJ
CQluZXh0Ow0KCQkJfQ0KCQl9DQoNCgkJIyBvbmx5IG90aGVyIHRoaW5nIHRv
IGNoZWNrIGlzIG1lc3NhZ2UgYWdlDQoJCWlmKCAkb3B0X2EgKSB7DQoJCQlp
ZiggJG1zZ19hZ2UgPD0gJG9wdF9hICkgew0KCQkJCWlmKCAkb3B0X3YgJiYg
ISRvcHRfVyApIHsNCgkJCQkJI3ByaW50IFNURE9VVCAiXHRNc2cgIyRjb3Vu
dDogbmV3ZXIgICBcciI7DQoJCQkJCXByaW50IFNURE9VVCAiXHRNc2cgIyRj
b3VudDogbmV3ZXIgICBcbiI7DQoJCQkJfQ0KCQkJCSZ3cml0ZV9tZXNzYWdl
KCAkbXNnICk7DQoJCQkJbmV4dDsNCgkJCX0NCgkJfQ0KDQoJCSMgbG9nIHRo
ZSBleHBpcnkNCgkJaWYoICRvcHRfdiAmJiAhJG9wdF9XICkgew0KCQkJI3By
aW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogZXhwaXJlZCAgIFxyIjsNCgkJ
CXByaW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogZXhwaXJlZCAgIFxuIjsN
CgkJfQ0KDQoJCSMgY29weSBtZXNzYWdlIGFjcm9zcyBpZiBpbiBkZWJ1Zw0K
CQlpZiggJG9wdF9kICkgew0KCQkJJndyaXRlX21lc3NhZ2UoICRtc2cgKTsN
CgkJCWlmKCRvcHRfVykgew0KCQkJCSMgcmVjb3JkIHRoZSBtYWlsIG1lc3Nh
Z2UgZnJvbSBhbmQgc3ViamVjdCBsaW5lDQoJCQkJJHBhZCA9ICcgJyB4ICgy
NSAtIGxlbmd0aCgkbXNnX2Zyb20pICk7DQoJCQkJJG5wYWQgPSAnICcgeCAo
IDQgLSBsZW5ndGgoJGNvdW50KSApOw0KCQkJCSRzdWJqZWN0c1skZXhwXSA9
ICIkbnBhZCRjb3VudCAkbXNnX2Zyb20kcGFkICRtc2dfZGF0ZVxuICAgICAk
bXNnX3N1YmplY3RcbiI7DQoJCQl9DQoJCX0gZWxzZSB7DQoJCQkjIHJlY29y
ZCB0aGUgbWFpbCBtZXNzYWdlIGZyb20gYW5kIHN1YmplY3QgbGluZQ0KCQkJ
JHBhZCA9ICcgJyB4ICgyNSAtIGxlbmd0aCgkbXNnX2Zyb20pICk7DQoJCQkk
bnBhZCA9ICcgJyB4ICggNCAtIGxlbmd0aCgkY291bnQpICk7DQoJCQkkc3Vi
amVjdHNbJGV4cF0gPSAiJG5wYWQkY291bnQgJG1zZ19mcm9tJHBhZCAkbXNn
X2RhdGVcbiAgICAgJG1zZ19zdWJqZWN0XG4iOw0KCQl9DQoNCgkJIyBpbmNy
ZW1lbnQgdGhlIGV4cGlyZWQgbWVzc2FnZSBjb3VudA0KCQkkZXhwKys7DQoJ
fQ0KDQoJaWYoICEkb3B0X2QgKSB7DQoNCgkJIyBpZiBzZW5kaW5nIG1haWwg
dG8gdGhlIG93bmVyIG9mIHRoZSBtYWlsYm94LCBhcHBlbmQgbWVzc2FnZSBv
biB0aGUgZW5kDQoJCWlmKCAkb3B0X00gJiYgJGV4cCA+IDAgKSB7DQoJCQlj
aG9wKCAkY3QgPSAmY3RpbWUodGltZSkgKTsNCgkJCSR0byA9ICZiYXNlbmFt
ZSggJG1haWxib3ggKTsNCgkJCWNob3AoICRmcm9tZGF0ZSA9IGBkYXRlICtc
IiVhICViICVkICVYICVZXCJgICk7DQoJCQlwcmludCBUTVBGICJGcm9tICRw
b3N0bWFzdGVyICAkZnJvbWRhdGVcbiI7DQoJCQlwcmludCBUTVBGICJEYXRl
OiAkY3RcbiI7DQoJCQlwcmludCBUTVBGICJGcm9tOiAkcG9zdG1hc3RlciAo
TWFpbCBFeHBpcnkgQWdlbnQpXG4iOw0KCQkJcHJpbnQgVE1QRiAiUmVwbHkt
VG86ICRwb3N0bWFzdGVyXG4iOw0KCQkJcHJpbnQgVE1QRiAiVG86ICR0b1xu
IjsNCgkJCXByaW50IFRNUEYgIlN1YmplY3Q6IEV4cGlyZWQgTWFpbCBTdW1t
YXJ5XG5cbiI7DQoJCQlwcmludCBUTVBGICIkbm90aWNlXG5cbiI7DQoJCQkj
IGZpdHRlZCB0byAkc3ViamVjdHMgbGF5b3V0DQoJCQlwcmludCBUTVBGICIg
TXNnIEZyb20gJiBTdWJqZWN0ICAgICAgICAgICAgRGF0ZWRcblxuIjsNCgkJ
CWZvcmVhY2ggJG1zZyAoIEBzdWJqZWN0cyApIHsNCgkJCQlwcmludCBUTVBG
ICIkbXNnXG4iOw0KCQkJfQ0KDQoJCQlpZiggISRvcHRfVCApIHsNCgkJCQkj
IHNldCB0aGUgbW9kaWZpY2F0aW9uIHRpbWUgZm9yIHRoZSBtYWlsYm94IHRv
IGJlIG5vdw0KCQkJCUBzYlskU1RfTVRJTUVdID0gdGltZTsNCgkJCX0NCgkJ
fQ0KDQoJCSMgY29weSBkYXRhIGJhY2sgaW50byBtYWlsYm94IHRvIHByZXNl
cnZlIHBlcm1pc3Npb25zLCBjcmVhdGlvbiB0aW1lDQoJCSMgYW5kIHVzZXIg
YW5kIGdyb3VwIGlkDQoNCgkJIyB6ZXJvIGxlbmd0aCB0aGUgbWFpbGJveA0K
CQl0cnVuY2F0ZSggTUJPWCwgMCApOw0KCQkjICoqKiBTVEFSVCBDcml0aWNh
bA0KCQkjIGFueSBkYXRhIHRvIGNvcHk/DQoJCWlmKCAkZXhwIDw9ICRjb3Vu
dCApIHsNCgkJCSMgcmVzdGFydCBib3RoIGZpbGVzDQoJCQlzZWVrKE1CT1gs
IDAsIDApOw0KCQkJc2VlayhUTVBGLCAwLCAwKTsNCgkJCSMgY29weSBmaWxl
IGludG8gbWFpbGJveCwgYmV0dGVyIHdpdGggc3lzcmVhZC9zeXN3cml0ZT8N
CgkJCXdoaWxlKCA8VE1QRj4gKSB7DQoJCQkJcHJpbnQgTUJPWCAkXzsNCgkJ
CX0NCgkJfSBlbHNpZiggISRvcHRfeiApIHsNCgkJCXVubGluayggJG1haWxi
b3ggKTsNCgkJfQ0KCQkjICoqKiBFTkQgQ3JpdGljYWwNCg0KCX0gZWxzZSB7
DQoJCSMgaWYgc2VuZGluZyB3YXJuaW5nIHRvIHRoZSBvd25lciBvZiB0aGUg
bWFpbGJveCwgYXBwZW5kIHdhcm5pbmcNCgkJaWYoICRvcHRfVyAmJiAkZXhw
ID4gMCApIHsNCgkJCWNob3AoICRjdCA9ICZjdGltZSh0aW1lKSApOw0KCQkJ
JHRvID0gJmJhc2VuYW1lKCAkbWFpbGJveCApOw0KCQkJY2hvcCggJGZyb21k
YXRlID0gYGRhdGUgK1wiJWEgJWIgJWQgJVggJVlcImAgKTsNCnByaW50Zigi
ZnJvbWRhdGUgPSAkZnJvbWRhdGVcbiIpOw0KCQkJcHJpbnQgVE1QRiAiRnJv
bSAkcG9zdG1hc3RlciAgJGZyb21kYXRlXG4iOw0KCQkJcHJpbnQgVE1QRiAi
RGF0ZTogJGN0XG4iOw0KCQkJcHJpbnQgVE1QRiAiRnJvbTogJHBvc3RtYXN0
ZXIgKE1haWwgRXhwaXJ5IEFnZW50KVxuIjsNCgkJCXByaW50IFRNUEYgIlJl
cGx5LVRvOiAkcG9zdG1hc3RlclxuIjsNCgkJCXByaW50IFRNUEYgIlRvOiAk
dG9cbiI7DQoJCQlwcmludCBUTVBGICJTdWJqZWN0OiBQbGVhc2UgZGVsZXRl
IG9sZCBtYWlsIGZyb20gc3lzdGVtIG1haWxib3hcblxuIjsNCgkJCXByaW50
IFRNUEYgIiR3YXJuaW5nXG5cbiI7DQoJCQkjIGZpdHRlZCB0byAkc3ViamVj
dHMgbGF5b3V0DQoJCQlwcmludCBUTVBGICIgTXNnIEZyb20gJiBTdWJqZWN0
ICAgICAgICAgICAgRGF0ZWRcblxuIjsNCgkJCWZvcmVhY2ggJG1zZyAoIEBz
dWJqZWN0cyApIHsNCgkJCQlwcmludCBUTVBGICIkbXNnXG4iOw0KCQkJfQ0K
DQoJCQlpZiggISRvcHRfVCApIHsNCgkJCQkjIHNldCB0aGUgbW9kaWZpY2F0
aW9uIHRpbWUgZm9yIHRoZSBtYWlsYm94IHRvIGJlIG5vdw0KCQkJCUBzYlsk
U1RfTVRJTUVdID0gdGltZTsNCgkJCX0NCg0KCQkJIyBjb3B5IGRhdGEgYmFj
ayBpbnRvIG1haWxib3ggdG8gcHJlc2VydmUgcGVybWlzc2lvbnMsIGNyZWF0
aW9uIHRpbWUNCgkJCSMgYW5kIHVzZXIgYW5kIGdyb3VwIGlkDQoJDQoJCQkj
IHplcm8gbGVuZ3RoIHRoZSBtYWlsYm94DQoJCQl0cnVuY2F0ZSggTUJPWCwg
MCApOw0KCQkJIyAqKiogU1RBUlQgQ3JpdGljYWwNCgkJCSMgYW55IGRhdGEg
dG8gY29weT8NCgkJCWlmKCAkZXhwIDw9ICRjb3VudCApIHsNCgkJCQkjIHJl
c3RhcnQgYm90aCBmaWxlcw0KCQkJCXNlZWsoTUJPWCwgMCwgMCk7DQoJCQkJ
c2VlayhUTVBGLCAwLCAwKTsNCgkJCQkjIGNvcHkgZmlsZSBpbnRvIG1haWxi
b3gsIGJldHRlciB3aXRoIHN5c3JlYWQvc3lzd3JpdGU/DQoJCQkJd2hpbGUo
IDxUTVBGPiApIHsNCgkJCQkJcHJpbnQgTUJPWCAkXzsNCgkJCQl9DQoJCQl9
IGVsc2lmKCAhJG9wdF96ICkgew0KCQkJCXVubGluayggJG1haWxib3ggKTsN
CgkJCX0NCgkJCSMgKioqIEVORCBDcml0aWNhbA0KCQl9DQoJfQ0KDQoJIyB1
bmxvY2sgbWFpbGJveA0KCWZsb2NrKCBNQk9YLCAkTE9DS19VTiApOw0KDQoJ
IyBjbG9zZSBmaWxlcw0KCWNsb3NlKCBNQk9YICk7DQoJY2xvc2UoIFRNUEYg
KTsNCg0KCSMgcmVzZXQgYWNjZXNzIGFuZCBtb2RpZmljYXRpb24gZGF0ZXMN
CgkjIGlmIHdlIGhhdmUgc2VudCBtYWlsLCB0aGVuIHRoZSBtb2RpZmljYXRp
b24gdGltZSBpcyB0aGUgdGltZSBvZiB0aGUgbWFpbA0KCWlmKCAhJG9wdF90
ICkgew0KCQl1dGltZSggQHNiWyRTVF9BVElNRV0sIEBzYlskU1RfTVRJTUVd
LCAkbWFpbGJveCApOw0KCX0NCg0KCSMgc2hvdyBjb3VudGVycw0KCWlmKCAk
b3B0X3YgfHwgKCAkb3B0X2wgJiYgJGV4cCApICkgew0KCQlwcmludCAiJG1h
aWxib3ggY29udGFpbmVkICRjb3VudCBtZXNzYWdlcywgZXhwaXJlZCAkZXhw
IG1lc3NhZ2VzXG4iOw0KCX0NCn0NCg=
---559023410-1483920592-993739196=:375--
Date: Thu, 28 Jun 2001 13:15:52 -0400
From: Daniel Senie <dts at senie dot com>
Subject: Re: Tools/methods for deleting old email?
At 10:49 AM 6/28/01, Gregory Hicks wrote:
>Actually, the setting is on the email client.
Right, but the ISP needs to be able to set limits as well. There's
auto-delete, but that just forces it all out immediately.
> Eudora, for example, has
>a setting where the user can specify whether or not to download the
>message. There is also a setting to delete mail after x days (x is
>user specified).
>
>Of course, with Eudora, there are other problems. For instance, if the
>user sets the option "Do not download any email more than xKB", once
>the user downloads the first xKB of the email, Eudora (or Popper, I'm
>not sure which is at fault here) thinks the mail has been read. What
>the user really wanted to do was to defer downloading until they get to
>a faster connection. What happens is that Eudora *never* downloads the
>message again.
Actually, in Eudora, if you go back to the messages where headers-only were
downloaded due to size, you can then ask to get the rest of the message
from the server. It acts kind of IMAP-ish, but does work pretty well. I
agree that my expectation also was that I'd get only the small messages,
and not even see the large ones, but their method has its merits too.
>The only fix I have found is to log in to the mail server and use some
>command line client ('pine' seems to work best), resend the message to
>the user and delete the original message.
I set up garbmail last night, and it does do what's needed. Still
interested in other choices (and will look at the other ones people pointed
to).
-----------------------------------------------------------------
Daniel Senie dts at senie dot com
Amaranth Networks Inc. http://www.amaranth.com
Date: Thu, 28 Jun 2001 12:10:49 -0400 (EDT)
From: Homer Wilson Smith <homer at lightlink dot com>
Subject: Re: Tools/methods for deleting old email?
> > I'd like to find some tools to go through mailboxes (mbox format, in
> > /var/spool/mail) and delete anything that's been read, and which is more
> > than 30 days old. I've got some users who just won't set the "delete from
> > server" switch, and it's time to take action. I really don't want to do
> > quotas enforcement at this point, though.
My wish is to have a username database that *ENABLES* leaving mail
on server for which users could pay an extra service fee.
However the problem is that the server can't tell client accesses
from webmail accesses which need to have mail left on server since
they don't download it.
> > An alternative would be to add auto-delete on a per-user basis, targetting
> > the abusive users only.
Its an easy hack which we made to 2.52 but abandoned when we
realized that some use webmail interfaces a lot, and they must by
definition leave the mail on the server.
Homer
> >
> > Any thoughts or pointers to tools would be greatly appreciated.
> >
> > Dan
> > -----------------------------------------------------------------
> > Daniel Senie dts at senie dot com
> > Amaranth Networks Inc. http://www.amaranth.com
>
From: "Alex M" <alex at myzona dot net>
Subject: Re: Qpopper 4.03
Date: Thu, 28 Jun 2001 11:44:03 -0700
Since it is FreeBSD you are using, you might want to consider using ports to
install qpopper, /usr/ports/mail/qpopper, it should and/or will install it
without troubles with all the freebsd patches applied and etc etc. You might
want to check the Makefile to see what options will be compiled in.
-=-=-=-
Regards,
Alex M aka TZapper
alex at myzona dot net
----- Original Message -----
From: "Alexander Utkin" <sasha at un.minsk dot by>
To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
Cc: <ams at un.minsk dot by>
Sent: Thursday, June 28, 2001 6:34 AM
Subject: Qpopper 4.03
> Dear Colleagues,
>
> I use popper 2.53 on old 2.1 FreeBSD box. I need to disable reverse DNS
> lookups to decrease client connection time. So i decided to shift to
> qpopper 4.0.2 (my first try) and 4.0.3 (the second one). From qpopper
manual
> i found out that i have to use crypt library to compile uner FreeBSD. As
far
> as i could understand (although i am not sure) i should compile
> with --enable-specialauth. On that process Qpopper.4.0.2 and 4.0.3 on
> FreeBSD 2.1 and 3.4 give me while making:
>
> pop_pass.c: In function `auth_user':
> pop_pass.c:1170: warning: assignment makes pointer from integer without a
> cast
> pop_pass.c:1177: dereferencing pointer to incomplete type
> *** Error code 1
>
> Stop.
>
> Can you advise me wether my corse of action for FreeBSD is correct and if
so
> what i can do with that. Ver. 2.53 doesn't have such problems but doesn't
> allow to disable lookups as well.
>
> Thank you very much for your help.
>
> Sasha
>
>
>
>
>
Date: Thu, 28 Jun 2001 13:17:26 -0400
From: Daniel Senie <dts at senie dot com>
Subject: Re: Tools/methods for deleting old email?
At 10:27 AM 6/28/01, Eric Luyten wrote:
> > Boy do I ever 2nd this motion. ;)
> > Maybe we should add it to Qpoppers wish list?
> > I suppose someone's going to tell us next that it's a procmail issue.
>
>
>No, we'll tell you to search the list archives.
>The question gets asked every six months or so :-)
If the list archives were searchable without downloading the whole set,
that might be a more worthwhile solution. Guess the only way to do it is a
wget followed by grep.
-----------------------------------------------------------------
Daniel Senie dts at senie dot com
Amaranth Networks Inc. http://www.amaranth.com
From: "Alex M" <alex at myzona dot net>
Subject: Re: Qpopper authentication.
Date: Thu, 28 Jun 2001 11:50:57 -0700
You would get a better help if'd post a more detailed error message, OS and
qpopper version.
-=-=-=-
Regards,
Alex M aka TZapper
alex at myzona dot net
----- Original Message -----
From: "Mark Weisman" <mweisman at gci dot net>
To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
Sent: Wednesday, June 27, 2001 11:28 PM
Subject: Qpopper authentication.
> Excuse all,
> I've got a really dumb question. I've recently setup Qpopper again, and
> for some reason it refuses to see what I've set for user passwords. I did
> not configure qpopper with any specauth or md5 password validation? What
> gives? Any help would be greatly appreciated.
>
> I did do a "make clean" prior to running this configure and make, my
> sendmail is working but the transistion between the two is not(however I
> don't really know that cause I can't log in). Any help??
>
> In Christ,
> Mark
>
>
Date: Thu, 28 Jun 2001 16:11:12 -0400 (EDT)
From: Admin Mailing Lists <mlist at intergrafix dot net>
Subject: Re: Tools/methods for deleting old email?
>
> However the problem is that the server can't tell client accesses
> from webmail accesses which need to have mail left on server since
> they don't download it.
>
sure ya can, jsut look at the client/peer ip. the web accesses will always
come from the ip of the web server, while client accesses will be from
dialup ips or whatever.
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
thelittleprince at asteroid-b612 dot org Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.org http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> > > An alternative would be to add auto-delete on a per-user basis, targetting
> > > the abusive users only.
>
> Its an easy hack which we made to 2.52 but abandoned when we
> realized that some use webmail interfaces a lot, and they must by
> definition leave the mail on the server.
>
> Homer
>
> > >
> > > Any thoughts or pointers to tools would be greatly appreciated.
> > >
> > > Dan
> > > -----------------------------------------------------------------
> > > Daniel Senie dts at senie dot com
> > > Amaranth Networks Inc. http://www.amaranth.com
> >
>
>
From: "Kent Morris" <gaunt at cophq dot org>
Subject: Compiling QPopper 4.0.3
Date: Thu, 28 Jun 2001 15:58:45 -0400
Sorry to post this again so soon, but I would like to get my server up as
soon as possible, and I'm getting pretty discouraged with this whole
situation. Somebody out there must have attempted to compile 4.0.3 with a
newer version of gcc (mine is 2.9.6 I believe) and gotten the error about
the use of tempnam() in maillock.c. If anybody has a solution to this
problem, could you please let me know.
Thanks,
Kent Morris
Date: Thu, 28 Jun 2001 14:04:51 -0800
Subject: Questions about authentication.
From: Mark Weisman <mweisman at gci dot net>
Excuse the topic,
I'm currently using Qpopper 3.1.2 effectively, on a Red hat v6.2 box. I've
got sendmail and DNS all setup so the machine is working. I went through and
followed the steps below:
>> make clean
>> ./configure --enable-servermode --enable-log-login --enable-bulletins
>>=/var/spool/bulls --enable-timing
>>
>> make
I then use the kill -HUP on the inetd.conf file and then attempt to login
using a telnet session:
telnet <servername> pop3
Enter my username,
Enter my password,
I get the following error message:
-ERR [AUTH] Password supplied for "username" is incorrect.
I know I've entered the correct password, and I've checked to ensure that
the path is readable, I'm missing something, I just don't know what.
The weird thing is that I can use the pine software, and read all messages
from /var/spool/mail folder just fine, yet Qpopper will not read them.
Any ideas,
Thanks,
Mark
Date: Thu, 28 Jun 2001 19:40:24 -0400 (EDT)
From: Homer Wilson Smith <homer at lightlink dot com>
Subject: Re: Tools/methods for deleting old email?
------------------------------------------------------------------------
Homer Wilson Smith Clean Air, Clear Water, Art Matrix - Lightlink
(607) 277-0959 A Green Earth and Peace. Internet Access, Ithaca NY
homer at lightlink.com Is that too much to ask? http://www.lightlink dot com
On Thu, 28 Jun 2001, Admin Mailing Lists wrote:
> >
> > However the problem is that the server can't tell client accesses
> > from webmail accesses which need to have mail left on server since
> > they don't download it.
> >
>
> sure ya can, jsut look at the client/peer ip. the web accesses will always
> come from the ip of the web server, while client accesses will be from
> dialup ips or whatever.
The problem here is that users tend to use any random
web mail interface they stumble across all over the world,
including proprietary ones in foreign lands, cafe shops etc.
There is no way to assure that s user will ONLY use the one we
provide on our web server.
Now if you have an answer to that problem, we are in business!
Homer
Date: Thu, 28 Jun 2001 20:19:38 -0500
From: Tim Olson <tolson at unionsemiconductor dot com>
Subject: Re: Questions about authentication.
Ok, I'm no expert at all, but have you considered "--with-pam"
and then gone through the stuff you need to do when you're
using pam? I think RedHat 6.2 uses PAM by default on
installs. The PAM stuff is in the documentation and I believe
in the text files that come with the qpopper tarball.
Hope I'm leading you up the right path anyway.
Tim
Mark Weisman wrote:
>
> Excuse the topic,
> I'm currently using Qpopper 3.1.2 effectively, on a Red hat v6.2 box. I've
> got sendmail and DNS all setup so the machine is working. I went through and
> followed the steps below:
> >> make clean
> >> ./configure --enable-servermode --enable-log-login --enable-bulletins
> >>=/var/spool/bulls --enable-timing
> >>
> >> make
>
> I then use the kill -HUP on the inetd.conf file and then attempt to login
> using a telnet session:
> telnet <servername> pop3
>
> Enter my username,
> Enter my password,
>
> I get the following error message:
> -ERR [AUTH] Password supplied for "username" is incorrect.
> I know I've entered the correct password, and I've checked to ensure that
> the path is readable, I'm missing something, I just don't know what.
>
> The weird thing is that I can use the pine software, and read all messages
> from /var/spool/mail folder just fine, yet Qpopper will not read them.
>
> Any ideas,
> Thanks,
> Mark
Date: Thu, 28 Jun 2001 20:26:43 -0600
From: "Joseph Lee Pereira" <joseph at jpereira dot com>
Subject: Inetd won't run
Mandrake 8 and I'm using Qpopper 4. I have the inetd.conf file configured with pop3 setting. No matter what I do I can't get inetd process to run.
Date: Fri, 29 Jun 2001 12:28:23 +0800 (HKT)
From: PM WONG <pmwong at power25t.hkbu.edu dot hk>
Subject: about option fast-update in ver4
Hello
Is this fast-update option only beneficial if
.user.pop lives in mail spool /var/spool/mail
(becos it uses mv instead of cp)
But for our mail server (AIX) , if they are in different
filesystem (i.e. directory), mv simply cp and then rm
, which doesn't save time at all
Date: Fri, 29 Jun 2001 12:34:53 +0800 (HKT)
From: PM WONG <pmwong at power25t.hkbu.edu dot hk>
Subject: runtime options in config file NOT user-specific?
Just downloaded the user adm. manual for ver 4.
Uunder the chapter "Run-Time Options from a Config file"
(page 27 to be exact), it said :
"Some options have restrictions indicating that they can't be
used in a .qpopper-options file in a user's home directory ..."
But when i looked at the table that follows, it doesn't
say which are those that can and those that can't
Any comments
From: "Dan Trainor" <dan at concept-factory dot com>
Subject: RE: Inetd won't run
Date: Thu, 28 Jun 2001 22:44:15 -0700
Ok.. can we get some more info then?
Dan Trainor
Systems Administrator
Concept Factory, LLC
www.concept-factory.com
dan at concept-factory dot com
-----Original Message-----
From: Joseph Lee Pereira [mailto:joseph at jpereira dot com]
Sent: Thursday, June 28, 2001 7:27 PM
To: Subscribers of Qpopper
Subject: Inetd won't run
Mandrake 8 and I'm using Qpopper 4. I have the inetd.conf file
configured with pop3 setting. No matter what I do I can't get inetd
process to run.
Date: Thu, 28 Jun 2001 20:04:13 -1000
From: Robert Brewer <rbrewer at lava dot net>
Subject: Re: web interface
--On Tuesday, June 26, 2001 4:40 PM +0100 Wasim Bashir
<wasim.bashir at broadband.co dot uk> wrote:
> Also what other mail clients support Apop, i've only found 3, these
> are Eudora, The Bat and Pegasus.
Mulberry <http://www.cyrusoft.com/> supports APOP as well (though I have
never used the APOP functionality).
Date: Thu, 28 Jun 2001 21:46:56 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: about option fast-update in ver4
On Fri, Jun 29, 2001 at 12:28:23PM +0800, PM WONG wrote:
> Hello
> Is this fast-update option only beneficial if
> .user.pop lives in mail spool /var/spool/mail
> (becos it uses mv instead of cp)
> But for our mail server (AIX) , if they are in different
> filesystem (i.e. directory), mv simply cp and then rm
> , which doesn't save time at all
Partially correct. They can be in a different directory, as long as
they are on the same filesystem (disk partition.) We used to have ours
on a separate partition but moved it back to the same partition (but a
different directory) to get the performance gain.
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- cliftonr at lava dot net
WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
From: "Megias Sanchez, Jose Manuel" <JMegias at caja-granada dot es>
Subject: Message unknown command: "xsender"
Date: Fri, 29 Jun 2001 10:41:13 +0200
Hello I've installed qpopper version 4.0.3 in a PC running FreeBSD
4.3 and sometimes it appears the following message:
mihost# Jun 29 10:31:25 mihost qpopper[82671]: jms2 at jms.mi-dominio.com
(10.130.105.3): -ERR Unknown command: "xsender".
the mail is working fine but what does it mean this message?. Thanks in
advance.
From: "Kenneth Porter" <shiva at well dot com>
Date: Fri, 29 Jun 2001 03:01:56 -0700
Subject: Re: Message unknown command: "xsender"
On Fri, 29 Jun 2001 10:41:13 +0200, Megias Sanchez, Jose Manuel wrote:
>the mail is working fine but what does it mean this message?. Thanks in
>advance.
This is in the FAQ at http://www.qpopper.org (which I can't seem to
connect to right now, looks like a DNS issue). Found an alternative
URL:
http://www.eudora.com/qpopper/faq.html#netscape.auth
Ken
mailto:shiva at well dot com
http://www.sewingwitch.com/ken/
[If answering a mailing list posting, please don't cc me your reply. I'll take my answer on the list.]
Date: Fri, 29 Jun 2001 05:24:59 -0700 (PDT)
From: Gustavo Viscaino <g_viscaino at yahoo dot com>
Subject: Re: Questions about authentication.
You're right. But I think that an easier way would be
to use the --enable-specialauth, flag. Btw, Mark, this
is in the FAQ:
http://www.eudora.com/qpopper/faq.html#shadow
Hope it helps,
Gustavo
--- Tim Olson <tolson at unionsemiconductor dot com> wrote:
> Ok, I'm no expert at all, but have you considered
> "--with-pam"
> and then gone through the stuff you need to do when
> you're
> using pam? I think RedHat 6.2 uses PAM by default
> on
> installs. The PAM stuff is in the documentation and
> I believe
> in the text files that come with the qpopper
> tarball.
> Hope I'm leading you up the right path anyway.
>
> Tim
>
>
> Mark Weisman wrote:
> >
> > Excuse the topic,
> > I'm currently using Qpopper 3.1.2 effectively,
> on a Red hat v6.2 box. I've
> > got sendmail and DNS all setup so the machine is
> working. I went through and
> > followed the steps below:
> > >> make clean
> > >> ./configure --enable-servermode
> --enable-log-login --enable-bulletins
> > >>=/var/spool/bulls --enable-timing
> > >>
> > >> make
> >
> > I then use the kill -HUP on the inetd.conf file
> and then attempt to login
> > using a telnet session:
> > telnet <servername> pop3
> >
> > Enter my username,
> > Enter my password,
> >
> > I get the following error message:
> > -ERR [AUTH] Password supplied for "username"
> is incorrect.
> > I know I've entered the correct password, and I've
> checked to ensure that
> > the path is readable, I'm missing something, I
> just don't know what.
> >
> > The weird thing is that I can use the pine
> software, and read all messages
> > from /var/spool/mail folder just fine, yet Qpopper
> will not read them.
> >
> > Any ideas,
> > Thanks,
> > Mark
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Subject: Re: Tools/methods for deleting old email?
Date: Fri, 29 Jun 2001 15:53:58 +0200 (MET DST)
From: Eric Luyten <Eric.Luyten at vub.ac dot be>
> > Eric Luyten, Computing Centre VUB/ULB,
> > running 'em' for mailbox expiration here.
>
> What do you use for mailbox expiration?
'em', which stand for 'Expire Mail'.
Written by Steve Mitchell of California State University, Fresno in 1991 (!)
I found a 'shar' type file on our system, 16 kilobytes large, containing
C source, man page, Makefile and README, but I am unable to provide you
with a public software repository location where you could find it.
I strongly hesitate to throw other people's work onto a public forum, even
ten years after date.
Eric Luyten.
Date: Fri, 29 Jun 2001 08:34:03 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: Tools/methods for deleting old email?
On Fri, Jun 29, 2001 at 03:53:58PM +0200, Eric Luyten wrote:
> > > Eric Luyten, Computing Centre VUB/ULB,
> > > running 'em' for mailbox expiration here.
> >
> > What do you use for mailbox expiration?
>
>
> 'em', which stand for 'Expire Mail'.
> Written by Steve Mitchell of California State University, Fresno in 1991 (!)
A google search with "em Steve Mitchell" as keywords found a posting to
this mailing list from last year, which pointed here:
<http://www.westnet.com/providers/>
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- cliftonr at lava dot net
WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
Date: Sat, 30 Jun 2001 16:14:43 +0800 (HKT)
From: PM WONG <pmwong at power25t.hkbu.edu dot hk>
Subject: define server mode for user without telling him
Now this new version 4 has this flexible option of having
the server mode for a specific user. This is handy as the
"global" server mode has too large impact on users.
Now i could trace some user's whose mailbox is tremendously
large (most probably he never deletes his mail or he has
somehow configure his mail client to "always leave on server")
Now suppose for performance sake, i make this user to have
"server mode" but don't inform him. If his mail client is
configured as "always leave on server", then fine.
But if it's config is "leave on server" AND "delete mail from server
when local copy is deleted", what will the behaviour be for this
qpopper 4.0.3 ? Does it depend also on whether his client is
netscape or eudora or outlook .. etc
From: "Mark Steil" <msteil at trvnet dot net>
Subject: Config File eror message please help
Date: Sat, 30 Jun 2001 09:38:22 -0500
Hello All,
I am getting the following error in my log files:
Config file nesting exceeds 100; will not process config file
/etc/qpopper.config
I do not see in the FAQ where this error is listed does anyone know what
Qpopper is trying to tell me?
Any help would be appreciated
Mark Steil
Systems Administrator
Twin Rivers Valley Communications Inc.
Phone 515-379-1070
Date: Sat, 30 Jun 2001 15:49:07 -0400 (EDT)
From: Homer Wilson Smith <homer at lightlink dot com>
Subject: Re: Config File eror message please help
Another one I loved was 'could not glue together text...'
Had mispelled tmp-dir
------------------------------------------------------------------------
Homer Wilson Smith Clean Air, Clear Water, Art Matrix - Lightlink
(607) 277-0959 A Green Earth and Peace. Internet Access, Ithaca NY
homer at lightlink.com Is that too much to ask? http://www.lightlink dot com
On Sat, 30 Jun 2001, Mark Steil wrote:
> Hello All,
>
> I am getting the following error in my log files:
>
> Config file nesting exceeds 100; will not process config file
> /etc/qpopper.config
>
> I do not see in the FAQ where this error is listed does anyone know what
> Qpopper is trying to tell me?
>
> Any help would be appreciated
>
>
> Mark Steil
> Systems Administrator
> Twin Rivers Valley Communications Inc.
> Phone 515-379-1070
>
>
>
>
Date: Sat, 30 Jun 2001 12:44:20 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: Config File eror message please help
On Sat, Jun 30, 2001 at 09:38:22AM -0500, Mark Steil wrote:
> Hello All,
>
> I am getting the following error in my log files:
>
> Config file nesting exceeds 100; will not process config file
> /etc/qpopper.config
>
> I do not see in the FAQ where this error is listed does anyone know what
> Qpopper is trying to tell me?
Are you trying to "include" /etc/qpopper.config from within
/etc/qpopper.config, maybe? Or perhaps a pair of files each of which
includes the other?
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- cliftonr at lava dot net
WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
Date: Sun, 1 Jul 2001 17:31:18 +0800 (HKT)
From: PM WONG <pmwong at power25t.hkbu.edu dot hk>
Subject: unix netscape messenger don't delete mail from server
Does anyone know anything about this.
I run the netscape 4.5 messenger to test some mail function
of qpopper. But i find that even setting the option that
"delete mail from server when local copy is deleted" don't
have any effect, i.e. the mail on server still remains.
Date: Sun, 1 Jul 2001 05:08:08 -0700 (PDT)
From: Gregory Hicks <ghicks at cadence dot com>
Subject: Re: unix netscape messenger don't delete mail from server
> Date: Sun, 1 Jul 2001 17:31:18 +0800 (HKT)
> From: PM WONG <pmwong at power25t.hkbu.edu dot hk>
>
> Does anyone know anything about this.
> I run the netscape 4.5 messenger to test some mail function
> of qpopper. But i find that even setting the option that
> "delete mail from server when local copy is deleted" don't
> have any effect, i.e. the mail on server still remains.
That setting actually only takes effect when the 'trash' is emptied.
Until the trash is emptied, the mail still exists.
Regards,
Gregory Hicks
Date: Mon, 2 Jul 2001 01:41:20 +0800 (HKT)
From: PM WONG <pmwong at power25t.hkbu.edu dot hk>
Subject: Re: unix netscape messenger don't delete mail from server
>
> That setting actually only takes effect when the 'trash' is emptied.
>
> Until the trash is emptied, the mail still exists.
But i did empty the trash. Is it a bug of qpopper or that of
my netscape
Date: Sun, 1 Jul 2001 21:09:27 -0700
From: Chuck Yerkes <chuck+qpopper at yerkes dot com>
Subject: Re: Tools/methods for deleting old email?
This is where I like cucipop's tactics. Simply ignore UIDL
and spew the mail to them fresh EVERY TIME. If you are mandating
that they don't store mail on server.
If it's okay for them to leave mail on server, then either
implement quota or blow money on disk (it's hard to buy
less than 36GB disks these days).
But deleting mail "for them" is wrong and evil.
If they are abusing, use a quota. They don't get their
new mail (temp fail) until they make room. End of Story.
Quoting Daniel Senie (dts at senie dot com):
> I'd like to find some tools to go through mailboxes (mbox format, in
> /var/spool/mail) and delete anything that's been read, and which is more
> than 30 days old. I've got some users who just won't set the "delete from
> server" switch, and it's time to take action. I really don't want to do
> quotas enforcement at this point, though.
>
> Anyone know of tools to do this? I'd love it if Qpopper had an option for
> this and would just perform the trim while it was doing its processing, but
> the only switch I find there is auto-delete.
>
> An alternative would be to add auto-delete on a per-user basis, targetting
> the abusive users only.
>
> Any thoughts or pointers to tools would be greatly appreciated.
>
> Dan
> -----------------------------------------------------------------
> Daniel Senie dts at senie dot com
> Amaranth Networks Inc. http://www.amaranth.com
From: "Desmond Lim" <ddl76 at singnet.com dot sg>
Subject: RE: Tools/methods for deleting old email?
Date: Mon, 2 Jul 2001 13:15:24 +0800
How do I unsubscribe from the mailing list?
-----Original Message-----
From: Chuck Yerkes [mailto:chuck+qpopper at yerkes dot com]
Sent: Monday, July 02, 2001 12:09 PM
To: Subscribers of Qpopper
Cc: Daniel Senie
Subject: Re: Tools/methods for deleting old email?
This is where I like cucipop's tactics. Simply ignore UIDL
and spew the mail to them fresh EVERY TIME. If you are mandating
that they don't store mail on server.
If it's okay for them to leave mail on server, then either
implement quota or blow money on disk (it's hard to buy
less than 36GB disks these days).
But deleting mail "for them" is wrong and evil.
If they are abusing, use a quota. They don't get their
new mail (temp fail) until they make room. End of Story.
Quoting Daniel Senie (dts at senie dot com):
> I'd like to find some tools to go through mailboxes (mbox format, in
> /var/spool/mail) and delete anything that's been read, and which is more
> than 30 days old. I've got some users who just won't set the "delete from
> server" switch, and it's time to take action. I really don't want to do
> quotas enforcement at this point, though.
>
> Anyone know of tools to do this? I'd love it if Qpopper had an option for
> this and would just perform the trim while it was doing its processing,
but
> the only switch I find there is auto-delete.
>
> An alternative would be to add auto-delete on a per-user basis, targetting
> the abusive users only.
>
> Any thoughts or pointers to tools would be greatly appreciated.
>
> Dan
> -----------------------------------------------------------------
> Daniel Senie dts at senie dot com
> Amaranth Networks Inc. http://www.amaranth.com
Date: Mon, 2 Jul 2001 11:40:18 +0400
From: "koriun@ipia" <koriun at ipia dot sci dot am>
Subject: QPopper and SSL
Hi all
How can I configure qpopper4 for ssl conection ??
I have some mail client and want make secure connection.
Qpopper docs are not enough for this.
Any other info or docs??
Thanks.
--
Best regards,
koriun mailto:koriun at ipia.sci dot am
Date: Mon, 2 Jul 2001 15:16:07 +0800 (HKT)
From: PM WONG <pmwong at power25t.hkbu.edu dot hk>
Subject: setting server-mode for individual user,how?
The manual was not clear at all as to the format of the
user config file. So i want to make sure i'm doing things right.
1. Compile qpopper with many default settings, i.e. NO server mode
2. When i run the qpopper the command line in my inetd.conf is
qpopper -U
(so i could make some user to have server mode)
3. Under /var/spool/mail , i place a file called
.some-user-name.qpopper-options
4. But now i'm confused , do i put
set server-mode
OR
server-mode
in this file ?
BTW, the main aim of having server-mode is to avoid the
step of creating the .user.pop file, isn't it?
BUt it seems that whether this is created depends ALSO
on the client side. If that user still set "delete mail from
server when local copy is deleted" , that .user.pop file
creation still happens.
Is this true ?
From: "Megias Sanchez, Jose Manuel" <JMegias at caja-granada dot es>
Subject: RE: Message unknown command: "xsender"
Date: Mon, 2 Jul 2001 10:32:06 +0200
Hello, thanks in advance.
-----Mensaje original-----
De: Kenneth Porter [mailto:shiva at well dot com]
Enviado el: viernes 29 de junio de 2001 12:02
Para: Subscribers of Qpopper
CC: Megias Sanchez, Jose Manuel
Asunto: Re: Message unknown command: "xsender"
On Fri, 29 Jun 2001 10:41:13 +0200, Megias Sanchez, Jose Manuel wrote:
>the mail is working fine but what does it mean this message?. Thanks in
>advance.
This is in the FAQ at http://www.qpopper.org (which I can't seem to
connect to right now, looks like a DNS issue). Found an alternative
URL:
http://www.eudora.com/qpopper/faq.html#netscape.auth
Ken
mailto:shiva at well dot com
http://www.sewingwitch.com/ken/
[If answering a mailing list posting, please don't cc me your reply. I'll
take my answer on the list.]
Date: Mon, 2 Jul 2001 06:45:48 -0700 (PDT)
From: Gregory Hicks <ghicks at cadence dot com>
Subject: RE: Message unknown command: "xsender"
> From: "Megias Sanchez, Jose Manuel" <JMegias at caja-granada dot es>
> Date: Mon, 2 Jul 2001 10:32:06 +0200
>
> -----Mensaje original-----
> De: Kenneth Porter [mailto:shiva at well dot com]
> Enviado el: viernes 29 de junio de 2001 12:02
>
> On Fri, 29 Jun 2001 10:41:13 +0200, Megias Sanchez, Jose Manuel wrote:
>
> >the mail is working fine but what does it mean this message?. Thanks in
> >advance.
>
> This is in the FAQ at http://www.qpopper.org (which I can't seem to
> connect to right now, looks like a DNS issue). Found an alternative
> URL:
>
> http://www.eudora.com/qpopper/faq.html#netscape.auth
>
Went here to see what it said...
The link to the "Netscape SMTP AUTH document" went to /dev/null...
Found the following:
http://www3.innosoft.com/~chris/smtpauth_client.html
Useful, discusses multiple clients.
Also went to knowledge.iplanet.com, did a quick search with "SMTP AUTH"
as the search args, and found a multitude of references.
Also, found a multitude of references with a Netscape search of
"Netscape SMTP AUTH"...
Hope this helps.
Regards,
Gregory Hicks
---------------------------------------------------------------------
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 at cadence dot com
Date: Mon, 2 Jul 2001 11:04:46 -0400
From: Scott McDermott <mcdermot at questra dot com>
Subject: Re: setting server-mode for individual user,how?
PM WONG on Mon 2/07 15:16 +0800:
> BTW, the main aim of having server-mode is to avoid the step of
> creating the .user.pop file, isn't it?
I think it also serves as a mutex to prevent concurrent sessions
From: "Crawford, Ray" <CrawfordRL at navair.navy dot mil>
Subject: Cancel
Date: Mon, 2 Jul 2001 08:23:25 -0700
Could I be removed from your list please. Thank You
Raymond L. Crawford
NAWCWD Code 413300D
(760) 939-4599 (Fax - 3028)
Date: Tue, 3 Jul 2001 00:36:46 +0900
From: Peter Evans <peter at gol dot com>
Subject: Re: Cancel
Crawford, Ray (CrawfordRL at navair.navy dot mil) wrote:
> List-Subscribe: <mailto:qpopper-request at lists.pensive dot org?body=subscribe>
> List-Unsubscribe: <mailto:qpopper-request at lists.pensive dot org?body=unsubscribe>
> List-Post: <mailto:qpopper at lists.pensive dot org>
> List-Help: http://www.pensive.org/Mailing_Lists/
> List-Id: <QPopper.lists.pensive.org>
> List-Software: AutoShare 4.2.3 by Mikael Hansen
> Could I be removed from your list please. Thank You
The above headers are in every single mail that this list sends out.
Now you know, you can remove yourself, rather than asking everyone
on this list.
-.-;
Last updated on 2 Jul 2001 by Pensive Mailing List Admin