The qpopper list archive ending on 27 Feb 1999
Topics covered in this issue include:
1. QPoppr Test Message #1
Randall Gellens <randy at pensive dot org>
Fri, 13 Nov 1998 09:44:32 -0800
2. QPoppr Test Message #2
Randall Gellens <randy at pensive dot org>
Fri, 13 Nov 1998 09:57:18 -0800
3. making patches to qpopper
<unknown at riverstyx dot net>
Thu, 14 Jan 1999 05:56:16 -0800 (PST)
4. FreeBSD 2.2.5 and QPopper's Popauth dumps core
Weldon S Godfrey 3 <weldon at excelsus dot com>
Thu, 14 Jan 1999 13:31:51 -0500 (EST)
5. 3.0 compile problem
System Administrator <admin at intergrafix dot net>
Thu, 14 Jan 1999 15:44:37 -0500 (EST)
6. Re: making patches to qpopper
Matthew Fillmore <MFillmore at pensive dot org>
Thu, 14 Jan 1999 21:01:16 -0800
7. Re: 3.0 compile problem
<unknown at riverstyx dot net>
Fri, 15 Jan 1999 12:44:54 -0800 (PST)
8. Re: making patches to qpopper
<unknown at riverstyx dot net>
Fri, 15 Jan 1999 13:14:28 -0800 (PST)
9. Re: 3.0 compile problem
System Administrator <admin at intergrafix dot net>
Fri, 15 Jan 1999 17:02:59 -0500 (EST)
10. Re: 3.0 compile problem
<unknown at riverstyx dot net>
Fri, 15 Jan 1999 14:27:41 -0800 (PST)
11. Can't find HTONL() code
Patrick Briggs <pbriggs at televar dot com>
Fri, 15 Jan 1999 14:32:51 -0800 (PST)
12. Re: Can't find HTONL() code
<unknown at riverstyx dot net>
Fri, 15 Jan 1999 14:45:55 -0800 (PST)
13. ERR Unable to process From ...
John Malick <john at starinc dot com>
Tue, 19 Jan 1999 14:27:17 -0500 (EST)
14. Re: ERR Unable to process From ...
System Administrator <admin at intergrafix dot net>
Tue, 19 Jan 1999 14:42:40 -0500 (EST)
15. Re: ERR Unable to process From ...
<unknown at riverstyx dot net>
Tue, 19 Jan 1999 14:52:44 -0800 (PST)
16. Re: ERR Unable to process From ...
Matthew Fillmore <MFillmore at pensive dot org>
Tue, 19 Jan 1999 19:45:40 -0800
17. Re: ERR Unable to process From ...
Matthew Fillmore <MFillmore at pensive dot org>
Tue, 19 Jan 1999 19:48:17 -0800
18. Re: ERR Unable to process From ...
unknown at riverstyx dot net
Tue, 19 Jan 1999 22:30:41 -0800 (PST)
19. Re: ERR Unable to process From ...
System Administrator <admin at intergrafix dot net>
Wed, 20 Jan 1999 10:52:14 -0500 (EST)
20. Re: ERR Unable to process From ...
Matthew Fillmore <MFillmore at pensive dot org>
Wed, 20 Jan 1999 09:42:28 -0800
21. Re: ERR Unable to process From ...
System Administrator <admin at intergrafix dot net>
Wed, 20 Jan 1999 13:31:02 -0500 (EST)
22. Re: ERR Unable to process From ...
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Wed, 20 Jan 1999 15:27:10 -0800
23. getsubopt()
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Wed, 20 Jan 1999 15:52:21 -0800
24. Re: ERR Unable to process From ...
System Administrator <admin at intergrafix dot net>
Wed, 20 Jan 1999 18:40:51 -0500 (EST)
25. Re: getsubopt()
<unknown at riverstyx dot net>
Wed, 20 Jan 1999 16:40:57 -0800 (PST)
26. Re: getsubopt()
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Wed, 20 Jan 1999 18:52:35 -0800
27. pop3 mail download timing out
Michael Dorin <dorin at puma.chaski dot com>
Sun, 24 Jan 1999 07:09:08 -0600 (CST)
28. Re: getsubopt()
System Administrator <admin at intergrafix dot net>
Mon, 25 Jan 1999 10:25:26 -0500 (EST)
29. old message
System Administrator <admin at intergrafix dot net>
Mon, 25 Jan 1999 11:28:24 -0500 (EST)
30.
"Kislov_D" <kislov at tekom.odessa dot ua>
Mon, 25 Jan 1999 23:33:30 +0300
31.
"Kislov_D" <kislov at tekom.odessa dot ua>
Mon, 25 Jan 1999 23:18:42 +0300
32. Un
"Laydron" <laydron at gte dot net>
Tue, 26 Jan 1999 22:15:25 -0600
33. Multiple emails in one message
Patrice Bruhat <patrice.bruhat at pcotech dot fr>
Wed, 27 Jan 1999 16:36:21 +0100
34. Re: Multiple emails in one message
Tim Mabbott <tmabbott at hbs dot edu>
Wed, 27 Jan 1999 11:06:00 -0500
35. can't open popauth DB
"Laydron" <laydron at gte dot net>
Wed, 27 Jan 1999 16:19:23 -0600
36. Re: can't open popauth DB
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Wed, 27 Jan 1999 17:59:07 -0800
37. problem with Netscape
Michael Huettich - NetWorks/GroupZ Technical Support <michaelh at cjnetworks dot com>
Thu, 28 Jan 1999 09:35:49 -0600 (CST)
38. Re: problem with Netscape
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Thu, 28 Jan 1999 11:55:28 -0800
39. Re: problem with Netscape
<unknown at riverstyx dot net>
Thu, 28 Jan 1999 11:58:24 -0800 (PST)
40. Re: Multiple emails in one message
Leonard Hermens <Leonard.Hermens at itron dot com>
Thu, 28 Jan 1999 12:15:14 -0800
41. Re: getsubopt()
Earle Ake <earle.ake at hcst dot com>
Thu, 28 Jan 1999 22:16:19 -0500 (EST)
42. lock busy
System Administrator <admin at intergrafix dot net>
Wed, 3 Feb 1999 20:06:18 -0500 (EST)
43. BULLETINS
Ross Mistretta <rossm at imedgecom dot com>
Fri, 05 Feb 1999 08:46:31 -0500
44. Re: BULLETINS
Tomasz Orzechowski <tmo at mail.hep.utexas dot edu>
Fri, 5 Feb 1999 09:03:41 -0600
45. problem with HP-UX 10.20
antonio chavez <achavez at apollo.ccu.umich dot mx>
Fri, 05 Feb 1999 19:48:04 CST
46. Re: problem with HP-UX 10.20
Tomasz Orzechowski <tmo at mail.hep.utexas dot edu>
Fri, 5 Feb 1999 21:32:19 -0600
47. APOP & CRAM on Netscape
Walcir Fontanini-ADM- <walcir at densis.fee.unicamp dot br>
Mon, 8 Feb 1999 10:33:21 -0200 (BDB)
48. Dual syslog messaging
Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Mon, 8 Feb 1999 18:40:00 -0200 (EDT)
49. Qpopper 3.0b13 available
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Mon, 8 Feb 1999 15:50:40 -0800
50. getsubopt() again
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Wed, 10 Feb 1999 15:42:44 -0800
51. Re: getsubopt() again
Earle Ake <earle.ake at hcst dot com>
Wed, 10 Feb 1999 19:29:16 -0500 (EST)
52. Re: getsubopt() again
Albert Mamanov <albert at kosnet dot ru>
Thu, 11 Feb 1999 08:55:25 +0300 (MSK)
53. Qpopper3.0b13 on HPUX10.20
"T.Ueda" <ueda at power.elec.kitami-it.ac dot jp>
Fri, 12 Feb 1999 09:12:51 +0900
54. P.S. of "Qpopper3.0b13 on HPUX10.20"
"T.Ueda" <ueda at power.elec.kitami-it.ac dot jp>
Fri, 12 Feb 1999 09:31:39 +0900
55. QPOP 2.53 Bug??
Systems Administration <dk at intercomm dot com>
Thu, 11 Feb 1999 17:44:51 -0800 (PST)
56. Re: getsubopt() again
Roy Kidder <rkidder at ocom dot com>
Fri, 12 Feb 1999 16:18:36 -0500
57. interaction between sendmail's local delivery agent & qpopper
rosenblg at nyu dot edu
Fri, 12 Feb 1999 20:52:57 -0500 (EST)
58. Re: interaction between sendmail's local delivery agent & qpopper
Leonard Hermens <Leonard.Hermens at itron dot com>
Fri, 12 Feb 1999 19:57:47 -0800
59. Re: interaction between sendmail's local delivery agent & qpopper
Systems Administration <dk at intercomm dot com>
Fri, 12 Feb 1999 20:18:42 -0800 (PST)
60. STAT log message containing IP?
Alan Brown <alan at manawatu.gen dot nz>
Mon, 15 Feb 1999 00:14:52 +1300 (NZDT)
61. qpopper configuration help
Mike Cantrell <linux at onethirtyeight dot org>
Sun, 14 Feb 1999 18:36:17 +0000
62. Re: qpopper configuration help
Mike Cantrell <yomahz at cx611883-d.chnd1.az.home dot com>
Sun, 14 Feb 1999 19:26:11 +0000
63. Re: qpopper configuration help
Tomasz Orzechowski <tmo at mail.hep.utexas dot edu>
Sun, 14 Feb 1999 13:03:58 -0600
64. Re: qpopper configuration help
System Administrator <admin at intergrafix dot net>
Sun, 14 Feb 1999 16:05:52 -0500 (EST)
65. Extended logging with Qpopper
"Andy Brown" <andy at tc3net dot net>
Sun, 14 Feb 1999 22:54:15 -0000
66. problems with qpopper
Byron Jones <byron at vianet.net dot au>
Mon, 15 Feb 1999 10:03:15 +0800
67. Re: problems with qpopper
Alan Brown <alan at manawatu.gen dot nz>
Mon, 15 Feb 1999 16:17:06 +1300 (NZDT)
68. Re: problems with qpopper
Byron Jones <byron at vianet.net dot au>
Mon, 15 Feb 1999 11:37:17 +0800
69. Re: STAT log message containing IP?
Matthew Fillmore <MFillmore at pensive dot org>
Sun, 14 Feb 1999 22:25:09 -0800
70. Re: STAT log message containing IP?
Alan Brown <alan at manawatu.gen dot nz>
Mon, 15 Feb 1999 19:44:50 +1300 (NZDT)
71. Re: problems with qpopper
System Administrator <admin at intergrafix dot net>
Mon, 15 Feb 1999 08:59:49 -0500 (EST)
72. Re: problems with qpopper
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Tue, 16 Feb 1999 19:09:16 -0800
73. Re: getsubopt() again
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Tue, 16 Feb 1999 19:20:33 -0800
74. Re: problems with qpopper
Alan Brown <alan at manawatu.gen dot nz>
Wed, 17 Feb 1999 19:00:04 +1300 (NZDT)
75. NFS with qpopper?
"Tabor J. Wells" <twells at shore dot net>
Wed, 17 Feb 1999 13:16:19 -0500
76. Re: getsubopt() again
Roy Kidder <rkidder at ocom dot com>
Wed, 17 Feb 1999 14:18:15 -0500
77. Popper exec size seems too large
Brad Groshok <brad at mur3.odyssey.on dot ca>
Wed, 17 Feb 1999 15:11:24 -0500 (EST)
78. Re: Popper exec size seems too large
Ben Duncan - iSecure Networks <ben at isecure dot net>
Wed, 17 Feb 1999 16:02:32 -0400
79. Re: getsubopt() again
Erik Andersen <erikande at danbbs dot dk>
Wed, 17 Feb 1999 21:55:49 +0100
80. Re: getsubopt() again
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Wed, 17 Feb 1999 12:54:31 -0800
81. Re: getsubopt() again
Roy Kidder <rkidder at ocom dot com>
Wed, 17 Feb 1999 17:38:09 -0500
82.
"Daryl" <daryl at ledanet.com dot au>
Thu, 18 Feb 1999 11:05:35 +1000
83. SERVER_MODE
"William F. Dudley" <dud at squid.monmouth dot com>
Thu, 18 Feb 1999 10:42:12 -0500 (EST)
84. Canonical Name Error
=?iso-8859-1?Q?Søren_Peter_Skou?= <SPS at mobilix dot dk>
Thu, 18 Feb 1999 17:04:30 +0100
85. Re: Canonical Name Error
Alan Brown <alan at manawatu.gen dot nz>
Fri, 19 Feb 1999 06:01:46 +1300 (NZDT)
86. Time Out - Help needed
John Vozza <john at netrom dot com>
Thu, 18 Feb 1999 13:35:44 -0500 (EST)
87. Re: Time Out - Help needed
Alan Brown <alan at manawatu.gen dot nz>
Fri, 19 Feb 1999 07:47:28 +1300 (NZDT)
88. Re: Time Out - Help needed
John Vozza <john at netrom dot com>
Thu, 18 Feb 1999 14:45:52 -0500 (EST)
89. Re: Time Out - Help needed
Alan Brown <alan at manawatu.gen dot nz>
Fri, 19 Feb 1999 09:01:02 +1300 (NZDT)
90. Re: Time Out - Help needed
John Vozza <john at netrom dot com>
Thu, 18 Feb 1999 16:11:29 -0500 (EST)
91. Re: NFS with qpopper?
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Thu, 18 Feb 1999 14:34:02 -0800
92. Re: SERVER_MODE
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Thu, 18 Feb 1999 14:39:43 -0800
93. Re: Canonical Name Error
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Thu, 18 Feb 1999 14:44:06 -0800
94.
=?iso-8859-1?Q?Frédéric_Van_Walle?= <fred at CAC dot BE>
Fri, 19 Feb 1999 08:35:23 +0100
95. Re: getsubopt() again
Roy Kidder <rkidder at ocom dot com>
Fri, 19 Feb 1999 10:18:09 -0500
96. Re: SERVER_MODE
"William F. Dudley" <dud at squid.monmouth dot com>
Fri, 19 Feb 1999 10:25:23 -0500 (EST)
97. (no subject)
Sarah Riner <riners at lituus dot net>
Fri, 19 Feb 1999 17:11:12 -0600
98. Re: SERVER_MODE
Alan Brown <alan at manawatu.gen dot nz>
Sat, 20 Feb 1999 12:44:43 +1300 (NZDT)
99. Compiling 2.53 on DG/UX
"Peter Turner" <Peter_Turner at walkergreenbank dot com>
Mon, 22 Feb 1999 11:17:36 -0000
100. Re: Compiling 2.53 on DG/UX
Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Mon, 22 Feb 1999 08:44:15 -0300 (EST)
101. Several problems
"Steven W. Riggins" <geek at geeksrus dot com>
Wed, 24 Feb 1999 00:30:31 -0800
102. Re: Several problems
System Administrator <admin at intergrafix dot net>
Wed, 24 Feb 1999 08:51:50 -0500 (EST)
103. XTND XMIT
Alan Brown <alan at manawatu.gen dot nz>
Thu, 25 Feb 1999 03:16:01 +1300 (NZDT)
104. qpopper2.53: Slow login
"Technik, GRUENE" <technik at gruene dot de>
Wed, 24 Feb 1999 19:51:22 +0100
105. Re: qpopper2.53: Slow login
Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Wed, 24 Feb 1999 16:00:17 -0300 (EST)
106. Re: getsubopt() again
Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Wed, 24 Feb 1999 12:08:40 -0800
107. Re: getsubopt() again
Roy Kidder <rkidder at ocom dot com>
Wed, 24 Feb 1999 15:23:13 -0500
108. qpopper not releasing lock
Byron Jones <byron at vianet.net dot au>
Thu, 25 Feb 1999 12:06:55 +0800
109. Re: qpopper not releasing lock
Alan Brown <alan at manawatu.gen dot nz>
Thu, 25 Feb 1999 23:39:29 +1300 (NZDT)
110. Re: qpopper not releasing lock
Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Thu, 25 Feb 1999 10:27:23 -0300 (EST)
111. Re: qpopper not releasing lock
System Administrator <admin at intergrafix dot net>
Thu, 25 Feb 1999 09:55:47 -0500 (EST)
112. popper(?) loosing mail messages
Brad Groshok <bgroshok at odyssey.on dot ca>
Thu, 25 Feb 1999 10:32:41 -0500
113. Longer then 8 character passwds
"Reid Sutherland" <reid at isys dot ca>
Thu, 25 Feb 1999 12:31:37 -0500
114. Re: Longer then 8 character passwds
Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Fri, 26 Feb 1999 13:25:24 -0300 (EST)
115. Can someone help me?
"Frost" <frost at engen dot com>
Sat, 27 Feb 1999 10:28:47 -0700
116. popauth problem...
"Evan Erwin" <obiwan at frag dot com>
Sun, 28 Feb 1999 00:55:16 -0500
Date: Fri, 13 Nov 1998 09:44:32 -0800
From: Randall Gellens <randy at pensive dot org>
Subject: QPoppr Test Message #1
This is, indeed, a test. Line 1.
This is, indeed, a test. Line 2.
This is, indeed, a test. Line 3.
This is, indeed, a test. Line 4.
This is, indeed, a test. Line 5.
This is, indeed, a test. Line 6.
--
Normally, a witty signature would appear here.
Randy at Pensive dot Org
Date: Fri, 13 Nov 1998 09:57:18 -0800
From: Randall Gellens <randy at pensive dot org>
Subject: QPoppr Test Message #2
This is, indeed, a test. Line 1.
This is, indeed, a test. Line 2.
This is, indeed, a test. Line 3.
This is, indeed, a test. Line 4.
This is, indeed, a test. Line 5.
This is, indeed, a test. Line 6.
--
Normally, a witty signature would appear here.
Randy at Pensive dot Org
Date: Thu, 14 Jan 1999 05:56:16 -0800 (PST)
From: <unknown at riverstyx dot net>
Subject: making patches to qpopper
i was just wondering how legal it is to release patches to qpopper. it's
not like i'm asking for money, i'm just giving out a couple things that i
did to my server, but that legal document in the distro looks kinda
restrictive about that kinda thing.
---
unknown at riverstyx dot net
Date: Thu, 14 Jan 1999 13:31:51 -0500 (EST)
From: Weldon S Godfrey 3 <weldon at excelsus dot com>
Subject: FreeBSD 2.2.5 and QPopper's Popauth dumps core
I am having trouble getting APOP to work. The problem is that popauth
works fine for initaialiing the database, but any other command causes a
core dump.
the pop user is 'pop' (UID=110, GID=110)
The mode of pop.auth database is 600, the database is in /etc owned by pop
The mode of popauth is 4755, owned by pop
The proper options was used during the configure (the error is 'not
configured for APOP' if it wasn't configured.
popauth is in /usr/local/bin
Same problem occures with the latest beta release and 2.3
I have tried playing with the modes, ownership and uid/gid numbers of the
pop user, same results.
Date: Thu, 14 Jan 1999 15:44:37 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: 3.0 compile problem
Trying to compile the 3.0 beta. I have Caldera Openlinux 1.1, libc 5.4.38
shadow passwords, pam support, kernel 2.0.35
Ran ./configure --prefix=/usr -enable-servermode --enable-specialauth
On a make i get:
pop_init.o: In function `pop_init':
/usr/src/qpopper3.0/popper/pop_init.c:240: undefined reference to
`getsubopt'
ideas?
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"The best way to predict the future, is to invent it."
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Thu, 14 Jan 1999 21:01:16 -0800
From: Matthew Fillmore <MFillmore at pensive dot org>
Subject: Re: making patches to qpopper
At 5:56 AM -0800 1/14/99, <unknown at riverstyx dot net> wrote:
> i was just wondering how legal it is to release patches to qpopper. it's
> not like i'm asking for money, i'm just giving out a couple things that i
> did to my server, but that legal document in the distro looks kinda
> restrictive about that kinda thing.
There is no problem with making patches available. You might want to
post a URL for them to this list, and if you think they should be
included in future releases of Qpopper, also send them to
<qpopper at qualcomm dot com>.
--
Matthew Fillmore
MFillmore at Pensive dot Org
Date: Fri, 15 Jan 1999 12:44:54 -0800 (PST)
From: <unknown at riverstyx dot net>
Subject: Re: 3.0 compile problem
Yeh. libc5 don't got getsupopt. i commented out that entire block and
got it to compile fine. i'm going to write a getsubopt replacement next,
i guess... not that i intend to use that function much, but i hate having
cheap hacks like that on my machine.
---
unknown at riverstyx dot net
On Thu, 14 Jan 1999, System Administrator wrote:
> Trying to compile the 3.0 beta. I have Caldera Openlinux 1.1, libc 5.4.38
> shadow passwords, pam support, kernel 2.0.35
>
> Ran ./configure --prefix=/usr -enable-servermode --enable-specialauth
> On a make i get:
>
> pop_init.o: In function `pop_init':
> /usr/src/qpopper3.0/popper/pop_init.c:240: undefined reference to
> `getsubopt'
>
> ideas?
>
> -Tony
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> Anthony J. Biacco Network Administrator/Engineer
> admin at intergrafix dot net Intergrafix Internet Services
>
> "The best way to predict the future, is to invent it."
> http://cygnus.ncohafmuta.com http://www.intergrafix.net
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
>
>
Date: Fri, 15 Jan 1999 13:14:28 -0800 (PST)
From: <unknown at riverstyx dot net>
Subject: Re: making patches to qpopper
Cool. I put together a patch for 2.53 and 3.0b12 that allows you to store
all your usernames/passwords/uid/gid/maildrop in a mysql database. it's
at http://www.riverstyx.net/qpopmysql/
i'm going to patch qpop for pam once i put together a mysql module for pam
and get pam running on my slackware box (looks like it's going to be a
nightmare).
---
unknown at riverstyx dot net
On Thu, 14 Jan 1999, Matthew Fillmore wrote:
> At 5:56 AM -0800 1/14/99, <unknown at riverstyx dot net> wrote:
>
> > i was just wondering how legal it is to release patches to qpopper. it's
> > not like i'm asking for money, i'm just giving out a couple things that i
> > did to my server, but that legal document in the distro looks kinda
> > restrictive about that kinda thing.
>
> There is no problem with making patches available. You might want to
> post a URL for them to this list, and if you think they should be
> included in future releases of Qpopper, also send them to
> <qpopper at qualcomm dot com>.
>
>
> --
> Matthew Fillmore
> MFillmore at Pensive dot Org
>
Date: Fri, 15 Jan 1999 17:02:59 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: 3.0 compile problem
On Fri, 15 Jan 1999 unknown at riverstyx dot net wrote:
> Yeh. libc5 don't got getsupopt. i commented out that entire block and
> got it to compile fine. i'm going to write a getsubopt replacement next,
> i guess... not that i intend to use that function much, but i hate having
> cheap hacks like that on my machine.
>
*nod* i just commented it out and now it works fine. Do you know of any
problems it has with kernel 2.2.0pre7..specifically with quotas. I've run
the 2.1.x kernels with quotas enabled on my other machines, web server,
etc.. with no problem, but on the mail server the dquot-nr (under
/proc/sys/fs/) is exceeding the default dquot-max of 256 and wreaking
havoc.
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"The best way to predict the future, is to invent it."
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> ---
> unknown at riverstyx dot net
>
>
> On Thu, 14 Jan 1999, System Administrator wrote:
>
> > Trying to compile the 3.0 beta. I have Caldera Openlinux 1.1, libc 5.4.38
> > shadow passwords, pam support, kernel 2.0.35
> >
> > Ran ./configure --prefix=/usr -enable-servermode --enable-specialauth
> > On a make i get:
> >
> > pop_init.o: In function `pop_init':
> > /usr/src/qpopper3.0/popper/pop_init.c:240: undefined reference to
> > `getsubopt'
> >
> > ideas?
> >
> > -Tony
> > .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> > Anthony J. Biacco Network Administrator/Engineer
> > admin at intergrafix dot net Intergrafix Internet Services
> >
> > "The best way to predict the future, is to invent it."
> > http://cygnus.ncohafmuta.com http://www.intergrafix.net
> > .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> >
> >
>
Date: Fri, 15 Jan 1999 14:27:41 -0800 (PST)
From: <unknown at riverstyx dot net>
Subject: Re: 3.0 compile problem
I haven't done much with 2.2.0. I'm pretty sure that you can set a higher
dquot-max in /proc/sys/kernel/dquot-max though. That should fix any kind
of problems you have.
---
unknown at riverstyx dot net
On Fri, 15 Jan 1999, System Administrator wrote:
> On Fri, 15 Jan 1999 unknown at riverstyx dot net wrote:
>
> > Yeh. libc5 don't got getsupopt. i commented out that entire block and
> > got it to compile fine. i'm going to write a getsubopt replacement next,
> > i guess... not that i intend to use that function much, but i hate having
> > cheap hacks like that on my machine.
> >
>
> *nod* i just commented it out and now it works fine. Do you know of any
> problems it has with kernel 2.2.0pre7..specifically with quotas. I've run
> the 2.1.x kernels with quotas enabled on my other machines, web server,
> etc.. with no problem, but on the mail server the dquot-nr (under
> /proc/sys/fs/) is exceeding the default dquot-max of 256 and wreaking
> havoc.
>
> -Tony
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> Anthony J. Biacco Network Administrator/Engineer
> admin at intergrafix dot net Intergrafix Internet Services
>
> "The best way to predict the future, is to invent it."
> http://cygnus.ncohafmuta.com http://www.intergrafix.net
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
>
>
> > ---
> > unknown at riverstyx dot net
> >
> >
> > On Thu, 14 Jan 1999, System Administrator wrote:
> >
> > > Trying to compile the 3.0 beta. I have Caldera Openlinux 1.1, libc 5.4.38
> > > shadow passwords, pam support, kernel 2.0.35
> > >
> > > Ran ./configure --prefix=/usr -enable-servermode --enable-specialauth
> > > On a make i get:
> > >
> > > pop_init.o: In function `pop_init':
> > > /usr/src/qpopper3.0/popper/pop_init.c:240: undefined reference to
> > > `getsubopt'
> > >
> > > ideas?
> > >
> > > -Tony
> > > .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> > > Anthony J. Biacco Network Administrator/Engineer
> > > admin at intergrafix dot net Intergrafix Internet Services
> > >
> > > "The best way to predict the future, is to invent it."
> > > http://cygnus.ncohafmuta.com http://www.intergrafix.net
> > > .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> > >
> > >
> >
>
>
Date: Fri, 15 Jan 1999 14:32:51 -0800 (PST)
From: Patrick Briggs <pbriggs at televar dot com>
Subject: Can't find HTONL() code
Attempting to compile Qpopper3.0Beta12 on HP-UX 10.20 results in a linker
error trying to find the code to htonl(). Anyone know what library that
code might be contained in? Here is the man page for htonl if that
helps. It appears like HP-UX might not need htonl() call and should be
omitted by the sounds of the man page.
byteorder(3N)
NAME
htonl(), htons(), ntohl(), ntohs() - convert values between host and
network byte order
SYNOPSIS
#include <netinet/in.h>
_XOPEN_SOURCE_EXTENDED only
#include <arpa/inet.h>
unsigned long htonl(unsigned long hostlong);
unsigned short htons(unsigned short hostshort);
unsigned long ntohl(unsigned long netlong);
unsigned short ntohs(unsigned short netshort);
DESCRIPTION
These routines convert 16- and 32-bit quantities between networkbyte
order and host byte order. On HP-UX systems, network and host byte
orders are identical, so these routines are defined as null macros in
the include file <netinet/in.h>. If _XOPEN_SOURCE_EXTENDED is defined
then these routines are defined in the include file <arpa/inet.h>.
These routines are most often used in conjunction with Internet
addresses and ports as returned by gethostent() and getservent() (see
gethostent(3N) and getservent(3N)). Use these routines to write
portable programs.
AUTHOR
byteorder() was developed by the University of California, Berkeley.
SEE ALSO
gethostent(3N), getservent(3N).
STANDARDS CONFORMANCE
byteorder(): XPG4
Hewlett-Packard Company - 1 - HP-UX Release 10.20: July 1996
--
Patrick Briggs
E-MAIL: pbriggs at televar dot com
Date: Fri, 15 Jan 1999 14:45:55 -0800 (PST)
From: <unknown at riverstyx dot net>
Subject: Re: Can't find HTONL() code
afaik, htonl is standard c library. and, i think hp is bigendian, so you
can write a dummy htonl that takes in a unsigned long and returns that
same unsigned long.
if that does something truly weird, then it's a simple enough matter to
swap the order of the bytes in the longint and return that instead.
don't take my word for it though, i'm primarily a linux user, i only
venture out into foreign territory when absolutely necessary.
---
unknown at riverstyx dot net
On Fri, 15 Jan 1999, Patrick Briggs wrote:
> Attempting to compile Qpopper3.0Beta12 on HP-UX 10.20 results in a linker
> error trying to find the code to htonl(). Anyone know what library that
> code might be contained in? Here is the man page for htonl if that
> helps. It appears like HP-UX might not need htonl() call and should be
> omitted by the sounds of the man page.
>
> byteorder(3N)
>
> NAME
> htonl(), htons(), ntohl(), ntohs() - convert values between host and
> network byte order
>
> SYNOPSIS
> #include <netinet/in.h>
>
> _XOPEN_SOURCE_EXTENDED only
> #include <arpa/inet.h>
>
> unsigned long htonl(unsigned long hostlong);
>
> unsigned short htons(unsigned short hostshort);
>
> unsigned long ntohl(unsigned long netlong);
>
> unsigned short ntohs(unsigned short netshort);
>
> DESCRIPTION
> These routines convert 16- and 32-bit quantities between networkbyte
> order and host byte order. On HP-UX systems, network and host byte
> orders are identical, so these routines are defined as null macros in
> the include file <netinet/in.h>. If _XOPEN_SOURCE_EXTENDED is defined
> then these routines are defined in the include file <arpa/inet.h>.
>
> These routines are most often used in conjunction with Internet
> addresses and ports as returned by gethostent() and getservent() (see
> gethostent(3N) and getservent(3N)). Use these routines to write
> portable programs.
>
> AUTHOR
> byteorder() was developed by the University of California, Berkeley.
>
> SEE ALSO
> gethostent(3N), getservent(3N).
>
> STANDARDS CONFORMANCE
> byteorder(): XPG4
>
> Hewlett-Packard Company - 1 - HP-UX Release 10.20: July 1996
>
>
> --
> Patrick Briggs
> E-MAIL: pbriggs at televar dot com
>
>
Date: Tue, 19 Jan 1999 14:27:17 -0500 (EST)
From: John Malick <john at starinc dot com>
Subject: ERR Unable to process From ...
I am in the process of converting Netscape's mail server to qpopper for the pop
side and using Sendmail 8.9.1 for the SMTP mailer.
Everything is working fine except for transition of Netscape's user mail to the
standard Unix single file mail.
Netscape uses the format:
/netmail/username/mail1
mail2
mail3
...
In other words, every piece of mail is a separate file. In Unix, Solaris
specifically, all email is simply in one file.
The answer seemed obvious, append or cat all the files together into one large
file. The problem is a get the following error message when I try to pop to the
server:
ERR Unable to process From lines (envelopes) change recognition modes ..
If I manually edit my newly made file and manually add From lines before each
email entry it works. Obviously I do not want to do this to several gigabytes of
email.
Has anyone run into this one before.
Thanks and a summary will follow
************************************
*
John Malick - Systems Engineering *
Star Systems Engineering *
140 Roosevelt Ave. *
York, PA. 17404 *
*
(717) 854-5911 Phone *
(717) 852-9421 Fax *
john at starinc dot com Email *
www.starinc.com Web Site *
*
************************************
Date: Tue, 19 Jan 1999 14:42:40 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: ERR Unable to process From ...
On Tue, 19 Jan 1999, John Malick wrote:
> I am in the process of converting Netscape's mail server to qpopper for the pop
> side and using Sendmail 8.9.1 for the SMTP mailer.
>
haha, oh my gawd, it's john! when you hear from patti (she's still in
bermuda i think), tell her cyggie said hi!
anyway..i have this same problem with qpopper every so often (even 3.0b).
I'm not converting files or anything, but it still happens in user's mail
files. When i get this error and look in the user's mailfile, the first
line in the file will be a From line, but the F will be missing, like:
rom Anthony J. Biacco <admin at intergrafix dot net>
If i stick an F in there, save the file, bang! i can retrieve the mail
again
I dont know if this a problem with qpopper rewriting the mailfile or with
sendmail writing to the user's mailfile (we use sendmail 8.8.8)
ideas from the qualcomm people?
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"The best way to predict the future, is to invent it."
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> Everything is working fine except for transition of Netscape's user mail to the
> standard Unix single file mail.
>
> Netscape uses the format:
>
> /netmail/username/mail1
> mail2
> mail3
> ...
>
> In other words, every piece of mail is a separate file. In Unix, Solaris
> specifically, all email is simply in one file.
>
> The answer seemed obvious, append or cat all the files together into one large
> file. The problem is a get the following error message when I try to pop to the
> server:
>
> ERR Unable to process From lines (envelopes) change recognition modes ..
>
> If I manually edit my newly made file and manually add From lines before each
> email entry it works. Obviously I do not want to do this to several gigabytes of
> email.
>
> Has anyone run into this one before.
>
> Thanks and a summary will follow
>
>
>
> ************************************
> *
> John Malick - Systems Engineering *
> Star Systems Engineering *
> 140 Roosevelt Ave. *
> York, PA. 17404 *
> *
> (717) 854-5911 Phone *
> (717) 852-9421 Fax *
> john at starinc dot com Email *
> www.starinc.com Web Site *
> *
> ************************************
>
Date: Tue, 19 Jan 1999 14:52:44 -0800 (PST)
From: <unknown at riverstyx dot net>
Subject: Re: ERR Unable to process From ...
Well, I've seen that problem happen with ipop3d before... I couldn't
really say. In answer to the first, one (nasty) way to fix the problem
would be to use fetchmail to pull down all the netscape mail into a normal
spool format. Heh. Ergh...
---
unknown at riverstyx dot net
On Tue, 19 Jan 1999, System Administrator wrote:
> On Tue, 19 Jan 1999, John Malick wrote:
>
> > I am in the process of converting Netscape's mail server to qpopper for the pop
> > side and using Sendmail 8.9.1 for the SMTP mailer.
> >
>
> haha, oh my gawd, it's john! when you hear from patti (she's still in
> bermuda i think), tell her cyggie said hi!
>
> anyway..i have this same problem with qpopper every so often (even 3.0b).
> I'm not converting files or anything, but it still happens in user's mail
> files. When i get this error and look in the user's mailfile, the first
> line in the file will be a From line, but the F will be missing, like:
> rom Anthony J. Biacco <admin at intergrafix dot net>
>
> If i stick an F in there, save the file, bang! i can retrieve the mail
> again
>
> I dont know if this a problem with qpopper rewriting the mailfile or with
> sendmail writing to the user's mailfile (we use sendmail 8.8.8)
>
> ideas from the qualcomm people?
>
> -Tony
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> Anthony J. Biacco Network Administrator/Engineer
> admin at intergrafix dot net Intergrafix Internet Services
>
> "The best way to predict the future, is to invent it."
> http://cygnus.ncohafmuta.com http://www.intergrafix.net
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
>
> > Everything is working fine except for transition of Netscape's user mail to the
> > standard Unix single file mail.
> >
> > Netscape uses the format:
> >
> > /netmail/username/mail1
> > mail2
> > mail3
> > ...
> >
> > In other words, every piece of mail is a separate file. In Unix, Solaris
> > specifically, all email is simply in one file.
> >
> > The answer seemed obvious, append or cat all the files together into one large
> > file. The problem is a get the following error message when I try to pop to the
> > server:
> >
> > ERR Unable to process From lines (envelopes) change recognition modes ..
> >
> > If I manually edit my newly made file and manually add From lines before each
> > email entry it works. Obviously I do not want to do this to several gigabytes of
> > email.
> >
> > Has anyone run into this one before.
> >
> > Thanks and a summary will follow
> >
> >
> >
> > ************************************
> > *
> > John Malick - Systems Engineering *
> > Star Systems Engineering *
> > 140 Roosevelt Ave. *
> > York, PA. 17404 *
> > *
> > (717) 854-5911 Phone *
> > (717) 852-9421 Fax *
> > john at starinc dot com Email *
> > www.starinc.com Web Site *
> > *
> > ************************************
> >
>
>
Date: Tue, 19 Jan 1999 19:45:40 -0800
From: Matthew Fillmore <MFillmore at pensive dot org>
Subject: Re: ERR Unable to process From ...
At 2:27 PM -0500 1/19/99, John Malick wrote:
> In other words, every piece of mail is a separate file. In Unix, Solaris
> specifically, all email is simply in one file.
>
> The answer seemed obvious, append or cat all the files together
> into one large
> file. The problem is a get the following error message when I try
> to pop to the
> server:
>
> ERR Unable to process From lines (envelopes) change recognition modes ..
>
> If I manually edit my newly made file and manually add From lines before each
> email entry it works. Obviously I do not want to do this to several
> gigabytes of
> email.
You need the "From " lines. (On some systems you need Content-Length
headers instead, but on most Unix systems you need lines that start
with "From ", and usually contain timestamp and other information as
well.
You have several options. You could use your your favorite editor to
add "From " lines at the start of each file, then cat them all
together. You could whip up a quick script in C, Perl, your favorite
shell, whatever, to cat each file into a new spool file, adding a
"From " line. You could have the script invoke sendmail to ressend
the message, but you'd need to be careful it only got sent to the
spool owner, not any addresses in the headers. You could have a
trivial program read each file and send it via SMTP to the user.
--
Matthew Fillmore
MFillmore at Pensive dot Org
Date: Tue, 19 Jan 1999 19:48:17 -0800
From: Matthew Fillmore <MFillmore at pensive dot org>
Subject: Re: ERR Unable to process From ...
At 2:42 PM -0500 1/19/99, System Administrator wrote:
> anyway..i have this same problem with qpopper every so often (even 3.0b).
> I'm not converting files or anything, but it still happens in user's mail
> files. When i get this error and look in the user's mailfile, the first
> line in the file will be a From line, but the F will be missing, like:
> rom Anthony J. Biacco <admin at intergrafix dot net>
>
> If i stick an F in there, save the file, bang! i can retrieve the mail
> again
>
> I dont know if this a problem with qpopper rewriting the mailfile or with
> sendmail writing to the user's mailfile (we use sendmail 8.8.8)
3.0 fixed some locking problems, so if it is still happening it may
be something else. It is always the "F" that is missing? What
elements to the incidents have in common? For example, very large
spool files, lots of attachments, lots of activity at the same time,
etc.?
--
Matthew Fillmore
MFillmore at Pensive dot Org
From: unknown at riverstyx dot net
Date: Tue, 19 Jan 1999 22:30:41 -0800 (PST)
Subject: Re: ERR Unable to process From ...
Pretty damn near always the 'F'. I personally only see it on mail spools
containing about 300+ messages, but that could just be a probability thing
'coz those spools get accessed more than the smaller ones.
---
unknown at riverstyx dot net
On Tue, 19 Jan 1999, Matthew Fillmore wrote:
> At 2:42 PM -0500 1/19/99, System Administrator wrote:
>
> > anyway..i have this same problem with qpopper every so often (even 3.0b).
> > I'm not converting files or anything, but it still happens in user's mail
> > files. When i get this error and look in the user's mailfile, the first
> > line in the file will be a From line, but the F will be missing, like:
> > rom Anthony J. Biacco <admin at intergrafix dot net>
> >
> > If i stick an F in there, save the file, bang! i can retrieve the mail
> > again
> >
> > I dont know if this a problem with qpopper rewriting the mailfile or with
> > sendmail writing to the user's mailfile (we use sendmail 8.8.8)
>
> 3.0 fixed some locking problems, so if it is still happening it may
> be something else. It is always the "F" that is missing? What
> elements to the incidents have in common? For example, very large
> spool files, lots of attachments, lots of activity at the same time,
> etc.?
> --
> Matthew Fillmore
> MFillmore at Pensive dot Org
>
Date: Wed, 20 Jan 1999 10:52:14 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: ERR Unable to process From ...
On Tue, 19 Jan 1999, Matthew Fillmore wrote:
>
> 3.0 fixed some locking problems, so if it is still happening it may
> be something else. It is always the "F" that is missing? What
> elements to the incidents have in common? For example, very large
> spool files, lots of attachments, lots of activity at the same time,
> etc.?
it's always the F, always the first message. doesn't follow any other
pattern really. does it when it's busy, not busy, large spool files,
1-message spool files, attachment or non-attachment.
I've also had a problem with people's lock files sticking around.
Like, if they have a 3 meg spool file, start downloading it, then click to
cancel, it'll keep their lock file and the popper process open until i go
in and kill it. I'm running in server mode
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"The best way to predict the future, is to invent it."
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Wed, 20 Jan 1999 09:42:28 -0800
From: Matthew Fillmore <MFillmore at pensive dot org>
Subject: Re: ERR Unable to process From ...
At 10:52 AM -0500 1/20/99, System Administrator wrote:
> I've also had a problem with people's lock files sticking around.
> Like, if they have a 3 meg spool file, start downloading it, then click to
> cancel, it'll keep their lock file and the popper process open until i go
> in and kill it. I'm running in server mode
Is this 3.0b12?
Date: Wed, 20 Jan 1999 13:31:02 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: ERR Unable to process From ...
On Wed, 20 Jan 1999, Matthew Fillmore wrote:
> At 10:52 AM -0500 1/20/99, System Administrator wrote:
>
> > I've also had a problem with people's lock files sticking around.
> > Like, if they have a 3 meg spool file, start downloading it, then click to
> > cancel, it'll keep their lock file and the popper process open until i go
> > in and kill it. I'm running in server mode
>
> Is this 3.0b12?
>
yes
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"The best way to predict the future, is to invent it."
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Wed, 20 Jan 1999 15:27:10 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: ERR Unable to process From ...
At 1:31 PM -0500 1/20/99, System Administrator wrote:
>> > I've also had a problem with people's lock files sticking around.
>> > Like, if they have a 3 meg spool file, start downloading it, then click to
>> > cancel, it'll keep their lock file and the popper process open until i go
>> > in and kill it. I'm running in server mode
>>
>> Is this 3.0b12?
>>
> yes
How are the users accessing their mail? When they cancel, is the TCP
connection closed?
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Wed, 20 Jan 1999 15:52:21 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: getsubopt()
Can someone who is having problems because of getsubopt() try adding
"#include <unistd.h>" to file popper/pop_init.c and let me know,
please?
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Wed, 20 Jan 1999 18:40:51 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: ERR Unable to process From ...
On Wed, 20 Jan 1999, Randall Gellens wrote:
> At 1:31 PM -0500 1/20/99, System Administrator wrote:
>
> >> > I've also had a problem with people's lock files sticking around.
> >> > Like, if they have a 3 meg spool file, start downloading it, then click to
> >> > cancel, it'll keep their lock file and the popper process open until i go
> >> > in and kill it. I'm running in server mode
> >>
> >> Is this 3.0b12?
> >>
> > yes
>
> How are the users accessing their mail? When they cancel, is the TCP
> connection closed?
netscape (dont know if it's 3 or 4) and yes
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"The best way to predict the future, is to invent it."
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Wed, 20 Jan 1999 16:40:57 -0800 (PST)
From: <unknown at riverstyx dot net>
Subject: Re: getsubopt()
Hey, groovy. Works like a charm.
---
unknown at riverstyx dot net
On Wed, 20 Jan 1999, Randall Gellens wrote:
> Can someone who is having problems because of getsubopt() try adding
> "#include <unistd.h>" to file popper/pop_init.c and let me know,
> please?
> --
> Randall Gellens
> rg=public.1 at worldmail1.qualcomm dot com
> Opinions are personal; facts are suspect; I speak for myself only
>
Date: Wed, 20 Jan 1999 18:52:35 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: getsubopt()
At 4:40 PM -0800 1/20/99, <unknown at riverstyx dot net> wrote:
> Hey, groovy. Works like a charm.
Great -- thanks for confirming that. It'll be in the next beta.
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
From: Michael Dorin <dorin at puma.chaski dot com>
Subject: pop3 mail download timing out
Date: Sun, 24 Jan 1999 07:09:08 -0600 (CST)
I hope this is the write place to email qpopper questions like this.
I have a user who is using Netscape 3.0 for his mail client. He is having
problems downloading 'large' files which contain things like excell spreadsheets
or rtf documents.
It seems that either qpopper or netscape have a timeout and neither
ever tries to send again.
Any ideas?
I'm using the latest non-beta qpopper on freebsd.
-Mike
Date: Mon, 25 Jan 1999 10:25:26 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: getsubopt()
On Wed, 20 Jan 1999, Randall Gellens wrote:
> Can someone who is having problems because of getsubopt() try adding
> "#include <unistd.h>" to file popper/pop_init.c and let me know,
> please?
no effect on my linux (libc5)
should also note that on compile i get this warning:
gcc -c -I.. -I.. -I. -I../mmangle -g -O2 -fstrength-reduce
-fpcc-struct-return -DHAVE_CONFIG_H -DLINUX -DUNIX pop_send.c -o
pop_send.o
pop_send.c: In function `pop_send':
pop_send.c:257: warning: passing arg 1 of `header_mucker_init' from
incompatible pointer type
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Mon, 25 Jan 1999 11:28:24 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: old message
just a notice/wondering for 3.0..
in pop_dropcopy.c, is the line..
DEBUG_LOG1(p,"DROPINFO Checking for old .%s.pop file",p->user);
really accurate?
shouldn't it be something like..
DEBUG_LOG1(p,"DROPINFO Checking for old %s file",p->drop);
since the drop file is not really static if the user changes it in
config.h. It might be nice if you could set this through 'configure'
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
From: "Kislov_D" <kislov at tekom.odessa dot ua>
Subject:
Date: Mon, 25 Jan 1999 23:33:30 +0300
SEARCH QPopper timeout
From: "Kislov_D" <kislov at tekom.odessa dot ua>
Subject:
Date: Mon, 25 Jan 1999 23:18:42 +0300
SEARCH QPopper timeout
From: "Laydron" <laydron at gte dot net>
Date: Tue, 26 Jan 1999 22:15:25 -0600
Subject: Un
Hi,
I am getting the error "popauth: /etc/pop.auth: unable to open POP
authorization DB" when I run popauth. I'm not sure why I am getting this
error as /etc/pop.auth is there. The permisions for /etc/pop.auth are:
-rwx------ 1 pop pop 1536 Jan 21 22:37 pop.auth
It doesn't matter who I try to use popauth with, root, pop, or as another user
trying to add themselves to the DB. I always get the same error. Anyone
have a clue? I recompiled popauth, deleted pop.auth, and re-ran popauth -
init just to make sure that wasn't it. think maybe it is bad source?
System info: OS = RedHat 5.2
auth = PAM
CPU = Intel 486 4-100DX
ram = 24
freespace = 300+ meg
Thanks,
Laydron
Date: Wed, 27 Jan 1999 16:36:21 +0100
From: Patrice Bruhat <patrice.bruhat at pcotech dot fr>
Subject: Multiple emails in one message
I experienced a strange problem sometime.
In my mail client Netscape, I received several emails, but they are seen
by Netscape as a single one.
I use qpopper 2.53, sendmail 8.8 and Solaris 2.5
When I look at the mail file in the Netscape folder, the mixed emails
have a '>' at the beginning of the FROM line.
If I delete this bad character, Netscape separate well all the messages.
Where does this bad character come from ? Is it a qpopper problem or a
sendmail problem ?
Thanks for any help,
Patrice Bruhat
Date: Wed, 27 Jan 1999 11:06:00 -0500
From: Tim Mabbott <tmabbott at hbs dot edu>
Subject: Re: Multiple emails in one message
we have seen this EXACT problem after upgrading to qpopper 2.53 (we are
running sendmail 8.9.1 and solaris 2.5.1) I don't think it's a sendmail
problem, we are running Uwash ipop3d on a different system that has not
seen this problem (same OS + sendmail version).
It's hard to debug as the problem is very intermittant - ie: it doesn't
seem to happen very often - of course there may be many users that are
just not noticing that they have the problem.
One thing we noticed (may be a fluke) is all the concatonated messages
(ie; the one that was attached - and thus began with the ">" ) were from
listserv's ???
looking through sendmail logs, I can see the messages coming in
independantly - we haven't been able to see a mailbox before the error
is reported (and thus qpopper has hit it)...
we have rolled back to 2.52 but are getting REALLY bad performance from
it (a lot of time-out's reported), we are considering moving these
systems to ipop3d, but users will get duplicate messages (those with
"leave-on-server").
arg...
Tim Mabbott
Patrice Bruhat wrote:
>
> I experienced a strange problem sometime.
> In my mail client Netscape, I received several emails, but they are seen
> by Netscape as a single one.
>
> I use qpopper 2.53, sendmail 8.8 and Solaris 2.5
> When I look at the mail file in the Netscape folder, the mixed emails
> have a '>' at the beginning of the FROM line.
> If I delete this bad character, Netscape separate well all the messages.
>
> Where does this bad character come from ? Is it a qpopper problem or a
> sendmail problem ?
>
> Thanks for any help,
> Patrice Bruhat
From: "Laydron" <laydron at gte dot net>
Date: Wed, 27 Jan 1999 16:19:23 -0600
Subject: can't open popauth DB
Hi, sorry for the spam, but my last mesg subject looked like an
unsubscribe request. Which was an accident.
I am getting the error "popauth: /etc/pop.auth: unable to open POP
authorization DB" when I run popauth. I'm not sure why I am getting this
error as /etc/pop.auth is there. The permisions for /etc/pop.auth are:
-rwx------ 1 pop pop 1536 Jan 21 22:37 pop.auth
It doesn't matter who I try to use popauth with, root, pop, or as another user
trying to add themselves to the DB. I always get the same error. Anyone
have a clue? I recompiled popauth, deleted pop.auth, and re-ran popauth -
init just to make sure that wasn't it. think maybe it is bad source?
System info: OS = RedHat 5.2
auth = PAM
CPU = Intel 486 4-100DX
ram = 24
freespace = 300+ meg
Thanks,
Laydron
Date: Wed, 27 Jan 1999 17:59:07 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: can't open popauth DB
At 4:19 PM -0600 1/27/99, Laydron wrote:
> I am getting the error "popauth: /etc/pop.auth: unable to open POP
> authorization DB" when I run popauth.
There have been other reports of problems such as this with popauth
under linux. I am looking into them.
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Thu, 28 Jan 1999 09:35:49 -0600 (CST)
From: Michael Huettich - NetWorks/GroupZ Technical Support <michaelh at cjnetworks dot com>
Subject: problem with Netscape
Just implemented qpopper on a 10000 user system, Sun Sparcstation 20,
384MB RAM, Sendmail 8.8.5, Solaris 2.6, getting a very strange recurring
problem with Netscape mail users. They do nothing with their prefs, and
somehow the POP username gets capitalized. Any ideas on a fix? Also, when
the system load gets high, which it does frequently, qpopper tends to go
nuts and want to puke. Any tips on how to optimize qpopper for a
high-load, excessive number of users system that's underpowered?
Michael Huettich
Manager, Technical Support
NetWorks - GroupZ
616 SE Jefferson, Topeka, KS 66607
(785) 295-5648 Topeka KS (NetWorks)
(785) 887-8013 Lawrence KS (NetWorks)
(800) 469-1411 Dodge City KS, Pittsburg KS, Grand Island NE (NetWorks)
(800) 480-7050 Augusta GA, N. Augusta SC, Aiken SC (GroupZ)
Support hours (Central Time): 9:00am to 9:00pm - Monday through Saturday
11:00am to 8:00pm - Sunday
e-mail - support at cjnetworks dot com
support at groupz dot net
webster at cjnetworks dot com
michaelh at cjnetworks dot com
http://www2.cjnetworks.com
Date: Thu, 28 Jan 1999 11:55:28 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: problem with Netscape
At 9:35 AM -0600 1/28/99, Michael Huettich - NetWorks/GroupZ
Technical Support wrote:
> Just implemented qpopper on a 10000 user system, Sun Sparcstation 20,
> 384MB RAM, Sendmail 8.8.5, Solaris 2.6, getting a very strange recurring
> problem with Netscape mail users. They do nothing with their prefs, and
> somehow the POP username gets capitalized. Any ideas on a fix?
This only happens with Netscape users? Which version of Netscape?
> Also, when
> the system load gets high, which it does frequently, qpopper tends to go
> nuts and want to puke.
Could you be more specific, please? What errors occur, and what triggers them?
Also, what version of qpopper?
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Thu, 28 Jan 1999 11:58:24 -0800 (PST)
From: <unknown at riverstyx dot net>
Subject: Re: problem with Netscape
Have you tried server mode? And have you made sure that all the extended
logging features are disabled? I was only running with about 2500 users,
and the logs made my machine crawl... on the other hand, I only had a
P-??? w/96 megs of RAM :)
---
unknown at riverstyx dot net
On Thu, 28 Jan 1999, Michael Huettich - NetWorks/GroupZ Technical Support wrote:
> Just implemented qpopper on a 10000 user system, Sun Sparcstation 20,
> 384MB RAM, Sendmail 8.8.5, Solaris 2.6, getting a very strange recurring
> problem with Netscape mail users. They do nothing with their prefs, and
> somehow the POP username gets capitalized. Any ideas on a fix? Also, when
> the system load gets high, which it does frequently, qpopper tends to go
> nuts and want to puke. Any tips on how to optimize qpopper for a
> high-load, excessive number of users system that's underpowered?
>
> Michael Huettich
> Manager, Technical Support
> NetWorks - GroupZ
> 616 SE Jefferson, Topeka, KS 66607
>
> (785) 295-5648 Topeka KS (NetWorks)
> (785) 887-8013 Lawrence KS (NetWorks)
> (800) 469-1411 Dodge City KS, Pittsburg KS, Grand Island NE (NetWorks)
> (800) 480-7050 Augusta GA, N. Augusta SC, Aiken SC (GroupZ)
>
> Support hours (Central Time): 9:00am to 9:00pm - Monday through Saturday
> 11:00am to 8:00pm - Sunday
>
> e-mail - support at cjnetworks dot com
> support at groupz dot net
> webster at cjnetworks dot com
> michaelh at cjnetworks dot com
>
> http://www2.cjnetworks.com
>
>
Date: Thu, 28 Jan 1999 12:15:14 -0800
From: Leonard Hermens <Leonard.Hermens at itron dot com>
Subject: Re: Multiple emails in one message
Ours is Solaris 2.6
Sendmail 8.9.2
qpopper 2.52 or 2.53
(our trouble logs indicate that it happened on both versions, but I
am not sure of the accuracy)
Are there other people with this problem, too?
-- Leonard
At 11:06 AM -0500 1/27/99, Tim Mabbott wrote:
> we have seen this EXACT problem after upgrading to qpopper 2.53 (we are
> running sendmail 8.9.1 and solaris 2.5.1) I don't think it's a sendmail
> problem, we are running Uwash ipop3d on a different system that has not
> seen this problem (same OS + sendmail version).
>
> It's hard to debug as the problem is very intermittant - ie: it doesn't
> seem to happen very often - of course there may be many users that are
> just not noticing that they have the problem.
>
> One thing we noticed (may be a fluke) is all the concatonated messages
> (ie; the one that was attached - and thus began with the ">" ) were from
> listserv's ???
>
> looking through sendmail logs, I can see the messages coming in
> independantly - we haven't been able to see a mailbox before the error
> is reported (and thus qpopper has hit it)...
>
> we have rolled back to 2.52 but are getting REALLY bad performance from
> it (a lot of time-out's reported), we are considering moving these
> systems to ipop3d, but users will get duplicate messages (those with
> "leave-on-server").
>
> arg...
>
>
> Tim Mabbott
>
>
> Patrice Bruhat wrote:
>>
>> I experienced a strange problem sometime.
>> In my mail client Netscape, I received several emails, but they are seen
>> by Netscape as a single one.
>>
>> I use qpopper 2.53, sendmail 8.8 and Solaris 2.5
>> When I look at the mail file in the Netscape folder, the mixed emails
>> have a '>' at the beginning of the FROM line.
>> If I delete this bad character, Netscape separate well all the messages.
>>
>> Where does this bad character come from ? Is it a qpopper problem or a
>> sendmail problem ?
>>
>> Thanks for any help,
>> Patrice Bruhat
________________________________________________
Leonard A. Hermens, Principal Engineer
(509)-891-3277 FAX: (509)-891-3355
Itron, Inc., 2818 N. Sullivan Road, Spokane, Washington 99216
http://www.itron.com/ mailto:Leonard.Hermens at itron dot com
From: Earle Ake <earle.ake at hcst dot com>
Subject: Re: getsubopt()
Date: Thu, 28 Jan 1999 22:16:19 -0500 (EST)
> At 4:40 PM -0800 1/20/99, <unknown at riverstyx dot net> wrote:
>
> > Hey, groovy. Works like a charm.
>
> Great -- thanks for confirming that. It'll be in the next beta.
> --
> Randall Gellens
> rg=public.1 at worldmail1.qualcomm dot com
> Opinions are personal; facts are suspect; I speak for myself only
Not working after I included the #include <unistd.h> on Slackware
kernel 2.0.30. I also do not have the setproctitle() function. It is not
important but was going to add it in for testing.
-Earle
--
Earle Ake System Analyst Earle.Ake at HCST dot com
Hassler Communication Systems Technology, Inc. http://www.hcst.net
Date: Wed, 3 Feb 1999 20:06:18 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: lock busy
I briefly mentioned this before. running 3.0b on linux. Got a bunch of
these errors in the pop log since I've been running it (80 today so far)
Wed Feb 3 13:45:59 1999 [8038] jacob01 at max27.haz.intergrafix dot net: -ERR
[IN-USE] /usr/tmp/.pop/jacob01 lock busy! Is another session active?
(22)
i'm assuming 22 is the errno. if so, it's EINVAL (Invalid argument)
what could possibly be an invalid argument for these users?
some users have them sporadically. others may have 10 clumped together, 1
a minute.
any help is appreciated
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Fri, 05 Feb 1999 08:46:31 -0500
From: Ross Mistretta <rossm at imedgecom dot com>
Subject: BULLETINS
Has anyone gotten the bulletin feature to work... I'm running SCO and
continually get the following message in the syslog file...
Bulletin 1.test_messgage does not start with a valid "From " separator
I've tried >From and > From and keep getting the same message in my syslog.
Any ideas???
Any help would be greatly appreciated.
Imedge Communications
576 Valley Road
Suite 111
Wayne, NJ 07470
Phone: 973-290-5505
Fax: 973-490-3107
Pager: 800-759-8888 pin 1556628
e-mail: rossm at imedgecom dot com
Date: Fri, 5 Feb 1999 09:03:41 -0600
From: Tomasz Orzechowski <tmo at mail.hep.utexas dot edu>
Subject: Re: BULLETINS
> I've tried >From and > From and keep getting the same message in my syslog.
> Any ideas???
--- quote from $src/INSTALL @line 200
Contents in bulletin should be in same format as
messages in mail spool. For example :
-------------- start message -------------
From qpop Wed Nov 9 13:31:08 1994
Date: Wed, 9 Nov 1994 13:31:07 -0800 (PST)
--- end quote ---
HTH
T
From: antonio chavez <achavez at apollo.ccu.umich dot mx>
Subject: problem with HP-UX 10.20
Date: Fri, 05 Feb 1999 19:48:04 CST
Hi,
I has installed qpopper 2.3 with HP-UX 10.01, now I
installed qpopper 2.4 and HP-UX 10.20 but i'm getting the message
execv /usr/local/lib/popper: permission denied
in syslog
I double checked the permissions in the path and in
popper , everything looks OK..
The path for the mail files is OK /var/mail
What am i doing wrong ?
I also get an "conmection closed" message when i
telnet to the port 110 or pop3
Thanks
Antonio Chavez
Date: Fri, 5 Feb 1999 21:32:19 -0600
From: Tomasz Orzechowski <tmo at mail.hep.utexas dot edu>
Subject: Re: problem with HP-UX 10.20
> I has installed qpopper 2.3 with HP-UX 10.01, now I
> installed qpopper 2.4 and HP-UX 10.20 but i'm getting the message
a) install qpopper-2.53, older ones have a security problem;
b) show us the output of:
`ls -l /usr/local/lib/popper`
` grep popper /etc/inetd.conf`
> execv /usr/local/lib/popper: permission denied
Are you sure you have your popper in _lib_ not bin or sbin?
> I also get an "conmection closed" message when i
> telnet to the port 110 or pop3
This strongly suggests you got your filenames/paths wrong.
T
Date: Mon, 8 Feb 1999 10:33:21 -0200 (BDB)
From: Walcir Fontanini-ADM- <walcir at densis.fee.unicamp dot br>
Subject: APOP & CRAM on Netscape
Does anybody known which version of Netscape is capable of APOP and/or CRAM
feature ? And perhaps how to active this ?
__
| /| / __ / _ . _ /_ _ __ /_ __ __ . __ .
|/ |/_(_(_/_(_/_/ /__(_)_/ /_(__(_(_/ /_/_/ /_/
System Administrator
____________________________________________________________________
Walcir Fontanini http://www.densis.fee.unicamp.br/~walcir
Rua Albert Einstein, 400
UNICAMP/FEE/DENSIS Fax (55-019) 289-1395
CP 6101 Telex (19) 1150 UCPS
13083-970 - Campinas - SP e-mail: walcir at densis.fee.unicamp dot br
BRAZIL Voice (019) 788-3853
____________________________________________________________________
Date: Mon, 8 Feb 1999 18:40:00 -0200 (EDT)
From: Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Subject: Dual syslog messaging
Hi there !
We have a lot of pop accounts in our server and We are using Qpopper
2.53 with special-auth and server-mode. We just finished an installation
of another qpopper in an other machine and We have a surprise. Both of
qpoppers are writing in the logfiles the same user at the same time. For
our users We said to use the one popper, but the another popper which We
are testing are authenticating users too, but the user doesn't know about
your existence. Anybody knows what is happened ?
-------------------------------------------------------------------------
Rodrigo Luiz Anami rodrigoa at bestway.com dot br
Best Way Internet Provider Atendimento ao Cliente
http://www.bestway.com.br (019) 254.6263 (Campinas)
webmaster at bestway.com dot br 0800.112262 (Outras Localidades)
-------------------------------------------------------------------------
Date: Mon, 8 Feb 1999 15:50:40 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Qpopper 3.0b13 available
This version includes fixes for compilation problems involving
getsubopt() not found on some platforms, popauth failures on some
platforms, and the "possible probe of account" message is now logged
as WARNING instead of CRITICAL (stupid typo).
Also, there is now a UK mirror.
See <http://eudora.qualcomm.com/freeware/qpop.html>.
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Wed, 10 Feb 1999 15:42:44 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: getsubopt() again
I'd appreciate it if someone who is having problems related to
getsubopt() not defined when trying to make 3.0b13 could please add
"#define __USE_XOPEN_EXTENDED" to popper/pop_init.c and let me know
if this fixes it. Also what platform you are using.
Thanks!
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
From: Earle Ake <earle.ake at hcst dot com>
Subject: Re: getsubopt() again
Date: Wed, 10 Feb 1999 19:29:16 -0500 (EST)
According to Randall Gellens:
>
> I'd appreciate it if someone who is having problems related to
> getsubopt() not defined when trying to make 3.0b13 could please add
> "#define __USE_XOPEN_EXTENDED" to popper/pop_init.c and let me know
> if this fixes it. Also what platform you are using.
Using the Slackware release of Linux and I will need to check the
version. That did not work but it may be I am running an older version. I
did try to compile on Redhat before the fix and that did work.
-Earle
--
Earle Ake Senior Systems Analyst Earle.Ake at HCST dot com
Hassler Communication Systems Technology, Inc. http://www.hcst.net
Date: Thu, 11 Feb 1999 08:55:25 +0300 (MSK)
From: Albert Mamanov <albert at kosnet dot ru>
Subject: Re: getsubopt() again
On Wed, 10 Feb 1999, Randall Gellens wrote:
> I'd appreciate it if someone who is having problems related to
> getsubopt() not defined when trying to make 3.0b13 could please add
> "#define __USE_XOPEN_EXTENDED" to popper/pop_init.c and let me know
> if this fixes it. Also what platform you are using.
Not FIXED!
I'm using Linux debian 1.3.1 (kernel 2.0.36, libc 5)
I check all my libs.
AND i do not have getsubopt() in my libs.
I know that glibc 2 have getsubopt()
>
> Thanks!
> --
> Randall Gellens
> rg=public.1 at worldmail1.qualcomm dot com
> Opinions are personal; facts are suspect; I speak for myself only
>
Û ž×¡÷‰‘Š‰Õ
·Ãÿ¬‰³Œ Ì¡Õ¡‘¦×
Date: Fri, 12 Feb 1999 09:12:51 +0900
From: "T.Ueda" <ueda at power.elec.kitami-it.ac dot jp>
Subject: Qpopper3.0b13 on HPUX10.20
I am tring to compile Qpopper on HPUX10.20.
Qpopper2.53 had any problem.
But , Qpopper3.0b13 was not sccessful in "make" .
Someone has the same problem or resolve it?
~~~~~~~~~~~~~~~~~~~~~
>make
cd ./popper && make all
cc -c -I.. -I.. -I. -I../mmangle -g -DHAVE_CONFIG_H -DHPUX -DHPUX10
-DU
NIX flock.c -o flock.o
cc -c -I.. -I.. -I. -I../mmangle -g -DHAVE_CONFIG_H -DHPUX -DHPUX10
-DU
NIX pop_dele.c -o pop_dele.o
cc: "popper.h", line 276: error 1000: Unexpected symbol: "*".
cc: "popper.h", line 278: error 1000: Unexpected symbol: "FP".
cc: "popper.h", line 276: error 1506: Parameters allowed in function definition
only.
cc: "popper.h", line 278: error 1573: Type of "Stack" is undefined due to an
ill
egal declaration.
cc: "popper.h", line 278: error 1578: Size of struct or union member is
unknown.
*** Error exit code 1
Stop.
*** Error exit code 1
Stop.
~~~~~~~~~~~~~~~~~~~~~~
T.Ueda
Date: Fri, 12 Feb 1999 09:31:39 +0900
From: "T.Ueda" <ueda at power.elec.kitami-it.ac dot jp>
Subject: P.S. of "Qpopper3.0b13 on HPUX10.20"
P.S.
Qpopper2.53 had any problem. => Qpopper2.53 had no problem.
Date: Thu, 11 Feb 1999 17:44:51 -0800 (PST)
From: Systems Administration <dk at intercomm dot com>
Subject: QPOP 2.53 Bug??
I'm finding users with locked mailboxes frequently lately.
Investigation of the mail file reveals a fragment of a message
present, such as shown below. It seems that Popper must be the cause,
anyone see this or have some clue as to what is wrong???
It's a Solaris 2.51 box, and I'd guess this is a problem about once
every 400 (or more) accesses for all users. It rarely strikes the
same user twice.
---Cut-------------------------------------------------------
-----=_NextPart_000_01BE50E5.8C7D3020--
From tracy at intercomm dot com Fri Feb 5 09:55 PST 1999
Received: from intercomm.com (AS1-23.intercomm.com [209.160.44.23]) by sunspot.intercomm.com (8.8.5/8.7) with ESMTP id JAA13450; Fri, 5 Feb 1999 09:55:06 -0800 (PST)
Message-ID: <36BB2F33.F3205663 at intercomm dot com>
Date: Fri, 05 Feb 1999 09:49:39 -0800
....
Date: Fri, 12 Feb 1999 16:18:36 -0500
From: Roy Kidder <rkidder at ocom dot com>
Subject: Re: getsubopt() again
I'm running Slackware 3.6 (kernel version 2.0.35) on an x86 and it did not
work.
Roy
At 07:29 PM 2/10/99 -0500, Earle Ake wrote:
>According to Randall Gellens:
>>
>> I'd appreciate it if someone who is having problems related to
>> getsubopt() not defined when trying to make 3.0b13 could please add
>> "#define __USE_XOPEN_EXTENDED" to popper/pop_init.c and let me know
>> if this fixes it. Also what platform you are using.
>
> Using the Slackware release of Linux and I will need to check the
>version. That did not work but it may be I am running an older version. I
>did try to compile on Redhat before the fix and that did work.
>
>
>-Earle
>--
>Earle Ake Senior Systems Analyst Earle.Ake at HCST dot com
>Hassler Communication Systems Technology, Inc. http://www.hcst.net
Date: Fri, 12 Feb 1999 20:52:57 -0500 (EST)
From: rosenblg at nyu dot edu
Subject: interaction between sendmail's local delivery agent & qpopper
hi,
i'm new to the list, but not to qpopper; i'm currently running
version 2.53, and have an interesting problem. i have a few machines
running qpopper - both digital unix 4.0X and solaris 2.6. users who have
large ( ~ >5 Mb mailboxes) and who choose "leave mail on server" from their
pop3 clients - usually eudora - at times complain that they were told they
were sent mail, but swear they've never seen the messages. upon inspection
of the mailboxes, i see the new messages interspersed among the old ones,
ie,
give me a sense of when NL will be available so I caFrom user.name at nyu dot edu Wed Jan 27 10:31:37 1999
Received: from theuser (xxx.xxx.xxx.xxx [128.122.xxx.xxx])
by is2.nyu.edu (8.8.8/8.8.7) with SMTP id KAA20441
for <xxx at is2.nyu dot edu>; Wed, 27 Jan 1999 10:31:32 -0500 (EST)
Message-Id: <3.0.5.32.19990127101100.009ef100 at is2.nyu dot edu>
X-Sender: xxx at is2.nyu dot edu
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Wed, 27 Jan 1999 10:11:00 -0800
To: xxx at is2.nyu dot edu
From: xxx <xxx.xxx at nyu dot edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
[and then the rest of the mailbox; the user.name and xxx have replaced
the actual text]
digital unix's mail locking protocol is settable - i can use lockf,
a lockfile, or both. sun's local delivery agent, mail.local, says
it uses /var/mail/*.lock
from looking at qpopper's code, it looks as if it is using flock (the
config.h is set up to use HAVE_FLOCK 1). what i'm wondering is,
has anyone seen this problem? am i correct to believe that it's a locking
problem? what's the best solution for this?
many thanks,
gary
Gary J. Rosenblum
Unix Systems Manager / News Manager / Networking Group
New York University
gary at nyu dot edu
Date: Fri, 12 Feb 1999 19:57:47 -0800
From: Leonard Hermens <Leonard.Hermens at itron dot com>
Subject: Re: interaction between sendmail's local delivery agent & qpopper
When you say "interspersed" I assume that you mean concatenated?
I am getting this (abeit rarely) on Solaris 2.6 with qpopper 2.53
too. It has happened to other clients, not just Eudora.
As far as I can tell a character get deleted (or added) to the spool
or the Content-Length is simply off by one. We are running Sendmail,
if that factors in.
I have found at least one other person on Usenet with this problem,
but they were running Solaris 2.5.1.
-- Leonard
> hi,
>
> i'm new to the list, but not to qpopper; i'm currently running
> version 2.53, and have an interesting problem. i have a few machines
> running qpopper - both digital unix 4.0X and solaris 2.6. users who have
> large ( ~ >5 Mb mailboxes) and who choose "leave mail on server" from their
> pop3 clients - usually eudora - at times complain that they were told they
> were sent mail, but swear they've never seen the messages. upon inspection
> of the mailboxes, i see the new messages interspersed among the old ones,
> ie,
>
> give me a sense of when NL will be available so I caFrom
> user.name at nyu dot edu Wed Jan 27 10:31:37 1999
> Received: from theuser (xxx.xxx.xxx.xxx [128.122.xxx.xxx])
> by is2.nyu.edu (8.8.8/8.8.7) with SMTP id KAA20441
> for <xxx at is2.nyu dot edu>; Wed, 27 Jan 1999 10:31:32 -0500 (EST)
> Message-Id: <3.0.5.32.19990127101100.009ef100 at is2.nyu dot edu>
> X-Sender: xxx at is2.nyu dot edu
> X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
> Date: Wed, 27 Jan 1999 10:11:00 -0800
> To: xxx at is2.nyu dot edu
> From: xxx <xxx.xxx at nyu dot edu>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
>
> [and then the rest of the mailbox; the user.name and xxx have replaced
> the actual text]
>
>
> digital unix's mail locking protocol is settable - i can use lockf,
> a lockfile, or both. sun's local delivery agent, mail.local, says
> it uses /var/mail/*.lock
>
> from looking at qpopper's code, it looks as if it is using flock (the
> config.h is set up to use HAVE_FLOCK 1). what i'm wondering is,
> has anyone seen this problem? am i correct to believe that it's a locking
> problem? what's the best solution for this?
>
> many thanks,
>
> gary
>
> Gary J. Rosenblum
> Unix Systems Manager / News Manager / Networking Group
> New York University
> gary at nyu dot edu
Date: Fri, 12 Feb 1999 20:18:42 -0800 (PST)
From: Systems Administration <dk at intercomm dot com>
Subject: Re: interaction between sendmail's local delivery agent & qpopper
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: hermens at mailserver.itron dot com (Unverified)
Date: Fri, 12 Feb 1999 19:57:47 -0800
Errors-To: qpopper-errors at lists.pensive dot org (List Administrator)
Precedence: bulk
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-Archive: <mailto:autoshare at lists.pensive dot org?body=index%20qpopper>
List-Post: <mailto:qpopper at lists.pensive dot org>
List-Owner: listmaster at lists.pensive dot org (Pensive Mailing List Admin)
List-Help: http://www.pensive.org/Mailing_Lists/
List-ID: qpopper.lists.pensive.org
List-Software: AutoShare 3.0.4 by Mikael Hansen
From: Leonard Hermens <Leonard.Hermens at itron dot com>
Cc: rosenblg at nyu dot edu
When you say "interspersed" I assume that you mean concatenated?
It really appears to be a fragment of a preceeding message left, as if
a small buffer had not been properly discarded. I mentioned this on the
list last night with a different example. I'd guess the problem
appears when there is new incoming email while the pop server is
actively serving the old.
Date: Mon, 15 Feb 1999 00:14:52 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: STAT log message containing IP?
We hacked our old qpopper to stamp the IP of each user STATing, in order
to allow other software to detect it and open a short-lived smtp access
window for offsite email clients.
Has anyone else done this? I thought that the patch had been submitted
to Qualcomm a while back, but it's not in the 3.0 source.
The patch against 2.4 is pretty straightforward, and I can't see that it
needs to be any different for 3.0. It also patched into 2.53 easily when
I updated our qpopper to that version.
pop_stat.c ../qpopper2.4-mailclone/pop_stat.c
--- ../qpopper2.4.ORIGINAL//pop_stat.c Fri Sep 12 12:22:29 1997
+++ ../qpopper2.4-mailclone/pop_stat.c Mon May 18 18:30:30 1998
@@ -20,9 +20,11 @@
int pop_stat (p)
POP * p;
{
#ifdef DEBUG
if (p->debug) pop_log(p,POP_DEBUG,"%d message(s) (%d octets).",p->msg_count-p->msgs_deleted,p->drop_size-p->bytes_deleted);
#endif
+ pop_log(p,POP_PRIORITY,
+ "(v%s) STAT request from \"%s\" at (%s@%s) %s : %d message(s)",
+ VERSION,p->user,p->user,p->client,p->ipaddr,
+ p->msg_count-p->msgs_deleted);
+
return (pop_msg (p,POP_SUCCESS,
"%u %u",p->msg_count-p->msgs_deleted,p->drop_size-p->bytes_deleted));
}
Something else which may be worth considering is a module to allow
qpopper to talk to DRAC (http://mail.cc.umanitoba.ca/drac/), as that has
greater promise than just watching syslog output.
AB
Date: Sun, 14 Feb 1999 18:36:17 +0000
From: Mike Cantrell <linux at onethirtyeight dot org>
Subject: qpopper configuration help
OK, this is my first attempt at trying to get a pop3 server running. I'm
using Redhat Linux 5.2 with 2.21 kernel. I downloaded the 2.53 qpopper
version and the configure (used ./configure --enable-specialauth since
I'm using shadowed passwd's) an make to go smoothly.
I added the following to my /etc/inetd.conf
# Qpop pop3 daemon
pop3 stream tcp nowait root /usr/local/lib/popper popper -s
I also verified that the /etc/services was configured properly:
pop-3 110/tcp # PostOffice V.3
I then copied popper to /usr/local/lib/
-rwxrwxr-x 1 root root 162454 Feb 14 11:07 popper
Then I restarted inetd (I even rebooted) and when I use netscape as my
mail client to access my server as a pop3 to retrieve mail it tells me
that a POP3 error has occured and to contact the sysadmin.
I'm seeing this in my messages file:
Feb 14 11:07:41 cx611883-d /usr/local/lib/popper[2364]: Unable to obtain
socket and address of client, err = 88
I didn't find anything else while searching through the documentation
and the FAQ on the website. Can anyone shed light on what I'm missing or
some steps to use to troubleshoot the problem?
Much thanks,
Mike Cantrell
"A mind is a terrible thing to taste"
Date: Sun, 14 Feb 1999 19:26:11 +0000
From: Mike Cantrell <yomahz at cx611883-d.chnd1.az.home dot com>
Subject: Re: qpopper configuration help
Tomasz Orzechowski wrote:
>
> > # Qpop pop3 daemon
> > pop3 stream tcp nowait root /usr/local/lib/popper popper -s
>
> did you throw away the line from RH, about the same service?
>
Yes, actually pter Belt from the mail list just helped me with this
(about 10 mins ago). The problem was that I was using pop3 as the name
in the inetd and pop-3 in the services file (which was what was there by
default of course due to the pop-3 entry in the inetd.conf).
That did the trick. I should have paid a bit closer attention to detail
:)
> > Then I restarted inetd (I even rebooted) and when I use netscape as my
> > mail client to access my server as a pop3 to retrieve mail it tells me
> > that a POP3 error has occured and to contact the sysadmin.
>
> read the README ;) which tells you to do the following:
>
> $ telnet localhost 110
>
> and await a prompt like:
> $ telnet localhost 110
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> OK QPOP (version 2.54) at localhost starting.
I did this and it would just close the connection (No connection
refused). I read the README and it said to use the -d to debug . I
tailed my messages and didn't see anything but what I gave below. I
couldn't find much else on this subject (or at least I had another one
of those attention to detail problems :)
Thanks for all of your help though. I'm very happy to get this running.
>
> which would mean you got it all right; if you don't see that you have
> something wrong with TCP-Wrappers, inetd.conf or just the binary
>
> > I'm seeing this in my messages file:
> > Feb 14 11:07:41 cx611883-d /usr/local/lib/popper[2364]: Unable to obtain
> > socket and address of client, err = 88
>
> This happens when you start popper from the shell, like:
> $ /usr/local/sbin/poppper-2.54
>
> > I didn't find anything else while searching through the documentation
> > and the FAQ on the website. Can anyone shed light on what I'm missing or
> > some steps to use to troubleshoot the problem?
>
> Search better :) Do the telnet, if that doesn't work, it would mean you
> might need something like:
>
> popper : ALLOW : ALL
>
> in /etc/hosts.allow; although it may be many different things.
>
> Good luck,
>
> T
Date: Sun, 14 Feb 1999 13:03:58 -0600
From: Tomasz Orzechowski <tmo at mail.hep.utexas dot edu>
Subject: Re: qpopper configuration help
> # Qpop pop3 daemon
> pop3 stream tcp nowait root /usr/local/lib/popper popper -s
did you throw away the line from RH, about the same service?
> Then I restarted inetd (I even rebooted) and when I use netscape as my
> mail client to access my server as a pop3 to retrieve mail it tells me
> that a POP3 error has occured and to contact the sysadmin.
read the README ;) which tells you to do the following:
$ telnet localhost 110
and await a prompt like:
$ telnet localhost 110
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OK QPOP (version 2.54) at localhost starting.
which would mean you got it all right; if you don't see that you have
something wrong with TCP-Wrappers, inetd.conf or just the binary
> I'm seeing this in my messages file:
> Feb 14 11:07:41 cx611883-d /usr/local/lib/popper[2364]: Unable to obtain
> socket and address of client, err = 88
This happens when you start popper from the shell, like:
$ /usr/local/sbin/poppper-2.54
> I didn't find anything else while searching through the documentation
> and the FAQ on the website. Can anyone shed light on what I'm missing or
> some steps to use to troubleshoot the problem?
Search better :) Do the telnet, if that doesn't work, it would mean you
might need something like:
popper : ALLOW : ALL
in /etc/hosts.allow; although it may be many different things.
Good luck,
T
Date: Sun, 14 Feb 1999 16:05:52 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: qpopper configuration help
first try authenticating through telnet.
like: telnet 0 110
then when it connects, type: USER <your username>
then: PASS <your password>
no <>'s..and see what it says..maybe you dont have an IP set on your box??
-Cygnus
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
On Sun, 14 Feb 1999, Mike Cantrell wrote:
> OK, this is my first attempt at trying to get a pop3 server running. I'm
> using Redhat Linux 5.2 with 2.21 kernel. I downloaded the 2.53 qpopper
> version and the configure (used ./configure --enable-specialauth since
> I'm using shadowed passwd's) an make to go smoothly.
>
> I added the following to my /etc/inetd.conf
>
> # Qpop pop3 daemon
> pop3 stream tcp nowait root /usr/local/lib/popper popper -s
>
> I also verified that the /etc/services was configured properly:
>
> pop-3 110/tcp # PostOffice V.3
>
> I then copied popper to /usr/local/lib/
>
> -rwxrwxr-x 1 root root 162454 Feb 14 11:07 popper
>
> Then I restarted inetd (I even rebooted) and when I use netscape as my
> mail client to access my server as a pop3 to retrieve mail it tells me
> that a POP3 error has occured and to contact the sysadmin.
>
> I'm seeing this in my messages file:
>
> Feb 14 11:07:41 cx611883-d /usr/local/lib/popper[2364]: Unable to obtain
> socket and address of client, err = 88
>
>
> I didn't find anything else while searching through the documentation
> and the FAQ on the website. Can anyone shed light on what I'm missing or
> some steps to use to troubleshoot the problem?
>
> Much thanks,
>
> Mike Cantrell
>
> "A mind is a terrible thing to taste"
>
From: "Andy Brown" <andy at tc3net dot net>
Subject: Extended logging with Qpopper
Date: Sun, 14 Feb 1999 22:54:15 -0000
Hi,
Ive only just subscribed to this list, so Im not sure of the etiquette with
regarding asking questions... so here goes.
I compiled 2.53 yesterday with the DEBUG and HOMEDIRMAIL options.
everything works fine, but with this new build I have been asked to provide
my bosses with statistics and logging for pop connections.
This should include hostname or ip of incomming connection, username, errors
when usernames/password are incorrect and general stats (that are created by
default with the -s switch.)
I looked at the debugging option, but this generates too much information.
Does anyone have any suggestions, or does anyone else require these sort of
stats/logging, and how do you go about generating it.
Thanks for reading... any help much apprecited!
Regards
Andy Brown
Operations Manager
Trinome Networks
Date: Mon, 15 Feb 1999 10:03:15 +0800
From: Byron Jones <byron at vianet.net dot au>
Subject: problems with qpopper
greetings,
i'm running qpopper 2.53 under redhat 5.2
it works fine, for a handful of minutes ...
---
[root@freddie rpms]# telnet pop pop
Trying 203.13.35.4...
Connected to freddie.vianet.net.au.
Escape character is '^]'.
+OK QPOP (version 2.53) at freddie.vianet.net.au starting.
<26157.919044524 at freddie.vianet.net dot au>
user test
+OK Password required for test.
pass wrong
-ERR Password supplied for "test" is incorrect.
+OK Pop server at freddie.vianet.net.au signing off.
Connection closed by foreign host.
---
but then qpopper stops accepting connections about anywhere between 30
seconds or 5 minutes :
---
[root@freddie rpms]# telnet pop pop
Trying 203.13.35.4...
telnet: Unable to connect to remote host: Connection refused
---
here's my inetd.conf line :
---
pop-3 stream tcp nowait root /usr/sbin/tcpd in.qpopper
---
qpopper was installed using the rpm, and we're running the pam version.. ie
"qpopper-2.53-1-PAM.i386.rpm".
i'm pretty well at a loss as to why this is happening. please help :)
- Byron Jones -
- Systems Administrator -
- Vianet Australia -
- http://www.vianet.net.au/~byron -
Date: Mon, 15 Feb 1999 16:17:06 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: problems with qpopper
On Mon, 15 Feb 1999, Byron Jones wrote:
> [root@freddie rpms]# telnet pop pop
> Trying 203.13.35.4...
> telnet: Unable to connect to remote host: Connection refused
> here's my inetd.conf line :
>
> ---
> pop-3 stream tcp nowait root /usr/sbin/tcpd in.qpopper
> ---
It's not a qpopper fault, it's inetd.
Inetd's default is to shut down a service called 40 times or more in 60
seconds on the basis that it's looping.
To change that number, change "nowait" to "nowait.XX".
My pop servers sit at nowait.400
AB
Date: Mon, 15 Feb 1999 11:37:17 +0800
From: Byron Jones <byron at vianet.net dot au>
Subject: Re: problems with qpopper
>> [root@freddie rpms]# telnet pop pop
>> Trying 203.13.35.4...
>> telnet: Unable to connect to remote host: Connection refused
>
>> here's my inetd.conf line :
>>
>> ---
>> pop-3 stream tcp nowait root /usr/sbin/tcpd in.qpopper
>> ---
>
>It's not a qpopper fault, it's inetd.
>
>Inetd's default is to shut down a service called 40 times or more in 60
>seconds on the basis that it's looping.
>
>To change that number, change "nowait" to "nowait.XX".
>
>My pop servers sit at nowait.400
excellent - this appears to have fixed the problem :)
large thanks
- Byron Jones -
- Systems Administrator -
- Vianet Australia -
- http://www.vianet.net.au/~byron -
Date: Sun, 14 Feb 1999 22:25:09 -0800
From: Matthew Fillmore <MFillmore at pensive dot org>
Subject: Re: STAT log message containing IP?
At 12:14 AM +1300 2/15/99, Alan Brown wrote:
> We hacked our old qpopper to stamp the IP of each user STATing, in order
> to allow other software to detect it and open a short-lived smtp access
> window for offsite email clients.
This does sound useful, but long-term I think SMTP AUTH is the way to go.
Date: Mon, 15 Feb 1999 19:44:50 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: STAT log message containing IP?
On Sun, 14 Feb 1999, Matthew Fillmore wrote:
> > We hacked our old qpopper to stamp the IP of each user STATing, in order
> > to allow other software to detect it and open a short-lived smtp access
> > window for offsite email clients.
>
> This does sound useful, but long-term I think SMTP AUTH is the way to go.
Long-term, yes.
However authenticated SMTP is quite a way off yet, and we have to be
able to provide smtp access to roaming users without them having to
reconfigure their clients all the time for the local mailserver.
Leaving SMTP servers open to relay for anyone who uses a local domain
name is a surefire way to end up in various relay blacklists. It's a
common spammer trick to forge domains local to the server they're
relaying through. Sendmail's documentation now warns specifically
against doing it (relay_local_from) for this reason.
AB
Date: Mon, 15 Feb 1999 08:59:49 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: problems with qpopper
On Mon, 15 Feb 1999, Alan Brown wrote:
> On Mon, 15 Feb 1999, Byron Jones wrote:
>
> > [root@freddie rpms]# telnet pop pop
> > Trying 203.13.35.4...
> > telnet: Unable to connect to remote host: Connection refused
>
> > here's my inetd.conf line :
> >
> > ---
> > pop-3 stream tcp nowait root /usr/sbin/tcpd in.qpopper
> > ---
>
> It's not a qpopper fault, it's inetd.
>
> Inetd's default is to shut down a service called 40 times or more in 60
> seconds on the basis that it's looping.
>
> To change that number, change "nowait" to "nowait.XX".
>
> My pop servers sit at nowait.400
>
woah, so that's why mine keeps looping at peak times!!
I have seen the light!
maybe this little snippet should be put in the README
-Cygnus
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Tue, 16 Feb 1999 19:09:16 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: problems with qpopper
At 6:28 PM -0800 2/16/99, System Administrator wrote:
> maybe this little snippet should be put in the README
I've updated the INSTALL and FAQ for b14. I was looking into reports
of this looping, to see if there was a bug in Qpopper. I haven't
found one yet in this area.
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Tue, 16 Feb 1999 19:20:33 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: getsubopt() again
At 6:27 PM -0800 2/16/99, Roy Kidder wrote:
> I'm running Slackware 3.6 (kernel version 2.0.35) on an x86 and it did not
> work.
I've verified that 3.0b14 fixes the getsubopt() problem for good,
even on Slackware.
This is now available on the FTP site
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper3.0b14.tar.Z
>.
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Wed, 17 Feb 1999 19:00:04 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: problems with qpopper
On Tue, 16 Feb 1999, Randall Gellens wrote:
> I've updated the INSTALL and FAQ for b14. I was looking into reports
> of this looping, to see if there was a bug in Qpopper. I haven't
> found one yet in this area.
Adjusting the service shutdown threshold should be approached with
caution - having a heavily loaded server starting up lots of qpoppers
from inetd can easily lead to a denial of service attack scenario if
nowait.xxx is set too high for the machine's capabilities.
It gets into a nasty positive feedback state when frustrated users start
pounding on "check mail" because of slowness, leaving a bunch of
half-open connections, etc.
It would probably be a "really good idea" to look into having a master
qpopper started from inetd, which then spawns off child processes for
new connects - as can be done with processes like tacacsd/radiusd.
Given an appropriate idle period, the master server can shut itself
down. In general it's lower load in both cpu and process memory to fork
off child processes than to keep starting a service from inetd - inetd's
not really designed to be hammered on.
Btw, the same looping problem is often seen on identd, especially on
busy servers with lots of outgoing smtp traffic. If you're running
pidentd (the most commonly used one), the best solution is to start it
this way:
auth stream tcp wait root /usr/sbin/in.identd in.identd -w -t120 -l
That's in the pidentd man pages, but not in its INSTALL file. It can
significantly reduce loads when things get hectic.
AB
Date: Wed, 17 Feb 1999 13:16:19 -0500
From: "Tabor J. Wells" <twells at shore dot net>
Subject: NFS with qpopper?
Ok, I know that #5 in the INSTALL file states that qpopper shouldn't be
used over NFS in 2.53. Is that still going to be case with the 3.0 series?
Also I've seen it mentioned that people do use qpopper over NFS (at least
in the Dejanews search I did yesterday I saw a few references). How
successful/dangerous is this?
We're in the process of moving local accounts to a pair of failover NFS'd
systems served off of a fibre channel array and I need to find a way to
handle POP3 support with mail which is delivered to $HOME/.mail. We tried
the switch from qpopper to cucipop once upon a time, but our userbase
nearly lynched us due to weird problems with some mail clients downloading
the mail repeatedly, etc. I'd love to stay with qpopper if it isn't going
to be mutually exclusive with the architecture outlined above.
Thanks in advance for any info you can provide,
Tabor
Shore.Net
--
___________________________________________________________________________
Tabor J. Wells twells at shore dot net
Systems Administration Manager Just another victim of the ambient morality
Shore.Net -- High quality Internet access and hosting services since 1993
Date: Wed, 17 Feb 1999 14:18:15 -0500
From: Roy Kidder <rkidder at ocom dot com>
Subject: Re: getsubopt() again
I obtained the 3.0b14 and compiled it. The getsubopt() problem went away,
but now I'm seeing a new problem.
I sent myself an email message and verified it's arrival on my Linux box. I
then went to my Microsoft box and fired up Eudora. The POP3 conversation
(according to the packets I sniffed off the network) went something like this:
S: OK QPOP (version 3.0b14) at gandalf.network starting.
<21741.919277421 at gandalf dot network>
C: APOP rkidder [encrypted password]
S: +OK rkidder has 1 message(s) (339 octets).
Both boxes do some dancing around with changing port numbers for this
session before the
MS box changes back to 110 and sends the STAT command.
At some point during this exchange, Eudora complains of the following
error: "Closing
the connection, [02:14:27 PM] Error writing to network. Cause: connection
aborted due
to timeout or other failure (10053)"
The log output generated by popper looks something like this:
Wed Feb 17 14:15:09 1999 [25703] apop "rkidder"
Wed Feb 17 14:15:09 1999
Wed Feb 17 14:15:09 1999 [25703] Found top of first message
Wed Feb 17 14:15:09 1999
The email message was never transferred to the client.
At 07:20 PM 2/16/99 -0800, Randall Gellens wrote:
>At 6:27 PM -0800 2/16/99, Roy Kidder wrote:
>
>> I'm running Slackware 3.6 (kernel version 2.0.35) on an x86 and it did not
>> work.
>
>I've verified that 3.0b14 fixes the getsubopt() problem for good,
>even on Slackware.
>
>This is now available on the FTP site
><ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper3.0b14.tar.Z >>.
>--
>Randall Gellens
>rg=public.1 at worldmail1.qualcomm dot com
>Opinions are personal; facts are suspect; I speak for myself only
Date: Wed, 17 Feb 1999 15:11:24 -0500 (EST)
From: Brad Groshok <brad at mur3.odyssey.on dot ca>
Subject: Popper exec size seems too large
Hi all:
New to this list, so please excuse if this has been addressed b4
I've had a peek at a mailing list archive and did not see any mention.
I've just built popper 3.0B14 on a UltrasparcII with Solaris 2.7
using gcc Version 2.8.1 and GHU make 3.76.1
Previous versions of popper were had a filesize of something in the
125K range. The one I have just built is in the 775k range.
Should this be? any suggestions as to what I might have done wrong?
Pretty basic build, no options. Just ran configure and make
then copied the popper file from the /popper dir to /usr/lib
====================================================================
Regards: Brad Groshok (brad.groshok at odyssey.on dot ca)
President Odyssey Network Inc
London Ontario Canada Phone: (519) 660-8883
http://www.odyssey.on.ca Fax: (519) 660-6111
====================================================================
Date: Wed, 17 Feb 1999 16:02:32 -0400
From: Ben Duncan - iSecure Networks <ben at isecure dot net>
Subject: Re: Popper exec size seems too large
Greetings.
> New to this list, so please excuse if this has been addressed b4
> I've had a peek at a mailing list archive and did not see any mention.
>
> I've just built popper 3.0B14 on a UltrasparcII with Solaris 2.7
> using gcc Version 2.8.1 and GHU make 3.76.1
>
> Previous versions of popper were had a filesize of something in the
> 125K range. The one I have just built is in the 775k range.
Try running "strip"
admin:/usr/home/admin# ls -l /vkernel/popper
-rwxr-xr-x 1 root wheel 280380 Feb 3 15:41 /vkernel/popper
admin:/usr/home/admin# strip /vkernel/popper
admin:/usr/home/admin# ls -l /vkernel/popper
-rwxr-xr-x 1 root wheel 36864 Feb 17 16:17 /vkernel/popper
--
------------------------------------------------------------
Ben Duncan ben at isecure dot net
iSecure Networks http://isecure.net/ben
------------------------------------------------------------
Date: Wed, 17 Feb 1999 21:55:49 +0100
From: Erik Andersen <erikande at danbbs dot dk>
Subject: Re: getsubopt() again
Im using Qpop 3.0b14, my netscape 3.04 clients statusbar when
receiving emails doesn't show? its empty, so i cannot see the
process bar, any ideas?
Qpop3.0b14 works perfectly on my Linux 2.0.35 system, even
the getsub works now :-)
Rgds, Erik
Date: Wed, 17 Feb 1999 12:54:31 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: getsubopt() again
This doesn't sound like a Qpopper problem. By the way, the port
numbers in use should not change during a session.
Has it happened more than once?
At 12:45 PM -0800 2/17/99, Roy Kidder wrote:
> I obtained the 3.0b14 and compiled it. The getsubopt() problem went away,
> but now I'm seeing a new problem.
>
> I sent myself an email message and verified it's arrival on my Linux box. I
> then went to my Microsoft box and fired up Eudora. The POP3 conversation
> (according to the packets I sniffed off the network) went something
> like this:
>
> S: OK QPOP (version 3.0b14) at gandalf.network starting.
> <21741.919277421 at gandalf dot network>
> C: APOP rkidder [encrypted password]
> S: +OK rkidder has 1 message(s) (339 octets).
>
> Both boxes do some dancing around with changing port numbers for this
> session before the
> MS box changes back to 110 and sends the STAT command.
>
> At some point during this exchange, Eudora complains of the following
> error: "Closing
> the connection, [02:14:27 PM] Error writing to network. Cause: connection
> aborted due
> to timeout or other failure (10053)"
>
> The log output generated by popper looks something like this:
> Wed Feb 17 14:15:09 1999 [25703] apop "rkidder"
> Wed Feb 17 14:15:09 1999
> Wed Feb 17 14:15:09 1999 [25703] Found top of first message
> Wed Feb 17 14:15:09 1999
>
>
> The email message was never transferred to the client.
>
>
>
> At 07:20 PM 2/16/99 -0800, Randall Gellens wrote:
>>At 6:27 PM -0800 2/16/99, Roy Kidder wrote:
>>
>>> I'm running Slackware 3.6 (kernel version 2.0.35) on an x86 and it did not
>>> work.
>>
>>I've verified that 3.0b14 fixes the getsubopt() problem for good,
>>even on Slackware.
>>
>>This is now available on the FTP site
>><ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper3.0b14.tar.Z >>.
>>--
>>Randall Gellens
>>rg=public.1 at worldmail1.qualcomm dot com
>>Opinions are personal; facts are suspect; I speak for myself only
>
> Return-Path: <kmahesh at qualcomm dot com>
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Wed, 17 Feb 1999 17:38:09 -0500
From: Roy Kidder <rkidder at ocom dot com>
Subject: Re: getsubopt() again
It happens every time. And every time it follows the same pattern. My
Eudora client thinks there was some sort of failure and the Linux server
doesn't report a problem.
You're right about the port numbers. The client was binding to a different
random port number, but the server was on 110.
I did a "rm popper/popauth.o; make realclean; ./configure --
enable-apop=/etc/pop.auth --with-popuid=pop --enable-debugging; make" so=
I
might take advantage of any debugging info I might be able to generate.
Below is the log. It is interesting to note that all I did was add the
--enable-debugging and my authentication failed.
It's also interesting to note that I have to manually remove the
popper/popauth.o file. A "make clean" or "make realclean" doesn't do that.
I assume that's simply an oversight when the Makefile is created.
Wed Feb 17 17:18:39 1999 [1065] Trace and Debug destination is file
"/logs/syslog/popper.log"
Wed Feb 17 17:18:39 1999 [1065] (v3.0b14) Servicing request from
"rkidder.network" at 10.224.1.252
Wed Feb 17 17:18:39 1999 [1065] +OK QPOP (version 3.0b14) at
gandalf.network starting. <1065.919289919 at gandalf dot network>
Wed Feb 17 17:18:39 1999 [1065] Received: "APOP rkidder [snip]"
Wed Feb 17 17:18:39 1999 [1065] apop "rkidder"
Wed Feb 17 17:18:39 1999 [1065] AUTH KEYS : ¦z"Ì to [snip]
Wed Feb 17 17:18:39 1999 [1065] rkidder at rkidder dot network: -ERR
authentication failure
Wed Feb 17 17:18:39 1999 [1065] Received: "QUIT"
Wed Feb 17 17:18:39 1999 [1065] rkidder at rkidder dot network: -ERR Unknown
command: "quit".
Wed Feb 17 17:18:39 1999 [1065] rkidder at rkidder dot network: -ERR POP EOF=
received
Wed Feb 17 17:18:39 1999 [1065] Performing maildrop update...
Wed Feb 17 17:18:39 1999 [1065] Checking to see if all messages were deleted=
Wed Feb 17 17:18:39 1999 [1065] Stats: rkidder 0 0 0 0 rkidder.network
10.224.1.252
Wed Feb 17 17:18:39 1999 [1065] +OK Pop server at gandalf.network signing=
off.
Wed Feb 17 17:18:39 1999 [1065] (v3.0b14) Ending request from "rkidder" at
(rkidder.network) 10.224.1.252
At 12:54 PM 2/17/99 -0800, you wrote:
>This doesn't sound like a Qpopper problem. By the way, the port
>numbers in use should not change during a session.
>
>Has it happened more than once?
>
>At 12:45 PM -0800 2/17/99, Roy Kidder wrote:
>
>> I obtained the 3.0b14 and compiled it. The getsubopt() problem went away,
>> but now I'm seeing a new problem.
>>
>> I sent myself an email message and verified it's arrival on my Linux box.=
I
>> then went to my Microsoft box and fired up Eudora. The POP3 conversation
>> (according to the packets I sniffed off the network) went something
>> like this:
>>
>> S: OK QPOP (version 3.0b14) at gandalf.network starting.
>> <21741.919277421 at gandalf dot network>
>> C: APOP rkidder [encrypted password]
>> S: +OK rkidder has 1 message(s) (339 octets).
>>
>> Both boxes do some dancing around with changing port numbers for this
>> session before the
>> MS box changes back to 110 and sends the STAT command.
>>
>> At some point during this exchange, Eudora complains of the following
>> error: "Closing
>> the connection, [02:14:27 PM] Error writing to network. Cause: connection
>> aborted due
>> to timeout or other failure (10053)"
>>
>> The log output generated by popper looks something like this:
>> Wed Feb 17 14:15:09 1999 [25703] apop "rkidder"
>> Wed Feb 17 14:15:09 1999
>> Wed Feb 17 14:15:09 1999 [25703] Found top of first message
>> Wed Feb 17 14:15:09 1999
>>
>>
>> The email message was never transferred to the client.
>>
>>
>>
>> At 07:20 PM 2/16/99 -0800, Randall Gellens wrote:
>>>At 6:27 PM -0800 2/16/99, Roy Kidder wrote:
>>>
>>>> I'm running Slackware 3.6 (kernel version 2.0.35) on an x86 and it did=
not
>>>> work.
>>>
>>>I've verified that 3.0b14 fixes the getsubopt() problem for good,
>>>even on Slackware.
>>>
>>>This is now available on the FTP site
>>><ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper3.0b14.tar.Z=
>>.
>>>--
>>>Randall Gellens
>>>rg=public.1 at worldmail1.qualcomm dot com
>>>Opinions are personal; facts are suspect; I speak for myself only
>>
>> Return-Path: <kmahesh at qualcomm dot com>
>
>--
>Randall Gellens
>rg=public.1 at worldmail1.qualcomm dot com
>Opinions are personal; facts are suspect; I speak for myself only
From: "Daryl" <daryl at ledanet.com dot au>
Subject:
Date: Thu, 18 Feb 1999 11:05:35 +1000
This is a multi-part message in MIME format.
------=_NextPart_000_000E_01BE5B2E.9C311C40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
------=_NextPart_000_000E_01BE5B2E.9C311C40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=text/html;charset=iso-8859-1 =
http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_000E_01BE5B2E.9C311C40--
Date: Thu, 18 Feb 1999 10:42:12 -0500 (EST)
From: "William F. Dudley" <dud at squid.monmouth dot com>
Subject: SERVER_MODE
Hi,
We've got about 12000 email accounts on a single machine running BSDI,
and the disk i/o due to qpopper copying the mail spool back and forth
is starting to choke the machine.
We're not running qpopper in SERVER_MODE currently, but are using the
HASH_SPOOL=2 feature that assumes user's email is in /var/mail/u/s/user.
Can anyone explain exactly the issues of running qpopper in SERVER_MODE
while also running elm,pine,mail,Mail as mail reader programs plus
mail.local (the BSDI mail delivery agent) ? I find the qpopper
documentation weak on this point.
Bill Dudley
Monmouth Internet
New Jersey, USA
From: =?iso-8859-1?Q?Søren_Peter_Skou?= <SPS at mobilix dot dk>
Subject: Canonical Name Error
Date: Thu, 18 Feb 1999 17:04:30 +0100
Hi all
Where I work, we're using Qpopper, nice product, but at some point, the logs
started to get flooded with errors like :
(v2.53) Unable to get canonical name of client, err = 0
or the other one
(v2.53) Unable to get canonical name of client, err = 60
Not very informative in my opinion, yes, you see that the error is either 60
or 0 (whatever that means), and that it's related to DNS. Strolling through
the code I notice this in pop_init.c, and yes, it's the reverse lookup that
fails. Now, I've included a patch that shows what IP the culprit is coming
from, but it's also available from http://www.mud.dk/~sps/qpopper for
versions 2.53, 3.0B13 and 3.0B14. The patch has also been sent to
qpopper at eudora dot com
---- *SNIP* ---- *SNIP* ---- *SNIP* ---- *SNIP* ---- *SNIP* ---- *SNIP* ----
*SNIP* ---- *SNIP* ---- *SNIP* ---- *SNIP* ----
--- pop_init.c.org Thu Feb 18 16:25:25 1999
+++ pop_init.c Thu Feb 18 16:25:57 1999
@@ -281,8 +281,8 @@
ch = gethostbyaddr((char *) &cs.sin_addr, sizeof(cs.sin_addr),
AF_INET);
if (ch == NULL){
pop_log(p,POP_PRIORITY,
- "(v%s) Unable to get canonical name of client, err = %d",
- VERSION, errno);
+ "(v%s) From IP# {%s}: Unable to get canonical name of client,
err = %d",
+ VERSION, p->ipaddr, errno);
p->client = p->ipaddr;
}
/* Save the cannonical name of the client host in
---- *SNIP* ---- *SNIP* ---- *SNIP* ---- *SNIP* ---- *SNIP* ---- *SNIP* ----
*SNIP* ---- *SNIP* ---- *SNIP* ---- *SNIP* ----
Please note this patch is for V2.53.
Friendly Greetings
S. P. Skou
Date: Fri, 19 Feb 1999 06:01:46 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: Canonical Name Error
On Thu, 18 Feb 1999, [iso-8859-1] S¯ren Peter Skou wrote:
> (v2.53) Unable to get canonical name of client, err = 0
> (v2.53) Unable to get canonical name of client, err = 60
>
> Not very informative in my opinion, yes, you see that the error is either 60
> or 0 (whatever that means), and that it's related to DNS.
One will be a temporary DNS lookup failure, the other permanent. :-)
AB
Date: Thu, 18 Feb 1999 13:35:44 -0500 (EST)
From: John Vozza <john at netrom dot com>
Subject: Time Out - Help needed
I am running qpopper 2.5.3 and the timeout does not seem to work. For
example at Thu Feb 18 13:02:19 EST 1999 the following process was
running...
bintou41 11127 0.0 0.4 940 624 1 S 12:33 0:00
/usr/sbin/popper.2.5.3 -s -T 45 -b /var/spool/mail/popbulletins
As you can see from the following login record the customer had already
been logged out for 20 minutes!
bintou41 000:pm1.WM 204.141.216.150 Thu Feb 18 12:33 - 12:42 (00:08)
Am I correct in assuming from the docs that -T 45 is supposed to timeout
after 45 seconds or is it minutes?
Is this a known bug or am I doing something wrong? Willing to try 3.0betas
if this issue may already be fixed in the beta series.
John
-------------------------------------------------------------------------
NetRom Internet Services 973-208-1339 voice
john at netrom dot com 973-208-0942 fax
http://www.netrom.com
-------------------------------------------------------------------------
Date: Fri, 19 Feb 1999 07:47:28 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: Time Out - Help needed
On Thu, 18 Feb 1999, John Vozza wrote:
> Am I correct in assuming from the docs that -T 45 is supposed to timeout
> after 45 seconds or is it minutes?
45 seconds, but get rid of the space (-T45)
45 seconds is way too short, even for LAN use. For general ISP dialup,
you need to stick to the RFC-defined 600 seconds.
AB
Date: Thu, 18 Feb 1999 14:45:52 -0500 (EST)
From: John Vozza <john at netrom dot com>
Subject: Re: Time Out - Help needed
But why is the session I described still running after 20 minutes?
What is the default timeout in qpopper since it appears I had the -T
wrong?
John
-------------------------------------------------------------------------
NetRom Internet Services 973-208-1339 voice
john at netrom dot com 973-208-0942 fax
http://www.netrom.com
-------------------------------------------------------------------------
On Fri, 19 Feb 1999, Alan Brown wrote:
> On Thu, 18 Feb 1999, John Vozza wrote:
>
> > Am I correct in assuming from the docs that -T 45 is supposed to timeout
> > after 45 seconds or is it minutes?
>
> 45 seconds, but get rid of the space (-T45)
>
> 45 seconds is way too short, even for LAN use. For general ISP dialup,
> you need to stick to the RFC-defined 600 seconds.
>
> AB
>
Date: Fri, 19 Feb 1999 09:01:02 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: Time Out - Help needed
On Thu, 18 Feb 1999, John Vozza wrote:
> But why is the session I described still running after 20 minutes?
>
> What is the default timeout in qpopper since it appears I had the -T
> wrong?
Whatever you compiled in - you need to check the setting in the source.
Things can get messed up if the user has a single large message to
download. You need to check that hasn't happened in this case.
AB
Date: Thu, 18 Feb 1999 16:11:29 -0500 (EST)
From: John Vozza <john at netrom dot com>
Subject: Re: Time Out - Help needed
Checked the source and popper.h contained;
popper.h:#define POP_TIMEOUT 120 /* timeout connection after this
So it appears that there may be a problem in that if the customers modem
disconnects and qpopper is running in server mode with pop bulletins that
the timeout is broken since the session was still active after 20 minutes?
Guess I'll try 3.0b14 and see if the problem persists.
John
-------------------------------------------------------------------------
NetRom Internet Services 973-208-1339 voice
john at netrom dot com 973-208-0942 fax
http://www.netrom.com
-------------------------------------------------------------------------
On Fri, 19 Feb 1999, Alan Brown wrote:
> On Thu, 18 Feb 1999, John Vozza wrote:
>
> > But why is the session I described still running after 20 minutes?
> >
> > What is the default timeout in qpopper since it appears I had the -T
> > wrong?
>
> Whatever you compiled in - you need to check the setting in the source.
>
> Things can get messed up if the user has a single large message to
> download. You need to check that hasn't happened in this case.
>
> AB
>
Date: Thu, 18 Feb 1999 14:34:02 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: NFS with qpopper?
At 2:25 PM -0800 2/18/99, Tabor J. Wells wrote:
> Ok, I know that #5 in the INSTALL file states that qpopper shouldn't be
> used over NFS in 2.53. Is that still going to be case with the 3.0 series?
>
> Also I've seen it mentioned that people do use qpopper over NFS (at least
> in the Dejanews search I did yesterday I saw a few references). How
> successful/dangerous is this?
>
> We're in the process of moving local accounts to a pair of failover NFS'd
> systems served off of a fibre channel array and I need to find a way to
> handle POP3 support with mail which is delivered to $HOME/.mail. We tried
> the switch from qpopper to cucipop once upon a time, but our userbase
> nearly lynched us due to weird problems with some mail clients downloading
> the mail repeatedly, etc. I'd love to stay with qpopper if it isn't going
> to be mutually exclusive with the architecture outlined above.
> Thanks in advance for any info you can provide,
The reason it is in the FAQ is because of the file locking. If you
plan on exporting the mail spool and you trust the system's file
locking that should be good. We have had some complaints about the
locking on NFS and we can not recommend using it over NFS. However,
if you are successful please let us know.
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Thu, 18 Feb 1999 14:39:43 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: SERVER_MODE
At 2:25 PM -0800 2/18/99, William F. Dudley wrote:
> Hi,
>
> We've got about 12000 email accounts on a single machine running BSDI,
> and the disk i/o due to qpopper copying the mail spool back and forth
> is starting to choke the machine.
>
> We're not running qpopper in SERVER_MODE currently, but are using the
> HASH_SPOOL=2 feature that assumes user's email is in /var/mail/u/s/user.
>
> Can anyone explain exactly the issues of running qpopper in SERVER_MODE
> while also running elm,pine,mail,Mail as mail reader programs plus
> mail.local (the BSDI mail delivery agent) ? I find the qpopper
> documentation weak on this point.
Server mode helps in two usage cases, both of which are fairly
common: users download and delete all mail during each connection
(classic POP model). or users leave all mail on the server all the
time. In either case, server mode avoids copying the mail spool,
which can be a big help on a loaded system.
Even in server mode, if users delete some mail but leave others, or
if there is new mail, the spool is copied.
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Thu, 18 Feb 1999 14:44:06 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: Canonical Name Error
At 2:25 PM -0800 2/18/99, Søren Peter Skou wrote:
> Where I work, we're using Qpopper, nice product, but at some point, the lo=
gs
> started to get flooded with errors like :
>
> (v2.53) Unable to get canonical name of client, err = 0
>
> or the other one
> (v2.53) Unable to get canonical name of client, err = 60
I'll patch the error message to include the IP address. Note that
3.0b14 includes the ability to use the -R run-time option to disable
reverse lookups.
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
From: =?iso-8859-1?Q?Frédéric_Van_Walle?= <fred at CAC dot BE>
Subject:
Date: Fri, 19 Feb 1999 08:35:23 +0100
UNSUBSCRIBE
Date: Fri, 19 Feb 1999 10:18:09 -0500
From: Roy Kidder <rkidder at ocom dot com>
Subject: Re: getsubopt() again
I keep trying to solve this problem without any luck. I've used a sniffer
to capture the packets between the two machines and I've been capturing the
output from a "netstat -n" running in a loop on either machine. I've
recreated the failure fifty or sixty times without once getting any kind of
positive results.
Capturing the packets between my Eudora client and my Linux QPopper server,
this is what I consistently get:
C: [socket open on POP3]
S: +OK QPOP (version 3.b14) at gandalf.network starting.
<xxxxxxx at gandalf dot network>
C: APOP rkidder xxxxxxx
S: +OK rkidder has 1 message(s) (511 octets).
C: STAT
Then immediately Eudora comes back with the following two errors:
"Closing the connection, [09:32:10 AM]. Error writing to the network.
Cause: connection aborted due to timeout or other failure (10053)"
"Logging into POP Server, [09:59:55 AM] Error reading from network. Cause:
Connection closed by foreign host. (0)"
I can't figure out what is going wrong. My server is Slackware 3.6 (2.0.35)
running on an x86. My client is Eudora Pro v4.1 running on NT Server 4.0
SP3. I configured QPopper several times using the following combinations:
"--enable-debugging --enable-apop --with-popuid --enable-servermode",
"--enable-debugging --enable-apop --with-popuid", and "--enable-apop
--with-popuid". My /etc/inetd.conf entry looks like this: "pop3 stream tcp
nowait root /usr/local/bin/popper popper -s".
If anyone has a suggestion, I'd be glad to hear them.
Thanks in advance,
Roy
At 12:54 PM 2/17/99 -0800, Randall Gellens wrote:
>This doesn't sound like a Qpopper problem. By the way, the port
>numbers in use should not change during a session.
>
>Has it happened more than once?
>
>At 12:45 PM -0800 2/17/99, Roy Kidder wrote:
>
>> I obtained the 3.0b14 and compiled it. The getsubopt() problem went away,
>> but now I'm seeing a new problem.
>>
>> I sent myself an email message and verified it's arrival on my Linux box. I
>> then went to my Microsoft box and fired up Eudora. The POP3 conversation
>> (according to the packets I sniffed off the network) went something
>> like this:
>>
>> S: OK QPOP (version 3.0b14) at gandalf.network starting.
>> <21741.919277421 at gandalf dot network>
>> C: APOP rkidder [encrypted password]
>> S: +OK rkidder has 1 message(s) (339 octets).
>>
>> Both boxes do some dancing around with changing port numbers for this
>> session before the
>> MS box changes back to 110 and sends the STAT command.
>>
>> At some point during this exchange, Eudora complains of the following
>> error: "Closing
>> the connection, [02:14:27 PM] Error writing to network. Cause: connection
>> aborted due
>> to timeout or other failure (10053)"
>>
>> The log output generated by popper looks something like this:
>> Wed Feb 17 14:15:09 1999 [25703] apop "rkidder"
>> Wed Feb 17 14:15:09 1999
>> Wed Feb 17 14:15:09 1999 [25703] Found top of first message
>> Wed Feb 17 14:15:09 1999
>>
>>
>> The email message was never transferred to the client.
>>
>>
>>
>> At 07:20 PM 2/16/99 -0800, Randall Gellens wrote:
>>>At 6:27 PM -0800 2/16/99, Roy Kidder wrote:
>>>
>>>> I'm running Slackware 3.6 (kernel version 2.0.35) on an x86 and it did not
>>>> work.
>>>
>>>I've verified that 3.0b14 fixes the getsubopt() problem for good,
>>>even on Slackware.
>>>
>>>This is now available on the FTP site
>>><ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper3.0b14.tar.Z >>.
>>>--
>>>Randall Gellens
>>>rg=public.1 at worldmail1.qualcomm dot com
>>>Opinions are personal; facts are suspect; I speak for myself only
>>
>> Return-Path: <kmahesh at qualcomm dot com>
>
>--
>Randall Gellens
>rg=public.1 at worldmail1.qualcomm dot com
>Opinions are personal; facts are suspect; I speak for myself only
Date: Fri, 19 Feb 1999 10:25:23 -0500 (EST)
From: "William F. Dudley" <dud at squid.monmouth dot com>
Subject: Re: SERVER_MODE
Randall,
Thanks very much for your reply, but I'm still in the dark about
the interactions between qpopper and mail,Mail,elm,pine (used to
read/create mail) and mail.local (the local delivery agent)
and qpopper. The qpopper docs say only that you can use SERVER_MODE
if you only run /bin/mail, which I assume means in our case, mail.local,
the mail delivery agent.
(On a BSDI system, sendmail calls mail.local to do the actual mail delivery).
Can you clarify the problems? I assume file locking is the main issue here.
Thanks in advance, and running out of disk bandwidth on the mail machine,
Bill Dudley
Monmouth Internet
New Jersey, USA
P.S. We're running two SCSI disks as a raid-0 array dedicated to the mail
spool directories on a dual Pentium box, so we're already running semi-serious
disk hardware. So it isn't immediately obvious how to throw money at it
to improve matters. This machine is our mail and shell account machine,
since we not happy with trying to NFS mount the mail spool from the
mail machine onto the shell machine. BSDI 4.0 supports real NFS locking
but there are still problems as it is a new feature.
Date: Fri, 19 Feb 1999 17:11:12 -0600
From: Sarah Riner <riners at lituus dot net>
Subject: (no subject)
> UNSUBSCRIBE
Date: Sat, 20 Feb 1999 12:44:43 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: SERVER_MODE
On Fri, 19 Feb 1999, William F. Dudley wrote:
> (On a BSDI system, sendmail calls mail.local to do the actual mail delivery).
>
> Can you clarify the problems? I assume file locking is the main issue here.
As far as I've been able to determine from local experiments, it is.
The key to Server_mode is that if this is enabled, it must be the only
thing working on that mailspool (apart from anything appending mail to
the end).
I've never seen it, but I'd guess some people run a local Pine/elm
session as well as popping, and there are some obvious dangers to the
file's integrity when that happens (not too obvious - Pine reacts to
anything else grabbing a folder being worked on by switching to
read-only mode).
AB
From: "Peter Turner" <Peter_Turner at walkergreenbank dot com>
Subject: Compiling 2.53 on DG/UX
Date: Mon, 22 Feb 1999 11:17:36 -0000
Hi
whilst trying to compile version 2.53 on a Data General Intel machine the
following error is reported from 'ld'
Undefined first referenced
symbol in file
getpeername pop_init.o
Anyone got a fix for this.
I also had a similar error from pop_ruser - ruserok but was able to fix
this by adding the following line to popper.h
extern int ruser();
after all the othe extern int lines.
Peter Turner
e-mail : Peter.Ulysses at dial.pipex dot com
Date: Mon, 22 Feb 1999 08:44:15 -0300 (EST)
From: Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Subject: Re: Compiling 2.53 on DG/UX
Hello Peter,
I had the same error and the cause is gcc. Try upgrade gcc ! It works
with me.
Bye.
-------------------------------------------------------------------------
Rodrigo Luiz Anami rodrigoa at bestway.com dot br
Best Way Internet Provider Atendimento ao Cliente
http://www.bestway.com.br (019) 254.6263 (Campinas)
webmaster at bestway.com dot br 0800.112262 (Outras Localidades)
-------------------------------------------------------------------------
On Mon, 22 Feb 1999, Peter Turner wrote:
> Hi
>
> whilst trying to compile version 2.53 on a Data General Intel machine the
> following error is reported from 'ld'
>
> Undefined first referenced
> symbol in file
> getpeername pop_init.o
>
> Anyone got a fix for this.
>
> I also had a similar error from pop_ruser - ruserok but was able to fix
> this by adding the following line to popper.h
>
> extern int ruser();
>
> after all the othe extern int lines.
>
> Peter Turner
>
> e-mail : Peter.Ulysses at dial.pipex dot com
>
Date: Wed, 24 Feb 1999 00:30:31 -0800
Subject: Several problems
From: "Steven W. Riggins" <geek at geeksrus dot com>
Hi!
I am running qpopper on a Power Computing Clone running linuxppc (redhat 4)
kernel 2.1.127
With both 2.5.3 and 3.0b13 I have the problem where Outlook Express gets a
"pop lock busy" on my support account if say one of my other accounts its
checking at the same time has mail. I am checking 4 accounts on the same
machine, threaded.
Second problem. When trying to compile for APOP, gcc is telling me is does
not understand the format of popauth.o. Any ideas what that could be? I
used the .configure args from the INSTALL file.
Steve
Date: Wed, 24 Feb 1999 08:51:50 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: Several problems
>
> With both 2.5.3 and 3.0b13 I have the problem where Outlook Express gets a
> "pop lock busy" on my support account if say one of my other accounts its
> checking at the same time has mail. I am checking 4 accounts on the same
> machine, threaded.
>
i'm kinda fuzzy on this. are you checking the same username more than once
at the same time? if so, then you're most certainly gonna get a pop lock
busy error. It wont let you read from the same mailbox more than once at
any one time. not to MY knowledge anyway
-Cygnus
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Thu, 25 Feb 1999 03:16:01 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: XTND XMIT
Qpopper 2.53/3.x has this feature, anyone have canned instructions on
making eudora/pegasus/{MS's various brokenware}/whatever actually make
use of it?
AB
Date: Wed, 24 Feb 1999 19:51:22 +0100
From: "Technik, GRUENE" <technik at gruene dot de>
Subject: qpopper2.53: Slow login
Hello,
Im a Newbie to Linux from Germany.
We are running qpopper 2.5.3 on a PC with S.U.S.E 6.0-Linux, Kernel 2.0.36
Problem: loggin to a Pop3-account from outside
(Internet, different ISPs) is very slow (5-10 Seconds),
because qpopper every time makes a Reverse DNS Lookup.
After this I get my mail rather quickly.
Is it possible to avoid the lookup in order to speed up login?
Herbert Peters
technik at gruene dot de
Date: Wed, 24 Feb 1999 16:00:17 -0300 (EST)
From: Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Subject: Re: qpopper2.53: Slow login
Hallo,
The new release of qpopper, 3.0b14 has a option that can disable reverse
verification. On your version I think you have to edit the code and delete
part that do this. Try a "grep canonical *" on source directory to find
the rotine that implements reverse verification. I didn't do that, so I
can't give any garanty. So good luck if decide to keep 2.53 and try
alterate code.
-------------------------------------------------------------------------
Rodrigo Luiz Anami rodrigoa at bestway.com dot br
Best Way Internet Provider Atendimento ao Cliente
http://www.bestway.com.br (019) 254.6263 (Campinas)
webmaster at bestway.com dot br 0800.112262 (Outras Localidades)
-------------------------------------------------------------------------
On Wed, 24 Feb 1999, Technik, GRUENE wrote:
> Hello,
>
> Im a Newbie to Linux from Germany.
>
> We are running qpopper 2.5.3 on a PC with S.U.S.E 6.0-Linux, Kernel 2.0.36
>
> Problem: loggin to a Pop3-account from outside
> (Internet, different ISPs) is very slow (5-10 Seconds),
> because qpopper every time makes a Reverse DNS Lookup.
>
> After this I get my mail rather quickly.
>
> Is it possible to avoid the lookup in order to speed up login?
>
>
> Herbert Peters
> technik at gruene dot de
>
Date: Wed, 24 Feb 1999 12:08:40 -0800
From: Randall Gellens <rg=public.1 at worldmail1.qualcomm dot com>
Subject: Re: getsubopt() again
At 12:26 PM -0800 2/19/99, Roy Kidder wrote:
> I keep trying to solve this problem without any luck. I've used a sniffer
> to capture the packets between the two machines and I've been capturing the
> output from a "netstat -n" running in a loop on either machine. I've
> recreated the failure fifty or sixty times without once getting any kind of
> positive results.
Have you tried using other clients (e.g., Netscape, Mac Eudora,
telnet it manually, etc.)?
--
Randall Gellens
rg=public.1 at worldmail1.qualcomm dot com
Opinions are personal; facts are suspect; I speak for myself only
Date: Wed, 24 Feb 1999 15:23:13 -0500
From: Roy Kidder <rkidder at ocom dot com>
Subject: Re: getsubopt() again
At 12:08 PM 2/24/99 -0800, Randall Gellens wrote:
>At 12:26 PM -0800 2/19/99, Roy Kidder wrote:
>
>> I keep trying to solve this problem without any luck. I've used a sniffer
>> to capture the packets between the two machines and I've been capturing the
>> output from a "netstat -n" running in a loop on either machine. I've
>> recreated the failure fifty or sixty times without once getting any kind of
>> positive results.
>
>Have you tried using other clients (e.g., Netscape, Mac Eudora,
>telnet it manually, etc.)?
>
I've compiled it you support APOP, so no, I haven't. If I reconfigure it
for traditional POP3, it works with my Eudora client just fine.
Thanks,
Roy
Date: Thu, 25 Feb 1999 12:06:55 +0800
From: Byron Jones <byron at vianet.net dot au>
Subject: qpopper not releasing lock
greetings,
i'm running qpopper-2.53-1-PAM on redhat 5.2. something that's been
happening frequently is when someone checks their email, the qpopper
process and the lock on their file isn't being released in any decent
lentgh of time (ie more than 5 minutes).
none of our clients have a mail program that crashes, like we've asked them
to close their email client, and even disconnect from the internet, however
the processes still run on our mail server. what we've been doing is
manually killing their in.qpopper process and removing the lock. this gets
kinda tedious :(
we've also had several reports of timeouts when downloading large messages.
i'm just wondering if the timeout period is in effect while the user is
download large emails (in this case "large" means above 2 meg .. our max is
set to 5 meg).
oh, and inetd.conf calls qpopper as :
pop-3 stream tcp nowait.400 root /usr/sbin/tcpd in.qpopper
so.. anyone got any [good] ideas?
thanks :)
- Byron Jones -
- Systems Administrator -
- Vianet Australia -
- http://www.vianet.net.au/~byron -
Date: Thu, 25 Feb 1999 23:39:29 +1300 (NZDT)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: qpopper not releasing lock
On Thu, 25 Feb 1999, Byron Jones wrote:
> none of our clients have a mail program that crashes, like we've asked them
> to close their email client, and even disconnect from the internet, however
> the processes still run on our mail server. what we've been doing is
> manually killing their in.qpopper process and removing the lock. this gets
> kinda tedious :(
>
> we've also had several reports of timeouts when downloading large messages.
> i'm just wondering if the timeout period is in effect while the user is
> download large emails (in this case "large" means above 2 meg .. our max is
> set to 5 meg).
The most common cause I've seen for hanging in.qpopper processes on
dialups is noisy phone lines causing the user to get disconnected.
Download timeouts are a client function. Eudora (and most other
packages) only default to 60 seconds per message, which is only enough
time for about 250kb @ 33k6.
Eudora 1 and 2 don't close off the connection cleanly when they abort
because of timeouts, resulting in the pop dropfile being appended to
the mail file ("exploding mailbox syndrome"). Our advice to users is to
update to current software and set the collect timeout high enough to
cope with the largest message they expect to see.
AB
Date: Thu, 25 Feb 1999 10:27:23 -0300 (EST)
From: Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Subject: Re: qpopper not releasing lock
Hi, Byron.
I don''t understand your first question, are you using qpopper in
server-mode. If you don't, try to build qpopper in server-mode.
We have the problems with timeout, but limited our e-mails to 2 meg. And
we are using option -T600 on inetd.conf. By default, timeout is set to
120s (look popper.h), with this flag, timeout is set to 10 minutes now.
Bye.
-------------------------------------------------------------------------
Rodrigo Luiz Anami rodrigoa at bestway.com dot br
Best Way Internet Provider Atendimento ao Cliente
http://www.bestway.com.br (019) 254.6263 (Campinas)
webmaster at bestway.com dot br 0800.112262 (Outras Localidades)
-------------------------------------------------------------------------
On Thu, 25 Feb 1999, Byron Jones wrote:
> greetings,
>
> i'm running qpopper-2.53-1-PAM on redhat 5.2. something that's been
> happening frequently is when someone checks their email, the qpopper
> process and the lock on their file isn't being released in any decent
> lentgh of time (ie more than 5 minutes).
>
> none of our clients have a mail program that crashes, like we've asked them
> to close their email client, and even disconnect from the internet, however
> the processes still run on our mail server. what we've been doing is
> manually killing their in.qpopper process and removing the lock. this gets
> kinda tedious :(
>
> we've also had several reports of timeouts when downloading large messages.
> i'm just wondering if the timeout period is in effect while the user is
> download large emails (in this case "large" means above 2 meg .. our max is
> set to 5 meg).
>
> oh, and inetd.conf calls qpopper as :
>
> pop-3 stream tcp nowait.400 root /usr/sbin/tcpd in.qpopper
>
> so.. anyone got any [good] ideas?
>
> thanks :)
>
> - Byron Jones -
> - Systems Administrator -
> - Vianet Australia -
> - http://www.vianet.net.au/~byron -
>
Date: Thu, 25 Feb 1999 09:55:47 -0500 (EST)
From: System Administrator <admin at intergrafix dot net>
Subject: Re: qpopper not releasing lock
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.
---171031142-37121570-919954547=:21504
Content-Type: TEXT/PLAIN; charset=US-ASCII
well, first I suggest upgrading to a 3.0 beta of qpopper, then replacing
your pop_dropcopy.c with the attached text file. and recompiling.
i've changed this source file to:
A) check for the glitch of the missing 'F' in the "From" line of the
headers
B) check for an already existing popper process and/or lock file for the
user. If a popper process exists for the user trying to retrieve their
mail, the old process will be killed, and the current process will
continue the mail retrieval. If a lock file is found, it will be unlocked
and removed, and the current process will continue the mail retrieval.
This does NOT check for GOOD retrievals..(i.e. if you start retrieving
mail from one machine, then try to retrieve on another while the first
retrieval is sitll happening, the first will be cancelled and the 2nd
started) just an FYI.
the file contains 2 extra #defines. PS_COMMAND which sets the command to
use to find the old processes. and PS_SEARCH that defines the name of the
popper process we'll search for. I use linux and the default executable
name, so mine are set to "ps ux" and "popper"
i dont make any guarantees about this hack. it may should on your system,
it works on mine in server mode, but it may not for some reason. if you
lose any mail over it, I'm not responsible. :-)
Hope it works for you.
-Cygnus
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
On Thu, 25 Feb 1999, Byron Jones wrote:
> greetings,
>
> i'm running qpopper-2.53-1-PAM on redhat 5.2. something that's been
> happening frequently is when someone checks their email, the qpopper
> process and the lock on their file isn't being released in any decent
> lentgh of time (ie more than 5 minutes).
>
> none of our clients have a mail program that crashes, like we've asked them
> to close their email client, and even disconnect from the internet, however
> the processes still run on our mail server. what we've been doing is
> manually killing their in.qpopper process and removing the lock. this gets
> kinda tedious :(
>
> we've also had several reports of timeouts when downloading large messages.
> i'm just wondering if the timeout period is in effect while the user is
> download large emails (in this case "large" means above 2 meg .. our max is
> set to 5 meg).
>
> oh, and inetd.conf calls qpopper as :
>
> pop-3 stream tcp nowait.400 root /usr/sbin/tcpd in.qpopper
>
> so.. anyone got any [good] ideas?
>
> thanks :)
>
> - Byron Jones -
> - Systems Administrator -
> - Vianet Australia -
> - http://www.vianet.net.au/~byron -
>
---171031142-37121570-919954547=:21504
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="pop_dropcopy.send"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9902250955470.21504 at athena.intergrafix dot net>
Content-Description:
Content-Disposition: attachment; filename="pop_dropcopy.send"
LyoNCiAqIENvcHlyaWdodCAoYykgMTk4OSBSZWdlbnRzIG9mIHRoZSBVbml2
ZXJzaXR5IG9mIENhbGlmb3JuaWEuDQogKiBBbGwgcmlnaHRzIHJlc2VydmVk
LiAgVGhlIEJlcmtlbGV5IHNvZnR3YXJlIExpY2Vuc2UgQWdyZWVtZW50DQog
KiBzcGVjaWZpZXMgdGhlIHRlcm1zIGFuZCBjb25kaXRpb25zIGZvciByZWRp
c3RyaWJ1dGlvbi4NCiAqLw0KDQovKg0KICogQ29weXJpZ2h0IChjKSAxOTk4
IFF1YWxjb21tIEluY29ycG9yYXRlZC4gQWxsIHJpZ2h0cyByZXNlcnZlZC4N
CiAqDQogKiBSZXZpc2lvbnMgOiANCiAqICA2LzIyLzk4ICBbcHldDQogKiAg
ICAgICAgIC0gQWRkZWQga2x1ZGdlIGZvciBOVUxMcyBpbiBtZXNzYWdlIGNv
bnRlbnQoc3VnZ2VzdGVkIGJ5IA0KICogICAgICAgICAgIE1vcmRlY2hhaSBU
LkFienVnKS4NCiAqICAgICAgICAgICBVaWRsIHRvIGNvbnRhaW4gRnJvbSBF
bnZlbG9wZSBpbiBub24tbW1kZiwgYW5kIGxlbmd0aCBjaGVjay4NCiAqICAz
LzE4Lzk4ICBbcHldDQogKiAgICAgICAgIC0gUmV2aWV3ZWQgdGhlIGNvZGUs
IGFkZGVkIERFQlVHIG1hY3JvcywgY29ycmVjdGVkIHRoZSANCiAqICAgICAg
ICAgICAgcmVzb3VyY2VzIHRoYXQgYXJlIG5vdCBjbG9zZWQuDQogKi8NCg0K
LyoNCiAqIFdoZW4gYWRkaW5nIGVhY2ggbGluZSBsZW5ndGggaW50byB0aGUg
c2l6ZSBvZiB0aGUgbWVzc2FnZSBhbmQgdGhlIG1haWxkcm9wLA0KICogaW5j
cmVhc2UgdGhlIGNoYXJhY3RlciBjb3VudCBieSBvbmUgZm9yIHRoZSA8Y3I+
IGFkZGVkIHdoZW4gc2VuZGluZyB0aGUNCiAqIG1lc3NhZ2UgdG8gdGhlIG1h
aWwgY2xpZW50LiAgQWxsIGxpbmVzIHNlbnQgdG8gdGhlIGNsaWVudCBhcmUg
dGVybWluYXRlZA0KICogd2l0aCBhIDxjcj48bGY+Lg0KICovDQoNCiNpbmNs
dWRlIDxjb25maWcuaD4NCg0KI2luY2x1ZGUgPGVycm5vLmg+DQojaW5jbHVk
ZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNpbmNsdWRl
IDxjdHlwZS5oPg0KI2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUgPGZs
b2NrLmg+DQoNCiNpZiBIQVZFX1VOSVNURF9IDQojIGluY2x1ZGUgPHVuaXN0
ZC5oPg0KI2VuZGlmDQoNCiNpZiBIQVZFX1NZU19VTklTVERfSA0KIyBpbmNs
dWRlIDxzeXMvdW5pc3RkLmg+DQojZW5kaWYNCg0KI2lmbmRlZiBIQVZFX0lO
REVYDQojICBkZWZpbmUJaW5kZXgocyxjKQkJc3RyY2hyKHMsYykNCiMgIGRl
ZmluZQlyaW5kZXgocyxjKQkJc3RycmNocihzLGMpDQojIGVuZGlmDQojaWYg
SEFWRV9TVFJJTkdTX0gNCiMgaW5jbHVkZSA8c3RyaW5ncy5oPg0KI2VuZGlm
DQojaW5jbHVkZSA8c3lzL3N0YXQuaD4NCiNpbmNsdWRlIDxzeXMvZmlsZS5o
Pg0KI2luY2x1ZGUgPHB3ZC5oPg0KI2luY2x1ZGUgPHBvcHBlci5oPg0KDQoj
aWZkZWYgTUFJTE9DSw0KIyBpZmRlZiBIQVZFX01BSUxMT0NLDQojICBpbmNs
dWRlIDxtYWlsbG9jay5oPg0KIyBlbmRpZg0KIyBkZWZpbmUgTUFJTFVOTE9D
SygpIG1haWx1bmxvY2soKQ0KI2Vsc2UgDQojIGRlZmluZSBNQUlMVU5MT0NL
KCkNCiNlbmRpZg0KDQojZGVmaW5lIE1JTl9VSURMX0xFTkdUSCA1ICAgICAv
KiBUaGVyZSBpcyBubyBwYXJ0aWN1bGFyIHJlYXNvbiB0byBoYXZlIHRoaXMg
Ki8NCiNkZWZpbmUgTUFYX1VJRExfTEVOR1RIIDcwDQoNCi8qIFRoaXMgbWFj
cm8gY29tZXMgZnJvbSBNYXJrIENyaXNwaW4ncyBjLWNsaWVudCBjb2RlICov
DQoNCi8qIFZhbGlkYXRlIGxpbmUNCiAqIEFjY2VwdHM6IHBvaW50ZXIgdG8g
Y2FuZGlkYXRlIHN0cmluZyB0byB2YWxpZGF0ZSBhcyBhIEZyb20gaGVhZGVy
DQogKgkgICAgcmV0dXJuIHBvaW50ZXIgdG8gZW5kIG9mIGRhdGUvdGltZSBm
aWVsZA0KICoJICAgIHJldHVybiBwb2ludGVyIHRvIG9mZnNldCBmcm9tIHQg
b2YgdGltZSAoaG91cnMgb2YgYGBtbW0gZGQgaGg6bW0nJykNCiAqCSAgICBy
ZXR1cm4gcG9pbnRlciB0byBvZmZzZXQgZnJvbSB0IG9mIHRpbWUgem9uZSAo
aWYgbm9uLXplcm8pDQogKiBSZXR1cm5zOiB0LHRpLHpuIHNldCBpZiB2YWxp
ZCBGcm9tIHN0cmluZywgZWxzZSB0aSBpcyBOSUwNCiAqLw0KDQojZGVmaW5l
IFBTX0NPTU1BTkQJInBzIHV4IgkvKiB0aGlzIGNvbW1hbmQgaXMgcnVuIGFz
IHRoZSB1c2VybmFtZSAqLw0KCQkJCS8qIGFuZCBzaG91bGQgc2hvdyBwcm9j
ZXNzIG5hbWVzLHBpZHMsICovDQoJCQkJLyogYW5kIHRoZSBwcm9jZXNzIG93
bmVyCSAgICAgICAqLw0KCQkJCS8qIHBzIHV4IHdvcmtzIGZvciBsaW51eCBm
b3Igc3VyZSAgICAgICovDQojZGVmaW5lIFBTX1NFQVJDSAkicG9wcGVyIiAv
KiBuYW1lIHRoZSBwb3BwZXIgcHJvY2VzcyBydW5zIGFzICAgICovDQoJCQkJ
IC8qIGFzIHNob3duIGluIHRoZSBwcm9jZXNzIGxpc3QgICAgICAgKi8NCnZv
aWQgY2xlYXJfb2xkKFBPUCAqcCk7DQoNCiNkZWZpbmUgVkFMSUQocyx4LHRp
LHpuKSB7CQkJCQkJXA0KICB0aSA9IDA7CQkJCQkJCQlcDQogIGlmICgoKnMg
PT0gJ0YnKSAmJiAoc1sxXSA9PSAncicpICYmIChzWzJdID09ICdvJykgJiYg
KHNbM10gPT0gJ20nKSAmJglcDQogICAgICAoc1s0XSA9PSAnICcpKSB7CQkJ
CQkJCVwNCiAgICBmb3IgKHggPSBzICsgNTsgKnggJiYgKnggIT0gJ1xuJzsg
eCsrKTsJCQkJXA0KICAgIGlmICh4KSB7CQkJCQkJCQlcDQogICAgICBpZiAo
eCAtIHMgPj0gNDEpIHsJCQkJCQlcDQoJZm9yICh6biA9IC0xOyB4W3puXSAh
PSAnICc7IHpuLS0pOwkJCQlcDQoJaWYgKCh4W3puLTFdID09ICdtJykgJiYg
KHhbem4tMl0gPT0gJ28nKSAmJiAoeFt6bi0zXSA9PSAncicpICYmCVwNCgkg
ICAgKHhbem4tNF0gPT0gJ2YnKSAmJiAoeFt6bi01XSA9PSAnICcpICYmICh4
W3puLTZdID09ICdlJykgJiYJXA0KCSAgICAoeFt6bi03XSA9PSAndCcpICYm
ICh4W3puLThdID09ICdvJykgJiYgKHhbem4tOV0gPT0gJ20nKSAmJglcDQoJ
ICAgICh4W3puLTEwXSA9PSAnZScpICYmICh4W3puLTExXSA9PSAncicpICYm
ICh4W3puLTEyXSA9PSAnICcpKVwNCgkgIHggKz0gem4gLSAxMjsJCQkJCQkJ
XA0KICAgICAgfQkJCQkJCQkJCVwNCiAgICAgIGlmICh4IC0gcyA+PSAyNykg
ewkJCQkJCVwNCglpZiAoeFstNV0gPT0gJyAnKSB7CQkJCQkJXA0KCSAgaWYg
KHhbLThdID09ICc6Jykgem4gPSAwLHRpID0gLTU7CQkJCVwNCgkgIGVsc2Ug
aWYgKHhbLTldID09ICcgJykgdGkgPSB6biA9IC05OwkJCQlcDQoJICBlbHNl
IGlmICgoeFstMTFdID09ICcgJykgJiYgKCh4Wy0xMF09PScrJykgfHwgKHhb
LTEwXT09Jy0nKSkpCVwNCgkgICAgdGkgPSB6biA9IC0xMTsJCQkJCQlcDQoJ
fQkJCQkJCQkJXA0KCWVsc2UgaWYgKHhbLTRdID09ICcgJykgewkJCQkJXA0K
CSAgaWYgKHhbLTldID09ICcgJykgem4gPSAtNCx0aSA9IC05OwkJCQlcDQoJ
fQkJCQkJCQkJXA0KCWVsc2UgaWYgKHhbLTZdID09ICcgJykgewkJCQkJXA0K
CSAgaWYgKCh4Wy0xMV0gPT0gJyAnKSAmJiAoKHhbLTVdID09ICcrJykgfHwg
KHhbLTVdID09ICctJykpKQlcDQoJICAgIHpuID0gLTYsdGkgPSAtMTE7CQkJ
CQkJXA0KCX0JCQkJCQkJCVwNCglpZiAodGkgJiYgISgoeFt0aSAtIDNdID09
ICc6JykgJiYJCQkJXA0KCQkgICAgKHhbdGkgLT0gKCh4W3RpIC0gNl0gPT0g
JzonKSA/IDkgOiA2KV0gPT0gJyAnKSAmJglcDQoJCSAgICAoeFt0aSAtIDNd
ID09ICcgJykgJiYgKHhbdGkgLSA3XSA9PSAnICcpICYmCQlcDQoJCSAgICAo
eFt0aSAtIDExXSA9PSAnICcpKSkgdGkgPSAwOwkJCVwNCiAgICAgIH0JCQkJ
CQkJCQlcDQogICAgfQkJCQkJCQkJCVwNCiAgfQkJCQkJCQkJCVwNCiAgZWxz
ZSBpZiAoKCpzID09ICdyJykgJiYgKHNbMV0gPT0gJ28nKSAmJiAoc1syXSA9
PSAnbScpICYmIChzWzNdID09ICcgJykpIHsJXA0KICAgIGZvciAoeCA9IHMg
KyA0OyAqeCAmJiAqeCAhPSAnXG4nOyB4KyspOwkJCQlcDQogICAgaWYgKHgp
IHsJCQkJCQkJCVwNCiAgICAgIGlmICh4IC0gcyA+PSA0MSkgewkJCQkJCVwN
Cglmb3IgKHpuID0gLTE7IHhbem5dICE9ICcgJzsgem4tLSk7CQkJCVwNCglp
ZiAoKHhbem4tMV0gPT0gJ20nKSAmJiAoeFt6bi0yXSA9PSAnbycpICYmICh4
W3puLTNdID09ICdyJykgJiYJXA0KCSAgICAoeFt6bi00XSA9PSAnZicpICYm
ICh4W3puLTVdID09ICcgJykgJiYgKHhbem4tNl0gPT0gJ2UnKSAmJglcDQoJ
ICAgICh4W3puLTddID09ICd0JykgJiYgKHhbem4tOF0gPT0gJ28nKSAmJiAo
eFt6bi05XSA9PSAnbScpICYmCVwNCgkgICAgKHhbem4tMTBdID09ICdlJykg
JiYgKHhbem4tMTFdID09ICdyJykgJiYgKHhbem4tMTJdID09ICcgJykpXA0K
CSAgeCArPSB6biAtIDEyOwkJCQkJCQlcDQogICAgICB9CQkJCQkJCQkJXA0K
ICAgICAgaWYgKHggLSBzID49IDI3KSB7CQkJCQkJXA0KCWlmICh4Wy01XSA9
PSAnICcpIHsJCQkJCQlcDQoJICBpZiAoeFstOF0gPT0gJzonKSB6biA9IDAs
dGkgPSAtNTsJCQkJXA0KCSAgZWxzZSBpZiAoeFstOV0gPT0gJyAnKSB0aSA9
IHpuID0gLTk7CQkJCVwNCgkgIGVsc2UgaWYgKCh4Wy0xMV0gPT0gJyAnKSAm
JiAoKHhbLTEwXT09JysnKSB8fCAoeFstMTBdPT0nLScpKSkJXA0KCSAgICB0
aSA9IHpuID0gLTExOwkJCQkJCVwNCgl9CQkJCQkJCQlcDQoJZWxzZSBpZiAo
eFstNF0gPT0gJyAnKSB7CQkJCQlcDQoJICBpZiAoeFstOV0gPT0gJyAnKSB6
biA9IC00LHRpID0gLTk7CQkJCVwNCgl9CQkJCQkJCQlcDQoJZWxzZSBpZiAo
eFstNl0gPT0gJyAnKSB7CQkJCQlcDQoJICBpZiAoKHhbLTExXSA9PSAnICcp
ICYmICgoeFstNV0gPT0gJysnKSB8fCAoeFstNV0gPT0gJy0nKSkpCVwNCgkg
ICAgem4gPSAtNix0aSA9IC0xMTsJCQkJCQlcDQoJfQkJCQkJCQkJXA0KCWlm
ICh0aSAmJiAhKCh4W3RpIC0gM10gPT0gJzonKSAmJgkJCQlcDQoJCSAgICAo
eFt0aSAtPSAoKHhbdGkgLSA2XSA9PSAnOicpID8gOSA6IDYpXSA9PSAnICcp
ICYmCVwNCgkJICAgICh4W3RpIC0gM10gPT0gJyAnKSAmJiAoeFt0aSAtIDdd
ID09ICcgJykgJiYJCVwNCgkJICAgICh4W3RpIC0gMTFdID09ICcgJykpKSB0
aSA9IDA7CQkJXA0KICAgICAgfQkJCQkJCQkJCVwNCiAgICB9CQkJCQkJCQkJ
XA0KICB9CQkJCQkJCQkJXA0KfQ0KDQovKiBZb3UgYXJlIG5vdCBleHBlY3Rl
ZCB0byB1bmRlcnN0YW5kIHRoaXMgbWFjcm8sIGJ1dCByZWFkIHRoZSBuZXh0
IHBhZ2UgaWYNCiAqIHlvdSBhcmUgbm90IGZhaW50IG9mIGhlYXJ0Lg0KICoN
CiAqIEtub3duIGZvcm1hdHMgdG8gdGhlIFZBTElEIG1hY3JvIGFyZToNCiAq
IAkJRnJvbSB1c2VyIFdlZCBEZWMgIDIgMDU6NTMgMTk5Mg0KICogQlNECQlG
cm9tIHVzZXIgV2VkIERlYyAgMiAwNTo1MzoyMiAxOTkyDQogKiBTeXNWCQlG
cm9tIHVzZXIgV2VkIERlYyAgMiAwNTo1MyBQU1QgMTk5Mg0KICogcm4JCUZy
b20gdXNlciBXZWQgRGVjICAyIDA1OjUzOjIyIFBTVCAxOTkyDQogKgkJRnJv
bSB1c2VyIFdlZCBEZWMgIDIgMDU6NTMgLTA3MDAgMTk5Mg0KICoJCUZyb20g
dXNlciBXZWQgRGVjICAyIDA1OjUzOjIyIC0wNzAwIDE5OTINCiAqCQlGcm9t
IHVzZXIgV2VkIERlYyAgMiAwNTo1MyAxOTkyIFBTVA0KICoJCUZyb20gdXNl
ciBXZWQgRGVjICAyIDA1OjUzOjIyIDE5OTIgUFNUDQogKgkJRnJvbSB1c2Vy
IFdlZCBEZWMgIDIgMDU6NTMgMTk5MiAtMDcwMA0KICogU29sYXJpcwlGcm9t
IHVzZXIgV2VkIERlYyAgMiAwNTo1MzoyMiAxOTkyIC0wNzAwDQogKg0KICog
UGx1cyBhbGwgb2YgdGhlIGFib3ZlIHdpdGggYGAgcmVtb3RlIGZyb20geHh4
JycgYWZ0ZXIgaXQuIFRoYW5rIHlvdSB2ZXJ5DQogKiBtdWNoLCBzbWFpbCBh
bmQgU29sYXJpcywgZm9yIG1ha2luZyBteSBsaWZlIGNvbnNpZGVyYWJseSBt
b3JlIGNvbXBsaWNhdGVkLg0KICovDQoNCg0KaW50IG5ld2xpbmUgPSAxOw0K
DQovKg0KICogIDAgZm9yIG5vdCBhIGZyb20gbGluZQ0KICogIDEgZm9yIGlz
IGEgZnJvbSBsaW5lDQogKi8NCg0KLyogVmFsaWQgVVVDUCBGcm9tIGxpbmVz
Og0KICoNCiAqCUZyb20gQWRkcmVzcyBbdHR5XSBkYXRlDQogKglGcm9tIFt0
dHldIGRhdGUNCiAqDQogKgkiRnJvbSBbdHR5XSBkYXRlIiBpcyBwcm9iYWJs
eSB2YWxpZCBidXQgSSdtIHRvbyBsYXp5IGF0IHRoaXMNCiAqCXRpbWUgdG8g
YWRkIHRoZSBjb2RlLg0KICoNCiAqLw0KaW50DQppc2Zyb21saW5lKGNwKQ0K
Y2hhcgkqY3A7DQp7DQogICAgaW50IHRpLCB6bjsNCiAgICBjaGFyICp4Ow0K
DQogICAgLyogSWYgdGhlIHByZXZpb3VzIGxpbmUgd2FzIG5vdCBhIG5ld2xp
bmUgdGhlbiBqdXN0IHJldHVybiAqLw0KICAgIC8qIEZyb20gbWVzc2FnZSBz
ZXBhcmF0b3JzIGFyZSBwcmVjZWVkZWQgYnkgYSBuZXdsaW5lICovIA0KICAg
IGlmICgqY3AgPT0gJ1xuJykgew0KCW5ld2xpbmUgPSAxOw0KCXJldHVybigw
KTsNCiAgICB9IGVsc2UgaWYgKCFuZXdsaW5lKSB7DQoJcmV0dXJuKDApOw0K
ICAgIH0gZWxzZQ0KCW5ld2xpbmUgPSAwOw0KDQogICAgVkFMSUQoY3AsIHgs
IHRpLCB6bik7DQogICAgcmV0dXJuKHRpICE9IDApOw0KfQ0KDQoNCi8qDQog
KiBCYXNlIDgwIGVuY29kaW5nIG9mIDE2Ynl0ZSBNRDUgaGFzaC4gVGhpcyBp
cyBhYm91dCB0aGUgc21hbGxlcyBlbmNvZGluZw0KICogcG9zc2libGUgZm9y
IHRoZSBNRDUgaGFzaCB1c2luZyB0aGUgY2hhcnMgYWxsb3dlZCBmb3IgVUlE
THMuIA0KICogKDkzIEFTQ0lJIHZhbHVlcyBhcmUgYXZhaWxhYmxlIGFuZCAx
OV45MyA8IDJeMTI4IDwgMjBeOTMpDQogKiBUaGlzIGltcGxlbWVudGF0aW9u
IGlzbid0IGV4YWN0IGFib3V0IE1TQnMgYW5kIExTQiwgYnV0IGl0IGlzIHVu
aXF1ZS4uDQogKi8NCg0KY2hhciAqYmFzZTgwKGNoYXIgKm91dHB1dCwgY2hh
ciAqZGlnZXN0KQ0Kew0KICB1bnNpZ25lZCBsb25nIHYsIG4sIGo7DQogIGlu
dCBpLCBrOw0KDQogIGZvcihpID0gMCA7IGkgPCAxNjsgKSB7DQogICAgdiA9
IDBMOw0KICAgIGRvIHsNCiAgICAgIHYgPSAodiA8PCA0KSArIGRpZ2VzdFtp
KytdOw0KICAgIH0gd2hpbGUoaSU0KTsNCiAgICBmb3IoayA9IDA7IGsgPCA1
OyBrKyspIHsNCiAgICAgIGogPSB2ICUgODA7DQogICAgICB2ID0gKHYgLSBq
KS84MDsNCiAgICAgICpvdXRwdXQgPSAweDIxICsgajsNCiAgICAgIC8qIEF2
b2lkIC4gYWx0Z290aGVyIHRvIGF2b2lkIGhhdmluZyB0byBzdHVmZiBpdCAq
Lw0KICAgICAgaWYoKm91dHB1dCA9PSAnLicpDQogICAgICAgICpvdXRwdXQg
PSAnfic7DQogICAgICBvdXRwdXQrKzsNCiAgICB9DQogIH0NCiAgKm91dHB1
dCA9ICdcMCc7DQogIHJldHVybihvdXRwdXQpOw0KfQ0KDQoNCg0KLyogSGFz
aGluZyB0byBhIHNwb29sIGRpcmVjdG9yeSBoZWxwcyByZWR1Y2UgdGhlIGxv
b2t1cCB0aW1lIGZvciBzaXRlcw0KICogd2l0aCB0aG91c2FuZHMgb2YgbWFp
bCBzcG9vbCBmaWxlcy4gIFVuaXggdXNlcyBhIGxpbmVhciBsaXN0IHRvDQog
KiBzYXZlIGRpcmVjdG9yeSBpbmZvcm1hdGlvbiBhbmQgdGhlIGZvbGxvd2lu
ZyBtZXRob2RzIGF0dGVtcHQgdG8NCiAqIGltcHJvdmUgdGhlIHBlcmZvcm1h
bmNlLg0KICoNCiAqIE1ldGhvZCAxIC0gYWRkIHRoZSB2YWx1ZSBvZiB0aGUg
Zmlyc3QgNCBjaGFycyBtb2QgMjYgYW5kIG9wZW4gdGhlDQogKgkgICAgICBz
cG9vbCBmaWxlIGluIHRoZSBkaXJlY3RvcnkgJ2EnIC0gJ3onL3VzZXIuDQog
KgkgICAgICBCcmlhbiBCdWhyb3cgPGJ1aHJvd0BjYXRzLnVjc2MuZWR1Pg0K
ICoNCiAqIE1ldGhvZCAyIC0gVXNlIHRoZSBmaXJzdCAyIGNoYXJhY3RlcnMg
dG8gZGV0ZXJtaW5lIHdoaWNoIG1haWwgc3Bvb2wNCiAqCSAgICAgIHRvIG9w
ZW4uICBFZzogL3Vzci9zcG9vbC91L3MvdXNlci4NCiAqCSAgICAgIExhcnJ5
IFNjaHdpbW1lciA8cm9zZWJ1ZEBjeWNsb25lLnN0YW5mb3JkLmVkdT4NCiAq
DQogKiBBbGwgdGhlc2UgbWV0aG9kcyByZXF1aXJlIHRoYXQgbG9jYWwgbWFp
bCBkZWxpdmVyeSBhbmQgY2xpZW50IHByb2dyYW1zDQogKiB1c2UgdGhlIHNh
bWUgYWxnb3JpdGhtLiAgT25seSBvbmUgbWV0aG9kIHRvIGEgY3VzdG9tZXIg
Oi0pDQogKi8NCg0KI2lmIChIQVNIX1NQT09MID09IDEpDQoNCmludA0KZ2Vu
cGF0aChwKQ0KUE9QICpwOw0Kew0KICAgIGludCBzZWVkID0gMDsNCiAgICBj
aGFyIGRpcmNoYXJbNF07DQoNCiAgICBpZiAoIXAtPnVzZXIgfHwgKnAtPnVz
ZXIgPT0gJ1wwJykNCglyZXR1cm4oTlVMTCk7IC8qYm9ndXMgbG9naW4gbmFt
ZSovDQoNCiAgICAvKk5vdywgcGVyZm9ybSB0aGUgaGFzaCovDQoNCiAgICBz
d2l0Y2goc3RybGVuKHAtPnVzZXIpKSB7DQoJICAgY2FzZSAxOg0KCSAgIHNl
ZWQgPSAocC0+dXNlclswXSk7DQoJICAgYnJlYWs7DQoJICAgY2FzZSAyOg0K
CSAgIHNlZWQgPSAocC0+dXNlclswXSArIHAtPnVzZXJbMV0pOw0KCSAgIGJy
ZWFrOw0KCSAgIGNhc2UgMzoNCgkgICBzZWVkID0gKHAtPnVzZXJbMF0gKyBw
LT51c2VyWzFdICsgcC0+dXNlclsyXSk7DQoJICAgYnJlYWs7DQoJICAgY2Fz
ZSA0Og0KCSAgIHNlZWQgPSAocC0+dXNlclswXSArIHAtPnVzZXJbMV0gKyBw
LT51c2VyWzJdK3AtPnVzZXJbM10pOw0KCSAgIGJyZWFrOw0KCSAgIGRlZmF1
bHQ6DQoJICAgc2VlZCA9IChwLT51c2VyWzBdICsgcC0+dXNlclsxXSArIHAt
PnVzZXJbMl0rcC0+dXNlclszXStwLT51c2VyWzRdKTsNCgkgICBicmVhazsN
CiAgICB9DQogICAgZGlyY2hhclswXSA9ICcvJzsNCiAgICBkaXJjaGFyWzFd
ID0gKGNoYXIpKChzZWVkICUgMjYpICsgJ2EnKTsNCiAgICBkaXJjaGFyWzJd
ID0gJy8nOw0KICAgIGRpcmNoYXJbM10gPSAnXDAnOw0KICAgIHN0cm5jcHko
cC0+ZHJvcF9uYW1lLCBQT1BfTUFJTERJUiwgc2l6ZW9mKHAtPmRyb3BfbmFt
ZSkpOw0KICAgIHN0cm5jYXQocC0+ZHJvcF9uYW1lLCBkaXJjaGFyLCBzaXpl
b2YocC0+ZHJvcF9uYW1lKSAtIHN0cmxlbihwLT5kcm9wX25hbWUpKTsNCiAg
ICBzdHJuY2F0KHAtPmRyb3BfbmFtZSwgcC0+dXNlciwgc2l6ZW9mKHAtPmRy
b3BfbmFtZSkgLSBzdHJsZW4ocC0+ZHJvcF9uYW1lKSk7DQoNCiAgICByZXR1
cm4oMSk7DQp9DQoNCiNlbmRpZg0KI2lmIChIQVNIX1NQT09MID09IDIpDQoN
CmludA0KZ2VucGF0aChwKQ0KUE9QICpwOw0Kew0KICAgIHN0YXRpYyBjaGFy
IHBhdGhzdHJbMjU2XTsNCg0KICAgIGlmICghcC0+dXNlciB8fCAqcC0+dXNl
ciA9PSAnXDAnKQ0KCXJldHVybihOVUxMKTsNCiAgICANCiAgICBzcHJpbnRm
KHBhdGhzdHIsICIvJWMvJWMvJXMiLA0KCQkgICAgKnAtPnVzZXIsICoocC0+
dXNlcisxKSA/ICoocC0+dXNlcisxKSA6ICpwLT51c2VyLCBwLT51c2VyKTsN
Cg0KICAgIHN0cm5jcHkocC0+ZHJvcF9uYW1lLCBQT1BfTUFJTERJUiwgc2l6
ZW9mKHAtPmRyb3BfbmFtZSkpOw0KICAgIHN0cm5jYXQocC0+ZHJvcF9uYW1l
LCBwYXRoc3RyLCBzaXplb2YocC0+ZHJvcF9uYW1lKSAtIHN0cmxlbihwLT5k
cm9wX25hbWUpKTsNCg0KICAgIHJldHVybigxKTsNCn0NCg0KI2VuZGlmDQoj
aWYgKEhBU0hfU1BPT0wgIT0gMSAmJiBIQVNIX1NQT09MICE9IDIpDQoNCmlu
dA0KZ2VucGF0aChwKQ0KUE9QICpwOw0Kew0KICAgIHN0cnVjdCBwYXNzd2Qg
KnB3cDsNCg0KI2lmZGVmIEhPTUVESVJNQUlMDQogICAgaWYgKChwd3AgPSBn
ZXRwd25hbShwLT51c2VyKSkgPT0gTlVMTCkgew0KCXBvcF9sb2cocCwgUE9Q
X0ZBSUxVUkUsICJ1bmFibGUgdG8gcmV0cmlldmUgdXNlcnMgcGFzc3dvcmQg
ZW50cnkiKTsNCglyZXR1cm4oLTEpOw0KICAgIH0NCiAgICBzdHJuY3B5KHAt
PmRyb3BfbmFtZSwgcHdwLT5wd19kaXIsIHNpemVvZihwLT5kcm9wX25hbWUp
KTsNCiAgICBzdHJuY2F0KHAtPmRyb3BfbmFtZSwgIi8ubWFpbCIsc2l6ZW9m
KHAtPmRyb3BfbmFtZSkgLSBzdHJsZW4ocC0+ZHJvcF9uYW1lKSk7DQojZWxz
ZQ0KICAgIHN0cm5jcHkocC0+ZHJvcF9uYW1lLCBQT1BfTUFJTERJUiwgc2l6
ZW9mKHAtPmRyb3BfbmFtZSkpOw0KICAgIHN0cm5jYXQocC0+ZHJvcF9uYW1l
LCAiLyIsIHNpemVvZihwLT5kcm9wX25hbWUpIC0gc3RybGVuKHAtPmRyb3Bf
bmFtZSkpOw0KICAgIHN0cm5jYXQocC0+ZHJvcF9uYW1lLCBwLT51c2VyLCBz
aXplb2YocC0+ZHJvcF9uYW1lKSAtIHN0cmxlbihwLT5kcm9wX25hbWUpKTsN
CiNlbmRpZg0KDQogICAgcmV0dXJuKDEpOw0KfQ0KDQojZW5kaWYgLyogSEFT
SF9TUE9PTCAqLw0KDQogIA0KDQovKiANCiAqIEJ1aWxkIHRoZSBNc2dfaW5m
b19saXN0IGZyb20gdGhlIHRlbXBfZHJvcCBpbiBjYXNlIHRoZSBwcmV2aW91
cyBzZXNzaW9uDQogKiBmYWlsZWQgdG8gdHJ1bmNhdGUuIGluaXRfZHJvcGlu
Zm8gYW5kIGRvX2Ryb3BfY29weSBkaWZmZXIgaW4gdGhhdA0KICogZG9fZHJv
cF9jb3B5IHdvdWxkIGNvcHkgYWxsIHRoZSBtZXNzYWdlcyBmcm9tIHNvdXJj
ZSBmaWxlIHRvIGRlc3RpbmF0aW9uDQogKiBmaWxlIHdoaWxlIGl0IGdlbmVy
YXRlcyB0aGUgTXNnX2luZm9fbGlzdC4NCiAqLw0KaW50IGluaXRfZHJvcGlu
Zm8ocCkNClBPUCAqcDsNCnsNCiAgICBNc2dJbmZvTGlzdCAgICAgICAgICog
ICBtcDsgICAgICAgICAvKiBQb2ludGVyIHRvIG1lc3NhZ2UgaW5mbyBsaXN0
ICovDQogICAgaW50CQkJICAgIG1zZ19udW07CS8qIEN1cnJlbnQgbWVzc2Fn
ZSBudW1iZXIgKi8NCiAgICBpbnQJCQkgICAgbmNoYXI7DQogICAgaW50CQkJ
ICAgIGluaGVhZGVyOw0KICAgIGludAkJCSAgICB1aWRsX2ZvdW5kOw0KICAg
IGludAkJCSAgICBleHBlY3RpbmdfdHJhaWxlcjsNCiAgICBpbnQJCQkgICAg
Y29udGVudF9sZW5ndGgsIGNvbnRlbnRfbmNoYXIsIGNvbnRfbGVuOw0KICAg
IGNoYXIgICAgICAgICAgICAgICAgICAgIGJ1ZmZlcltNQVhMSU5FTEVOXTsJ
CS8qICBSZWFkIGJ1ZmZlciAqLw0KICAgIGNoYXIgICAgICAgICAgICAgICAg
ICAgIGZyb21idWZbTUFYTElORUxFTl07ICAgICAgICAvKiBGcm9tIEVudmVs
b3BlIG9mIGVhY2gNCgkJCQkJCQkgKiBtZXNzYWdlIGlzIHNhdmVkLCBmb3IN
CgkJCQkJCQkgKiBhZGRpbmcgaXQgdG8gVUlETA0KCQkJCQkJCSAqIGNvbXB1
dGF0aW9uICovDQogICAgTUQ1X0NUWAkJICAgIG1kQ29udGV4dDsNCiAgICB1
bnNpZ25lZCBjaGFyCSAgICBkaWdlc3RbMTZdOw0KICAgIGxvbmcgdW5pcXVl
X251bSA9IHRpbWUoMCk7DQoNCiAgICBERUJVR19MT0cxKHAsIkRST1BJTkZP
IENoZWNraW5nIGZvciBvbGQgLiVzLnBvcCBmaWxlIiwgcC0+dXNlcik7DQoN
Cg0KI2lmZGVmIE5VTExLTFVER0UNCiAgICB7DQoJLyogRWF0IE5VTExzIGF0
IHRoZSBiZWdpbm5pbmcgb2YgdGhlIG1haWxzcG9vbCAqLw0KCWNoYXIgdGVt
cGNoYXI7DQoJd2hpbGUgKCh0ZW1wY2hhciA9IGdldGMocC0+ZHJvcCkpID09
IDApOw0KCXVuZ2V0Yyh0ZW1wY2hhciwgcC0+ZHJvcCk7DQogICAgfQ0KI2Vu
ZGlmDQoNCiAgICBpZiAobWZnZXRzKGJ1ZmZlciwgTUFYTVNHTElORUxFTiwg
cC0+ZHJvcCkgPT0gTlVMTCkgew0KCURFQlVHX0xPRzEocCwgIkRyb3AgZmls
ZSBlbXB0eSBpbnRpYWxseSA6ICVzIiwgcC0+dGVtcF9kcm9wKTsNCglyZXR1
cm4oUE9QX1NVQ0NFU1MpOyAgICANCiAgICB9DQoNCiAgICAvKiBJcyB0aGlz
IGFuIE1NREYgZmlsZT8gKi8NCiAgICBpZiAoKmJ1ZmZlciA9PSBNTURGX1NF
UF9DSEFSKSB7DQoJcC0+bW1kZl9zZXBhcmF0b3IgPSAoY2hhciAqKXN0cmR1
cChidWZmZXIpOw0KICAgIH0gZWxzZSBpZiAoIWlzZnJvbWxpbmUoYnVmZmVy
KSkgew0KCXJldHVybiBwb3BfbXNnIChwLFBPUF9GQUlMVVJFLA0KCSAgIlVu
YWJsZSB0byBwcm9jZXNzIEZyb20gbGluZXMgKGVudmVsb3BlcykgaW4gJXMu
IixwLT50ZW1wX2Ryb3ApOw0KICAgIH0NCg0KICAgIG5ld2xpbmUgPSAxOw0K
ICAgIHJld2luZChwLT5kcm9wKTsNCg0KICAgIGluaGVhZGVyID0gMDsNCiAg
ICBtc2dfbnVtID0gMDsNCiAgICB1aWRsX2ZvdW5kID0gMDsNCiAgICBleHBl
Y3RpbmdfdHJhaWxlciA9IDA7DQogICAgY29udGVudF9sZW5ndGggPSAwOw0K
ICAgIGNvbnRlbnRfbmNoYXIgPSAwOw0KICAgIGNvbnRfbGVuID0gMDsNCiAg
ICBwLT5tc2dfY291bnQgPSBBTExPQ19NU0dTOw0KDQoNCiNpZmRlZiBOVUxM
S0xVREdFDQogICAgew0KCS8qIEVhdCBOVUxMcyBhdCB0aGUgYmVnaW5uaW5n
IG9mIHRoZSBtYWlsc3Bvb2wgKi8NCgljaGFyIHRlbXBjaGFyOw0KCXdoaWxl
ICgodGVtcGNoYXIgPSBnZXRjKHAtPmRyb3ApKSA9PSAwKTsNCgl1bmdldGMo
dGVtcGNoYXIsIHAtPmRyb3ApOw0KICAgIH0NCiNlbmRpZg0KDQogICAgREVC
VUdfTE9HMShwLCJCdWlsZGluZyB0aGUgTWVzc2FnZSBJbmZvcm1hdGlvbiBs
aXN0IGZyb20gJXMiLHAtPnRlbXBfZHJvcCk7DQoNCiAgICBmb3IgKG1wPXAt
Pm1scCAtIDE7IG1mZ2V0cyhidWZmZXIsIE1BWE1TR0xJTkVMRU4sIHAtPmRy
b3ApOykgew0KCW5jaGFyID0gc3RybGVuKGJ1ZmZlcik7DQoNCglpZiAoKGNv
bnRlbnRfbmNoYXIgPj0gY29udGVudF9sZW5ndGgpICYmDQoJICAgIChwLT5t
bWRmX3NlcGFyYXRvciA/ICFzdHJjbXAocC0+bW1kZl9zZXBhcmF0b3IsIGJ1
ZmZlcikgOg0KCSAgICBpc2Zyb21saW5lKGJ1ZmZlcikpKSB7DQogICAgICAg
ICAgICAvKiAtLS0tIEEgbWVzc2FnZSBib3VuZGFyeSAtLS0tLSAqLw0KICAg
ICAgICAgICAgLyogLS0tLSBUaWR5IHVwIHByZXZpb3VzIG1lc3NhZ2UgKGlm
IHRoZXJlIHdhcyBvbmUpIC0tLS0gKi8NCgkgICAgaWYgKGV4cGVjdGluZ190
cmFpbGVyKSB7DQoJCS8qIHNraXAgb3ZlciB0aGUgTU1ERiB0cmFpbGVyICov
DQoJCWV4cGVjdGluZ190cmFpbGVyID0gMDsNCgkJY29udGludWU7DQoJICAg
IH0NCg0KCSAgICBpZighcC0+bW1kZl9zZXBhcmF0b3IpIHsNCgkJc3RyY3B5
KGZyb21idWYsYnVmZmVyKTsgLyogUHJlc2VydmVkIEZyb20gZW52ZWxvcGUg
Ki8NCgkgICAgfQ0KICAgICAgICAgICAgLyogLS0tLS0tIEdldCByZWFkeSBm
b3IgdGhlIG5leHQgbWVzc2FnZSAtLS0tLSAqLw0KCSAgICBNRDVJbml0ICgm
bWRDb250ZXh0KTsNCgkgICAgTUQ1VXBkYXRlKCZtZENvbnRleHQsKHVuc2ln
bmVkIGNoYXIgKilidWZmZXIsc3RybGVuKGJ1ZmZlcikpOw0KICAgICAgICAg
ICAgLyogSW5jbHVkZSBhIHVuaXF1ZSBudW1iZXIgaW4gY2FzZSBldmVyeXRo
aW5nIGVsc2UgaXMgbm90ICovDQogICAgICAgICAgICB1bmlxdWVfbnVtKys7
DQogICAgICAgICAgICBNRDVVcGRhdGUoJm1kQ29udGV4dCwodW5zaWduZWQg
Y2hhciAqKSZ1bmlxdWVfbnVtLCBzaXplb2YobG9uZykpOw0KDQoJICAgIGlm
ICghaW5oZWFkZXIpIHsNCgkJaWYgKCsrbXNnX251bSA+IHAtPm1zZ19jb3Vu
dCkgew0KCQkgICAgcC0+bWxwID0gKE1zZ0luZm9MaXN0ICopIHJlYWxsb2Mo
cC0+bWxwLA0KCQkJKHAtPm1zZ19jb3VudCArPSBBTExPQ19NU0dTKSAqIHNp
emVvZihNc2dJbmZvTGlzdCkpOw0KCQkgICAgaWYgKHAtPm1scCA9PSBOVUxM
KXsNCgkJCXAtPm1zZ19jb3VudCA9IDA7DQoJCQlyZXR1cm4gcG9wX21zZyAo
cCwgUE9QX0ZBSUxVUkUsDQoJCQkgICAgIkNhbid0IGJ1aWxkIG1lc3NhZ2Ug
bGlzdCBmb3IgJyVzJzogT3V0IG9mIG1lbW9yeSIsDQoJCQkJICAgIHAtPnVz
ZXIpOw0KCQkgICAgfQ0KCQkgICAgbXAgPSBwLT5tbHAgKyBtc2dfbnVtIC0g
MjsNCgkJfQ0KCQlpZihtc2dfbnVtICE9IDEpew0KCQkgICAgREVCVUdfTE9H
NShwLCJNc2cgJWQgdWlkbCAlcyBhdCBvZmZzZXQgJWQgaXMgJWQgb2N0ZXRz
IGxvbmcgYW5kIGhhcyAldSBsaW5lcy4iLA0KCQkJICAgICAgIG1wLT5udW1i
ZXIsIG1wLT51aWRsX3N0ciwgbXAtPm9mZnNldCwgDQoJCQkgICAgICAgbXAt
Pmxlbmd0aCwgbXAtPmxpbmVzKTsNCgkJfQ0KCQllbHNlDQoJCSAgICBwb3Bf
bG9nKHAsUE9QX0RFQlVHLCAiRm91bmQgdG9wIG9mIGZpcnN0IG1lc3NhZ2Ui
KTsNCgkJKyttcDsNCg0KCSAgICB9IA0KCSAgICBlbHNlIHsgDQoJCXBvcF9s
b2cocCxQT1BfREVCVUcsDQoJCSAgICAiTXNnICVkIGNvcnJ1cHRlZCwgaWdu
b3JpbmcgcHJldmlvdXMgaGVhZGVyIGluZm9ybWF0aW9uLiIsDQoJCSAgICAg
bXAtPm51bWJlcik7DQoJICAgIH0NCgkgICAgbXAtPm51bWJlciA9IG1zZ19u
dW07DQoJICAgIG1wLT5sZW5ndGggPSAwOw0KCSAgICBtcC0+bGluZXMgPSAw
Ow0KCSAgICBtcC0+Ym9keV9saW5lcyA9IDA7DQoJICAgIG1wLT5vZmZzZXQg
PSBmdGVsbChwLT5kcm9wKSAtIG5jaGFyOw0KCSAgICBtcC0+ZGVsX2ZsYWcg
PSBGQUxTRTsNCgkgICAgbXAtPnJldHJfZmxhZyA9IEZBTFNFOw0KCSAgICBt
cC0+b3JpZ19yZXRyX3N0YXRlID0gRkFMU0U7DQoJICAgIG1wLT51aWRsX3N0
ciA9ICJcbiI7DQoJICAgIERFQlVHX0xPRzEocCwiTXNnICVkIGJlaW5nIGFk
ZGVkIHRvIGxpc3QgJXgiLCBtcC0+bnVtYmVyKTsNCgkgICAgaW5oZWFkZXIg
PSAxOw0KCSAgICB1aWRsX2ZvdW5kID0gMDsNCgkgICAgY29udGVudF9uY2hh
ciA9IDA7DQoJICAgIGNvbnRlbnRfbGVuZ3RoID0gMDsNCgkgICAgY29udF9s
ZW4gPSAwOw0KCSAgICBpZiAocC0+bW1kZl9zZXBhcmF0b3IpDQoJCWV4cGVj
dGluZ190cmFpbGVyID0gMTsNCg0KCSAgICBjb250aW51ZTsJLyogRG9uJ3Qg
Y291bnQgbWVzc2FnZSBzZXBhcmF0b3IgaW4gdG90YWwgc2l6ZSAqLw0KCX0N
CgkNCglpZiAoaW5oZWFkZXIpIHsNCgkgICAgaWYgKCpidWZmZXIgPT0gJ1xu
Jykgew0KCQlpbmhlYWRlciA9IDA7DQoJCWNvbnRlbnRfbGVuZ3RoID0gY29u
dF9sZW47DQoJCW1wLT5ib2R5X2xpbmVzID0gMTsgIC8qIENvdW50IG5ld2xp
bmUgYXMgdGhlIGZpcnN0IGJvZHkgbGluZSAqLw0KCQlpZiAoIXVpZGxfZm91
bmQpIHsNCgkJICAgIGNoYXIJKmNwOw0KCQkgICAgaW50CQlpOw0KDQoJCSAg
ICBNRDVVcGRhdGUoJm1kQ29udGV4dCwgKHVuc2lnbmVkIGNoYXIgKilmcm9t
YnVmLCANCgkJCSAgICAgIHN0cmxlbihmcm9tYnVmKSk7DQoJCSAgICBNRDVG
aW5hbCAoZGlnZXN0LCAmbWRDb250ZXh0KTsNCgkJICAgIGNwID0gbXAtPnVp
ZGxfc3RyID0gKGNoYXIgKiltYWxsb2MoKERJR19TSVpFICogMikgKyAyKTsN
CgkJICAgIGNwID0gYmFzZTgwKGNwLCBkaWdlc3QpOw0KCQkgICAgKmNwKysg
PSAnXG4nOw0KCQkgICAgKmNwICAgPSAnXDAnOw0KDQoJCSAgICBtcC0+bGVu
Z3RoICs9IHN0cmxlbigiWC1VSURMOiAiKSArIHN0cmxlbihtcC0+dWlkbF9z
dHIpICsgMTsNCgkJICAgIHAtPmRyb3Bfc2l6ZSArPSBzdHJsZW4oIlgtVUlE
TDogIikgKyBzdHJsZW4obXAtPnVpZGxfc3RyKSsxOw0KDQoJLyogTmV3IFVJ
RHMgZG8gbm90IGRpcnR5IHRoZSBtYWlsc3Bvb2wgaWYgTk9fU1RBVFVTIGlz
IHNldC4gIFRoZXkNCgkgICBhcmUganVzdCByZWNhbGN1bGF0ZWQgZWFjaCB0
aW1lIHRoZSBwb3BwZXIgaXMgcnVuIG9yIExNT1MgaXMNCgkgICBzZXQgYW5k
IHRoZSBtYWlsIHNwb29sIGlzIHVwZGF0ZWQuDQoJICovDQojaWZuZGVmIE5P
X1NUQVRVUw0KCQkgICAgcC0+ZGlydHkgPSAxOw0KI2VuZGlmDQoJCX0NCg0K
CSAgICB9IGVsc2UgaWYgKENPTlRFTlRfTEVOR1RIICYmICFzdHJuY21wKGJ1
ZmZlciwgIkNvbnRlbnQtTGVuZ3RoOiIsIDE1KSkgew0KCQljb250X2xlbiA9
IGF0b2koYnVmZmVyICsgMTUpOw0KCQlNRDVVcGRhdGUoJm1kQ29udGV4dCwo
dW5zaWduZWQgY2hhciAqKWJ1ZmZlcixzdHJsZW4oYnVmZmVyKSk7DQoJCW1w
LT5saW5lcysrOw0KCQljb250aW51ZTsJLyogbm90IHBhcnQgb2YgdGhlIG1l
c3NhZ2Ugc2l6ZSAqLw0KCSAgICB9IGVsc2UgaWYgKCF1aWRsX2ZvdW5kICYm
ICghc3RybmNhc2VjbXAoIlJlY2VpdmVkOiIsIGJ1ZmZlciwgOSkgfHwNCgkJ
CQkgICAgICAgIXN0cm5jYXNlY21wKCJEYXRlOiIsIGJ1ZmZlciwgNSkgfHwN
CgkJCQkgICAgICAgIXN0cm5jYXNlY21wKCJNZXNzYWdlLUlkOiIsYnVmZmVy
LCAxMSkgfHwNCgkJCQkgICAgICAgIXN0cm5jYXNlY21wKCJTdWJqZWN0OiIs
YnVmZmVyLCA4KQ0KCQkJCSAgICAgICApKSB7DQoJCU1ENVVwZGF0ZSgmbWRD
b250ZXh0LCh1bnNpZ25lZCBjaGFyICopYnVmZmVyLHN0cmxlbihidWZmZXIp
KTsNCgkgICAgfSBlbHNlIGlmICghc3RybmNhc2VjbXAoIlgtVUlETDoiLCBi
dWZmZXIsIDcpKSB7DQoJCWlmICghdWlkbF9mb3VuZCkgew0KCQkgICAgY2hh
ciAqY3A7DQoJCSAgICBpbnQgbGVuOw0KDQoJCSAgICAvKiBTa2lwIG92ZXIg
aGVhZGVyIHN0cmluZyAqLw0KCQkgICAgY3AgPSBidWZmZXI7DQoJCSAgICBp
ZiAoY3AgPSBpbmRleChidWZmZXIsICc6JykpIHsNCgkJCWNwKys7DQoJCQl3
aGlsZSAoKmNwICYmICgqY3AgPT0gJyAnIHx8ICpjcCA9PSAnXHQnKSkgY3Ar
KzsNCgkJICAgIH0gZWxzZQ0KCQkJY3AgPSAiIjsNCg0KCQkgICAgaWYoIChs
ZW4gPSBzdHJsZW4oY3ApKSA+IE1JTl9VSURMX0xFTkdUSCAmJiBsZW4gPCBN
QVhfVUlETF9MRU5HVEggKSB7DQoJCQl1aWRsX2ZvdW5kKys7DQoJCQltcC0+
dWlkbF9zdHIgPSAoY2hhciAqKXN0cmR1cChjcCk7DQoJCQltcC0+bGVuZ3Ro
ICs9IG5jaGFyICsgMTsNCgkJCXAtPmRyb3Bfc2l6ZSArPSBuY2hhciArIDE7
DQoJCSAgICB9DQoJCX0NCgkJbXAtPmxpbmVzKys7DQoJCWNvbnRpbnVlOyAg
LyogRG8gbm90IGluY2x1ZGUgdGhpcyB2YWx1ZSBpbiB0aGUgbWVzc2FnZSBz
aXplICovDQoJICAgIH0gZWxzZSBpZiAoKHN0cm5jYXNlY21wKGJ1ZmZlciwi
U3RhdHVzOiIsNykgPT0gMCkpIHsNCgkJaWYgKGluZGV4KGJ1ZmZlciwgJ1In
KSAhPSBOVUxMKSB7DQoJCSAgICBtcC0+cmV0cl9mbGFnID0gVFJVRTsNCgkJ
ICAgIG1wLT5vcmlnX3JldHJfc3RhdGUgPSBUUlVFOw0KCQl9DQoJICAgIH0N
Cgl9IGVsc2Ugew0KCSAgICBjb250ZW50X25jaGFyICs9IG5jaGFyOw0KCSAg
ICBtcC0+Ym9keV9saW5lcysrOw0KCX0NCiAgICAgICANCgltcC0+bGVuZ3Ro
ICs9IG5jaGFyICsgMTsNCglwLT5kcm9wX3NpemUgKz0gbmNoYXIgKyAxOw0K
CW1wLT5saW5lcysrOw0KICAgIH0NCg0KICAgIHAtPm1zZ19jb3VudCA9IG1z
Z19udW07DQoNCiAgICByZXR1cm4oUE9QX1NVQ0NFU1MpOw0KfQ0KDQoNCi8q
IA0KICogIHVzZSB0byBiZSBkcm9waW5mbzogICBFeHRyYWN0IGluZm9ybWF0
aW9uIGFib3V0IHRoZSBQT1AgbWFpbGRyb3AgYW5kIHN0b3JlIA0KICogIGl0
IGZvciB1c2UgYnkgdGhlIG90aGVyIFBPUCByb3V0aW5lcy4NCiAqDQogKiAg
Tm93LCB0aGUgY29weSBhbmQgaW5mbyBjb2xsZWN0aW9uIGFyZSBkb25lIGF0
IHRoZSBzYW1lIHRpbWUuDQogKi8NCg0KZG9fZHJvcF9jb3B5KHAsIG1mZCwg
ZGZkKQ0KaW50CW1mZCwgZGZkOw0KUE9QCSpwOw0Kew0KICAgIGNoYXIgICAg
ICAgICAgICAgICAgICAgIGJ1ZmZlcltNQVhMSU5FTEVOXTsgICAgIC8qICBS
ZWFkIGJ1ZmZlciAqLw0KICAgIGNoYXIgICAgICAgICAgICAgICAgICAgIGZy
b21idWZbTUFYTElORUxFTl07ICAgIC8qICBUbyBzYXZlIEZyb20gRW52ZWxv
cGUgKi8NCiAgICBNc2dJbmZvTGlzdCAgICAgICAgICogICBtcDsgICAgICAg
ICAgICAgICAgICAgICAvKiAgUG9pbnRlciB0byBtZXNzYWdlIA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBpbmZvIGxpc3QgKi8NCiAgICBpbnQgICAgICAgICAgICAgICAgICAg
ICBuY2hhcjsgICAgICAgICAgICAgICAgICAvKiAgQnl0ZXMgd3JpdHRlbi9y
ZWFkICovDQogICAgaW50CQkJICAgIGluaGVhZGVyOwkJICAgIC8qICBIZWFk
ZXIgc2VjdGlvbiBmbGFnICovDQogICAgaW50CQkJICAgIHVpZGxfZm91bmQ7
CQkgICAgLyogIFVJREwgaGVhZGVyIGZsYWcgKi8NCiAgICBpbnQJCQkgICAg
bXNnX251bTsNCiAgICBpbnQJCQkgICAgZXhwZWN0aW5nX3RyYWlsZXI7DQog
ICAgaW50CQkJICAgIGNvbnRlbnRfbGVuZ3RoLCBjb250ZW50X25jaGFyLCBj
b250X2xlbjsNCiAgICBNRDVfQ1RYCQkgICAgbWRDb250ZXh0Ow0KICAgIHVu
c2lnbmVkIGNoYXIJICAgIGRpZ2VzdFsxNl07DQogICAgaW50ICAgICAgICAg
ICAgICAgICAgICAgbWFuZ2xlZF9vbmU7DQogICAgRklMRQkJICAgICptYWls
X2Ryb3A7CQkgICAgLyogIFN0cmVhbXMgZm9yIGZpZHMgKi8NCiAgICBsb25n
IHVuaXF1ZV9udW0gPSB0aW1lKDApOw0KDQogICAgREVCVUdfTE9HMChwLCJE
Uk9QQ09QWTogUmVhZGluZyB0aGUgTWFpbCBEcm9wIGJveC4iKTsNCiAgICAv
KiAgQWNxdWlyZSBhIHN0cmVhbSBwb2ludGVyIGZvciB0aGUgbWFpbGRyb3Ag
Ki8NCiAgICBpZiAoIChtYWlsX2Ryb3AgPSBmZG9wZW4obWZkLCJyIikpID09
IE5VTEwgKSB7DQogICAgICAgIHJldHVybiBwb3BfbXNnKHAsUE9QX0ZBSUxV
UkUsIkNhbm5vdCBhc3NpZ24gc3RyZWFtIGZvciAlcyAoJWQpIiwNCgkJICAg
ICAgIHAtPmRyb3BfbmFtZSwgZXJybm8pOw0KICAgIH0NCg0KICAgIHJld2lu
ZCAobWFpbF9kcm9wKTsNCiNpZmRlZiBOVUxMS0xVREdFDQogICAgey8qIEVh
dCBOVUxMcyBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBtYWlsc3Bvb2wgKi8N
CiAgICAgICAgY2hhciB0ZW1wY2hhciA7DQoJd2hpbGUgKCh0ZW1wY2hhciA9
IGdldGMocC0+ZHJvcCkpID09IDApOw0KCXVuZ2V0Yyh0ZW1wY2hhciwgcC0+
ZHJvcCk7DQogICAgfQ0KI2VuZGlmDQogICAgaWYgKG1mZ2V0cyhidWZmZXIs
IE1BWE1TR0xJTkVMRU4sIG1haWxfZHJvcCkgPT0gTlVMTCkgew0KCXJldHVy
bihQT1BfU1VDQ0VTUyk7DQogICAgfQ0KDQogICAgLyogSXMgdGhpcyBhbiBN
TURGIGZpbGU/ICovDQogICAgaWYgKCpidWZmZXIgPT0gTU1ERl9TRVBfQ0hB
Uikgew0KCWlmICghcC0+bW1kZl9zZXBhcmF0b3IpDQoJICAgIHAtPm1tZGZf
c2VwYXJhdG9yID0gKGNoYXIgKilzdHJkdXAoYnVmZmVyKTsNCiAgICB9IGVs
c2UgaWYgKCFpc2Zyb21saW5lKGJ1ZmZlcikpIHsNCglERUJVR19MT0cxKHAs
ImJ1ZmZlciBjaGVja2VkICVzIiwgYnVmZmVyKTsNCglyZXR1cm4gcG9wX21z
ZyAocCxQT1BfRkFJTFVSRSwNCgkgIlVuYWJsZSB0byBwcm9jZXNzIEZyb20g
bGluZXMgKGVudmVsb3BlcyksIGNoYW5nZSByZWNvZ25pdGlvbiBtb2Rlcy4i
KTsNCiAgICB9DQoNCiAgICBuZXdsaW5lID0gMTsNCiAgICByZXdpbmQgKG1h
aWxfZHJvcCk7DQoNCiAgICAvKiAgU2NhbiB0aGUgZmlsZSwgbG9hZGluZyB0
aGUgbWVzc2FnZSBpbmZvcm1hdGlvbiBsaXN0IHdpdGggDQogICAgICAgIGlu
Zm9ybWF0aW9uIGFib3V0IGVhY2ggbWVzc2FnZSAqLw0KDQogICAgaW5oZWFk
ZXIgPSAwOw0KICAgIHVpZGxfZm91bmQgPSAwOw0KICAgIGV4cGVjdGluZ190
cmFpbGVyID0gMDsNCiAgICBtc2dfbnVtID0gcC0+bXNnX2NvdW50Ow0KICAg
IGNvbnRlbnRfbGVuZ3RoID0gMDsNCiAgICBjb250ZW50X25jaGFyID0gMDsN
CiAgICBjb250X2xlbiA9IDA7DQogICAgbWFuZ2xlZF9vbmUgPSAwOw0KICAg
IHAtPm1zZ19jb3VudCA9ICgoKHAtPm1zZ19jb3VudCAtIDEpIC8gQUxMT0Nf
TVNHUykgKyAxKSAqIEFMTE9DX01TR1M7DQojaWZkZWYgTlVMTEtMVURHRQ0K
ICAgIHsvKiBFYXQgTlVMTHMgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgbWFp
bHNwb29sIGlmIGFueS4qLw0KCWNoYXIgdGVtcGNoYXI7DQoJd2hpbGUgKCh0
ZW1wY2hhciA9IGdldGMocC0+ZHJvcCkpID09IDApOw0KCXVuZ2V0Yyh0ZW1w
Y2hhciwgcC0+ZHJvcCk7DQogICAgfQ0KI2VuZGlmDQogICAgZm9yIChtcCA9
IHAtPm1scCArIG1zZ19udW0gLSAxOyBtZmdldHMoYnVmZmVyLE1BWE1TR0xJ
TkVMRU4sbWFpbF9kcm9wKTspIHsNCg0KCW5jaGFyID0gc3RybGVuKGJ1ZmZl
cik7DQoNCglpZiAoZnB1dHMoYnVmZmVyLCBwLT5kcm9wKSA9PSBFT0YpIHsN
CgkgICAgaWYgKGVycm5vID09IEVEUVVPVCkNCgkJcmV0dXJuIHBvcF9tc2cg
KHAsUE9QX0ZBSUxVUkUsDQoJCSAgICAiVW5hYmxlIHRvIGNvcHkgbWFpbCBz
cG9vbCBmaWxlLCBxdW90YSBleGNlZWRlZCAoJWQpIiwNCgkJCWVycm5vKTsN
CgkgICAgcmV0dXJuIHBvcF9tc2cgKHAsUE9QX0ZBSUxVUkUsDQoJCSJVbmFi
bGUgdG8gY29weSBtYWlsIHNwb29sIGZpbGUgdG8gdGVtcCBwb3AgZHJvcGJv
eCAlcyAoJWQpIiwNCgkJICAgIHAtPnRlbXBfZHJvcCwgZXJybm8pOw0KCX0N
CgkvKiBFbmQgb2YgcHJldmlvdXMgbWVzc2FnZSAqLw0KCWlmICgoY29udGVu
dF9uY2hhciA+PSBjb250ZW50X2xlbmd0aCkgJiYNCgkgICAgKHAtPm1tZGZf
c2VwYXJhdG9yID8gIXN0cmNtcChwLT5tbWRmX3NlcGFyYXRvciwgYnVmZmVy
KSA6DQoJICAgIGlzZnJvbWxpbmUoYnVmZmVyKSkpIHsNCiAgICAgICAgICAg
IC8qPT09IE1hdGNoZWQgc2VwYXJhdG9yLCB0aWUgb2YgbGFzdCBtZXNzYWdl
LCBzdGFydCBuZXcgb25lID09PSovDQoNCg0KCSAgICBpZiAoZXhwZWN0aW5n
X3RyYWlsZXIpIHsNCgkJZXhwZWN0aW5nX3RyYWlsZXIgPSAwOw0KCQljb250
aW51ZTsNCgkgICAgfQ0KDQoJICAgIGlmKCAhcC0+bW1kZl9zZXBhcmF0b3Ig
KSB7DQoJCXN0cmNweShmcm9tYnVmLCBidWZmZXIpOw0KCSAgICB9DQoNCiAg
ICAgICAgICAgIC8qPT09IFN0YXJ0aW5nIG5ldyBtZXNzYWdlID09PSovDQoJ
ICAgIE1ENUluaXQgKCZtZENvbnRleHQpOw0KCSAgICBNRDVVcGRhdGUoJm1k
Q29udGV4dCwodW5zaWduZWQgY2hhciAqKWJ1ZmZlcixzdHJsZW4oYnVmZmVy
KSk7DQogICAgICAgICAgICAvKiBJbmNsdWRlIGEgdW5pcXVlIG51bWJlciBp
biBjYXNlIGV2ZXJ5dGhpbmcgZWxzZSBpcyBub3QgKi8NCiAgICAgICAgICAg
IHVuaXF1ZV9udW0rKzsNCiAgICAgICAgICAgIE1ENVVwZGF0ZSgmbWRDb250
ZXh0LCh1bnNpZ25lZCBjaGFyICopJnVuaXF1ZV9udW0sIHNpemVvZihsb25n
KSk7DQoNCgkgICAgaWYgKCFpbmhlYWRlcikgew0KCQlpZiAoKyttc2dfbnVt
ID4gcC0+bXNnX2NvdW50KSB7DQoJCSAgICBwLT5tbHA9KE1zZ0luZm9MaXN0
ICopIHJlYWxsb2MocC0+bWxwLA0KCQkJKHAtPm1zZ19jb3VudCs9QUxMT0Nf
TVNHUykqc2l6ZW9mKE1zZ0luZm9MaXN0KSk7DQoJCSAgICBpZiAocC0+bWxw
ID09IE5VTEwpIHsNCgkJCXAtPm1zZ19jb3VudCA9IDA7DQoJCQlyZXR1cm4g
cG9wX21zZyAocCxQT1BfRkFJTFVSRSwNCgkJCSAgICAiQ2FuJ3QgYnVpbGQg
bWVzc2FnZSBsaXN0IGZvciAnJXMnOiBPdXQgb2YgbWVtb3J5IiwNCgkJCQlw
LT51c2VyKTsNCgkJICAgIH0NCgkJICAgIG1wID0gcC0+bWxwICsgbXNnX251
bSAtIDI7DQoJCX0NCgkJaWYoIG1zZ19udW0gIT0gMSkNCgkJICAgIERFQlVH
X0xPRzUocCwiTXNnICVkIHVpZGwgJXMgYXQgb2Zmc2V0ICVkIGlzICVkIG9j
dGV0cyBsb25nIGFuZCBoYXMgJXUgbGluZXMuIiwNCgkJCSAgICAgIG1wLT5u
dW1iZXIsbXAtPnVpZGxfc3RyLG1wLT5vZmZzZXQsbXAtPmxlbmd0aCwNCgkJ
CSAgICAgIG1wLT5saW5lcyk7DQoJCSsrbXA7DQoNCgkgICAgfSBlbHNlIHsN
CgkJcG9wX2xvZyhwLFBPUF9ERUJVRywiTXNnICVkIGNvcnJ1cHRlZCwgaWdu
b3JpbmcgcHJldmlvdXMgaGVhZGVyIGluZm9ybWF0aW9uLiIsDQoJCSAgICAg
bXAtPm51bWJlcik7DQoJICAgIH0NCg0KICAgICAgICAgICAgbXAtPm51bWJl
ciA9IG1zZ19udW07DQogICAgICAgICAgICBtcC0+bGVuZ3RoID0gMDsNCiAg
ICAgICAgICAgIG1wLT5saW5lcyA9IDA7DQogICAgICAgICAgICBtcC0+Ym9k
eV9saW5lcyA9IDA7DQogICAgICAgICAgICBtcC0+b2Zmc2V0ID0gZnRlbGwo
cC0+ZHJvcCkgLSBuY2hhcjsNCiAgICAgICAgICAgIG1wLT5kZWxfZmxhZyA9
IEZBTFNFOw0KICAgICAgICAgICAgbXAtPnJldHJfZmxhZyA9IEZBTFNFOw0K
ICAgICAgICAgICAgbXAtPm9yaWdfcmV0cl9zdGF0ZSA9IEZBTFNFOw0KCSAg
ICBtcC0+dWlkbF9zdHIgPSAiXG4iOw0KDQoJICAgIERFQlVHX0xPRzEocCwi
TXNnICVkIGJlaW5nIGFkZGVkIHRvIGxpc3QuIiwgbXAtPm51bWJlcik7DQoJ
ICAgIGluaGVhZGVyID0gMTsNCgkgICAgY29udGVudF9sZW5ndGggPSAwOw0K
CSAgICBjb250ZW50X25jaGFyID0gMDsNCgkgICAgY29udF9sZW4gPSAwOw0K
CSAgICB1aWRsX2ZvdW5kID0gMDsNCgkgICAgaWYgKHAtPm1tZGZfc2VwYXJh
dG9yKQ0KCQlleHBlY3RpbmdfdHJhaWxlciA9IDE7DQoNCg0KCSAgICBjb250
aW51ZTsJLyogRG8gbm90IGluY2x1ZGUgRnJvbSBzZXBhcmF0b3IgaW4gbWVz
c2FnZSBzaXplICovDQogICAgICAgIH0NCg0KICAgICAgICAvKiA9PT09PT0g
SGFuZGxlIGhlYWRlciBhbmQgYm9keSBvZiBtZXNzYWdlIGhlcmUgPT09PSAq
Lw0KCWlmIChpbmhlYWRlcikgew0KICAgICAgICAgICAgLyogPT09PT0gSGFu
ZGxlIHRoZSBoZWFkZXIgb2YgYSBtZXNzYWdlID09PT0gKi8NCgkgICAgaWYg
KCpidWZmZXIgPT0gJ1xuJykgew0KICAgICAgICAgICAgICAgIC8qID09PSBF
bmNvdW50ZXJlZCB0cmFuc2l0aW9uIHRvIGJvZHkgPT09PSovDQoJCWluaGVh
ZGVyID0gMDsNCgkJbXAtPmJvZHlfbGluZXMgPSAxOw0KCQljb250ZW50X2xl
bmd0aCA9IGNvbnRfbGVuOw0KDQoJCWlmICghdWlkbF9mb3VuZCkgew0KCQkg
ICAgY2hhciAqY3A7DQoJCSAgICBpbnQgIGk7DQoNCgkJICAgIE1ENVVwZGF0
ZSgmbWRDb250ZXh0LCAodW5zaWduZWQgY2hhciAqKWZyb21idWYsDQoJCQkg
ICAgICBzdHJsZW4oZnJvbWJ1ZikpOw0KCQkgICAgTUQ1RmluYWwgKGRpZ2Vz
dCwgJm1kQ29udGV4dCk7DQoJCSAgICBjcCA9IG1wLT51aWRsX3N0ciA9IChj
aGFyICopbWFsbG9jKChESUdfU0laRSAqIDIpICsgMik7DQogICAgICAgICAg
ICAgICAgICAgIGNwID0gYmFzZTgwKGNwLCBkaWdlc3QpOw0KCQkgICAgKmNw
KysgPSAnXG4nOw0KCQkgICAgKmNwICAgPSAnXDAnOw0KICAgICAgICAgICAg
ICAgICAgICBERUJVR19MT0cxKHAsICJVSURMIC0lcy0iLCBtcC0+dWlkbF9z
dHIpOw0KDQoJCSAgICBtcC0+bGVuZ3RoICs9IHN0cmxlbigiWC1VSURMOiAi
KSArIHN0cmxlbihtcC0+dWlkbF9zdHIpICsgMTsNCgkJICAgIHAtPmRyb3Bf
c2l6ZSArPSBzdHJsZW4oIlgtVUlETDogIikgKyBzdHJsZW4obXAtPnVpZGxf
c3RyKSsxOw0KDQogICAgICAgICAgICAgICAgICAgIC8qIE5ldyBVSURzIGRv
IG5vdCBkaXJ0eSB0aGUgbWFpbHNwb29sIGlmIE5PX1NUQVRVUyBpcw0KICAg
ICAgICAgICAgICAgICAgICAgICBzZXQuICBUaGV5IGFyZSBqdXN0IHJlY2Fs
Y3VsYXRlZCBlYWNoIHRpbWUgdGhlDQogICAgICAgICAgICAgICAgICAgICAg
IHBvcHBlciBpcyBydW4gb3IgTE1PUyBpcyBzZXQgYW5kIHRoZSBtYWlsIHNw
b29sDQogICAgICAgICAgICAgICAgICAgICAgIGlzIHVwZGF0ZWQuICovDQoj
aWZuZGVmIE5PX1NUQVRVUw0KCQkgICAgcC0+ZGlydHkgPSAxOw0KI2VuZGlm
DQoJCX0NCg0KCSAgICB9IGVsc2UgaWYoQ09OVEVOVF9MRU5HVEggJiYgIXN0
cm5jbXAoYnVmZmVyLCJDb250ZW50LUxlbmd0aDoiLDE1KSl7DQogICAgICAg
ICAgICAgICAgLyo9PT0gSGFuZGxlIGNvbnRlbnRfbGVuZ3RoIGlmIHdlIGRv
IHRoYXQgc29ydCBvZiB0aGluZyA9PT0qLw0KCQljb250X2xlbiA9IGF0b2ko
YnVmZmVyICsgMTUpOw0KCQlNRDVVcGRhdGUoJm1kQ29udGV4dCwodW5zaWdu
ZWQgY2hhciAqKWJ1ZmZlcixzdHJsZW4oYnVmZmVyKSk7DQoJCW1wLT5saW5l
cysrOw0KCQljb250aW51ZTsgIC8qIE5vdCBpbmNsdWRlZCBpbiBtZXNzYWdl
IHNpemUgKi8NCg0KCSAgICB9IGVsc2UgaWYgKCF1aWRsX2ZvdW5kICYmICgh
c3RybmNhc2VjbXAoIlJlY2VpdmVkOiIsIGJ1ZmZlciwgOSkgfHwNCgkJCQkg
ICAgICAgIXN0cm5jYXNlY21wKCJEYXRlOiIsIGJ1ZmZlciwgNSkgfHwNCgkJ
CQkgICAgICAgIXN0cm5jYXNlY21wKCJNZXNzYWdlLUlkOiIsYnVmZmVyLCAx
MSkgfHwNCgkJCQkgICAgICAgIXN0cm5jYXNlY21wKCJTdWJqZWN0OiIsYnVm
ZmVyLCA4KQ0KCQkJCSAgICAgICApKSB7DQogICAgICAgICAgICAgICAgLyog
PT09IEFjY3VtdWF0ZSBjZXJ0YWluIGhlYWRlciB3ZSBtaWdodCBzZWUgZm9y
IFVJREwgPT09Ki8NCgkJTUQ1VXBkYXRlKCZtZENvbnRleHQsKHVuc2lnbmVk
IGNoYXIgKilidWZmZXIsc3RybGVuKGJ1ZmZlcikpOw0KCSAgICB9IGVsc2Ug
aWYgKCFzdHJuY2FzZWNtcCgiWC1VSURMOiIsIGJ1ZmZlciwgNykpIHsNCiAg
ICAgICAgICAgICAgLyogPT09PSBEbyB0aGUgVUlETCBoZWFkZXIgPT09PSAq
Lw0KCQlpZiAoIXVpZGxfZm91bmQpIHsNCgkJICAgIGNoYXIgKmNwOw0KCQkg
ICAgaW50IGxlbjsNCg0KCQkgICAgLyogU2tpcCBvdmVyIGhlYWRlciAqLw0K
CQkgICAgY3AgPSBidWZmZXI7DQoJCSAgICBpZiAoY3AgPSBpbmRleChidWZm
ZXIsICc6JykpIHsNCgkJCWNwKys7DQoJCQl3aGlsZSAoKmNwICYmICgqY3Ag
PT0gJyAnIHx8ICpjcCA9PSAnXHQnKSkgY3ArKzsNCgkJICAgIH0gZWxzZQ0K
CQkJY3AgPSAiIjsNCg0KCQkgICAgaWYoIChsZW4gPSBzdHJsZW4oY3ApKSA+
IE1JTl9VSURMX0xFTkdUSCAmJiBsZW4gPCBNQVhfVUlETF9MRU5HVEggKSB7
DQoJCQl1aWRsX2ZvdW5kKys7DQoJCQltcC0+dWlkbF9zdHIgPSAoY2hhciAq
KXN0cmR1cChjcCk7DQoJCQltcC0+bGVuZ3RoICs9IG5jaGFyICsgMTsNCgkJ
CXAtPmRyb3Bfc2l6ZSArPSBuY2hhciArIDE7DQoJCSAgICB9DQoJCX0NCgkJ
bXAtPmxpbmVzKys7DQoJCWNvbnRpbnVlOyAgLyogRG8gbm90IGluY2x1ZGUg
dGhpcyB2YWx1ZSBpbiB0aGUgbWVzc2FnZSBzaXplICovDQoJICAgIH0gZWxz
ZSBpZiAoIXN0cm5jYXNlY21wKGJ1ZmZlciwiU3RhdHVzOiIsNykpIHsNCiAg
ICAgICAgICAgICAgICAvKiA9PT0gRG8gdGhlIHN0YXR1cyBoZWFkZXIgPT09
ICovDQoJCWlmIChpbmRleChidWZmZXIsICdSJykgIT0gTlVMTCkgew0KCQkg
ICAgbXAtPnJldHJfZmxhZyA9IFRSVUU7DQoJCSAgICBtcC0+b3JpZ19yZXRy
X3N0YXRlID0gVFJVRTsNCgkJfQ0KCSAgICB9DQoJfSBlbHNlIHsNCiAgICAg
ICAgICAgIC8qID09PT0gSGFuZGxlIHRoZSBib2R5IG9mIGEgbWVzc2FnZSAo
bm90IG11Y2ggdG8gZG8pID09PSAqLw0KCSAgICBjb250ZW50X25jaGFyICs9
IG5jaGFyOw0KCSAgICBtcC0+Ym9keV9saW5lcysrOw0KCX0NCg0KICAgICAg
ICBtcC0+bGVuZ3RoICs9IG5jaGFyICsgMTsNCiAgICAgICAgcC0+ZHJvcF9z
aXplICs9IG5jaGFyICsgMTsNCiAgICAgICAgbXAtPmxpbmVzKys7DQogICAg
fQ0KDQogICAgcC0+bXNnX2NvdW50ID0gbXNnX251bTsNCg0KI2lmZGVmIERF
QlVHDQogICAgaWYocC0+ZGVidWcgJiYgbXNnX251bSA+IDApIHsNCiAgICAg
ICAgcmVnaXN0ZXIgICAgaTsNCiAgICAgICAgZm9yIChpID0gMCwgbXAgPSBw
LT5tbHA7IGkgPCBwLT5tc2dfY291bnQ7IGkrKywgbXArKykNCiAgICAgICAg
ICAgIHBvcF9sb2cocCxQT1BfREVCVUcsDQoJICAgICJNc2cgJWQgdWlkbCAl
cyBhdCBvZmZzZXQgJWQgaXMgJWQgb2N0ZXRzIGxvbmcgYW5kIGhhcyAldSBs
aW5lcy4iLA0KCSAgICBtcC0+bnVtYmVyLG1wLT51aWRsX3N0cixtcC0+b2Zm
c2V0LG1wLT5sZW5ndGgsbXAtPmxpbmVzKTsNCiAgICB9DQojZW5kaWYNCg0K
ICAgIGlmIChmZmx1c2gocC0+ZHJvcCkgPT0gRU9GKQ0KICAgICAgICByZXR1
cm4gcG9wX21zZyhwLFBPUF9GQUlMVVJFLCJGbHVzaCBvZiB0ZW1wIHBvcCBk
cm9wYm94ICVzIGZhaWxlZCAoJWQpIiwNCgkgICAgcC0+dGVtcF9kcm9wLCBl
cnJubyk7DQoNCiAgICByZXR1cm4oUE9QX1NVQ0NFU1MpOw0KfQ0KDQovKiAN
CiAqICBkcm9wY29weTogICBNYWtlIGEgdGVtcG9yYXJ5IGNvcHkgb2YgdGhl
IHVzZXIncyBtYWlsIGRyb3AgYW5kIA0KICogIHNhdmUgYSBzdHJlYW0gcG9p
bnRlciBmb3IgaXQuDQogKi8NCg0KcG9wX2Ryb3Bjb3B5KHAsIHB3cCkNClBP
UCAgICAgKiAgIHA7DQpzdHJ1Y3QgcGFzc3dkCSoJcHdwOw0Kew0KICAgIGlu
dCAgICAgICAgICAgICAgICAgICAgIG1mZDsgICAgICAgICAgICAgICAgICAg
IC8qICBGaWxlIGRlc2NyaXB0b3IgZm9yIA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdXNl
cidzIG1haWxkcm9wICovDQogICAgaW50ICAgICAgICAgICAgICAgICAgICAg
ZGZkOyAgICAgICAgICAgICAgICAgICAgLyogIEZpbGUgZGVzY3JpcHRvciBm
b3IgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRoZSBTRVJWRVIgbWFpbGRyb3AgKi8NCiAgICBG
SUxFCQkgICAgKnRmOwkJICAgIC8qICBUaGUgdGVtcCBmaWxlICovDQogICAg
aW50CQkJICAgIHRmbjsJCSAgICANCiAgICBjaGFyICAgICAgICAgICAgICAg
ICAgICBidWZmZXJbTUFYTElORUxFTl07ICAgICAvKiAgUmVhZCBidWZmZXIg
Ki8NCiAgICBjaGFyCQkgICAgbWVzc1syNTZdOwkJLyogQ1lHTlVTICovDQog
ICAgbG9uZyAgICAgICAgICAgICAgICAgICAgb2Zmc2V0OyAgICAgICAgICAg
ICAgICAgLyogIE9sZC9OZXcgYm91bmRhcnkgKi8NCiAgICBpbnQgICAgICAg
ICAgICAgICAgICAgICBuY2hhcjsgICAgICAgICAgICAgICAgICAvKiAgQnl0
ZXMgd3JpdHRlbi9yZWFkICovDQogICAgc3RydWN0IHN0YXQgICAgICAgICAg
ICAgbXlidWY7ICAgICAgICAgICAgICAgICAgLyogIEZvciBmc3RhdCgpICov
DQoNCiAgICBpZiAoZ2VucGF0aChwKSA8IDApDQoJcmV0dXJuKHBvcF9tc2co
cCwgUE9QX0ZBSUxVUkUsICJVbmFibGUgdG8gY3JlYXRlIHRlbXBvcmFyeSBk
cm9wIG5hbWUiKSk7DQoNCiAgICAvKiAgQ3JlYXRlIGEgdGVtcG9yYXJ5IG1h
aWxkcm9wIGludG8gd2hpY2ggdG8gY29weSB0aGUgdXBkYXRlZCBtYWlsZHJv
cCAqLw0KICAgICh2b2lkKXNwcmludGYocC0+dGVtcF9kcm9wLCBQT1BfRFJP
UCwgcC0+dXNlcik7DQoNCiAgICBERUJVR19MT0cxKHAsIkNyZWF0aW5nIHRl
bXBvcmFyeSBtYWlsZHJvcCAnJXMnIixwLT50ZW1wX2Ryb3ApOw0KDQojaWZk
ZWYgQlVMTERCDQogICAgaWYgKHAtPmJ1bGxkaXIpIHsNCgljaGFyIGJ1bGxf
ZGJbTUFYTElORUxFTl07DQoNCiNpZmRlZiBCVUxMREJESVINCglzcHJpbnRm
KGJ1bGxfZGIsICIlcy9idWxsZGIiLCBCVUxMREJESVIpOw0KI2Vsc2UNCglz
cHJpbnRmKGJ1bGxfZGIsICIlcy9idWxsZGIiLCBwLT5idWxsZGlyKTsNCiNl
bmRpZg0KI2lmZGVmIEdEQk0NCglpZiAoKHAtPmJ1bGxfZGIgPSBnZGJtX29w
ZW4gKGJ1bGxfZGIsIDUxMiwgR0RCTV9XUkNSRUFULCAwNjAwLCAwKSkgPT0g
TlVMTCkNCiNlbHNlDQogICAgICAgIGlmICgocC0+YnVsbF9kYiA9IGRibV9v
cGVuIChidWxsX2RiLCBPX1JEV1IgfCBPX0NSRUFULCAwNjAwKSkgPT0gTlVM
TCkgDQojZW5kaWYNCgkJew0KCQkgICAgcG9wX2xvZyhwLFBPUF9QUklPUklU
WSwiZ2RibV9vcGVuIGZhaWxlZCA6ICVzICglZCkiLA0KCQkJICAgIHN5c19l
cnJsaXN0W2Vycm5vXSxlcnJubyk7DQoJCSAgICByZXR1cm4ocG9wX21zZyhw
LCBQT1BfRkFJTFVSRSwNCgkJCQkgICAiVW5hYmxlIHRvIG9wZW4gQnVsbGV0
aW4gZGF0YWJhc2UsIGNvbnRhY3QgeW91ciBhZG1pbmlzdHJhdG9yIikpOw0K
CQl9DQogICAgfQ0KI2VuZGlmDQoNCiAgICAvKiBIZXJlIHdlIHdvcmsgdG8g
bWFrZSBzdXJlIHRoZSB1c2VyIGRvZXNuJ3QgY2F1c2UgdXMgdG8gcmVtb3Zl
IG9yDQogICAgICogd3JpdGUgb3ZlciBleGlzdGluZyBmaWxlcyBieSBsaW1p
dGluZyBob3cgbXVjaCB3b3JrIHdlIGRvIHdoaWxlDQogICAgICogcnVubmlu
ZyBhcyByb290Lg0KICAgICAqLw0KDQojaWZkZWYgQklOTUFJTF9JU19TRVRH
SUQNCiMgaWYgQklOTUFJTF9JU19TRVRHSUQgPiAxDQogICAgcHdwLT5wd19n
aWQgPSAoZ2lkX3QpQklOTUFJTF9JU19TRVRHSUQ7DQojIGVsc2UNCiAgICBp
ZiAoIXN0YXQoUE9QX01BSUxESVIsICZteWJ1ZikpDQoJcHdwLT5wd19naWQg
PSBteWJ1Zi5zdF9naWQ7DQojIGVuZGlmDQojZW5kaWYNCg0KICAgIC8qIE5v
dyB3ZSBydW4gYXMgdGhlIHVzZXIuICovDQogICAgKHZvaWQpIHNldGdpZCgo
R0lEX1QpcHdwLT5wd19naWQpOw0KICAgIC8qIFNldCB0aGUgc3VwcGxlbWVu
dGFyeSBncm91cHMgbGlzdCAqLw0KICAgICh2b2lkKSBzZXRncm91cHMoMSwo
R0lEX1QgKikmcHdwLT5wd19naWQpOyANCiAgICAodm9pZCkgc2V0dWlkKChV
SURfVClwd3AtPnB3X3VpZCk7DQoNCiAgICBERUJVR19MT0cyKHAsInVpZCA9
ICVkLCBnaWQgPSAlZCIsZ2V0dWlkKCksZ2V0Z2lkKCkpOw0KDQovKiBTVEFS
VCBDWUdOVVMgKi8NClNUQVJUT1BFTjoNCm1lc3NbMF09MDsNCi8qIEVORCBD
WUdOVVMgKi8NCiAgICBpZiAoKGRmZCA9IG9wZW4ocC0+dGVtcF9kcm9wLCBP
X1JEV1IgfCBPX0NSRUFULCAwNjAwKSkgPT0gLTEpIHsNCiAgICAgICAgcG9w
X2xvZyhwLCBQT1BfUFJJT1JJVFksDQogICAgICAgICAgICAiVW5hYmxlIHRv
IG9wZW4gdGVtcG9yYXJ5IG1haWxkcm9wICclcyc6ICVzICglZCkiLHAtPnRl
bXBfZHJvcCwNCiAgICAgICAgICAgICAgICAoZXJybm8gPCBzeXNfbmVycikg
PyBzeXNfZXJybGlzdFtlcnJub10gOiAiIiwgZXJybm8pIDsNCiAgICAgICAg
cmV0dXJuIHBvcF9tc2cocCxQT1BfRkFJTFVSRSwNCiAgIAkgICAiRmFpbGVk
IHRvIGNyZWF0ZSAlcyB3aXRoIHVpZCAlZCwgZ2lkICVkLiBDaGFuZ2UgcGVy
bWlzc2lvbnMuIiwNCgkJICAgICAgIHAtPnRlbXBfZHJvcCxwd3AtPnB3X3Vp
ZCwgcHdwLT5wd19naWQpOw0KICAgIH0NCg0KICAgIGZzdGF0KGRmZCwgJm15
YnVmKTsNCiAgICBpZiAobXlidWYuc3RfdWlkICE9IHB3cC0+cHdfdWlkKSB7
DQoJY2xvc2UoZGZkKTsNCglyZXR1cm4ocG9wX21zZyhwLCBQT1BfRkFJTFVS
RSwiVGVtcG9yYXJ5IGRyb3AgZmlsZSBub3Qgb3duZWQgYnkgJXMuIiwNCgkJ
ICAgICAgIHAtPnVzZXIpKTsNCiAgICB9DQojaWZkZWYgTkVYVA0KICAgIGlm
IChteWJ1Zi5zdF9tb2RlICYgKDB4NykpDQojZWxzZQ0KICAgIGlmIChteWJ1
Zi5zdF9tb2RlICYgKFNfSVdPVEggfCBTX0lST1RIKSkNCiNlbmRpZg0KICAg
IHsNCgljbG9zZShkZmQpOw0KCXJldHVybihwb3BfbXNnKHAsIFBPUF9GQUlM
VVJFLA0KCSAgIllvdXIgdGVtcG9yYXJ5IGZpbGUgJXMgaXMgYWNjZXNzaWJs
ZSBieSBvdGhlcnMuICBUaGlzIG11c3QgYmUgZml4ZWQiLA0KCSAgICBwLT50
ZW1wX2Ryb3ApKTsNCiAgICB9DQogICAgLyogTWFrZSBzdXJlIHRoZSBtYWls
c3Bvb2wgaXMgbm90IGEgaGFyZCBsaW5rICovDQogICAgaWYgKG15YnVmLnN0
X25saW5rICE9IDEpIHsNCgljbG9zZShkZmQpOw0KCXJldHVybihwb3BfbXNn
KHAsIFBPUF9GQUlMVVJFLA0KCSAgICAiWW91ciB0ZW1wb3JhcnkgZmlsZSBh
cHBlYXJzIHRvIGhhdmUgbW9yZSB0aGFuIG9uZSBsaW5rLiIpKTsNCiAgICB9
DQoNCiAgICAvKiBJZiB0aGUgdGVtcG9yYXJ5IHBvcGRyb3AgaXMgbm90IGVt
cHR5LCByZXZlcnQgdG8gcmVndWxhciBtb2RlLiAqLw0KICAgIGlmIChteWJ1
Zi5zdF9zaXplICE9IDApDQoJcC0+c2VydmVyX21vZGUgPSAwOw0KDQogICAg
LyogIExvY2sgdGhlIHRlbXBvcmFyeSBtYWlsZHJvcC4gTG9ja2luZyBpcyBq
dXN0IHRvIGNoZWNrIGZvciBzaW5nbGUNCiAgICAgKiAgcG9wIHNlc3Npb24g
cGVyIHVzZXIuDQogICAgICovDQogICAgaWYgKCBmbG9jayAoZGZkLCBMT0NL
X0VYfExPQ0tfTkIpID09IC0xICkgew0KCXN3aXRjaChlcnJubykgew0KCSAg
ICBjYXNlIEVXT1VMREJMT0NLOg0KCQkvKiBTVEFSVCBDWUdOVVMgKi8NCgkJ
cG9wX2xvZyhwLFBPUF9QUklPUklUWSwiRm91bmQgbG9ja2VkIHNwb29sIGZv
ciAlcyEiLHAtPnVzZXIpOw0KCQljbGVhcl9vbGQocCk7IC8qIGtpbGwgdXNl
ciBwcm9jZXNzIGlmIHRoZXJlIGlzIG9uZSAqLw0KCQkvKiBwcmludF9sb2Nr
X2RpcihwKTsgKi8NCgkJcG9wX2xvZyhwLFBPUF9QUklPUklUWSwiVW5sb2Nr
aW5nIGxvY2sgZmlsZSBmb3IgJXMiLHAtPnVzZXIpOw0KCQkvKiB1bmxvY2sg
dGhlIGRyb3AgZmlsZSAqLw0KCSAgICAJaWYgKGZsb2NrKGRmZCwgTE9DS19V
Tik9PS0xKSB7DQoJCXBvcF9sb2cocCxQT1BfUFJJT1JJVFksIkNhbnQgdW5s
b2NrIGxvY2sgZmlsZSBmb3IgJXMhICglcykiLHAtPnVzZXIsc3RyZXJyb3Io
ZXJybm8pKTsNCgkJcG9wX2xvZyhwLFBPUF9QUklPUklUWSwiQ2xvc2luZyBk
cm9wIGZpbGUgZm9yICVzISIscC0+dXNlcik7DQoJCWNsb3NlKGRmZCk7IC8q
IGNsb3NlIHRoZSBkcm9wIGZpbGUgKi8NCgkJcG9wX2xvZyhwLFBPUF9QUklP
UklUWSwiQ0xPU0VEIGRyb3AgZmlsZSBmb3IgJXMhIixwLT51c2VyKTsNCgkJ
Z290byBTVEFSVEVORDsNCgkJfQ0KCQlwb3BfbG9nKHAsUE9QX1BSSU9SSVRZ
LCJVTkxPQ0tFRCBsb2NrIGZpbGUgZm9yICVzIixwLT51c2VyKTsNCgkJcG9w
X2xvZyhwLFBPUF9QUklPUklUWSwiQ2xvc2luZyBkcm9wIGZpbGUgZm9yICVz
ISIscC0+dXNlcik7DQoJCWNsb3NlKGRmZCk7IC8qIGNsb3NlIHRoZSBkcm9w
IGZpbGUgKi8NCgkJcG9wX2xvZyhwLFBPUF9QUklPUklUWSwiQ0xPU0VEIGRy
b3AgZmlsZSBmb3IgJXMhIixwLT51c2VyKTsNCgkJcG9wX2xvZyhwLFBPUF9Q
UklPUklUWSwiUmVtb3ZpbmcgZHJvcCBmaWxlIGZvciAlcyEiLHAtPnVzZXIp
Ow0KCQkodm9pZCl1bmxpbmsocC0+dGVtcF9kcm9wKTsgLyogcmVtb3ZlIHRo
ZSBkcm9wIGZpbGUgKi8NCgkJcG9wX2xvZyhwLFBPUF9QUklPUklUWSwiUkVN
T1ZFRCBkcm9wIGZpbGUgZm9yICVzISIscC0+dXNlcik7DQoJCWdvdG8gU1RB
UlRPUEVOOw0KCQlTVEFSVEVORDoNCgkJLyogRU5EIENZR05VUyAqLw0KCQly
ZXR1cm4gcG9wX21zZyhwLFBPUF9GQUlMVVJFLA0KCQkgICAgICJbSU4tVVNF
XSAlcyBsb2NrIGJ1c3khICBJcyBhbm90aGVyIHNlc3Npb24gYWN0aXZlPyAo
JWQpIiwNCgkJCQkJCQlwLT50ZW1wX2Ryb3AsIGVycm5vKTsNCgkgICAgZGVm
YXVsdDoNCgkJY2xvc2UoZGZkKTsNCgkJcmV0dXJuIHBvcF9tc2cocCxQT1Bf
RkFJTFVSRSwiZmxvY2s6ICclcyc6ICVzICglZCkiLA0KCQkJICAgICAgIHAt
PnRlbXBfZHJvcCwgKGVycm5vIDwgc3lzX25lcnIpID8gDQoJCQkgICAgICAg
c3lzX2Vycmxpc3RbZXJybm9dIDogIiIsIGVycm5vKTsNCgl9DQogICAgfQ0K
ICAgIA0KI2lmbmRlZiBLRUVQX1RFTVBfRFJPUA0KICAgIC8qIGNoZWNrIGZv
ciByYWNlIGNvbmRpdGlvbnMgaW52b2x2aW5nIHVubGluay4gIFNlZSBwb3Bf
dXBkdC5jICovDQogICAgLyogcy1kb3JuZXJAdWl1Yy5lZHUsIDEyLzkxICov
DQogICAgew0KICAgICAgc3RydWN0IHN0YXQgYnlOYW1lLCBieUZkOw0KICAg
ICAgaWYgKHN0YXQocC0+dGVtcF9kcm9wLCAmYnlOYW1lKSB8fCBmc3RhdChk
ZmQsICZieUZkKSB8fA0KCSAgYnlOYW1lLnN0X2lubyAhPSBteWJ1Zi5zdF9p
bm8pDQogICAgICB7DQogICAgICAgIHJldHVybiBwb3BfbXNnKHAsUE9QX0ZB
SUxVUkUsDQoJCSJNYWlsZHJvcCBiZWluZyB1bmxvY2tlZDsgdHJ5IGFnYWlu
LiIpOw0KICAgICAgfQ0KICAgIH0NCiNlbmRpZg0KICAgIA0KICAgIC8qICBB
Y3F1aXJlIGEgc3RyZWFtIHBvaW50ZXIgZm9yIHRoZSB0ZW1wb3JhcnkgbWFp
bGRyb3AgKi8NCiAgICBpZiAoIChwLT5kcm9wID0gZmRvcGVuKGRmZCwicisi
KSkgPT0gTlVMTCApIHsNCiAgICAgICAgKHZvaWQpY2xvc2UoZGZkKSA7DQog
ICAgICAgIHJldHVybiBwb3BfbXNnKHAsUE9QX0ZBSUxVUkUsIkNhbm5vdCBh
c3NpZ24gc3RyZWFtIGZvciAlcyAoJWQpIiwNCgkJICAgICAgIHAtPnRlbXBf
ZHJvcCwgZXJybm8pOw0KICAgIH0NCiAgICAvKiAgQWxsb2NhdGUgbWVtb3J5
IGZvciBtZXNzYWdlIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMgYW5kIHRoaXMg
aXMNCiAgICAgKiAgaXMgbm90IGRlbGV0ZWQgc2luY2UgYSBmYWlsdXJlLCBm
b3Igc29tZSByZWFzb24gaW4gdGhpcyBmdW5jdGlvbg0KICAgICAqICB3b3Vs
ZCByZXN1bHQgaW4gcHJvY2VzcyBkZWF0aC4gKi8NCiAgICBwLT5tbHAgPSAo
TXNnSW5mb0xpc3QgKiljYWxsb2MoKHVuc2lnbmVkKUFMTE9DX01TR1Msc2l6
ZW9mKE1zZ0luZm9MaXN0KSk7DQogICAgaWYgKHAtPm1scCA9PSBOVUxMKXsN
CiAgICAgICAgcmV0dXJuIHBvcF9tc2cgKHAsUE9QX0ZBSUxVUkUsDQogICAg
ICAgICAgICAiQ2FuJ3QgYWxsb2NhdGUgbWVtb3J5IGZvciBtZXNzYWdlIGxp
c3QuIik7DQogICAgfQ0KICAgIHAtPm1zZ19jb3VudCA9IDA7DQogICAgcC0+
ZHJvcF9zaXplID0gMDsNCg0KICAgIGlmIChteWJ1Zi5zdF9zaXplICE9IDAp
IHsgLyogTW9zdGx5IHRoaXMgaXMgZm9yIHJlZ3VsYXIgbW9kZS4gKi8NCglp
ZiAoaW5pdF9kcm9waW5mbyhwKSAhPSBQT1BfU1VDQ0VTUykgew0KCSAgICAv
KiBPY2N1cnMgb24gdGVtcF9kcm9wIGNvcnJ1cHRpb24gKi8NCgkgICAgZmxv
Y2soZGZkLCBMT0NLX1VOKTsNCgkgICAgY2xvc2UoZGZkKTsNCgkgICAgcmV0
dXJuKFBPUF9GQUlMVVJFKTsNCgl9DQoJLyogU3luYyB3aXRoIHN0ZGlvOyBz
aG91bGQgYmUgYXQgZW5kIGFueXdheSAqLw0KCSh2b2lkKWZzZWVrKHAtPmRy
b3AsIDBMLCBTRUVLX0VORCk7DQoJb2Zmc2V0ID0gZnRlbGwocC0+ZHJvcCk7
DQogICAgfQ0KDQojaWZkZWYgTUFJTE9DSw0KICAgIC8qIFNZU1YgbG9ja2lu
ZyBmb3IgdXNlcnMgbWFpbGJveC4qLw0KICAgIGlmIChtYWlsbG9jayhwLT51
c2VyLDEpICE9IDApDQogICAgICAgICAgICByZXR1cm4gcG9wX21zZyhwLFBP
UF9GQUlMVVJFLCAibWFpbGxvY2s6ICclcyciLCBwLT50ZW1wX2Ryb3ApOw0K
I2VuZGlmDQoNCiAgICAvKiAgT3BlbiB0aGUgdXNlcidzIG1haWxkcm9wLCBJ
ZiB0aGlzIGZhaWxzLCAgbm8gaGFybSBpbiBhc3N1bWluZyBlbXB0eSAqLw0K
ICAgIC8qIDx0b2RvPiBNYWlsIGRyb3AgaGFzIHRvIGJlIGNyZWF0ZWQgaWYg
b25lIGRvZXNuJ3QgZXhpc3QgZm9yIHNlcnZlcl9tb2RlLg0KICAgICAqIEJl
Y2F1c2UgcC0+ZHJvcCBpcyB1c2VkIGZvciBidWxsZXRpbnMuIFJpZ2h0IG5v
dyBpdCByZXZlcnRzIGJhY2sgdG8gDQogICAgICogcmVndWxhciBtb2RlIGlm
IGRyb3AgYm94IG9wZW4gZmFpbHMuIDwvdG9kbz4NCiAgICAgKi8NCiAgICBp
ZiAoKG1mZCA9IG9wZW4ocC0+ZHJvcF9uYW1lLCBPX1JEV1IpKSA+IDApIHsN
CiAgICAgICAgLyogTG9jayB0aGUgbWFpbGRyb3AgKi8NCiAgICAgICAgaWYg
KGZsb2NrIChtZmQsTE9DS19FWCkgPT0gLTEpIHsNCiAgICAgICAgICAgICh2
b2lkKWNsb3NlKG1mZCkgOw0KCSAgICBNQUlMVU5MT0NLKCk7DQogICAgICAg
ICAgICByZXR1cm4gcG9wX21zZyhwLFBPUF9GQUlMVVJFLCAiZmxvY2s6ICcl
cyc6ICVzICglZCkiLCBwLT5kcm9wX25hbWUsDQoJCQkgICAoZXJybm8gPCBz
eXNfbmVycikgPyBzeXNfZXJybGlzdFtlcnJub10gOiAiIiwgZXJybm8pOw0K
ICAgICAgICB9DQoNCglpZiAoIXAtPnNlcnZlcl9tb2RlKSB7DQoJICAgIC8q
IE5ldyByb3V0aW5lIHRvIGNvcHkgYW5kIGdldCBkcm9wYm94IGluZm8gYWxs
IGF0IHRoZSBzYW1lIHRpbWUgKi8NCgkgICAgbmNoYXIgPSBkb19kcm9wX2Nv
cHkocCwgbWZkLCBkZmQpOw0KDQoJICAgIGlmICggbmNoYXIgIT0gUE9QX1NV
Q0NFU1MgKSB7DQoJCS8qIHBvcF9kcm9wY29weSBoYXMgaW50ZWdyYXRlZCB0
aGUgaW5mbyBnYXRoZXJpbmcgcGFzcyBpbnRvDQoJCSAgIHRoZSBjb3B5IHBh
c3Mgc28gbm93IHRoZSBpbmZvcm1hdGlvbiBvZiB0aGUgZHJvcGZpbGUgaXMN
CgkJICAgaW5jb25zaXN0ZW50IGlmIHRoZXJlIGlzIGFuIGVycm9yLiAgTm93
IHdlIGV4aXQgaW5zdGVhZA0KCQkgICBvZiB0cnlpbmcgdG8gY29udGludWUg
d2l0aCB3aGF0IGlzIGF2YWlsYWJsZS4NCgkJKi8NCgkJKHZvaWQpZnRydW5j
YXRlKGRmZCwgKE9GRl9UKW9mZnNldCkgOw0KCQlnb3RvIGJhaWxvdXQ7DQoJ
ICAgIH0gDQoJICAgIGVsc2Ugew0KCQkvKiBNYWlsIHRyYW5zZmVycmVkISAg
WmVybyB0aGUgbWFpbCBkcm9wIE5PVywgIHRoYXQgd2UNCgkJICAgZG8gbm90
IGhhdmUgdG8gZG8gZ3ltbmFzdGljcyB0byBmaWd1cmUgb3V0IHdoYXQncyBu
ZXcNCgkJICAgYW5kIHdoYXQgaXMgb2xkIGxhdGVyICovDQoJCSh2b2lkKWZ0
cnVuY2F0ZShtZmQsIChPRkZfVCkwKSA7DQoJICAgIH0NCg0KCSAgICAvKiBV
bmxvY2sgYW5kIGNsb3NlIHRoZSBhY3R1YWwgbWFpbCBkcm9wICovDQoJICAg
IGZsb2NrKG1mZCwgTE9DS19VTik7DQoJICAgICh2b2lkKWNsb3NlIChtZmQp
Ow0KCX0gDQoJZWxzZSB7IC8qIFNFUlZFUl9NT0RFICovDQoJICAgIC8qIFNh
dmUgdGhlIHRlbXBvcmFyeSBkcm9wIEZJTEUgYW5kIGZpZCB2YWx1ZXMgKi8N
CgkgICAgcC0+aG9sZCA9IHAtPmRyb3A7DQoJICAgIGlmICgocC0+ZHJvcCA9
IGZkb3BlbihtZmQsInIrIikpID09IE5VTEwpIHsNCgkJcG9wX21zZyhwLFBP
UF9GQUlMVVJFLCJDYW5ub3QgYXNzaWduIHN0cmVhbSBmb3IgJXMgKCVkKSIs
DQoJCQlwLT5kcm9wX25hbWUsIGVycm5vKTsNCgkJZ290byBiYWlsb3V0Ow0K
CSAgICB9DQoJICAgIGlmIChpbml0X2Ryb3BpbmZvKHApICE9IFBPUF9TVUND
RVNTKQ0KCQlnb3RvIGJhaWxvdXQ7DQoJfQ0KICAgIH0NCiAgICBlbHNlIHsN
CgkvKiBSZXZlcnQgdG8gcmVndWxhciBvcGVyYXRpb24gd2hlbiB0aGVyZSBh
cmUgbm8gbWFpbHMgaW4NCgkgKiB1c2VycyBtYWlsIGJveC4gVGhpcyBpcyBm
b3IgdGhlIHNha2Ugb2YgYW55IGJ1bGxldGlucywgDQoJICogd2hpY2ggdXNl
cyBwLT5kcm9wICh0ZW1wX2Ryb3ApIGFuZCB0byBhbGxvdyBwb3BfdXBkdCB0
bw0KCSAqIGNvcHkgYmFjayB0byBvcmlnaW5hbCBtYWlsIGJveC4qLw0KCWlm
KHAtPnNlcnZlcl9tb2RlKSB7DQoJICAgIHAtPnNlcnZlcl9tb2RlID0gMDsg
DQoJfQ0KICAgIH0NCg0KICAgIGlmIChwLT5idWxsZGlyKSB7DQoJLyogUmVj
YWxjdWxhdGUgb2Zmc2V0ICovDQoJKHZvaWQpZnNlZWsocC0+ZHJvcCwgMEws
IFNFRUtfRU5EKTsNCglvZmZzZXQgPSBmdGVsbChwLT5kcm9wKTsNCgkvKiBJ
biBTZXJ2ZXJfbW9kZSwgcC0+ZHJvcCBjYW4gYmUgDQoJICogbnVsbChubyBt
YWlscyksIHBvcF9idWxsIHJlcXVpcmVzIGEgZHJvcCBoYW5kbGUuIDwvYnVn
PiAqLw0KCWlmKHBvcF9idWxsKHAsIHB3cCkgIT0gUE9QX1NVQ0NFU1Mpew0K
CSAgICAvKiBSZXR1cm4gcG9wIGRyb3AgYmFjayB0byB3aGF0IGl0IHdhcyBi
ZWZvcmUgdGhlIGJ1bGxldGlucyAqLw0KCSAgICAodm9pZClmdHJ1bmNhdGUo
cC0+c2VydmVyX21vZGUgPyANCgkJCSAgICAoKG1mZCA9PSAtMSk/ZGZkOm1m
ZCk6ZGZkLCAoT0ZGX1Qpb2Zmc2V0KTsNCgl9DQogICAgfQ0KI2lmZGVmIEJV
TExEQg0KI2lmZGVmIEdEQk0NCiAgICBnZGJtX2Nsb3NlKHAtPmJ1bGxfZGIp
Ow0KI2Vsc2UNCiAgICBkYm1fY2xvc2UocC0+YnVsbF9kYik7DQojZW5kaWYN
CiNlbmRpZg0KDQogICAgKHZvaWQpZnNlZWsocC0+ZHJvcCwgMEwsIFNFRUtf
RU5EKTsNCiAgICBwLT5zcG9vbF9lbmQgPSBmdGVsbChwLT5kcm9wKTsNCg0K
I2lmZGVmIERFQlVHDQogICAgaWYocC0+ZGVidWcgJiYgcC0+bXNnX2NvdW50
ID4gMCkgew0KICAgICAgICByZWdpc3RlciAgICBpOw0KCU1zZ0luZm9MaXN0
ICptcDsgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICBmb3IgKGkgPSAw
LCBtcCA9IHAtPm1scDsgaSA8IHAtPm1zZ19jb3VudDsgaSsrLCBtcCsrKQ0K
ICAgICAgICAgICAgcG9wX2xvZyhwLFBPUF9ERUJVRywNCgkgICAgIk1zZyAl
ZCB1aWRsICVzIGF0IG9mZnNldCAlZCBpcyAlZCBvY3RldHMgbG9uZyBhbmQg
aGFzICV1IGxpbmVzLiIsDQoJCSAgICBtcC0+bnVtYmVyLG1wLT51aWRsX3N0
cixtcC0+b2Zmc2V0LG1wLT5sZW5ndGgsbXAtPmxpbmVzKTsNCiAgICB9DQoj
ZW5kaWYNCiAgICBNQUlMVU5MT0NLKCk7DQoNCiAgICBpZiAocC0+c2VydmVy
X21vZGUpDQogICAgICAgIGZsb2NrKG1mZCwgTE9DS19VTik7DQoNCiAgICBy
ZXR1cm4oUE9QX1NVQ0NFU1MpOw0KDQogYmFpbG91dDoNCiAgICBNQUlMVU5M
T0NLKCk7DQogICAgZmxvY2sobWZkLCBMT0NLX1VOKTsNCiAgICBmbG9jayhk
ZmQsIExPQ0tfVU4pOw0KICAgIGNsb3NlKG1mZCk7DQogICAgY2xvc2UoZGZk
KTsNCiAgICByZXR1cm4oUE9QX0ZBSUxVUkUpOw0KfQ0KDQovKg0KICogVGhp
cyBmdW5jdGlvbiBlbXVsYXRlcyBmZ2V0cygpIGV4Y2VwdCB0aGF0IGl0IHJl
cGxhY2VzIHRoZSBOVUxMcyB3aXRoDQogKiBTUEFDRXMNCiAqLw0KDQpjaGFy
ICoNCm1mZ2V0cyggcywgc2l6ZSwgc3RyZWFtICkNCmNoYXIgKnM7DQppbnQg
c2l6ZTsNCkZJTEUgKnN0cmVhbTsNCnsNCiAgICBpbnQgYzsNCiAgICBjaGFy
ICpwID0gczsNCiAgICBpZiggc2l6ZSA8PSAwICkgew0KCXJldHVybiBOVUxM
Ow0KICAgIH0NCiAgICB3aGlsZSggLS1zaXplICYmICgoYyA9IGdldGMoc3Ry
ZWFtKSkgIT0gRU9GKSApIHsNCglpZiggKCpwID0gKGNoYXIpYykgPT0gJ1ww
JyApICpwID0gJyAnOw0KCWlmKCAqcCsrID09ICdcbicgKSBicmVhazsNCiAg
ICB9DQogICAgaWYoIHAgPT0gcyApIHJldHVybiBOVUxMOw0KICAgICpwID0g
J1wwJzsNCiAgICByZXR1cm4gczsNCn0NCg0KLyogU1RBUlQgQ1lHTlVTICov
DQoNCnZvaWQgY2xlYXJfb2xkKFBPUCAqcCkNCnsNCmludCBwc2ZvdW5kPTA7
DQpjaGFyIHBzbGluZVsyNTddOw0KY2hhciBwc3BpZF9zdHJbMTBdOw0KcGlk
X3QgcHNwaWQ9LTE7DQpGSUxFICpwcDsNCg0KcHNsaW5lWzBdPTA7DQpwc3Bp
ZF9zdHJbMF09MDsNCnBwPXBvcGVuKFBTX0NPTU1BTkQsInIiKTsNCndoaWxl
IChmZ2V0cyhwc2xpbmUsMjU2LHBwKSAhPSBOVUxMKSB7DQoJaWYgKHN0cnN0
cihwc2xpbmUsUFNfU0VBUkNIKSkgew0KCQlyZW1vdmVfZmlyc3QocHNsaW5l
KTsNCgkJc3NjYW5mKHBzbGluZSwiJXMgIixwc3BpZF9zdHIpOw0KCQlwc3Bp
ZD0ocGlkX3QpYXRvaShwc3BpZF9zdHIpOyANCgkJaWYgKGdldHBpZCgpPT1w
c3BpZCkgew0KCQkJcHNsaW5lWzBdPTA7DQoJCQlwc3BpZF9zdHJbMF09MDsN
CgkJCWNvbnRpbnVlOw0KCQkgIH0NCgkJcHNmb3VuZD0xOw0KCQlicmVhazsN
Cgl9DQogfSAvKiBlbmQgb2Ygd2hpbGUgKi8NCnBjbG9zZShwcCk7DQppZiAo
cHNmb3VuZD09MSkgew0KIC8qIHNlbmQgU0lHVEVSTSAqLw0KIHBvcF9sb2co
cCxQT1BfUFJJT1JJVFksIkdvdCBwaWQgJXMgZm9yIHVzZXIgJXMiLHBzcGlk
X3N0cixwLT51c2VyKTsNCiBpZiAoa2lsbChwc3BpZCwxNSkgPCAwKSB7DQog
IHBvcF9sb2cocCxQT1BfUFJJT1JJVFksIkZBSUxFRCBzZW5kaW5nIFRFUk0g
c2lnbmFsIHRvIHBvcHBlciBwcm9jZXNzICV1IGZvciAlcyAoJXMpIiwodW5z
aWduZWQgaW50KXBzcGlkLHAtPnVzZXIsc3RyZXJyb3IoZXJybm8pKTsNCiB9
DQogZWxzZSB7DQogIHBvcF9sb2cocCxQT1BfUFJJT1JJVFksIlNlbnQgVEVS
TSBzaWduYWwgdG8gcG9wcGVyIHByb2Nlc3MgJXUgZm9yICVzIiwodW5zaWdu
ZWQgaW50KXBzcGlkLHAtPnVzZXIpOw0KICBzbGVlcCgyKTsNCiAgfQ0KIH0g
LyogZW5kIG9mIGlmIHBzZm91bmQgKi8NCmVsc2Ugew0KIHBvcF9sb2cocCxQ
T1BfUFJJT1JJVFksIk5vIG9wZW4gcG9wcGVyIHByb2Nlc3MgZm91bmQgZm9y
ICVzIixwLT51c2VyKTsNCiB9DQoNCn0NCg0KDQovKioqIHJlbW92ZXMgZmly
c3Qgd29yZCBhdCBmcm9udCBvZiBzdHJpbmcgYW5kIG1vdmVzIHJlc3QgZG93
biAqKiovDQpyZW1vdmVfZmlyc3QoaW5wc3RyKQ0KY2hhciAqaW5wc3RyOw0K
ew0KaW50IG5ld3BvcyxvbGRwb3M7DQoNCm5ld3Bvcz0wOyAgb2xkcG9zPTA7
DQovKiBmaW5kIGZpcnN0IHdvcmQgKi8NCndoaWxlKGlucHN0cltvbGRwb3Nd
PT0nICcpIHsNCiAgICAgICAgaWYgKCFpbnBzdHJbb2xkcG9zXSkgeyBpbnBz
dHJbMF09MDsgIHJldHVybjsgfQ0KICAgICAgICBvbGRwb3MrKzsNCiAgICAg
ICAgfQ0KLyogZmluZCBlbmQgb2YgZmlyc3Qgd29yZCAqLw0Kd2hpbGUoaW5w
c3RyW29sZHBvc10hPScgJykgew0KICAgICAgICBpZiAoIWlucHN0cltvbGRw
b3NdKSB7IGlucHN0clswXT0wOyAgcmV0dXJuOyB9DQogICAgICAgIG9sZHBv
cysrOw0KICAgICAgICB9DQovKiBmaW5kIHNlY29uZCB3b3JkICovDQp3aGls
ZShpbnBzdHJbb2xkcG9zXT09JyAnKSB7DQogICAgICAgIGlmICghaW5wc3Ry
W29sZHBvc10pIHsgaW5wc3RyWzBdPTA7ICByZXR1cm47IH0NCiAgICAgICAg
b2xkcG9zKys7DQogICAgICAgIH0NCndoaWxlKGlucHN0cltvbGRwb3NdIT0w
KQ0KICAgICAgICBpbnBzdHJbbmV3cG9zKytdPWlucHN0cltvbGRwb3MrK107
DQppbnBzdHJbbmV3cG9zXT0nXDAnOw0KfQ0KDQovKiBFTkQgQ1lHTlVTICov
DQoNCg==
---171031142-37121570-919954547=:21504--
Date: Thu, 25 Feb 1999 10:32:41 -0500
From: Brad Groshok <bgroshok at odyssey.on dot ca>
Subject: popper(?) loosing mail messages
Popper loosing mail message:
Running popper Version 3.0b14 on Sun Sparc, Solaris 2.7
We are getting many customers complaining that we/they are loosing messages
from our server. They use whatever mail client (but seems outlook express
more often) and it reports a certain number of messages available for
download, but when the mail client finishes downloading it has a fewer
number of messages in the in-box.
I thought at first that the problem might be specific to a certain mail
client or user, but we are getting too many comments from too many
customers, so...
I'm suspecting problem may be a local thing.
Looking through the popper.log file shows the proper number of messages
retrieved, but customer can't see/find the messages on their system.
I have not been able to see or duplicate this myself so am having a bit of
a problem tracking it down. Has anybody seen anything like this, or have
any suggestions on method of tracking this?
My inetd.conf fine contains:
pop3 stream tcp nowait root /usr/lib/popper popper -s -T600
Here is a snippet from a customer:
<snip>
I have been having a problem with my email, but haven't been able to prove
it until today. I am loosing messages and can't retrieve them anywhere. I
turned a function on on my icq so I would be able to know what was
happening. When I turn the Internet on, ICQ alerts me I have messages and
gives me just the headers. When I went into retrieve my mail, I pressed
send and receive and it said downloading 3 messages. But, only 2 came
through. This has happened 3 times now. One time in fact it said
downloading 4 messages and nothing appeared in my inbox.
</snip>
Any help greatly appreciated!!!
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Regards: Brad Groshok (bgroshok at odyssey.on dot ca) _/
_/ President Odyssey Network Inc. http://www.odyssey.on.ca _/
_/ London Ontario Canada PH:(519)660-8883 Fax:(519)660-6111 _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
From: "Reid Sutherland" <reid at isys dot ca>
Subject: Longer then 8 character passwds
Date: Thu, 25 Feb 1999 12:31:37 -0500
Anyone knows how to get qpopper to allow longer then standard 8 char passwds
in a shadow passwd environment? I'm running Linux 2.2.1 with PAM-0.57 using
the bigcrypt encrypter.
Any ideas?
Reid Sutherland
Network Administrator
ISYS Technology Inc.
http://www.isys.ca
Fingerprint: 1683 001F A573 B6DF A074 0C96 DBE0 A070 28BE EEA5
Date: Fri, 26 Feb 1999 13:25:24 -0300 (EST)
From: Rodrigo Luiz Anami <rodrigoa at bestway.com dot br>
Subject: Re: Longer then 8 character passwds
Hello Reid,
Do you know APOP authentication ?
-------------------------------------------------------------------------
Rodrigo Luiz Anami rodrigoa at bestway.com dot br
Best Way Internet Provider Atendimento ao Cliente
http://www.bestway.com.br (019) 254.6263 (Campinas)
webmaster at bestway.com dot br 0800.112262 (Outras Localidades)
-------------------------------------------------------------------------
On Thu, 25 Feb 1999, Reid Sutherland wrote:
> Anyone knows how to get qpopper to allow longer then standard 8 char passwds
> in a shadow passwd environment? I'm running Linux 2.2.1 with PAM-0.57 using
> the bigcrypt encrypter.
>
> Any ideas?
>
> Reid Sutherland
> Network Administrator
> ISYS Technology Inc.
> http://www.isys.ca
> Fingerprint: 1683 001F A573 B6DF A074 0C96 DBE0 A070 28BE EEA5
>
>
From: "Frost" <frost at engen dot com>
Subject: Can someone help me?
Date: Sat, 27 Feb 1999 10:28:47 -0700
We are running a SCO Unix ver. 3.2.4.2 server and unfortunately we don't have a
compiler on the system. Are binaries of qpopper available and if so, could
someone please send them to me. Thank you.
Regards,
Harv
______________________________________________________
Harv Frost En.gen
mailto:frost at engen dot com 2727 W. Baseline Rd #13
http://www.engen.com Tempe, AZ 85283
ftp://ftp.engen.com Voc: 602-438-1110
From: "Evan Erwin" <obiwan at frag dot com>
Subject: popauth problem...
Date: Sun, 28 Feb 1999 00:55:16 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_0023_01BE62B5.016743E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I downloaded qpopper-2.53-PAM.rpm and installed it. It placed in.qpopper =
in the /usr/sbin directory, as well as popauth. I got the pop server =
working, but its only popauth that I'm having a problem with. I run =
popauth -init, and it creates /etc/pop.auth (database). Everything seems =
fine. So, then I do popauth -user root (i'm logged in as root), and I =
type in my new password twice. Then it comes up with the error: =
"POPauth: Not able to write to popauth DB" (or something very close to =
that). Seeing that I'm logged in as root, i figured this should not =
happen. I read the instructions, and made a user named 'pop'. Assigned =
the right permissions, even gave ownership of popauth to it. still no =
dice. Please, PLEASE, help! any locations of the latest qpopper rpm =
would be greatly appreciated.
I always thought getting the server up was the hard part, not the user =
db...
thanks
Obiwan
------=_NextPart_000_0023_01BE62B5.016743E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=text/html;charset=iso-8859-1 =
http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>I downloaded qpopper-2.53-PAM.rpm and installed it. =
It placed
in.qpopper in the /usr/sbin directory, as well as popauth. I got the pop =
server
working, but its only popauth that I'm having a problem with. I run =
popauth
-init, and it creates /etc/pop.auth (database). Everything seems fine. =
So, then
I do popauth -user root (i'm logged in as root), and I type in my new =
password
twice. Then it comes up with the error: "POPauth: Not able to write =
to
popauth DB" (or something very close to that). Seeing that I'm =
logged in as
root, i figured this should not happen. I read the instructions, and =
made a user
named 'pop'. Assigned the right permissions, even gave ownership of =
popauth to
it. still no dice. Please, PLEASE, help! any locations of the latest =
qpopper rpm
would be greatly appreciated. </FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>I always thought getting the server up was the hard =
part, not
the user db...</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>thanks</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Obiwan</FONT></DIV></BODY></HTML>
------=_NextPart_000_0023_01BE62B5.016743E0--