The qpopper list archive ending on 20 Apr 2005
Topics covered in this issue include:
1. Re: qpopper test suite
Randall Gellens <randy at qualcomm dot com>
Thu, 16 Dec 2004 16:48:13 -0800
2. Re: .pop lockfile
"Lisa Casey" <lisa at jellico dot net>
Fri, 17 Dec 2004 10:27:27 -0500
3. Re: .pop lockfile
Alan Brown <alanb at digistar dot com>
Sat, 18 Dec 2004 10:48:35 -0500 (EST)
4. From APOP to PASSWORDS
Ezio Paglia <ezio at comune dot grosseto dot it>
Mon, 20 Dec 2004 12:39:20 +0100
5. Stats logging under Solaris 9
Tim Villa <tvilla at cyllene dot uwa dot edu dot au>
Thu, 23 Dec 2004 09:24:31 +0800
6. Re: Stats logging under Solaris 9
Chip Old <fold at bcpl dot net>
Wed, 22 Dec 2004 23:08:04 -0500 (EST)
7. Re: Stats logging under Solaris 9
David Champion <dgc at uchicago dot edu>
Thu, 23 Dec 2004 14:47:28 -0600
8. getting qpopper to work with SSL/TLS
"Jeff A dot Earickson" <jaearick at colby dot edu>
Wed, 29 Dec 2004 16:17:54 -0500 (EST)
9. Re: getting qpopper to work with SSL/TLS
Daniel Senie <dts at senie dot com>
Wed, 29 Dec 2004 16:42:10 -0500
10. 4.0.6b3 refuses to find qpopper.config file
"Jeff A dot Earickson" <jaearick at colby dot edu>
Mon, 3 Jan 2005 16:06:47 -0500 (EST)
11. log of qpopper becoming very big
JCS <jcsanchez at ccupm dot upm dot es>
Thu, 20 Jan 2005 18:42:03 +0100
12. qpopper and Mac OS 10.3.x (Panther)
James Medley <jmedley at aesrg dot tamu dot edu>
Wed, 26 Jan 2005 15:54:08 -0600
13. Re: qpopper and Mac OS 10.3.x (Panther)
Rudy Richter <rudy at esto dot gsfc dot nasa dot gov>
Fri, 28 Jan 2005 11:34:47 -0500
14. problem with xinetd.d
James Medley <jmedley at aesrg dot tamu dot edu>
Fri, 28 Jan 2005 12:53:13 -0600
15. RE: problem with xinetd.d
Mark <admin at asarian-host dot net>
Fri, 28 Jan 2005 21:25:09 GMT
16. log of qpopper becoming very big, second try
JCS <jcsanchez at ccupm dot upm dot es>
Wed, 02 Feb 2005 16:52:03 +0100
17. Re: log of qpopper becoming very big, second try
Clifton Royston <cliftonr at lava dot net>
Wed, 2 Feb 2005 08:54:03 -1000
18. qpopper 2.53 Error Msg
TaoZhi dot Hou at cn dot excelstor dot com
Thu, 3 Feb 2005 10:16:03 +0800
19. Re: qpopper 2.53 Error Msg
Ken A <ka at pacific dot net>
Thu, 03 Feb 2005 09:04:55 -0800
20. Re: qpopper and Mac OS 10.3.x (Panther)
Randall Gellens <randy at qualcomm dot com>
Thu, 3 Feb 2005 11:56:41 -0800
21. Cannot find ^?ELF^A^B^A Solaris9 qpopper 4.0.5
Roy_Harrison at notes dot rlg dot org
Fri, 4 Feb 2005 06:32:04 -0800
22. Re: Cannot find ^?ELF^A^B^A Solaris9 qpopper 4.0.5
Greg Earle <earle at isolar dot DynDNS dot ORG>
Fri, 4 Feb 2005 09:01:37 -0800
23. Re: Cannot find ^?ELF^A^B^A Solaris9 qpopper 4.0.5
Roy_Harrison at notes dot rlg dot org
Fri, 4 Feb 2005 11:55:45 -0800
24. Re: Cannot find ^?ELF^A^B^A Solaris9 qpopper 4.0.5
Greg Earle <earle at isolar dot DynDNS dot ORG>
Fri, 4 Feb 2005 13:30:21 -0800
25. Re: qpopper 2.53 Error Msg
Randall Gellens <randy at qualcomm dot com>
Mon, 7 Feb 2005 14:24:38 -0800
26. Re: 4.0.6b3 refuses to find qpopper.config file
Randall Gellens <randy at qualcomm dot com>
Mon, 7 Feb 2005 14:50:14 -0800
27. QPopper LDAP support
"Geronimo Poppino" <gpoppino at novell dot com>
Wed, 23 Feb 2005 11:48:51 -0700
28. Re: QPopper LDAP support
Tim Villa <tvilla at cyllene dot uwa dot edu dot au>
Thu, 24 Feb 2005 09:41:14 +0800
29. error flushing output to client
Netlink Tech <tech at netlinkcom dot com>
Wed, 2 Mar 2005 12:44:05 -0600 (CST)
30. Re: error flushing output to client
Tim Villa <tvilla at cyllene dot uwa dot edu dot au>
Thu, 03 Mar 2005 11:22:39 +0800
31. Re: error flushing output to client
Netlink Tech <tech at netlinkcom dot com>
Thu, 3 Mar 2005 06:40:36 -0600 (CST)
32. patch submission?
Sylvain Robitaille <syl at alcor dot concordia dot ca>
Wed, 23 Mar 2005 13:41:00 -0500 (EST)
33. Re: patch submission?
"Joe Maimon" <jmaimon at ttec dot com>
Wed, 23 Mar 2005 13:57:22 -0500 (EST)
34. Re: patch submission?
Sylvain Robitaille <syl at alcor dot concordia dot ca>
Wed, 23 Mar 2005 17:27:13 -0500 (EST)
35. Re: patch submission?
Clifton Royston <cliftonr at lava dot net>
Wed, 23 Mar 2005 12:45:33 -1000
36. Re: patch submission?
Greg Earle <earle at isolar dot DynDNS dot ORG>
Wed, 23 Mar 2005 15:14:03 -0800
37. poppassd (epass) status?
"Alan W dot Rateliff, II" <lists at rateliff dot net>
Thu, 24 Mar 2005 16:45:31 -0500
38. Re: patch submission?
Sylvain Robitaille <syl at alcor dot concordia dot ca>
Fri, 25 Mar 2005 02:06:57 -0500 (EST)
39. Mail Relay not allowed
Roy_Harrison at notes dot rlg dot org
Fri, 1 Apr 2005 12:12:10 -0800
40. Re: Mail Relay not allowed
Roy_Harrison at notes dot rlg dot org
Fri, 1 Apr 2005 12:24:31 -0800
41. I/O EOF Help - I'm stuck...
"Phil Kemp" <kemp at pkemp dot com>
Mon, 18 Apr 2005 11:50:38 -0700
42. Re: I/O EOF Help - I'm stuck...
"Phil Kemp" <kemp at pkemp dot com>
Mon, 18 Apr 2005 12:42:27 -0700
43. Re: I/O EOF Help - I'm stuck...
Sylvain Robitaille <syl at alcor dot concordia dot ca>
Mon, 18 Apr 2005 15:23:19 -0400 (EDT)
44. Re: I/O EOF Help - I'm stuck...
Sylvain Robitaille <syl at alcor dot concordia dot ca>
Tue, 19 Apr 2005 13:03:10 -0400 (EDT)
45. Re: I/O EOF Help - I'm stuck...
Randall Gellens <randy at qualcomm dot com>
Wed, 20 Apr 2005 11:23:20 -0700
46. Re: I/O EOF Help - I'm stuck...
"Phil Kemp" <kemp at pkemp dot com>
Wed, 20 Apr 2005 12:15:32 -0700
47. Re: I/O EOF Help - I'm stuck...
Randall Gellens <randy at qualcomm dot com>
Wed, 20 Apr 2005 14:26:35 -0700
48. Re: I/O EOF Help - I'm stuck...
Clifton Royston <cliftonr at lava dot net>
Wed, 20 Apr 2005 11:51:18 -1000
49. Re: I/O EOF Help - I'm stuck...
Ken A <ka at pacific dot net>
Wed, 20 Apr 2005 15:48:56 -0700
50. Re: I/O EOF Help - I'm stuck...
Daniel Senie <dts at senie dot com>
Wed, 20 Apr 2005 23:21:15 -0400
Date: Thu, 16 Dec 2004 16:48:13 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: qpopper test suite
At 12:58 PM -0500 9/13/04, Ladar Levison wrote:
> Is there a test suite to look for common security vulnerabilities,
> ie. buffer overflows?
I do have a test program I wrote that checks for buffer overflows.
It's currently only available to Qpopper developers, but that's just
because it's in with the rest of the development tools. You're
welcome to join the developer team, of course.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Kids Make Nutritious Snacks
--Newspaper headline
From: "Lisa Casey" <lisa at jellico dot net>
Subject: Re: .pop lockfile
Date: Fri, 17 Dec 2004 10:27:27 -0500
Hi,
Regarding .pop lock files: if most of your customers are using an MS mail
client (Outlook Express, Outlook), try increasing the server timeout in
their settings. Microsoft's default is one minute. We have found that, by
increasing the server timeout on their end we get a lot fewer pop locks.
Lisa Casey
Netlink 2000, Inc.
----- Original Message -----
From: "Randall Gellens" <randy@qualcomm.com>
To: <popper@admin.mcb.net>; "Subscribers of Qpopper"
<qpopper@lists.pensive.org>
Sent: Thursday, December 16, 2004 7:45 PM
Subject: Re: .pop lockfile
> At 10:48 AM +0000 12/2/04, <popper@admin.mcb.net> wrote:
>
> > Is there a quick way to unlock a users mailbox after a failed pickup of
> > emails? Currently, we have to tell our users if this happens they must
> > wait approximately 20 mins for the mailbox to unlock itself and some
are
> > finding this unacceptable.
> >
> > We are running qpopper 4.05 on redhat9. It is also run in server mode.
>
> Try 4.0.6b3 (available at
> <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta>). It
> includes a work-around for a situation seen on some Linux systems
> where the timeout signal gets masked. This might help in your case.
> Please report back.
> --
> Randall Gellens
> Opinions are personal; facts are suspect; I speak for myself only
> -------------- Randomly-selected tag: ---------------
> Just because your doctor has a name for your condition doesn't mean he
> knows what it is.
>
Date: Sat, 18 Dec 2004 10:48:35 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: .pop lockfile
On Fri, 17 Dec 2004, Lisa Casey wrote:
> Regarding .pop lock files: if most of your customers are using an MS mail
> client (Outlook Express, Outlook), try increasing the server timeout in
> their settings. Microsoft's default is one minute. We have found that, by
> increasing the server timeout on their end we get a lot fewer pop locks.
In many cases it is easier to remove one's eyes with a rusty spoon than
to walk a customer through changing their settings.
This is particularly so with those insisting on using Outlook/OE
Many places have banned these packages for security reasons, many ISPs
have issued security warnings about these programs.
In preferenece to getting someone to change their timeouts, consider
migrating them to something more secure such as Thunderbird.
Date: Mon, 20 Dec 2004 12:39:20 +0100
From: Ezio Paglia <ezio at comune dot grosseto dot it>
Subject: From APOP to PASSWORDS
Hi all,
some users ask to go towards a PASSWORDS authentication.
I do not know their password, but obviouslly I have the popath gdbm file.
Looking at its content I only see sequences of unprintable characters for
each username. Do you know how can I revert to the plain text password in
order to reassign them to a PASSWORDS authentication through a popauth
-delete and and a passwd command ?
Ciao and thank you.
Yours Ezio.
--
Ezio Paglia
Sistema Informativo e Architetture
SED Comune di Grosseto
Date: Thu, 23 Dec 2004 09:24:31 +0800
From: Tim Villa <tvilla at cyllene dot uwa dot edu dot au>
Subject: Stats logging under Solaris 9
Hi all,
After reading through the list archives and all manner of resources, I'm
stumped as to why my POP stats are not being logged. I'm using the
"--enable-log-login" and "--enable-log-facility=LOG_LOCAL0" configure
options, and while the login information shows up as it should, the Stats
do not. They do work fine on my old mail server (Sol 8) however.
In /etc/syslog.conf I've tried both:
local0.debug /var/log/local0.log
and
local0.debug ifdef(`LOGHOST', /var/log/local0.log, @loghost)
with "loghost" the current machine in the DNS.
In /etc/inetd.conf I've specified the -s argument (and also tried a trace
file, which does result in debugging information being logged).
Everything seems to log EXCEPT the damned statistics!!
Any suggestions?
Thanks
Tim
--
Tim Villa, Network / Systems Administrator
M252, Business School and Law School
The University of Western Australia CRICOS provider number 00126G
Phone: +61-8-6488-1796, Fax: +61-8-6488-1068
Mail <mailto:tvilla@cyllene.uwa.edu.au> WWW <http://timvilla.com/>
Date: Wed, 22 Dec 2004 23:08:04 -0500 (EST)
From: Chip Old <fold at bcpl dot net>
Subject: Re: Stats logging under Solaris 9
On Thu, 23 Dec 2004 09:24 +0800, Tim Villa wrote:
> After reading through the list archives and all manner of resources, I'm
> stumped as to why my POP stats are not being logged. I'm using the
> "--enable-log-login" and "--enable-log-facility=LOG_LOCAL0" configure
> options, and while the login information shows up as it should, the
> Stats do not. They do work fine on my old mail server (Sol 8) however.
>
> In /etc/syslog.conf I've tried both:
>
> local0.debug /var/log/local0.log
> and
> local0.debug ifdef(`LOGHOST', /var/log/local0.log,
> @loghost)
>
> with "loghost" the current machine in the DNS.
>
> In /etc/inetd.conf I've specified the -s argument (and also tried a trace
> file, which does result in debugging information being logged).
>
> Everything seems to log EXCEPT the damned statistics!!
We had a similar situation when we upgraded to Solaris 9. That was so
long ago, I don't remember all the gory details, but I'll piece together
what I can.
Your syslog.conf entry isn't the problem. If it allows qpopper to write
entries for pop logins, it will allow qpopper to write session statistics.
For example, here's the relevant entry in my syslog.conf:
# POP3 server logs to local0
local0.debug /var/adm/poplog
The problem is that qpopper doesn't write statistics by default, and for
some reason invoking it from inetd.conf with the -s option stopped working
once we moved to Sol 9. After messing around with it for a while
I eventually did a plain vanilla compile and used a configuration file
instead. You'll find a sample config file in the tarball. The relevant
lines are:
set statistics = true
set timing = true
set log-login = "(v%0) POP login by user '%1' at (%2) %3"
That gives you a login entry, a statistics entry, and a timing entry for
each session.
Popper is invoked by inetd with the following /etc/inet/inetd.conf entry:
pop3 stream tcp nowait root /usr/local/lib/popper popper -f
/usr/local/etc/qpopper.conf
That's all one line, of course. The -f flag tells popper to use
/usr/local/etc/qpopper.conf as its configuration file.
Works fine for us. YMMV.
--
Chip Old (Francis E. Old) E-Mail: fold@bcpl.net
BCPL Network Operations Administrator Phone: 410-887-6180
BCPL.NET Internet Services Administrator FAX: 410-887-2091
320 York Road
Towson, MD 21204-5179 USA
Date: Thu, 23 Dec 2004 14:47:28 -0600
From: David Champion <dgc at uchicago dot edu>
Subject: Re: Stats logging under Solaris 9
> On Thu, 23 Dec 2004 09:24 +0800, Tim Villa wrote:
>
> >In /etc/inetd.conf I've specified the -s argument (and also tried a trace
> >file, which does result in debugging information being logged).
I don't know whether this solves your problem, but as Chip suggests, do
use a config file. Many inetds, including Solaris's, place a limit of
five command-line arguments in the argv[] array of the command being
executed. If you give more than that, the "extras" are silently ignored.
--
-D. dgc@uchicago.edu NSIT::ENSS
"There are things in this country that the market will not provide ....
things that are not profitable, but that still serve a value. The most
important thing that we can do is to treat Americans as citizens, not
just consumers." -- Bill Moyers
Date: Wed, 29 Dec 2004 16:17:54 -0500 (EST)
From: "Jeff A dot Earickson" <jaearick at colby dot edu>
Subject: getting qpopper to work with SSL/TLS
Help...
I'm attempting to get either 4.0.5 or 4.0.6b3 to work with
OpenSSL, on Solaris 9. I built the code with "--with-openssl=/opt/openssl",
where my openssl code is installed. The code compiled and loaded
with no complaints. I've got my certs in place and they work
(I use IMAP too so I know this).
I configured the qpopper.config file with:
set clear-text-password = never
set tls-support = stls
set tls-server-cert-file = /opt/openssl/ssl/certs/mail-hub.cert
set tls-workarounds = true
set timing = true
Running the code in debug mode, telnetting to port 110, and entering:
user testuser
pass testpass
I see in my debug trace-file:
Dec 29 16:04:44.563 2004 [14245] before TLS; tls_support==0 [popper.c:181]
Dec 29 16:04:44.563 2004
Dec 29 16:04:44.563 2004 [14245] Skipped TLS Init [popper.c:205]
right up at the top, before the the user and passwd info exchange even
happens. Hunh?? Why does the "if ( p.tls_support != QPOP_TLS_NONE )"
test in popper.c seem to fail? What have I missed?
Jeff Earickson
Colby College
Date: Wed, 29 Dec 2004 16:42:10 -0500
From: Daniel Senie <dts at senie dot com>
Subject: Re: getting qpopper to work with SSL/TLS
At 04:17 PM 12/29/2004, Jeff A. Earickson wrote:
>Help...
>
>I'm attempting to get either 4.0.5 or 4.0.6b3 to work with
>OpenSSL, on Solaris 9. I built the code with "--with-openssl=/opt/openssl",
>where my openssl code is installed. The code compiled and loaded
>with no complaints. I've got my certs in place and they work
>(I use IMAP too so I know this).
>
>I configured the qpopper.config file with:
>
>set clear-text-password = never
>set tls-support = stls
>set tls-server-cert-file = /opt/openssl/ssl/certs/mail-hub.cert
Looks like you're not telling it where to find the private key. May not be
the only issue, but it's one issue.
>set tls-workarounds = true
>set timing = true
>
>Running the code in debug mode, telnetting to port 110, and entering:
Before issuing a USER command, issue a CAPA command and see what's listed.
Clients will do this and then issue an STLS command if the CAPA said it was
available. Once you've logged in, it's too late to protect the password.
Your config above indicated clear-text-password never, so don't expect much
with your test below.
>user testuser
>pass testpass
>
>I see in my debug trace-file:
>
>Dec 29 16:04:44.563 2004 [14245] before TLS; tls_support==0 [popper.c:181]
>Dec 29 16:04:44.563 2004
>Dec 29 16:04:44.563 2004 [14245] Skipped TLS Init [popper.c:205]
>
>right up at the top, before the the user and passwd info exchange even
>happens. Hunh?? Why does the "if ( p.tls_support != QPOP_TLS_NONE )"
>test in popper.c seem to fail? What have I missed?
>
>Jeff Earickson
>Colby College
Date: Mon, 3 Jan 2005 16:06:47 -0500 (EST)
From: "Jeff A dot Earickson" <jaearick at colby dot edu>
Subject: 4.0.6b3 refuses to find qpopper.config file
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---559023410-341603450-1104786407=:10592
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Hi,
I'm working on getting TLS going with 4.0.5 and 4.0.6b3,
and I've discovered that 4.0.6b3 refuses to find/read the
qpopper.config file. 4.0.5 has no problems with this, using the
same file.
Platform: Solaris 9
Code compiled with the following settings:
CC=cc ./configure \
--prefix=/opt/maild \
--enable-debugging \
--enable-keep-temp-drop \
--enable-nonauth-file=/etc/pop.nonauth \
--enable-log-login \
--disable-hash-dir-check \
--disable-old-spool-loc \
--enable-hash-spool=3 \
--with-pam=pop3 \
--enable-uw-kludge \
--enable-temp-drop-dir=/var/spool/pop \
--enable-server-mode \
--enable-low-debug \
--with-openssl=/opt/openssl
Config file is: /opt/maild/qpopper.config, perms are 644 (attached).
/etc/inetd.conf entry on the server machine is:
pop3 stream tcp nowait root /opt/maild/popper popper -l 1 -f /opt/maild/qpopper.config -d -t /tmp/trace-file
What happens:
% telnet machine 110
Trying {IP number disguised]....
Connected to machine.colby.edu.
Escape character is '^]'.
Unable to process config file /opt/maild/qpopper.config
Connection to machine.colby.edu closed by foreign host.
(nothing appears in the trace-file)
Jeff Earickson
Colby College
---559023410-341603450-1104786407=:10592
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="qpopper.config"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.61.0501031606470.10592@garnet>
Content-Description:
Content-Disposition: attachment; filename="qpopper.config"
Iy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIyBTYW1wbGUgUXBvcHBlciA0
LjAgY29uZmlndXJhdGlvbiBmaWxlLg0KIw0KIyBUaGlzIGZpbGUgbGlzdHMg
YWxsIFFwb3BwZXIgY29uZmlndXJhdGlvbiBmaWxlIG9wdGlvbnMuICBUbyB1
c2UsDQojIGNvcHkgdGhlIGRlc2lyZWQgc2V0dGluZyB0byB5b3VyIG93biBj
b25maWd1cmF0aW9uIGZpbGUsIHJlbW92ZQ0KIyB0aGUgbGVhZGluZyAnIycg
YW5kIHNldCB0aGUgZGVzaXJlZCB2YWx1ZS4NCiMNCiMtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg0KDQoNCiMgQW4gaW50ZWdlciB2YWx1ZSBmb3IgdGhl
IG51bWJlciBvZiBzZWNvbmRzIHRvIGFubm91bmNlIGluDQojIHRoZSBDQVBB
IHJlc3BvbnNlIGZvciB0aGUgc2VydmVyJ3MgbWluaW11bSBsb2dpbiBkZWxh
eS4NCiMNCiMgRGVmYXVsdDogDQojDQojIHNldCBhbm5vdW5jZS1sb2dpbi1k
ZWxheSAgICAgPQ0KDQoNCiMgQW4gaW50ZWdlciB2YWx1ZSBmb3IgdGhlIG51
bWJlciBvZiBkYXlzIHRvIGFubm91bmNlIGluDQojIHRoZSBDQVBBIHJlc3Bv
bnNlIGZvciB0aGUgc2VydmVyJ3MgbWF4aW11bSBtZXNzYWdlDQojIHJldGVu
dGlvbiBwZXJpb2QuDQojDQojIERlZmF1bHQ6DQojDQojIHNldCBhbm5vdW5j
ZS1leHBpcmUgICAgICAgICAgPQ0KDQoNCiMgVGhlIGZ1bGwgcGF0aCB0byB0
aGUgYnVsbGV0aW5zIGRpcmVjdG9yeS4NCiMNCiMgRGVmYXVsdDogL3Zhci9z
cG9vbC9idWxscw0KIw0KIyBzZXQgYnVsbGRpciAgICAgICAgICAgICAgICAg
ID0gIi92YXIvc3Bvb2wvYnVsbHMiDQoNCg0KIyBTZXQgVFJVRSB0byBwZXJt
aXQgc2Vzc2lvbnMgdG8gY29udGludWUgZXZlbiBpZiB0aGUNCiMgYnVsbGV0
aW5zIGRhdGFiYXNlIGNhbid0IGJlIGFjY2Vzc2VkLiAgVGhpcyBwZXJtaXRz
DQojIHVzZXJzIHRvIGdldCB0aGVpciBtYWlsLCBidXQgdGhleSBtaWdodCBu
b3Qgc2VlIHNvbWUNCiMgYnVsbGV0aW5zIGZvciBhIHdoaWxlLCBvciBhdCBh
bGwuDQojDQojIE9ubHkgdmFsaWQgd2hlbiBjb21waWxlZCB3aXRoICctLWVu
YWJsZS1idWxsZGInLg0KIw0KIyBEZWZhdWx0OiBmYWxzZS4NCiMNCiMgc2V0
IGJ1bGxkYi1ub25mYXRhbCAgICAgICAgICA9IGZhbHNlDQoNCg0KIyBTZXRz
IHRoZSBtYXhpbXVtIG51bWJlciBvZiBhdHRlbXB0cyB0byBsb2NrIHRoZSBi
dWxsZXRpbnMNCiMgZGF0YWJhc2UuICBZb3Ugbm9ybWFsbHkgZG8gbm90IG5l
ZWQgdG8gYWRqdXN0IHRoaXMuICBUaGlzIHZhbHVlDQojIHNob3VsZCBvbmx5
IGJlIGNoYW5nZWQgaWYgeW91IGtub3cgaWYgeW91ciBzeXN0ZW0gaGFzIHVz
bGVlcCgzQykNCiMgb3Igbm90LiAgT24gc3lzdGVtcyB3aXRoIHVzbGVlcCgz
QyksIHRoaXMgY2FuIGJlIGEgbGFyZ2UgdmFsdWUNCiMgKHRoZSBkZWZhdWx0
IGlzIDc1KS4gIE9uIHN5c3RlbXMgd2l0aG91dCB1c2xlZXAoM0MpLCB0aGlz
IHNob3VsZA0KIyByZW1haW4gc21hbGwgKHRoZSBkZWZhdWx0IGlzIDEwKS4N
CiMNCiMgT25seSB2YWxpZCB3aGVuIGNvbXBpbGVkIHdpdGggJy0tZW5hYmxl
LWJ1bGxkYicuDQojDQojIERlZmF1bHQ6IDc1ICgxMCBvbiBzeXN0ZW1zIHdp
dGhvdXQgdXNsZWVwKDNjKSkuDQojDQojIHNldCBidWxsZGItbWF4LXRyaWVz
ICAgICAgICAgPSA3NQ0KDQoNCiMgU2V0cyBjbGVhciB0ZXh0IGhhbmRsaW5n
IG9wdGlvbnMuICBWYWx1ZXMgYXJlOg0KIyAgICBvICdkZWZhdWx0JyAgQ2xl
YXIgdGV4dCBwYXNzd29yZHMgYXJlIHBlcm1pdHRlZCBmb3IgYWxsIHVzZXJz
LA0KIyAgICAgICAgICAgICAgICAgZXhjZXB0IHRob3NlIGluIHRoZSBBUE9Q
IGRhdGFiYXNlDQojICAgIG8gJ25ldmVyJyAgICBDbGVhciB0ZXh0IHBhc3N3
b3JkcyBhcmUgbmV2ZXIgcGVybWl0dGVkDQojICAgIG8gJ2Fsd2F5cycgICBD
bGVhciB0ZXh0IHBhc3N3b3JkcyBhcmUgYWx3YXlzIHBlcm1pdHRlZA0KIyAg
ICBvICdsb2NhbCcgICAgQ2xlYXIgdGV4dCBwYXNzd29yZHMgYXJlIHBlcm1p
dHRlZCBvbiB0aGUgbG9jYWwNCiMgICAgICAgICAgICAgICAgICgxMjcuKi4q
LiopIGxvb3AgYmFjayBpbnRlcmZhY2Ugb25seQ0KIyAgICBvICd0bHMnICAg
ICAgQ2xlYXIgdGV4dCBwYXNzd29yZHMgYXJlIHBlcm1pdHRlZCB3aGVuIFRM
Uy9TU0wNCiMgICAgICAgICAgICAgICAgIGhhcyBiZWVuIG5lZ290aWF0ZWQg
Zm9yIHRoZSBzZXNzaW9uDQojICAgIG8gJ3NzbCcgICAgICBTYW1lIGFzIHRs
cw0KIw0KIyBUaGUgJ3RscycgYW5kICdzc2wnIHZhbHVlcyBhcmUgb25seSB2
YWxpZCBpZiAnLS13aXRoLW9wZW5zc2wnIG9yDQojICctLXdpdGgtc3NscGx1
cycgd2FzIHVzZWQgd2l0aCAuL2NvbmZpZ3VyZS4NCiMNCiMgRGVmYXVsdDog
ZGVmYXVsdA0KIw0Kc2V0IGNsZWFyLXRleHQtcGFzc3dvcmQgICAgICA9IG5l
dmVyDQoNCg0KIyBSZWFkcyBhZGRpdGlvbmFsIHJ1bi10aW1lIG9wdGlvbnMg
ZnJvbSB0aGUgc3BlY2lmaWVkIGZpbGUuDQojDQojICAgICAgICAgICBDYXV0
aW9uLiBUaGVyZSBhcmUgbm8gcmVzdHJpY3Rpb25zIG9uIHdoaWNoIG9wdGlv
bnMgbWF5DQojICAgICAgICAgICBhcHBlYXIgaW4gZmlsZXMgc3BlY2lmaWVk
IHdpdGggdGhlICctZicgY29tbWFuZC1saW5lIGZsYWcNCiMgICAgICAgICAg
IG9yIHRoZSAnY29uZmlnLWZpbGUnIGNvbmZpZ3VyYXRpb24gZmlsZSBvcHRp
b24gaW4gZmlsZXMgDQojICAgICAgICAgICBjaGFpbmVkIGZyb20gLWYuICBC
ZSBjZXJ0YWluIHRoYXQgdGhlIGZpbGUgc3BlY2lmaWVkIHdpdGgNCiMgICAg
ICAgICAgICctZicgb3IgaW4gYW55IGZpbGVzIGl0IGNoYWlucyB0byBhcmUg
bm90IHdyaXRhYmxlIGJ5DQojICAgICAgICAgICB1c2Vycy4NCiMNCiMgRGVm
YXVsdDogbm9uZQ0KIw0KIyBzZXQgY29uZmlnLWZpbGUgICAgICAgICAgICAg
ID0gL2V0Yy9tYWlsL3BvcC9xcG9wcGVyLmNvbmZpZw0KDQoNCiMgRW5hYmxl
cyBkZWJ1ZyBsb2dnaW5nLiAgT3V0cHV0IGlzIGluIHN5c2xvZy4gIElmIHRo
aXMgb3B0aW9uIGlzIHVzZWQsDQojIGl0IHNob3VsZCBiZSBmaXJzdCwgc28g
dGhhdCBkZWJ1ZyByZWNvcmRzIGFyZSBnZW5lcmF0ZWQgZm9yIHN1YnNlcXVl
bnQNCiMgb3B0aW9ucy4NCiMNCiMgT25seSB2YWxpZCBpZiAuL2NvbmZpZ3Vy
ZSB3YXMgcnVuIHdpdGggJy0tZW5hYmxlLWRlYnVnZ2luZycNCiMNCiMgRGVm
YXVsdDogZmFsc2UNCiMNCiMgc2V0IGRlYnVnICAgICAgICAgICAgICAgICAg
ICA9IGZhbHNlDQoNCg0KIyBDaGFuZ2VzIHVwcGVyY2FzZSB1c2VyIG5hbWVz
IHRvIGxvd2VyY2FzZS4gIFRoaXMgcGVybWl0cyB1c2VycyB0bw0KIyBjb25m
aWd1cmUgdGhlaXIgY2xpZW50cyB3aXRoIHVzZXIgbmFtZXMgaW4gVVBQRVIg
b3IgTWlYZUQgY2FzZS4NCiMgVGhleSBjYW4gdGhlbiBsb2dpbiwgYXNzdW1p
bmcgdGhlaXIgYWN0dWFsIHVzZXIgbmFtZSBpcyBhbGwNCiMgbG93ZXJjYXNl
Lg0KIw0KIyBEZWZhdWx0OiBmYWxzZQ0KIw0KIyBzZXQgZG93bmNhc2UtdXNl
ciAgICAgICAgICAgID0gZmFsc2UNCg0KDQojIElmICctLXdpdGgtZHJhYycg
dXNlZCB3aXRoIC4vY29uZmlndXJlLCB0aGlzIG9wdGlvbiBzcGVjaWZpZXMg
dGhlIERSQUMgDQojIGhvc3QuDQojDQojIERlZmF1bHQ6IGxvY2FsaG9zdA0K
Iw0KIyBzZXQgZHJhYy1ob3N0ICAgICAgICAgICAgICAgID0gbG9jYWxob3N0
DQoNCg0KIyBFbmFibGVzIEtlcmJlcm9zIHN1cHBvcnQuDQojDQojIE9ubHkg
dmFsaWQgaWYgLi9jb25maWd1cmUgcnVuIHdpdGggJy0tZW5hYmxlLWtlcmJl
cm9zNScuDQojDQojIERlZmF1bHQ6IGZhbHNlDQojDQojIHNldCBrZXJiZXJv
cyAgICAgICAgICAgICAgICAgPSBmYWxzZQ0KDQoNCiMgU3BlY2lmaWVzIHRo
ZSBLZXJiZXJvcyBzZXJ2aWNlIHRvIHVzZSAoc2FtZSBhcyB0aGUgY29tcGls
ZSB0aW1lDQojIEtFUkJFUk9TX1NFUlZJQ0UgZGVmaW5lKS4gVGhlIGRlZmF1
bHQgaXMgcmNtZCwgYWx0aG91Z2ggdGhlIHVzZSBvZg0KIyBwb3AgaXMgcG9w
dWxhci4NCiMNCiMgT25seSB2YWxpZCBpZiAuL2NvbmZpZ3VyZSBydW4gd2l0
aCAnLS1lbmFibGUta2VyYmVyb3M1Jy4NCiMNCiMgRGVmYXVsdDogcmNtZA0K
Iw0KIyBzZXQga2VyYmVyb3Mtc2VydmljZSAgICAgICAgID0gInJjbWQiDQoN
Cg0KIyBDaGVja3MgaWYgbWFpbCBsb2NrIG5lZWRzIHRvIGJlIHJlZnJlc2hl
ZCBldmVyeSB0aGlzIG1hbnkgbWVzc2FnZXMuDQojDQojIFlvdSBub3JtYWxs
eSBkbyBub3QgbmVlZCB0byBhZGp1c3QgdGhpcy4gIFNlZSAiUGVyZm9ybWFu
Y2UiIGluIHRoZQ0KIyBRcG9wcGVyIEFkbWluaXN0cmF0b3IncyBHdWlkZSBm
b3IgbW9yZSBpbmZvcm1hdGlvbi4NCiMNCiMgRGVmYXVsdDogDQojDQojIHNl
dCBtYWlsLWxvY2stY2hlY2sgICAgICAgICAgPQ0KDQoNCiMgRGlzYWJsZXMg
dGhlIHJldmVyc2UgbG9va3VwcyBvbiBjbGllbnQgSVAgYWRkcmVzc2VzLg0K
Iw0KIyBEZWZhdWx0OiB0cnVlDQojDQojIHNldCByZXZlcnNlLWxvb2t1cCAg
ICAgICAgICAgPSB0cnVlDQoNCg0KIyBFbmFibGVzIHNlcnZlciBtb2RlIGJ5
IGRlZmF1bHQuICBTZWUgdGhlIFFwb3BwZXIgQWRtaW5pc3RyYXRvcidzDQoj
IEd1aWRlIGZvciBtb3JlIGluZm9ybWF0aW9uLg0KIw0KIyBEZWZhdWx0OiBm
YWxzZQ0KIw0KIyBzZXQgc2VydmVyLW1vZGUgICAgICAgICAgICAgID0gZmFs
c2UNCg0KDQojIEVuYWJsZXMgc3RhdGlzdGljcyBsb2dnaW5nLiAgQWZ0ZXIg
ZWFjaCBzZXNzaW9uIGVuZHMsIGEgc3RhdGlzdGljcw0KIyByZWNvcmQgaXMg
IHdyaXR0ZW4gdG8gdGhlIGxvZy4gIFRoaXMgcmVjb3JkIHJlc2VtYmxlcyB0
aGUgZm9sbG93aW5nDQojIGV4YW1wbGU6ICdzdGF0cyByYW5keSAwIDAgMSAz
ODUgcmFuZHkuZXhhbXBsZS5vcmcgMTkyLjE2OC4yLjQnIGFuZA0KIyBoYXMg
dGhlIGZvbGxvd2luZyBtZWFuaW5nOg0KIyAgIFVzZXJuYW1lOiAncmFuZHkn
DQojICAgRGVsZXRlZCBtZXNzYWdlczogMA0KIyAgIERlbGV0ZWQgb2N0ZXRz
OiAwDQojICAgTWVzc2FnZXMgbGVmdCBvbiBzZXJ2ZXI6IDENCiMgICBPY3Rl
dHMgbGVmdCBvbiBzZXJ2ZXI6IDM4NQ0KIyAgIE5hbWUgb2YgY2xpZW50IG1h
Y2hpbmU6ICdyYW5keS5leGFtcGxlLm9yZycNCiMgICBJUCBhZGRyZXNzIG9m
IGNsaWVudCBtYWNoaW5lOiAnMTkyLjE2OC4yLjQnDQojDQojIERlZmF1bHQ6
IGZhbHNlDQojDQojIHNldCBzdGF0aXN0aWNzICAgICAgICAgICAgICAgPSBm
YWxzZQ0KDQoNCiMgU2V0cyB0aGUgdGltZW91dCBmb3IgbmV0d29yayByZWFk
cy4gIFFwb3BwZXIgdGVybWluYXRlcyB0aGUNCiMgY29ubmVjdGlvbiB3aXRo
IHRoZSBjbGllbnQgaWYgbm8gaW5wdXQgaXMgcmVjZWl2ZWQgaW4gdGhpcw0K
IyBtYW55IHNlY29uZHMuICBSRkMgMTkzOSBzdGF0ZXMgdGhhdCB0aGlzIHRp
bWVvdXQgbXVzdCBiZQ0KIyA2MDAgc2Vjb25kcyAoMTAgbWludXRlcykuICBI
b3dldmVyLCBpZGVhbCBzZXR0aW5ncyBpbiBzb21lDQojIGNhc2VzIGFyZSBi
ZXR3ZWVuIDMwIGFuZCAxMjAgc2Vjb25kcy4gIEluIG90aGVyIGNhc2VzIHRo
ZSA2MDANCiMgdmFsdWUgaXMgYmVzdCwgYW5kIHNvbWV0aW1lcyBhIHZhbHVl
IGluIGJldHdlZW4gaXMgYmV0dGVyLg0KIw0KIyBEZWZhdWx0OiAxMjANCiMN
CnNldCB0aW1lb3V0ICAgICAgICAgICAgICAgICAgPSAzMDANCg0KDQojIEVu
YWJsZXMgZGVidWcgbG9nZ2luZyBpZiAnLS1lbmFibGUtZGVidWdnaW5nJyB3
YXMgdXNlZCB3aXRoDQojIC4vY29uZmlndXJlLiAgQWxsIGRlYnVnIGFuZCBz
dGFuZGFyZCBsb2cgcmVjb3JkcyBhcmUgd3JpdHRlbiB0bw0KIyB0aGUgc3Bl
Y2lmaWVkIGZpbGUuICBJZiB0aGlzIG9wdGlvbiBpcyB1c2VkLCBpdCBzaG91
bGQgYmUgZmlyc3QsDQojIHNvIHRoYXQgZGVidWcgcmVjb3JkcyBhcmUgZ2Vu
ZXJhdGVkIGZvciBzdWJzZXF1ZW50IG9wdGlvbnMuDQojDQojIElmIHVzZWQg
d2l0aG91dCAnLS1lbmFibGUtZGVidWdnaW5nJywgcmVkaXJlY3RzIGFsbCBs
b2cgbWVzc2FnZXMNCiMgdG8gdGhlIHNwZWNpZmllZCBmaWxlIGJ1dCBkb2Vz
IG5vdCBlbmFibGUgZGVidWcgbG9nZ2luZy4NCiMNCiMgRGVmYXVsdDogbm9u
ZQ0KIw0KIyBzZXQgdHJhY2VmaWxlICAgICAgICAgICAgICAgID0NCg0KDQoj
IFJlYWRzIGFkZGl0aW9uYWwgcnVuLXRpbWUgb3B0aW9ucyBmcm9tIGEgZmls
ZSBuYW1lZA0KIyAnLnFwb3BwZXItb3B0aW9ucycgaW4gdGhlIHVzZXIncyBo
b21lIGRpcmVjdG9yeSwgaWYgcHJlc2VudC4NCiMNCiMgVGhpcyBmaWxlIGlz
IG5vcm1hbGx5IG93bmVkIGJ5IHRoZSB1c2VyLg0KIw0KIyBEZWZhdWx0OiBm
YWxzZQ0KIw0KIyBzZXQgdXNlci1vcHRpb25zICAgICAgICAgICAgID0gZmFs
c2UNCg0KDQojIFJlYWRzIGFkZGl0aW9uYWwgcnVuLXRpbWUgb3B0aW9ucyBm
cm9tIGEgZmlsZSBuYW1lZA0KIyAndXNlcm5hbWUucXBvcHBlci1vcHRpb25z
JyBpbiB0aGUgc3Bvb2wgZGlyZWN0b3J5Lg0KIw0KIyBUaGlzIGZpbGUgc2hv
dWxkIG5vdCBiZSBvd25lZCBieSBub3Igd3JpdGFibGUgYnkgdGhlIHVzZXIu
DQojDQojIERlZmF1bHQ6IGZhbHNlDQojDQojIHNldCBzcG9vbC1vcHRpb25z
ICAgICAgICAgICAgPSBmYWxzZQ0KDQoNCiMgV2hlbiB1cGRhdGluZyB0aGUg
c3Bvb2wgYXQgdGhlIGVuZCBvZiBhIHNlc3Npb24sIHRoaXMgb3B0aW9uDQoj
IGluc3RydWN0cyBRcG9wcGVyIHRvIHJlbmFtZSB0aGUgdGVtcG9yYXJ5IGZp
bGUgdG8gdGhlIHNwb29sIGluc3RlYWQNCiMgb2YgY29weWluZyBpdC4gIFRo
aXMgcmVkdWNlcyBJL08gYXQgc2Vzc2lvbiBlbmQgYnkgYSB0aGlyZCwgYnV0
IGlzDQojIGxpa2VseSB0byBicmVhayBwcm9ncmFtcyBzdWNoIGFzIGJpZmYg
b3IgdGhlIHNoZWxsJ3MgbWFpbCBjaGVjaw0KIyBmZWF0dXJlLiAgVXNlIHRo
aXMgb3B0aW9uIG9ubHkgaWYgc3VjaCBwcm9ncmFtcyBhcmUgbm90IHVzZWQu
ICBJdCBpcw0KIyBzYWZlc3QgdG8gb25seSBlbmFibGUgdGhpcyBvcHRpb24g
d2hlbiB1c2VycyBkbyBub3QgaGF2ZSBzaGVsbA0KIyBhY2Nlc3MgdG8gdGhl
IG1haWwgc2VydmVyLg0KIw0KIyBTZWUgIlBlcmZvcm1hbmNlIiBpbiB0aGUg
UXBvcHBlciBBZG1pbmlzdHJhdG9yJ3MgR3VpZGUgZm9yIG1vcmUNCiMgaW5m
b3JtYXRpb24uDQojDQojIERlZmF1bHQ6IGZhbHNlDQojDQojIHNldCBmYXN0
LXVwZGF0ZSAgICAgICAgICAgICAgPSBmYWxzZQ0KDQoNCiMgV2hlbiBzZXQs
IGRvbWFpbnMgYXJlIHRyaW1tZWQgZnJvbSB1c2VyIG5hbWVzIGJlZm9yZSB1
c2UuICBGb3INCiMgZXhhbXBsZSwgaWYgYSB1c2VyIG5hbWVkICdtYWlkYScg
ZW50ZXJzIGhlciBsb2dpbiBuYW1lIGluIGhlciBQT1ANCiMgY2xpZW50IGFz
ICdtYWlkYUBleGFtcGxlLm9yZycsIFFwb3BwZXIgdHJlYXRzIHRoaXMgYXMg
anVzdCAnbWFpZGEnLg0KIw0KIyBEZWZhdWx0OiBmYWxzZQ0KIw0KIyBzZXQg
dHJpbS1kb21haW4gICAgICAgICAgICAgID0gZmFsc2UNCg0KDQojIFNwZWNp
ZmllcyBUTFMvU1NMIHN1cHBvcnQuICBUaGUgcGVybWl0dGVkIHZhbHVlcyBh
cmU6DQojICAgIG8gJ2RlZmF1bHQnICAgICAgICAgVExTL1NTTCBpcyBub3Qg
c3VwcG9ydGVkDQojICAgIG8gJ25vbmUnICAgICAgICAgICAgU2FtZSBhcyBk
ZWZhdWx0DQojICAgIG8gJ3N0bHMnICAgICAgICAgICAgRW5hYmxlcyBzdXBw
b3J0IGZvciB0aGUgU1RMUyBjb21tYW5kLiBUaGlzDQojICAgICAgICAgICAg
ICAgICAgICAgICAgcGVybWl0cyBUTFMvU1NMIG5lZ290aWF0aW9ucyBvbiB0
aGUNCiMgICAgICAgICAgICAgICAgICAgICAgICBzdGFuZGFyZCAob3IgYW55
KSBwb3J0LCBhbGxvd2luZyB0aGUgc2FtZQ0KIyAgICAgICAgICAgICAgICAg
ICAgICAgIHBvcnQgdG8gYmUgdXNlZCBieSBUTFMvU1NMIGFuZCByZWd1bGFy
DQojICAgICAgICAgICAgICAgICAgICAgICAgY2xpZW50cy4NCiMgICAgbyAn
YWx0ZXJuYXRlLXBvcnQnICBFbmFibGVzIGFsdGVybmF0ZS1wb3J0IFRMUy9T
U0wuICBTb21lIG9sZGVyDQojICAgICAgICAgICAgICAgICAgICAgICAgY2xp
ZW50cyByZXF1aXJlIHRoaXMuIChUaGUgdXN1YWwgcG9ydCBmb3INCiMgICAg
ICAgICAgICAgICAgICAgICAgICBhbHRlcm5hdGUtcG9ydCBUTFMvU1NMIHdp
dGggcG9wIGlzIDk5NS4pDQojDQojIE9ubHkgdmFsaWQgd2hlbiAnLS13aXRo
LW9wZW5zc2wnIG9yICctLXdpdGgtc3NscGx1cycgdXNlZCB3aXRoDQojIC4v
Y29uZmlndXJlDQojDQojIERlZmF1bHQ6IGRlZmF1bHQNCiMNCnNldCB0bHMt
c3VwcG9ydCAgICAgICAgICAgICAgPSBzdGxzDQoNCg0KIyBTcGVjaWZpZXMg
dGhlIHBlcm1pdHRlZCBjaXBoZXIgc3VpdGVzLiAgU2VlIHRoZSBPcGVuU1NM
IGRvY3VtZW50YXRpb24NCiMgZm9yIHN5bnRheC4gIFlvdSBub3JtYWxseSBk
byBub3QgbmVlZCB0byBzZXQgdGhpcy4NCiMNCiMgT25seSB2YWxpZCB3aGVu
ICctLXdpdGgtb3BlbnNzbCcgdXNlZCB3aXRoIC4vY29uZmlndXJlDQojDQoj
IERlZmF1bHQ6IA0KIw0KIyBzZXQgdGxzLWNpcGhlci1saXN0ICAgICAgICAg
ID0NCg0KDQojIFJlc3RyaWN0cyB0aGUgdmVyc2lvbiBvZiBUTFMvU1NMIHJl
Y29nbml6ZWQgaW4gc2Vzc2lvbiBuZWdvdGlhdGlvbnMuDQojIFlvdSBub3Jt
YWxseSBkbyBub3QgbmVlZCB0byBzZXQgdGhpcy4gIFN1cHBvcnRlZCB2YWx1
ZXMgYXJlOg0KIyAgICBvICdkZWZhdWx0JyAoc2FtZSBhcyBTU0x2MjMpDQoj
ICAgIG8gJ1NTTHYyJyAgIEZvcmNlcyBRcG9wcGVyIG9ubHkgdG8gdW5kZXJz
dGFuZCBTU0x2MiBjbGllbnQgaGVsbG8NCiMgICAgICAgICAgICAgICAgbWVz
c2FnZXMuDQojICAgIG8gJ1NTTHYzJyAgIEZvcmNlcyBRcG9wcGVyIG9ubHkg
dG8gdW5kZXJzdGFuZCBTU0x2MyBjbGllbnQgaGVsbG8NCiMgICAgICAgICAg
ICAgICAgbWVzc2FnZXMuICBUaGlzIGVzcGVjaWFsbHkgbWVhbnMgdGhhdCBp
dCBkb2VzIG5vdA0KIyAgICAgICAgICAgICAgICB1bmRlcnN0YW5kIFNTTHYy
IGNsaWVudCBoZWxsbyBtZXNzYWdlcywgd2hpY2ggYXJlDQojICAgICAgICAg
ICAgICAgIHdpZGVseSB1c2VkIGZvciBjb21wYXRpYmlsaXR5IHJlYXNvbnMu
DQojICAgIG8gJ1RMU3YxJyAgIEZvcmNlcyBRcG9wcGVyIG9ubHkgdG8gdW5k
ZXJzdGFuZCBUTFN2MSBjbGllbnQgaGVsbG8NCiMgICAgICAgICAgICAgICAg
bWVzc2FnZXMuICBUaGlzIGVzcGVjaWFsbHkgbWVhbnMgdGhhdCBpdCBkb2Vz
IG5vdA0KIyAgICAgICAgICAgICAgICB1bmRlcnN0YW5kIFNTTHYyIGNsaWVu
dCBoZWxsbyBtZXNzYWdlcywgd2hpY2ggYXJlDQojICAgICAgICAgICAgICAg
IHdpZGVseSB1c2VkIGZvciBjb21wYXRpYmlsaXR5IHJlYXNvbnMuICBJdCBh
bHNvIGRvZXMNCiMgICAgICAgICAgICAgICAgbm90IHVuZGVyc3RhbmQgU1NM
djMgY2xpZW50IGhlbGxvIG1lc3NhZ2VzLg0KIyAgICBvICdTU0x2MjMnICBB
bGxvd3MgUXBvcHBlciB0byB1bmRlcnN0YW5kIFNTTHYyLCBTU0x2MywgYW5k
IFRMU3YxDQojICAgICAgICAgICAgICAgIGNsaWVudCBoZWxsbyBtZXNzYWdl
cy4gIFRoaXMgaXMgdGhlIGJlc3QgY2hvaWNlIHdoZW4NCiMgICAgICAgICAg
ICAgICAgY29tcGF0aWJpbGl0eSBpcyBhIGNvbmNlcm4uICBUaGlzIGlzIHRo
ZSBkZWZhdWx0DQojICAgICAgICAgICAgICAgIHZhbHVlLg0KIyAgICBvICdh
bGwnICAgICAoc2FtZSBhcyBTU0x2MjMpDQojDQojIE9ubHkgdmFsaWQgd2hl
biAnLS13aXRoLW9wZW5zc2wnIHVzZWQgd2l0aCAuL2NvbmZpZ3VyZQ0KIw0K
IyBEZWZhdWx0OiBkZWZhdWx0DQojDQojIHNldCB0bHMtdmVyc2lvbiAgICAg
ICAgICAgICAgPSBkZWZhdWx0DQoNCg0KIyBTcGVjaWZpZXMgdGhlIGZpbGUg
Y29udGFpbmluZyB0aGUgc2VydmVyJ3MgVExTL1NTTCBjZXJ0aWZpY2F0ZSBh
bmQNCiMgZW5jcnlwdGVkIHByaXZhdGUga2V5Lg0KIw0KIyBPbmx5IHZhbGlk
IGlmICctLXdpdGgtc3NscGx1cycgdXNlZCB3aXRoIC4vY29uZmlndXJlLg0K
Iw0KIyBEZWZhdWx0OiBub25lDQojDQojIHNldCB0bHMtaWRlbnRpdHktZmls
ZSAgICAgICAgPQ0KDQoNCiMgVGhpcyBvcHRpb24gYWxsb3dzIHZhcmlvdXMg
T3BlblNTTCBvcHRpb25zIHRvIGJlIHNldC4gIE9wZW5TU0wNCiMgb3B0aW9u
cyBhcmUgaW5kaXZpZHVhbCBiaXRzIHRoYXQgY29udHJvbCB2YXJpb3VzIHdv
cmstYXJvdW5kcy4NCiMNCiMgVGhlIGJpdCB2YWx1ZXMgYXJlIGxpc3RlZCBp
biBvcGVuc3NsL3NzbC5oLCBhbmQgc3RhcnQgd2l0aCBTU0xfT1BfLg0KIyBZ
b3UgbXVzdCBzcGVjaWZ5IHRoZSBhY3R1YWwgdmFsdWUgb2YgdGhlIGJpdChz
KSB5b3Ugd2FudCB0byBzZXQsDQojIG5vdCB0aGUgT3BlblNTTCBtbmVtb25p
Yy4NCiMNCiMgRm9yIGV4YW1wbGUsIHRvIHNldCBTU0xfT1BfRE9OVF9JTlNF
UlRfRU1QVFlfRlJBR01FTlRTLCBzZXQNCiMgdGxzLW9wdGlvbnMgdG8gMHgw
MDAwMDgwMC4NCiMNCiMgTm90ZSB0aGF0IHVubGlrZSBvdGhlciBvcHRpb25z
LCBpZiB5b3Ugc2V0IHRoaXMgb3B0aW9uIG1vcmUgdGhhbg0KIyBvbmNlLCB0
aGUgdmFsdWVzIGFyZSBhZGRlZCB0b2dldGhlci4gIEZvciBleGFtcGxlLCBp
ZiB5b3Ugc2V0DQojIHRscy1vcHRpb25zIHRvIDB4MDEsIGFuZCB0aGVuIGxh
dGVyIHNldCBpdCB0byAweDEwLCBpdCBnZXRzIHNldCB0bw0KIyAweDExLiAg
VGhpcyBtYWtlcyBpcyBzb21ld2hhdCBtb3JlIGNvbnZlbmllbnQgdG8gc2V0
IHZhcmlvdXMgU1NMDQojIG9wdGlvbnMgd2l0aG91dCBoYXZpbmcgdG8gbWFu
dWFsbHkgYWRkIHRoZW0gdG9nZXRoZXIuDQojDQojIE9ubHkgdmFsaWQgaWYg
Jy0td2l0aC1vcGVuc3NsJyB1c2VkIHdpdGggLi9jb25maWd1cmUNCiMNCiMg
RGVmYXVsdDogMA0KIw0KIyBzZXQgdGxzLW9wdGlvbnMgICAgICAgICAgICAg
ID0gMA0KDQoNCiMgU3BlY2lmaWVzIHRoZSBwYXNzcGhyYXNlIHRvIGRlY3J5
cHQgdGhlIHNlcnZlcidzIHByaXZhdGUga2V5IChpbiB0aGUNCiMgaWRlbnRp
ZnkgZmlsZSkuDQojDQojIE9ubHkgdmFsaWQgaWYgJy0td2l0aC1zc2xwbHVz
JyB1c2VkIHdpdGggLi9jb25maWd1cmUuDQojDQojIERlZmF1bHQ6IG5vbmUN
CiMNCiMgc2V0IHRscy1wYXNzcGhyYXNlICAgICAgICAgICA9DQoNCg0KIyBT
cGVjaWZpZXMgYSBmaWxlIHdoaWNoIGNvbnRhaW5zIHRoZSBzZXJ2ZXIncyBU
TFMvU1NMIHByaXZhdGUga2V5Lg0KIyBOb3RlOiBUaGlzIHByaXZhdGUga2V5
IG11c3Qgbm90IGJlIGVuY3J5cHRlZC4NCiMNCiMgSWYgdGhlIHByaXZhdGUg
a2V5IGlzIGNvbnRhaW5lZCBpbiB0aGUgc2FtZSBmaWxlIGFzIHRoZSBjZXJ0
aWZpY2F0ZQ0KIyAoYXMgc3BlY2lmaWVkIHdpdGggdGxzLXNlcnZlci1jZXJ0
LWZpbGUpLCB5b3UgZG8gbm90IG5lZWQgdG8gc2V0DQojIHRoaXMgb3B0aW9u
Lg0KIw0KIyBPbmx5IHZhbGlkIGlmICctLXdpdGgtb3BlbnNzbCcgdXNlZCB3
aXRoIC4vY29uZmlndXJlDQojDQojIERlZmF1bHQ6IG5vbmUNCiMNCnNldCB0
bHMtcHJpdmF0ZS1rZXktZmlsZSAgICAgPSAvb3B0L29wZW5zc2wvc3NsL3By
aXZhdGUvbWFpbC1odWIua2V5Lm5vcGFzc3dkDQoNCg0KIyBTcGVjaWZpZXMg
dGhlIGZpbGUgd2hpY2ggY29udGFpbnMgdGhlIHNlcnZlcidzIFRMUy9TU0wg
Y2VydGlmaWNhdGUuDQojIFRoaXMgZmlsZSBtYXkgYWxzbyBjb250YWluIHRo
ZSBzZXJ2ZXIncyB1bmVuY3J5cHRlZCBwcml2YXRlIGtleS4NCiMNCiMgT25s
eSB2YWxpZCBpZiAnLS13aXRoLW9wZW5zc2wnIHVzZWQgd2l0aCAuL2NvbmZp
Z3VyZQ0KIw0KIyBEZWZhdWx0OiBub25lDQojDQojDQpzZXQgdGxzLXNlcnZl
ci1jZXJ0LWZpbGUgICAgID0gL29wdC9vcGVuc3NsL3NzbC9jZXJ0cy9tYWls
LWh1Yi5jZXJ0DQoNCg0KIyBXaGVuIHNldCwgYW5kIFFwb3BwZXIgaXMgYmVp
bmcgdXNlZCB3aXRoIE9wZW5TU0wsIFFwb3BwZXIgZW5hYmxlcw0KIyBhbGwg
T3BlblNTTCB3b3JrYXJvdW5kcyBieSBzZXR0aW5nIHRoZSBTU0xfT1BfQUxM
IG9wdGlvbi4NCiMNCiMgT25seSB2YWxpZCBpZiAnLS13aXRoLW9wZW5zc2wn
IHVzZWQgd2l0aCAuL2NvbmZpZ3VyZQ0KIw0KIyBEZWZhdWx0OiBmYWxzZQ0K
Iw0Kc2V0IHRscy13b3JrYXJvdW5kcyAgICAgICAgICA9IHRydWUNCg0KDQoj
IFdoZW4gc2V0LCBRcG9wcGVyIHdyaXRlcyBhIGxvZyByZWNvcmQgYXQgdGhl
IGVuZCBvZiBhIHNlc3Npb24NCiMgY29udGFpbmluZyB0aGUgZWxhcHNlZCB0
aW1lIGZvciB0aGUgc2Vzc2lvbiBhdXRoZW50aWNhdGlvbiwNCiMgaW5pdGlh
bGl6YXRpb24uIGFuZCBjbGVhbnVwLg0KIw0KIyBEZWZhdWx0OiBmYWxzZQ0K
Iw0Kc2V0IHRpbWluZyAgICAgICAgICAgICAgICAgICA9IHRydWUNCg0KDQoj
IFdoZW4gc2V0LCBRcG9wcGVyIGNoZWNrcyBmb3Igb2xkIC51c2VyLnBvcCBm
aWxlcyBpbiBvbGQgbG9jYXRpb25zDQojIHdoZW4gaGFzaC1zcG9vbCBvciBo
b21lZGlybWFpbCBpcyB1c2VkLiAgV2hlbiByZXNldCwgUXBvcHBlciBza2lw
cw0KIyB0aGlzIGNoZWNrLCB3aGljaCBzcGVlZHMgdGhpbmdzIHVwLg0KIw0K
IyBEZWZhdWx0OiB0cnVlDQojDQojIHNldCBjaGVjay1vbGQtc3Bvb2wtbG9j
ICAgICAgPSB0cnVlDQoNCg0KIyBXaGVuIHNldCwgUXBvcHBlciBjaGVja3Mg
Zm9yIGFuZCBjcmVhdGVzIGlmIG5lZWRlZCB0aGUgaGFzaGVkIHNwb29sDQoj
IGRpcmVjdG9yaWVzLiAgV2hlbiByZXNldCwgUXBvcHBlciBkb2Vzbid0IGNo
ZWNrIGZvciBvciBjcmVhdGUgdGhlDQojIGhhc2hlZCBzcG9vbCBkaXJlY3Rv
cmllcy4gIFNldCB0byBmYWxzZSBpZiB5b3UgcHJlY3JlYXRlIHRoZQ0KIyBk
aXJlY3Rvcmllcy4NCiMNCiMgRGVmYXVsdDogdHJ1ZQ0KIw0KIyBzZXQgY2hl
Y2staGFzaC1kaXIgICAgICAgICAgID0gZmFsc2UNCg0KDQojIFdoZW4gc2V0
LCBRcG9wcGVyIGNoZWNrcyBmb3IgZXhwaXJlZCBwYXNzd29yZHMgKGlmIHRo
ZSBwbGF0Zm9ybQ0KIyBwZXJtaXRzKS4gIFdoZW4gcmVzZXQsIFFwb3BwZXIg
b21pdHMgdGhpcyBjaGVjay4NCiMNCiMgRGVmYXVsdDogdHJ1ZQ0KIw0KIyBz
ZXQgY2hlY2stcGFzc3dvcmQtZXhwaXJlZCAgID0gdHJ1ZQ0KDQoNCiMgRGV0
ZXJtaW5lcyB3aGV0aGVyIFFwb3BwZXIgdXBkYXRlcyB0aGUgcmVhZC91bnJl
YWQgc3RhdHVzIG9mDQojIG1lc3NhZ2VzIChhIGZlYXR1cmUgcmVsaWVkIG9u
IGJ5IHNvbWUgbWFpbCBjbGllbnRzKS4gIEFsc28NCiMgZGV0ZXJtaW5lcyBp
ZiBRcG9wcGVyIHNhdmVzIHRoZSBtZXNzYWdlJ3MgdW5pcXVlIGlkZW50aWZp
ZXINCiMgKFVJRCkgaW4gdGhlIHNwb29sLg0KIw0KIyBXaGVuIHJlc2V0LCBp
dCBmb3JjZXMgdGhlIFVJRCBmb3IgZXZlcnkgbWVzc2FnZSB0byBiZQ0KIyBy
ZWNhbGN1bGF0ZWQsIHVzaW5nIG1vcmUgQ1BVIGJ1dCBwb3RlbnRpYWxseSBs
ZXNzIEkvTy4NCiMNCiMgU2VlIHRoZSAiUGVyZm9ybWFuY2UiIHNlY3Rpb24g
b2YgdGhlIFFwb3BwZXIgQWRtaW5pc3RyYXRvcidzIEd1aWRlDQojIGZvciBt
b3JlIGluZm9ybWF0aW9uLg0KIw0KIyBEZWZhdWx0OiB0cnVlDQojDQojIHNl
dCB1cGRhdGUtc3RhdHVzLWhlYWRlcnMgICAgPSB0cnVlDQoNCg0KIyBEZXRl
cm1pbmVzIHdoZXRoZXIgUXBvcHBlciBlbnRlcnMgdXBkYXRlIHN0YXRlIHdo
ZW4gYSBzZXNzaW9uDQojIGFib3J0cy4gIFJlc2V0dGluZyB0aGlzIG9wdGlv
biBjYXVzZXMgUXBvcHBlciB0byBpZ25vcmUgYW55DQojIGRlbGV0aW9ucyBp
ZiB0aGUgc2Vzc2lvbiBpcyBhYm9ydGVkLg0KIw0KIyBOb3RlIHRoYXQgUkZD
IDE5MzksIHNlY3Rpb24gNiBwcm9oaWJpdHMgdGhlIGRlZmF1bHQgYmVoYXZp
b3IsDQojIGJ1dCBleHBlcmllbmNlIHNob3dlZCB0aGF0IG90aGVyd2lzZSB1
c2VycyBvbiBub2lzeSBsaW5lcyB3ZXJlDQojIG9mdGVuIHVuYWJsZSB0byBk
ZWxldGUgdGhlaXIgbWFpbC4gIFJlc2V0IHRoaXMgb3B0aW9uIHRvIGluaGli
aXQNCiMgdGhlIGRlZmF1bHQgYmVoYXZpb3IsIGFuZCBvYmV5IFJGQyAxOTM5
LCBidXQgd2F0Y2ggZm9yIHVzZXJzIHdobw0KIyBkb3dubG9hZCB0aGUgc2Ft
ZSBtZXNzYWdlcyBvdmVyIGFuZCBvdmVyLCBvciB3aG9zZSBzcG9vbHMgZmls
bCB1cC4NCiMNCiMgRGVmYXVsdDogdHJ1ZQ0KIw0KIyBzZXQgdXBkYXRlLW9u
LWFib3J0ICAgICAgICAgID0gdHJ1ZQ0KDQoNCiMgV2hlbiBzZXQsIFFwb3Bw
ZXIgYXV0b21hdGljYWxseSBhbmQgdW5jb25kaXRpb25hbGx5IGRlbGV0ZXMg
bWVzc2FnZXMNCiMgdGhhdCBoYXZlIGJlZW4gZG93bmxvYWRlZCB1c2luZyB0
aGUgUkVUUiBjb21tYW5kICh0aGUgbm9ybWFsIGNvbW1hbmQNCiMgZm9yIGFj
Y2Vzc2luZyBtZXNzYWdlcykuDQojDQojICAgICAgIENhdXRpb246IFRoaXMg
b3B0aW9uIGNvdWxkIHJlc3VsdCBpbiBsb3N0IG1haWwuICBCZSBzdXJlIHRv
DQojICAgICAgIGluZm9ybSB5b3VyIHVzZXJzIHRoYXQgdGhlIG9wdGlvbiBp
cyBpbiBlZmZlY3QgYmVmb3JlIGVuYWJsaW5nLg0KIw0KIyBEZWZhdWx0OiBm
YWxzZQ0KIw0KIyBzZXQgYXV0by1kZWxldGUgICAgICAgICAgICAgID0gZmFs
c2UNCg0KDQojIFdoZW4gc2V0LCBRcG9wcGVyIHNob3dzIGJ1bGxldGlucyB0
byB1c2VycyBieSBncm91cHMgKHRoZSBncm91cCBuYW1lDQojIGlzIHRoZSBz
ZWNvbmQgZG90LXNlcGFyYXRlZCBlbGVtZW50IGluIGVhY2ggYnVsbGV0aW4n
cyBuYW1lKS4gU2VlDQojICJVc2luZyBCdWxsZXRpbnMiIGluIHRoZSBRcG9w
cGVyIEFkbWluaXN0cmF0b3IncyBHdWlkZSBmb3IgbW9yZQ0KIyBpbmZvcm1h
dGlvbi4gIFVzZSBhIGdyb3VwIG5hbWUgb2YgJ0FMTCcgZm9yIGFsbCB1c2Vy
cy4NCiMNCiMgRGVmYXVsdDogZmFsc2UNCiMNCiMgc2V0IGdyb3VwLWJ1bGxl
dGlucyAgICAgICAgICA9IGZhbHNlDQoNCg0KIyBXaGVuIHNldCB0byBhIDEg
b3IgMiwgdGhlIHN1YmRpcmVjdG9yeSBmb3IgdGhlIG1haWwgc3Bvb2xzIGlz
DQojIGRldGVybWluZWQgZnJvbSB0aGUgdXNlciBuYW1lIGJ5IGVpdGhlciAo
MSkgaGFzaGluZyB0aGUgZmlyc3QgZm91cg0KIyBjaGFyYWN0ZXJzIG9yICgy
KSBieSB1c2luZyBkaXJlY3RvcmllcyBlcXVhbCB0byB0aGUgZmlyc3QgbGV0
dGVyIGFuZA0KIyB0aGUgc2Vjb25kIGxldHRlciAoaWYgYW55KS4gIEZvciBl
eGFtcGxlLCBpZiB0aGUgc3Bvb2wgZGlyZWN0b3J5IGlzDQojICcvdmFyL21h
aWwnLCB0aGUgc3Bvb2wgZmlsZSBmb3IgdXNlciAnbWFpZGEnIHdvdWxkIGJl
Og0KIyAgICAgICAnL3Zhci9tYWlsL21haWRhJyAgICAgICAgICAgICAgICBo
YXNoLXNwb29sID0gMA0KIyAgICAgICAnL3Zhci9tYWlsL28vbWFpZGEnICAg
ICAgICAgICAgICBoYXNoLXNwb29sID0gMQ0KIyAgICAgICAnL3Zhci9tYWls
L20vYS9tYWlkYScgICAgICAgICAgICBoYXNoLXNwb29sID0gMg0KIw0KIyBT
ZWUgdGhlICJQZXJmb3JtYW5jZSIgc2VjdGlvbiBvZiB0aGUgUXBvcHBlciBB
ZG1pbmlzdHJhdG9yJ3MgR3VpZGUNCiMgZm9yIG1vcmUgaW5mb3JtYXRpb24u
DQojDQojIERlZmF1bHQ6IDANCiMNCiMgc2V0IGhhc2gtc3Bvb2wgICAgICAg
ICAgICAgICA9IDANCg0KDQojIFRvIGhhdmUgdGhlIHVzZXIncyBob21lIGRp
cmVjdG9yeSBiZSB0aGUgc3Bvb2wgbG9jYXRpb24sIHNldCB0aGlzDQojIG9w
dGlvbiB0byBiZSB0aGUgY29ycmVjdCBmaWxlIG5hbWUgZm9yIHRoZSBzcG9v
bC4NCiMNCiMgRGVmYXVsdDogbm9uZQ0KIw0KIyBzZXQgaG9tZS1kaXItbWFp
bCAgICAgICAgICAgID0gIi5tYWlsIg0KDQoNCiMgV2hlbiBzZXQsIGluc3Ry
dWN0cyBRcG9wcGVyIHRvIGdlbmVyYXRlIG1lc3NhZ2UgdW5pcXVlIGlkZW50
aWZpZXJzDQojIChVSURzKSB1c2luZyBvbGQgKHByZS0zLngpIHN0eWxlIGVu
Y29kaW5nLiAgVGhpcyBpcyB1c2VmdWwgb25seSBpZg0KIyB5b3UgYWxzbyBz
ZXQgJ3VwZGF0ZS1zdGF0dXMtaGVhZGVycycgdG8gZmFsc2UsIGhhdmUgZXhp
c3RpbmcgdXNlcnMNCiMgd2l0aCBvbGQgKHByZS0zLngpIHNwb29sIGZpbGVz
LCBhbmQgeW91IHdhbnQgdG8ga2VlcCB0aGUgVUlEcyB0aGUNCiMgc2FtZS4N
CiMNCiMgRGVmYXVsdDogZmFsc2UNCiMNCiMgc2V0IG9sZC1zdHlsZS11aWQg
ICAgICAgICAgICA9IGZhbHNlDQoNCg0KIyBXaGVuIHNldCwgUXBvcHBlciBj
aGVja3MgZm9yIGFuZCBoaWRlcyBzdGF0dXMgbWVzc2FnZXMgY3JlYXRlZCBi
eQ0KIyBVbml2ZXJzaXR5IG9mIFdhc2hpbmd0b24gc29mdHdhcmUuDQojDQoj
IERlZmF1bHQ6IGZhbHNlDQojDQojIHNldCBVVy1rbHVnZSAgICAgICAgICAg
ICAgICAgPSBmYWxzZQ0KDQoNCiMgV2hlbiBzZXQsIFFwb3BwZXIga2VlcHMg
KGRvZXMgbm90IGRlbGV0ZSkgdGhlICcudXNlci5wb3AnIGZpbGUgKHRoZQ0K
IyB0ZW1wb3JhcnkgZHJvcCBmaWxlKS4gIE5vcm1hbGx5IHRoaXMgZmlsZSBp
cyBkZWxldGVkIHdoZW4gdGhlDQojIHNlc3Npb24gZW5kcy4gIFNvbWUgc2l0
ZXMgbGlrZSB0byByZXRhaW4gaXQgdG8gZGV0ZXJtaW5lIHRoZSBsYXN0DQoj
IHRpbWUgYSB1c2VyIGhhcyBhY2Nlc3NlZCBoaXMgb3IgaGVyIG1haWwuDQoj
DQojIERlZmF1bHQ6IGZhbHNlDQojDQojIHNldCBrZWVwLXRlbXAtZHJvcCAg
ICAgICAgICAgPSBmYWxzZQ0KDQoNCiMgV2hlbiBzZXQsIGNhdXNlcyBzZXJ2
ZXIgbW9kZSB0byBiZSBvbiBmb3IgdXNlcnMgd2hvIGFyZSBtZW1iZXJzIG9m
DQojIHRoZSBzcGVjaWZpZWQgZ3JvdXAuICBTZWUgdGhlICJFbmFibGluZyBT
ZXJ2ZXIgTW9kZSIgYW5kDQojICJQZXJmb3JtYW5jZSIgc2VjdGlvbnMgb2Yg
dGhlIFFwb3BwZXIgQWRtaW5pc3RyYXRvcidzIEd1aWRlIGZvciBtb3JlDQoj
IGluZm9ybWF0aW9uLg0KIw0KIyBEZWZhdWx0OiBub25lDQojDQojIHNldCBn
cm91cC1zZXJ2ZXItbW9kZSAgICAgICAgPQ0KDQoNCiMgV2hlbiBzZXQsIGNh
dXNlcyBzZXJ2ZXIgbW9kZSB0byBiZSBvZmYgZm9yIHVzZXJzIHdobyBhcmUg
bWVtYmVycyBvZg0KIyB0aGUgc3BlY2lmaWVkIGdyb3VwLiAgU2VlIHRoZSAi
RW5hYmxpbmcgU2VydmVyIE1vZGUiIGFuZA0KIyAiUGVyZm9ybWFuY2UiIHNl
Y3Rpb25zIG9mIHRoZSBRcG9wcGVyIEFkbWluaXN0cmF0b3IncyBHdWlkZSBm
b3IgbW9yZQ0KIyBpbmZvcm1hdGlvbi4NCiMNCiMgRGVmYXVsdDogbm9uZQ0K
Iw0KIyBzZXQgZ3JvdXAtbm8tc2VydmVyLW1vZGUgICAgID0NCg0KDQojIFNw
ZWNpZmllcyBhIGZpbGUgdGhhdCBwZXJtaXRzIG9ubHkgdXNlcnMgbGlzdGVk
IGluIHRoZSBmaWxlIHRvIGhhdmUNCiMgUXBvcHBlciBhY2Nlc3MuICBUaGUg
Zm9ybWF0IGlzIGEgbGlzdCBvZiB1c2VyIG5hbWVzLCBvbmUgcGVyIGxpbmUu
DQojDQojIERlZmF1bHQ6IG5vbmUNCiMNCiMgc2V0IGF1dGgtZmlsZSAgICAg
ICAgICAgICAgICA9DQoNCg0KIyBTcGVjaWZpZXMgYSBmaWxlIHRoYXQgZGVu
aWVzIGFjY2VzcyB0byB1c2VycyBsaXN0ZWQgaW4gdGhlIGZpbGUuDQojIFRo
ZSBmb3JtYXQgaXMgYSBsaXN0IG9mIHVzZXIgbmFtZXMsIG9uZSBwZXIgbGlu
ZS4NCiMNCiMgRGVmYXVsdDogbm9uZQ0KIw0Kc2V0IG5vbmF1dGgtZmlsZSAg
ICAgICAgICAgICA9IC9ldGMvcG9wLm5vbmF1dGgNCg0KDQojIFNldCB0aGlz
IG9wdGlvbiBpZiB5b3UgZG9uJ3Qgd2FudCBRcG9wcGVyIHRvIGRpc3BsYXkg
aXRzIHZlcnNpb24gaW4NCiMgdGhlIFBPUCBwcm90b2NvbCBiYW5uZXIgb3Ig
Q0FQQSBJTVBMRU1FTlRBVElPTiByZXNwb25zZSBvZg0KIyB1bmF1dGhlbnRp
Y2F0ZWQgdXNlcnMuDQojIFNvbWUgc2l0ZXMgYmVsaWV2ZSB0aGlzIGltcHJv
dmVzIHNlY3VyaXR5IHNpbmNlIGl0IGF2b2lkcyBhZHZlcnRpc2luZw0KIyB0
aGF0IGFuIG9sZCB2ZXJzaW9uIChwZXJoYXBzIHdpdGgga25vd24gdnVsbmVy
YWJpbGl0aWVzKSBpcyBiZWluZw0KIyB1c2VkLiAgT3RoZXJzIGZlZWwgaXMg
bWFrZXMgdGhlIHNpdGUgbW9yZSBsaWtlbHkgdG8gYmUgYXR0YWNrZWQsDQoj
IHNpbmNlIGl0IGFsc28gYXZvaWRzIGFkdmVydGlzaW5nIHdoZW4gcnVubmlu
ZyBhIHNlY3VyZSB2ZXJzaW9uLg0KIw0KIyBEZWZhdWx0OiBmYWxzZQ0KIw0K
IyBzZXQgc2h5ICAgICAgICAgICAgICAgICAgICAgID0gZmFsc2UNCg0KDQoj
IFNldCB0aGlzIHRvIHRoZSBmdWxsIHBhdGggdG8gc2VuZG1haWwgb3Igb3Ro
ZXIgc3VjaCBwcm9ncmFtIHVzZWQgdG8NCiMgc3VibWl0IG5ldyBtZXNzYWdl
cy4gIFFwb3BwZXIgdXNlcyB0aGlzIHRvIGltcGxlbWVudCBYVE5EIFhNSVQu
DQojDQojIFRoZSBkZWZhdWx0IGlzIGRldGVybWluZWQgYXQgY29tcGlsZSB0
aW1lLiAgDQojDQojDQojIHNldCBtYWlsLWNvbW1hbmQgICAgICAgICAgICAg
PSAvdXNyL3NiaW4vc2VuZG1haWwNCg0KDQojIFNldCB0aGlzIHRvIHRoZSBm
dWxsIHBhdGggdG8gdGhlIG1haWwgc3Bvb2wgZGlyZWN0b3J5Lg0KIw0KIyBU
aGUgZGVmYXVsdCBpcyBkZXRlcm1pbmVkIGF0IGNvbXBpbGUgdGltZS4gIA0K
Iw0KIyBzZXQgc3Bvb2wtZGlyICAgICAgICAgICAgICAgID0gL3Zhci9zcG9v
bC9tYWlsDQoNCg0KIyBJZiB5b3UgZG8gbm90IHdhbnQgJy51c2VyLnBvcCcg
KHRlbXBvcmFyeSBkcm9wIGZpbGVzKSB0byBiZSBpbiB0aGUNCiMgc3Bvb2wg
ZGlyZWN0b3J5LCBzZXQgdGhpcyB0byB0aGUgZnVsbCBwYXRoIHRvIHRoZSBk
aXJlY3RvcnkgdG8gYmUNCiMgdXNlZCBmb3IgdGVtcCBkcm9wIGZpbGVzLiAg
Tm90ZSB0aGF0IHVzZSBvZiAvdG1wIGlzIG5vdCByZWNvbW1lbmRlZCwNCiMg
YmVjYXVzZSBhIHN5c3RlbSByZWJvb3Qgd2lsbCB3aXBlIG91dCB0aGUgZmls
ZXMuICBUaGlzIGNvdWxkIGNhdXNlDQojIGxvc3QgbWFpbC4NCiMNCiMgRGVm
YXVsdDogc3Bvb2wgZGlyZWN0b3J5DQojDQojIHNldCB0ZW1wLWRpciAgICAg
ICAgICAgICAgICAgPQ0KDQoNCiMgVGhlIG5hbWUgb2YgdGhlIHRlbXBvcmFy
eSBkcm9wIGZpbGVzLiAgWW91IHNob3VsZCBub3Qgbm9ybWFsbHkgc2V0DQoj
IHRoaXMgb3B0aW9uLg0KIw0KIyBEZWZhdWx0OiAiLiVzLnBvcCINCiMNCiMg
c2V0IHRlbXAtbmFtZSAgICAgICAgICAgICAgICA9ICIuJXMucG9wIg0KDQoN
CiMgSWYgeW91IGRvIG5vdCB3YW50IHVzZXIgY2FjaGUgZmlsZXMgdG8gYmUg
aW4gdGhlIHNhbWUgZGlyZWN0b3J5IGFzDQojIHRlbXBvcmFyeSBkcm9wIGZp
bGVzLCBzZXQgdGhpcyB0byB0aGUgZnVsbCBwYXRoIHRvIHRoZSBkaXJlY3Rv
cnkgZm9yDQojIGNhY2hlIGZpbGVzLiAgTm90ZSB0aGF0IHVzZSBvZiAvdG1w
IGlzIG5vdCByZWNvbW1lbmRlZCwgYmVjYXVzZSBhDQojIHN5c3RlbSByZWJv
b3Qgd2lwZXMgb3V0IHRoZSBmaWxlcy4NCiMNCiMgRGVmYXVsdDogdGVtcC1k
aXINCiMNCiMgc2V0IGNhY2hlLWRpciAgICAgICAgICAgICAgICA9DQoNCg0K
IyBUaGUgbmFtZSBvZiB0aGUgY2FjaGUgZmlsZXMuICBZb3Ugc2hvdWxkIG5v
dCBub3JtYWxseSBzZXQgdGhpcw0KIyBvcHRpb24uDQojDQojIERlZmF1bHQ6
ICIuJXMuY2FjaGUiDQojDQojIHNldCBjYWNoZS1uYW1lICAgICAgICAgICAg
ICAgPSAiLiVzLmNhY2hlIg0KDQoNCiMgU3BlY2lmaWVzIHRoZSBtYXhpbXVt
IG51bWJlciBvZiBvbGQgYnVsbGV0aW5zIHNlZW4gYnkgbmV3IHVzZXJzLg0K
Iw0KIyBEZWZhdWx0OiAxDQojDQojIHNldCBtYXgtYnVsbGV0aW5zICAgICAg
ICAgICAgPSAxDQoNCg0KIyBXaGVuIHNldCwgUXBvcHBlciB1c2VzIGEgbWV0
aG9kIG9mIG9wZW5pbmcgbG9jayBmaWxlcyB0aGF0IG1heSB3b3JrDQojIG92
ZXIgTkZTLiAgVGhpcyBoYXMgbm90IGJlZW4gdGhvcm91Z2hseSB0ZXN0ZWQs
IGhvd2V2ZXIuDQojDQojIERlZmF1bHQ6IGZhbHNlDQojDQojIHNldCBuby1h
dG9taWMtb3BlbiAgICAgICAgICAgPSBmYWxzZQ0KDQoNCiMgUXBvcHBlciBz
ZW5kcyBuZXR3b3JrIG91dHB1dCB0byBjbGllbnQgaW4gc21hbGwgY2h1bmtz
IChmb3IgZXhhbXBsZSwNCiMgbGluZS1ieS1saW5lIHdoZW4gc2VuZGluZyBh
IG1lc3NhZ2UpLiAgQnkgZGVmYXVsdCwgUXBvcHBlcg0KIyBhZ2dyZWdhdGVz
IGRhdGEgdG8gYmUgc2VudCB0byBjbGllbnRzIGluIGxhcmdlIGNodW5rcy4g
IFRoaXMgbWF5IGJlDQojIGZhc3RlciBvciBzbG93ZXIsIGRlcGVuZGluZyBv
biBzcGVjaWZpY3Mgb2YgYm90aCB0aGUgY2xpZW50IGFuZA0KIyBzZXJ2ZXIg
aGFyZHdhcmUgYW5kIG5ldHdvcmtpbmcgc3RhY2tzIGFzIHdlbCBhcyBuZXR3
b3JrIGVsZW1lbnRzIGluDQojIGJldHdlZW4gKHN1Y2ggYXMgcm91dGVycyku
ICBBbHNvLCBzb21lIG5ldHdvcmtpbmcgc3RhY2tzIGRvIHRoZWlyDQojIG93
biBhZ2dyZWdhdGlvbi4NCiMNCiMgVW5kZXIgY29uZ2VzdGVkIG5ldHdvcmsg
Y29uZGl0aW9ucywgbGFyZ2VyIHBhY2tldHMgaW5jcmVhc2UgdGhlDQojIGlu
Y2lkZW5jZSBvZiBsb3N0IHBhY2tldHMgYW5kIHRodXMgY2xpZW50IG9yIHNl
cnZlciB0aW1lb3V0cywNCiMgbGVhZGluZyB0byAiUE9QIHRpbWVvdXQiIG9y
ICJFT0YiIGVycm9ycy4NCiMNCiMgV2hlbiBUTFMvU1NMIGlzIGluIGVmZmVj
dCwgc21hbGxlciBwYWNrZXRzIGluY3JlYXNlIHRoZSBvdmVyaGVhZA0KIyBu
ZWVkZWQgdG8gc2VuZCBkYXRhLCB3aGljaCBtYXkgcmVzdWx0IGluIHdvcnNl
IHBlcmZvcm1hbmNlLg0KIw0KIyBZb3UgY2FuIGFkanVzdCB0aGUgUXBvcHBl
ciBiZWhhdmlvciBieSBzZXR0aW5nIHRoaXMgb3B0aW9uLiAgVGhlDQojIHZh
bHVlcyBhcmU6DQojICAgIG8gJ2RlZmF1bHQnICBBbHdheXMgc2VuZCBsYXJn
ZSBjaHVua3MNCiMgICAgbyAnYWx3YXlzJyAgIFNhbWUgYXMgJ2RlZmF1bHQn
DQojICAgIG8gJ25ldmVyJyAgICBOZXZlciBhZ2dyZWdhdGUgZGF0YSBpbnRv
IGxhcmdlIGNodW5rcw0KIyAgICBvICd0bHMnICAgICAgT25seSBhZ2dyZWdh
dGUgZGF0YSBpbnRvIGxhcmdlIGNodW5rcyB3aGVuIFRMUy9TU0wNCiMgICAg
ICAgICAgICAgICAgIGhhcyBiZWVuIG5lZ290aWF0ZWQgZm9yIHRoZSBzZXNz
aW9uIA0KIyAgICBvICdzc2wnICAgICAgU2FtZSBhcyAndGxzJw0KIw0KIyBE
ZWZhdWx0OiBkZWZhdWx0DQojDQojIHNldCBjaHVua3ktd3JpdGVzICAgICAg
ICAgICAgPSBkZWZhdWx0DQoNCg0KIyBTcGVjaWZpZXMgdGhlIGxvZyBmYWNp
bGl0eSB0aGF0IFFwb3BwZXIgdXNlcy4NCiMNCiMgTm90ZSB0aGF0IHRoaXMg
ZG9lcyBub3QgYXBwbHkgdG8gcG9wYXV0aCwgbm9yIHRvIHRoZSBkYWVtb24g
aW4NCiMgc3RhbmRhbG9uZSBtb2RlLiAgVGhlc2UgY29udGludWUgdG8gdXNl
IHRoZSBjb21waWxlLXRpbWUgZGVmYXVsdC4NCiMNCiMgVmFsdWVzIGFyZToN
CiMgICAgbyAnbWFpbCcgICAgUXBvcHBlciBsb2dzIHRvIExPR19NQUlMIGZh
Y2lsaXR5Lg0KIyAgICBvICdsb2NhbDAnICBRcG9wcGVyIGxvZ3MgdG8gTE9H
X0xPQ0FMMCBmYWNpbGl0eS4NCiMgICAgbyAnbG9jYWwxJyAgUXBvcHBlciBs
b2dzIHRvIExPR19MT0NBTDEgZmFjaWxpdHkuDQojICAgIG8gJ2xvY2FsMicg
IFFwb3BwZXIgbG9ncyB0byBMT0dfTE9DQUwyIGZhY2lsaXR5Lg0KIyAgICBv
ICdsb2NhbDMnICBRcG9wcGVyIGxvZ3MgdG8gTE9HX0xPQ0FMMyBmYWNpbGl0
eS4NCiMgICAgbyAnbG9jYWw0JyAgUXBvcHBlciBsb2dzIHRvIExPR19MT0NB
TDQgZmFjaWxpdHkuDQojICAgIG8gJ2xvY2FsNScgIFFwb3BwZXIgbG9ncyB0
byBMT0dfTE9DQUw1IGZhY2lsaXR5Lg0KIyAgICBvICdsb2NhbDYnICBRcG9w
cGVyIGxvZ3MgdG8gTE9HX0xPQ0FMNiBmYWNpbGl0eS4NCiMgICAgbyAnbG9j
YWw3JyAgUXBvcHBlciBsb2dzIHRvIExPR19MT0NBTDcgZmFjaWxpdHkuDQoj
DQojIERlZmF1bHQ6IGRldGVybWluZWQgYXQgY29tcGlsZSB0aW1lLCB1c3Vh
bGx5IExPR19MT0NBTDAgb3INCiMgTE9HX01BSUwsIGRlcGVuZGluZyBvbiB0
aGUgb3BlcmF0aW5nIHN5c3RlbS4NCiMNCiMgc2V0IGxvZy1mYWNpbGl0eSAg
ICAgICAgICAgICA9IGxvY2FsMQ0KDQoNCiMgV2hlbiBzZXQsIFFwb3BwZXIg
bG9ncyBzdWNjZXNzZnVsIGF1dGhlbnRpY2F0aW9ucyB1c2luZyB0aGUNCiMg
c3BlY2lmaWVkIHN0cmluZy4gIFdpdGhpbiB0aGUgc3RyaW5nLCBhbiBvY2N1
cnJlbmNlIG9mICclMCcgaXMNCiMgcmVwbGFjZWQgd2l0aCB0aGUgUXBvcHBl
ciB2ZXJzaW9uLCAnJTEnIHdpdGggdGhlIHVzZXIgbmFtZSwgJyUyJw0KIyB3
aXRoIHRoZSB1c2VyJ3MgaG9zdCBuYW1lLCBhbmQgJyUzJyB3aXRoIHRoZSB1
c2VyJ3MgSVAgYWRkcmVzcy4NCiMNCiMgRGVmYXVsdDogbm9uZSwgdW5sZXNz
ICctLWVuYWJsZS1sb2ctbG9naW4nIHVzZWQgd2l0aCAuL2NvbmZpZ3VyZSwN
CiMgaW4gd2hpY2ggY2FzZSAiKHYlMCkgUE9QIGxvZ2luIGJ5IHVzZXIgLyIl
MS8iIGF0ICglMikgJTMiIGlzIHVzZWQuDQojDQojIHNldCBsb2ctbG9naW4g
ICAgICAgICAgICAgICAgPSAiKHYlMCkgUE9QIGxvZ2luIGJ5IHVzZXIgLyIl
MS8iIGF0ICglMikgJTMiDQoNCg0K
---559023410-341603450-1104786407=:10592--
Date: Thu, 20 Jan 2005 18:42:03 +0100
From: JCS <jcsanchez at ccupm dot upm dot es>
Subject: log of qpopper becoming very big
Hello:
Since a few days ago we are having some problems wiht qpopper log file.
We are running two different systems with different versions of qpopper
and having the same problem in both. I am (nearby) sure this problem is
new and had not happend before in our systems.
The problem is in the log file appears lines like this:
Jan 10 13:09:26 galileo /usr/local/bin/popper[27540]: [ID 702911
local1.notice] (null
) at xxx.yyy.zzz.ttt (xxx.yyy.zzz.ttt): -ERR Too many arguments supplied.
Jan 10 13:09:26 galileo /usr/local/bin/popper[27540]: [ID 702911
local1.notice] (null
) at xxx.yyy.zzz.ttt (xxx.yyy.zzz.ttt): -ERR Unknown command: "-err".
where xxx.yyy.zzz.ttt is the IP of the client user,
and then thousands (millions?) of messages like the last one.
The case is I realize of this maybe two hours after this starts, and
then, the log file is realy big. At than momment, you can see e popper
proccess started at the time the messsages started and if you kill the
proccess the log file stops adding lines. Even the client IP
xxx.yyy.zzz.ttt is not connected to Internet at that momment.
This has happened with several different IP. In other momments of the
day connections from those IP (and logging) are normal.
Has anybody seen this problem before?
qpopper starts as: /usr/local/bin/popper -S -s -T600 -R
and is running in a Solaris 8 box.
Any help is good as I have got the log system file at 100 % in last days.
Thanks.
Date: Wed, 26 Jan 2005 15:54:08 -0600
From: James Medley <jmedley at aesrg dot tamu dot edu>
Subject: qpopper and Mac OS 10.3.x (Panther)
Hi All,
I am about to try and install qpopper4.0.5 on a Mac running OS
10.3.7. I currently have sendmail / qpopper running on a machine with
OS 10.2.8 and all is well. I have read though that qpopper does not
install 'out of the box' onto OS 10.3.x. I am open for any suggestion
or advise before I start. Thanks in advance, Jim
--
From: Rudy Richter <rudy at esto dot gsfc dot nasa dot gov>
Subject: Re: qpopper and Mac OS 10.3.x (Panther)
Date: Fri, 28 Jan 2005 11:34:47 -0500
the patch file the fink project has for qpopper 4.0.5 works to get
qpopper compiling on Panther, it's been awhile since i wrote it but i
think it was the fact that qpopper was trying to link in a .o file
called mktemp.o that wasn't needed.
-rudy
On Jan 26, 2005, at 4:54 PM, James Medley wrote:
> Hi All,
>
> I am about to try and install qpopper4.0.5 on a Mac running OS 10.3.7.
> I currently have sendmail / qpopper running on a machine with OS
> 10.2.8 and all is well. I have read though that qpopper does not
> install 'out of the box' onto OS 10.3.x. I am open for any suggestion
> or advise before I start. Thanks in advance, Jim
> --
>
>
Date: Fri, 28 Jan 2005 12:53:13 -0600
From: James Medley <jmedley at aesrg dot tamu dot edu>
Subject: problem with xinetd.d
I have just installed qpopper4.0.5 on a Mac running OS 10.3.7
(Panther). I did the installation with Darwinports. After
installation I sent a HUP signal to xinetd and got the following in
my system log ...
Jan 28 11:45:30 localhost xinetd[390]: Starting reconfiguration
Jan 28 11:45:30 localhost xinetd[390]: service:pop3 id:pop3 not
unique or is a duplicate - DISABLING
Jan 28 11:45:30 localhost xinetd[390]: readjusting service ftp
Jan 28 11:45:30 localhost xinetd[390]: readjusting service pop3
Jan 28 11:45:30 localhost xinetd[390]: readjusting service ssh
Jan 28 11:45:30 localhost xinetd[390]: Reconfigured: new=0 old=3
dropped=0 (services)
I'm not sure what the id:pop3 not unique is. None the less, I cannot
telnet to myself.host pop3. I get a connection refused, Unable to
connect. Thanks for any help. Jim
--
James Medley
Senior Research Associate
Texas A&M University
Agricultural Research and Extension Center
Beaumont, Texas 77713
(409)752-2741 ext 2252
jmedley@aesrg.tamu.edu
http://aesrg.tamu.edu
From: Mark <admin at asarian-host dot net>
Date: Fri, 28 Jan 2005 21:25:09 GMT
Subject: RE: problem with xinetd.d
> -----Original Message-----
> From: James Medley [mailto:jmedley@aesrg.tamu.edu]
> Sent: vrijdag 28 januari 2005 19:54
> To: Subscribers of Qpopper
> Subject: problem with xinetd.d
>
> I have just installed qpopper4.0.5 on a Mac running OS 10.3.7
> (Panther). I did the installation with Darwinports. After
> installation I sent a HUP signal to xinetd and got the following in
> my system log ...
>
> Jan 28 11:45:30 localhost xinetd[390]: Starting reconfiguration
> Jan 28 11:45:30 localhost xinetd[390]: service:pop3 id:pop3 not
> unique or is a duplicate - DISABLING
> Jan 28 11:45:30 localhost xinetd[390]: readjusting service ftp
> Jan 28 11:45:30 localhost xinetd[390]: readjusting service pop3
> Jan 28 11:45:30 localhost xinetd[390]: readjusting service ssh
> Jan 28 11:45:30 localhost xinetd[390]: Reconfigured: new=0 old=3
> dropped=0 (services)
>
> I'm not sure what the id:pop3 not unique is. None the less, I cannot
> telnet to myself.host pop3. I get a connection refused, Unable to
> connect. Thanks for any help. Jim
It seems, to me, like xinetd is trying to tell you that the "pop3" service
name is not uniquely defined in /etc/services (or wherever your services
file exist on a Mac). I would do a "grep pop3" on the services file to find
out.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
Date: Wed, 02 Feb 2005 16:52:03 +0100
From: JCS <jcsanchez at ccupm dot upm dot es>
Subject: log of qpopper becoming very big, second try
Hello:
I repost this message as no reply has yet arrived.
There is nobody having the same problem?
Thanks
JCS escribió:
> Hello:
>
> Since a few days ago we are having some problems wiht qpopper log file.
> We are running two different systems with different versions of qpopper
> and having the same problem in both. I am (nearby) sure this problem is
> new and had not happend before in our systems.
>
> The problem is in the log file appears lines like this:
>
> Jan 10 13:09:26 galileo /usr/local/bin/popper[27540]: [ID 702911
> local1.notice] (null
> ) at xxx.yyy.zzz.ttt (xxx.yyy.zzz.ttt): -ERR Too many arguments supplied.
> Jan 10 13:09:26 galileo /usr/local/bin/popper[27540]: [ID 702911
> local1.notice] (null
> ) at xxx.yyy.zzz.ttt (xxx.yyy.zzz.ttt): -ERR Unknown command: "-err".
>
> where xxx.yyy.zzz.ttt is the IP of the client user,
> and then thousands (millions?) of messages like the last one.
>
> The case is I realize of this maybe two hours after this starts, and
> then, the log file is realy big. At than momment, you can see e popper
> proccess started at the time the messsages started and if you kill the
> proccess the log file stops adding lines. Even the client IP
> xxx.yyy.zzz.ttt is not connected to Internet at that momment.
>
> This has happened with several different IP. In other momments of the
> day connections from those IP (and logging) are normal.
>
> Has anybody seen this problem before?
>
> qpopper starts as: /usr/local/bin/popper -S -s -T600 -R
> and is running in a Solaris 8 box.
>
> Any help is good as I have got the log system file at 100 % in last days.
>
> Thanks.
>
>
>
>
Date: Wed, 2 Feb 2005 08:54:03 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: log of qpopper becoming very big, second try
On Wed, Feb 02, 2005 at 04:52:03PM +0100, JCS wrote:
> Hello:
>
> I repost this message as no reply has yet arrived.
> There is nobody having the same problem?
No, I've never seen anything like this.
What it looks like to me, reading these logs closely and applying
some imagination, is that you have a client at xxx.yyy.zzz.ttt running
some kind of script which is "looping back" or echoing all responses
from popper back into popper. Look at the sequence of commands here,
as logged by popper itself:
popper:
-ERR Too many arguments supplied.
popper:
-ERR Unknown command: "-err"
A little imagination for some of the problems that can occur with
computers suggests that the other side of the dialog may look like
this:
client:
(unknown initial command ???)
popper:
-ERR Too many arguments supplied.
client:
-ERR Too many arguments supplied.
popper:
-ERR Unknown command: "-err"
client:
-ERR Unknown command: "-err"
popper:
-ERR Unknown command: "-err"
etc.
You could see that if, for instance, somebody on that IP was running
a miscoded Perl script or shell or netcat script to connect to popper,
or if they had a misconfigured proxy server being used to connect, or
something of that kind.
I would look very closely into what is running on the specific
clients connecting from the affected IPs. That's my best guess for
you.
-- Clifton
--
Clifton Royston -- cliftonr@tikitechnologies.com
Tiki Technologies Lead Programmer/Software Architect
"I'm gonna tell my son to grow up pretty as the grass is green
And whip-smart as the English Channel's wide,
And I'm gonna tell my son to keep his money in his mattress
And his watch on any hand between his thighs,
And I'm gonna lock my son up in a tower
Till I write my whole life story on the back of his big brown eyes..."
-- 'Whip-Smart', Liz Phair
Subject: qpopper 2.53 Error Msg
From: TaoZhi dot Hou at cn dot excelstor dot com
Date: Thu, 3 Feb 2005 10:16:03 +0800
Hi, All:
Our email server using qpopper 2.53 act pop3 server, but when the user
recv the email, the maillog show below:
-ERR [SYS/TEMP] Unable to open Bulletin database; contact your
administrator [pop_dropcopy.c:1255]
-ERR POP timeout from mailsrv [popper.c:609]
it happens haphazard, seems when users mail box is bigger , it will easy
happen.
Dose any one can help me gow to avoid this ??
We are using Linux Redhad 7.0..
thanks...
Best Regards
Excelstor Technology ShenZhen
Information Technology: Hou Tao Zhi
-----------------------------------------
E-Mail:TaoZhi.Hou@cn.excelstor.com
Tel: 86-755-83346668 ext:8216
Date: Thu, 03 Feb 2005 09:04:55 -0800
From: Ken A <ka at pacific dot net>
Subject: Re: qpopper 2.53 Error Msg
That's a very old version of qpopper and redhat.
Upgrading will solve many more problems.
However, you may be able to fix this by running qpopper with -B option
(ignores bulletin db failures)
But.. I'm not sure this option was available in 2.53!
Ken
TaoZhi.Hou@cn.excelstor.com wrote:
> Hi, All:
>
> Our email server using qpopper 2.53 act pop3 server, but when the user
> recv the email, the maillog show below:
>
>
> -ERR [SYS/TEMP] Unable to open Bulletin database; contact your
> administrator [pop_dropcopy.c:1255]
> -ERR POP timeout from mailsrv [popper.c:609]
>
> it happens haphazard, seems when users mail box is bigger , it will easy
> happen.
>
>
> Dose any one can help me gow to avoid this ??
>
> We are using Linux Redhad 7.0..
> thanks...
>
> Best Regards
> Excelstor Technology ShenZhen
> Information Technology: Hou Tao Zhi
> -----------------------------------------
> E-Mail:TaoZhi.Hou@cn.excelstor.com
> Tel: 86-755-83346668 ext:8216
>
>
>
Date: Thu, 3 Feb 2005 11:56:41 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: qpopper and Mac OS 10.3.x (Panther)
At 11:34 AM -0500 1/28/05, Rudy Richter wrote:
> the patch file the fink project has for qpopper 4.0.5 works to get
> qpopper compiling on Panther, it's been awhile since i wrote it but
> i think it was the fact that qpopper was trying to link in a .o
> file called mktemp.o that wasn't needed.
I don't recall a problem like that, but there were other problems,
such as Panther requiring PAM to authenticate users (it doesn't like
daemons getting the shadow password, even if you ask nicely) and a
few other things. The later 4.0.6 betas should work out-of-the-box,
since ./configure detects if you need to use PAM or not (or at least
tries to).
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
He had occasional flashes of silence that made his conversation
perfectly delightful. --Sydney Smith
Subject: Cannot find ^?ELF^A^B^A Solaris9 qpopper 4.0.5
From: Roy_Harrison at notes dot rlg dot org
Date: Fri, 4 Feb 2005 06:32:04 -0800
Hi All
I've googled and searched archives to no avail,,the FAQ seems to mean
Forget About Questions (at least mine). I get this message on a fresh
installation of qpopper Ver 4.0.5 on a brand new installation of a
Solaris9 box.: elfexec: [ID 700856 kern.notice] popper: Cannot find
^?ELF^A^B^A. I uninstalled qpopper using "make realclean", reinstalled
making sure I had the "--enable-specialauth" statement just in case it
wasn't picking up that my machine uses shadow but to no avail.
This is annoying since I installed this on the same test machine with
Solaris8 2 years ago and it worked like a charm.
Any help will be greatly appreciated.
Roy
RLG
From: Greg Earle <earle at isolar dot DynDNS dot ORG>
Subject: Re: Cannot find ^?ELF^A^B^A Solaris9 qpopper 4.0.5
Date: Fri, 4 Feb 2005 09:01:37 -0800
On Feb 4, 2005, at 6:32 AM, Roy_Harrison@notes.rlg.org wrote:
> I've googled and searched archives to no avail, the FAQ seems to mean
> Forget About Questions (at least mine). I get this message on a fresh
> installation of qpopper Ver 4.0.5 on a brand new installation of a
> Solaris 9 box.: elfexec: [ID 700856 kern.notice] popper: Cannot find
> ^?ELF^A^B^A. I uninstalled qpopper using "make realclean", reinstalled
> making sure I had the "--enable-specialauth" statement just in case it
> wasn't picking up that my machine uses shadow but to no avail.
>
> This is annoying since I installed this on the same test machine with
> Solaris 8 2 years ago and it worked like a charm.
ELF is the executable file format on Solaris 9. It looks to me
like /kernel/exec/elfexec doesn't like your "popper" binary. Do a
file /path/to/popper
and see what it says. It should say something like
/usr/sbin/qpopper: ELF 32-bit MSB executable SPARC Version 1,
dynamically linked, stripped
Next, try this command:
ldd /path/to/popper
(Obviously replace "/path/to" with your own installed path to
the Qpopper binary, e.g. "/usr/sbin/popper")
It should say something like:
libnsl.so.1 => /usr/lib/libnsl.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libkrb.so.1 => /usr/lib/libkrb.so.1
librt.so.1 => /usr/lib/librt.so.1
libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1
libssl.so.0.9.7 => /usr/local/ssl/lib/libssl.so.0.9.7
libcrypto.so.0.9.7 => /usr/local/ssl/lib/libcrypto.so.0.9.7
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libaio.so.1 => /usr/lib/libaio.so.1
libgen.so.1 => /usr/lib/libgen.so.1
Finally, try running
ktrace -f -rall -wall /path/to/popper
It should fall over immediately, but there might be something
useful in the output.
This problem has been mentioned at least twice before on this
list; Google for elfexec with "Cannot find" and you'll get more
than one page of hits back. The last mention on this list was:
http://www.mail-archive.com/qpopper@lists.pensive.org/msg03764.html
- Greg
Subject: Re: Cannot find ^?ELF^A^B^A Solaris9 qpopper 4.0.5
From: Roy_Harrison at notes dot rlg dot org
Date: Fri, 4 Feb 2005 11:55:45 -0800
Thanks much Greg.
My results are:
# file /usr/local/sbin/popper
/usr/local/sbin/popper: ELF 32-bit MSB executable SPARC Version 1,
dynamically linked, stripped
# ldd /usr/local/sbin/popper
ldd: /usr/local/sbin/popper: file has insecure interpreter ELF
between this and the link you gave me (I swear I googled and searched..I
hate RTFM's :-) there should be enough to keep me busy.
Thanks ..and Peace
Roy
Greg Earle <earle@isolar.DynDNS.ORG>
02/04/2005 09:01 AM
To: Subscribers of Qpopper <qpopper@lists.pensive.org>
cc:
Subject: Re: Cannot find ^?ELF^A^B^A Solaris9 qpopper
4.0.5
On Feb 4, 2005, at 6:32 AM, Roy_Harrison@notes.rlg.org wrote:
> I've googled and searched archives to no avail, the FAQ seems to mean
> Forget About Questions (at least mine). I get this message on a fresh
> installation of qpopper Ver 4.0.5 on a brand new installation of a
> Solaris 9 box.: elfexec: [ID 700856 kern.notice] popper: Cannot find
> ^?ELF^A^B^A. I uninstalled qpopper using "make realclean", reinstalled
> making sure I had the "--enable-specialauth" statement just in case it
> wasn't picking up that my machine uses shadow but to no avail.
>
> This is annoying since I installed this on the same test machine with
> Solaris 8 2 years ago and it worked like a charm.
ELF is the executable file format on Solaris 9. It looks to me
like /kernel/exec/elfexec doesn't like your "popper" binary. Do a
file /path/to/popper
and see what it says. It should say something like
/usr/sbin/qpopper: ELF 32-bit MSB executable SPARC Version 1,
dynamically linked, stripped
Next, try this command:
ldd /path/to/popper
(Obviously replace "/path/to" with your own installed path to
the Qpopper binary, e.g. "/usr/sbin/popper")
It should say something like:
libnsl.so.1 => /usr/lib/libnsl.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libkrb.so.1 => /usr/lib/libkrb.so.1
librt.so.1 => /usr/lib/librt.so.1
libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1
libssl.so.0.9.7 => /usr/local/ssl/lib/libssl.so.0.9.7
libcrypto.so.0.9.7 => /usr/local/ssl/lib/libcrypto.so.0.9.7
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libaio.so.1 => /usr/lib/libaio.so.1
libgen.so.1 => /usr/lib/libgen.so.1
Finally, try running
ktrace -f -rall -wall /path/to/popper
It should fall over immediately, but there might be something
useful in the output.
This problem has been mentioned at least twice before on this
list; Google for elfexec with "Cannot find" and you'll get more
than one page of hits back. The last mention on this list was:
http://www.mail-archive.com/qpopper@lists.pensive.org/msg03764.html
- Greg
From: Greg Earle <earle at isolar dot DynDNS dot ORG>
Subject: Re: Cannot find ^?ELF^A^B^A Solaris9 qpopper 4.0.5
Date: Fri, 4 Feb 2005 13:30:21 -0800
On Feb 4, 2005, at 11:55 AM, Roy_Harrison@notes.rlg.org wrote:
> Thanks much Greg.
>
> My results are:
>
> # file /usr/local/sbin/popper
> /usr/local/sbin/popper: ELF 32-bit MSB executable SPARC Version 1,
> dynamically linked, stripped
> # ldd /usr/local/sbin/popper
> ldd: /usr/local/sbin/popper: file has insecure interpreter ELF
>
> between this and the link you gave me (I swear I Googled and
> searched... I hate RTFM's :-) there should be enough to keep me busy.
You probably built (or, to be more specific, linked) it wrong.
See, for example,
http://unix.derkeiler.com/Newsgroups/comp.unix.solaris/2004-08/1973.html
http://unix.derkeiler.com/Newsgroups/comp.unix.solaris/2004-08/1997.html
- Greg
Date: Mon, 7 Feb 2005 14:24:38 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: qpopper 2.53 Error Msg
At 10:16 AM +0800 2/3/05, TaoZhi.Hou@cn.excelstor.com wrote:
> Hi, All:
>
> Our email server using qpopper 2.53 act pop3 server, but when the user
> recv the email, the maillog show below:
>
>
> -ERR [SYS/TEMP] Unable to open Bulletin database; contact your
> administrator [pop_dropcopy.c:1255]
Are you sure you are running version 2.53? The error message you
cite did not exist in such an old version (especially note that the
error message includes the extended error code "SYS/TEMP", which was
added long after version 2.53).
I'd suggest checking the Qpopper version, and also check the log to
see details of what is causing this error.
> -ERR POP timeout from mailsrv [popper.c:609]
This is a different error.
>
> it happens haphazard, seems when users mail box is bigger , it will easy
> happen.
Which error? The second one?
>
>
> Dose any one can help me gow to avoid this ??
>
> We are using Linux Redhad 7.0..
> thanks...
>
> Best Regards
> Excelstor Technology ShenZhen
> Information Technology: Hou Tao Zhi
> -----------------------------------------
> E-Mail:TaoZhi.Hou@cn.excelstor.com
> Tel: 86-755-83346668 ext:8216
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
The Law, in its majestic equality, forbids the rich, as well as the
poor, to sleep under the bridges, to beg in the streets, and to steal
bread. --Anatole France
Date: Mon, 7 Feb 2005 14:50:14 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: 4.0.6b3 refuses to find qpopper.config file
At 4:06 PM -0500 1/3/05, Jeff A. Earickson wrote:
> Hi,
> I'm working on getting TLS going with 4.0.5 and 4.0.6b3,
> and I've discovered that 4.0.6b3 refuses to find/read the
> qpopper.config file. 4.0.5 has no problems with this, using the
> same file.
>
> Platform: Solaris 9
>
> Code compiled with the following settings:
> CC=cc ./configure \
> --prefix=/opt/maild \
> --enable-debugging \
> --enable-keep-temp-drop \
> --enable-nonauth-file=/etc/pop.nonauth \
> --enable-log-login \
> --disable-hash-dir-check \
> --disable-old-spool-loc \
> --enable-hash-spool=3 \
> --with-pam=pop3 \
> --enable-uw-kludge \
> --enable-temp-drop-dir=/var/spool/pop \
> --enable-server-mode \
> --enable-low-debug \
> --with-openssl=/opt/openssl
>
> Config file is: /opt/maild/qpopper.config, perms are 644 (attached).
>
> /etc/inetd.conf entry on the server machine is:
>
> pop3 stream tcp nowait root /opt/maild/popper popper -l 1 -f
> /opt/maild/qpopper.config -d -t /tmp/trace-file
>
> What happens:
>
> % telnet machine 110
> Trying {IP number disguised]....
> Connected to machine.colby.edu.
> Escape character is '^]'.
> Unable to process config file /opt/maild/qpopper.config
> Connection to machine.colby.edu closed by foreign host.
>
> (nothing appears in the trace-file)
I can't reproduce this with 4.0.6b4. I've tried:
- specifying a file that doesn't exist (it says it can't open it and exits)
- specifying the sample file (it processes it)
- specifying a file with bad syntax (it gives an error)
Please try changing the inetd line to put the -t option first, and
see if you get anything written to the trace file then.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Despite an abundance of devoted followers, the production of great
leaders been discontinued.
Date: Wed, 23 Feb 2005 11:48:51 -0700
From: "Geronimo Poppino" <gpoppino at novell dot com>
Subject: QPopper LDAP support
Hello,
I am trying to set up a server running QPopper 4.0.5 to authenticate its
users with a LDAP server. All user information should be stored in a
LDAP directory (uid, gid, home directory, etc).
The LDAP server schema will be extended with attributes and object
classes defined in RFC 2307.
Reading the FAQ I found that QPopper supports PAM, which means that its
pam config file can use a pam_ldap module, but it also says that it
still needs a _pwnam_ entry for the user (the system call getpwnam() get
this info from /etc/passwd).
The question is:
Where will QPopper get this pwnam entry for each user if it is
configured with PAM support and its PAM config file uses a LDAP module?
I suppose it will get it from the LDAP server, however I want to be
sure.
Thanks,
Geronimo
Date: Thu, 24 Feb 2005 09:41:14 +0800
From: Tim Villa <tvilla at cyllene dot uwa dot edu dot au>
Subject: Re: QPopper LDAP support
Hi Geronimo,
Our QPOPPER/LDAP/PAM setup doesn't require any pwnam entry - you'll get
along just fine without :-)
Tim
At 02:48 AM 24/02/2005, Geronimo Poppino wrote:
>Hello,
>
>I am trying to set up a server running QPopper 4.0.5 to authenticate its
>users with a LDAP server. All user information should be stored in a
>LDAP directory (uid, gid, home directory, etc).
>
>The LDAP server schema will be extended with attributes and object
>classes defined in RFC 2307.
>
>Reading the FAQ I found that QPopper supports PAM, which means that its
>pam config file can use a pam_ldap module, but it also says that it
>still needs a _pwnam_ entry for the user (the system call getpwnam() get
>this info from /etc/passwd).
>
>The question is:
>
>Where will QPopper get this pwnam entry for each user if it is
>configured with PAM support and its PAM config file uses a LDAP module?
>
>I suppose it will get it from the LDAP server, however I want to be
>sure.
>
>Thanks,
>Geronimo
--
Tim Villa, Network / Systems Administrator
M252, Business School and Law School
The University of Western Australia CRICOS provider number 00126G
Phone: +61-8-6488-1796, Fax: +61-8-6488-1068
Mail <mailto:tvilla@cyllene.uwa.edu.au> WWW <http://timvilla.com/>
Date: Wed, 2 Mar 2005 12:44:05 -0600 (CST)
From: Netlink Tech <tech at netlinkcom dot com>
Subject: error flushing output to client
Hello,
Is this still active?
Trying to find info on 'error flushing output to client' errors with
qpopper 4.05, Linux, etc.
Most of problems are slow connections and/or large messages and/or large
number of messages.
What is the solution to not have these problems.
OR what is a suitable replacement for qpopper?
Tried cucipop, but I have a number of users that use PINE to read e-mail,
which causes problems with UIDL and messages appearing as new (another
copy downloaded) to Outlook Express.
Thanks,
Curt
Date: Thu, 03 Mar 2005 11:22:39 +0800
From: Tim Villa <tvilla at cyllene dot uwa dot edu dot au>
Subject: Re: error flushing output to client
Try enable-chunky-writes, and perhaps having the temp drop folder residing
on a separate partition from your mail spools. Both will address
performance issues - the first for the link, the second for the server disk IO.
At 02:44 2005/03/03, Netlink Tech wrote:
>Hello,
>
>Is this still active?
>
>Trying to find info on 'error flushing output to client' errors with
>qpopper 4.05, Linux, etc.
>
>Most of problems are slow connections and/or large messages and/or large
>number of messages.
>
>What is the solution to not have these problems.
>
>OR what is a suitable replacement for qpopper?
>
>Tried cucipop, but I have a number of users that use PINE to read e-mail,
>which causes problems with UIDL and messages appearing as new (another
>copy downloaded) to Outlook Express.
>
>Thanks,
>Curt
--
Tim Villa, Network / Systems Administrator
M252, Business School and Law School
The University of Western Australia CRICOS provider number 00126G
Phone: +61-8-6488-1796, Fax: +61-8-6488-1068
Mail <mailto:tvilla@cyllene.uwa.edu.au> WWW <http://timvilla.com/>
Date: Thu, 3 Mar 2005 06:40:36 -0600 (CST)
From: Netlink Tech <tech at netlinkcom dot com>
Subject: Re: error flushing output to client
I am using enable-chunky-writes, enable-hash-spool=2,
enable-temp-drop-dir, enable-standalone.
The temp drop is not on a seperate partition right now, but I can try that too.
Thnx
On Thu, 3 Mar 2005, Tim Villa wrote:
> Try enable-chunky-writes, and perhaps having the temp drop folder residing
> on a separate partition from your mail spools. Both will address
> performance issues - the first for the link, the second for the server disk IO.
>
> At 02:44 2005/03/03, Netlink Tech wrote:
> >Hello,
> >
> >Is this still active?
> >
> >Trying to find info on 'error flushing output to client' errors with
> >qpopper 4.05, Linux, etc.
> >
> >Most of problems are slow connections and/or large messages and/or large
> >number of messages.
> >
> >What is the solution to not have these problems.
> >
> >OR what is a suitable replacement for qpopper?
> >
> >Tried cucipop, but I have a number of users that use PINE to read e-mail,
> >which causes problems with UIDL and messages appearing as new (another
> >copy downloaded) to Outlook Express.
> >
> >Thanks,
> >Curt
>
> --
> Tim Villa, Network / Systems Administrator
> M252, Business School and Law School
> The University of Western Australia CRICOS provider number 00126G
> Phone: +61-8-6488-1796, Fax: +61-8-6488-1068
> Mail <mailto:tvilla@cyllene.uwa.edu.au> WWW <http://timvilla.com/>
>
>
Date: Wed, 23 Mar 2005 13:41:00 -0500 (EST)
From: Sylvain Robitaille <syl at alcor dot concordia dot ca>
Subject: patch submission?
Hello ...
I have patched our installation of Qpopper-4.0b3 in an attempt to get
some of the benefit that's available in the "server" mode of that
version of the POP server, without needing to use "server" mode.
What I'm wondering is, is this an appropriate place to submit that
patch? Are the Qpopper developpers known to use this mailing list?
Are other people interested in my patch?
--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca
Systems analyst / Postmaster Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Date: Wed, 23 Mar 2005 13:57:22 -0500 (EST)
Subject: Re: patch submission?
From: "Joe Maimon" <jmaimon at ttec dot com>
> Hello ...
>
> I have patched our installation of Qpopper-4.0b3 in an attempt to get
> some of the benefit that's available in the "server" mode of that
> version of the POP server, without needing to use "server" mode.
>
> What I'm wondering is, is this an appropriate place to submit that
> patch? Are the Qpopper developpers known to use this mailing list?
> Are other people interested in my patch?
>
Yes
Thanks.
Date: Wed, 23 Mar 2005 17:27:13 -0500 (EST)
From: Sylvain Robitaille <syl at alcor dot concordia dot ca>
Subject: Re: patch submission?
Earlier, I wrote:
> What I'm wondering is, is this an appropriate place to submit that
> patch? Are the Qpopper developpers known to use this mailing list?
> Are other people interested in my patch?
Joe Maimon replied:
> Yes
Ok, so here goes ...
Appended below my signature is what actually amounts to two separate
patches against Qpopper-4.0.6b3: The first to reduce the amount of mail
spool copying that takes place in "normal" (non-server) mode, and the
second to have the POP server update the system "lastlog" file when the
user is authenticated.
For the first patch, pop_dropcopy.c and pop_updt.c are changed as
follows:
In pop_dropcopy.c, link the mail spool to the temp spool, acquire a
lock on the mail spool, unlink and recreate the mail spool, and release
the lock. If the link fails, (either because the temp spool is on a
different file system than the mail spool, or because the temp spool
already exists), fall back to the original code that copies the mail
spool into the temp spool.
In pop_updt.c, if no updates are pending (no messages were read,
requiring Status: or X-UIDL: header updates, and no no messages were
marked to be deleted), after the lock has been acquired on the mail
spool, and any new messages have been appended to the temp spool,
rename the temp spool to mail spool (overwriting the existing mail
spool whose contents have already been copied), rather than copying
the contents back.
This significantly reduces I/O on the system, particular in the case
where users who leave their mail on the server check frequently for
new mail. In our case, it has made the difference between a system
that had been otherwise rendered unusable (user's do use this system
for other purposes than POP, including an IMAP based webmail interface
and extensive filtering with Procmail in at least some cases), and a
system whose response has returned to what we consider normal for the
capabilities of this hardware.
The second patch permits us to use the system lastlog file to monitor
which accounts are used regularly, or more to the point, which ones
haven't been used in any way (interactively, POP, IMAP, FTP, etc.; I've
made the same mod to IMAP and FTP servers) in some extended period of
time. I added a function to pop_pass.c to update the lastlog file, then
added a call to that after the user authentication succeeds.
Note that some of the line numbers affected in pop_pass.c will be
different than a stock source tree, as I've removed from the diff some
site-specific changes we also make to that file.
We've been using the lastlog patch with various versions of the Qpopper
server for years without any trouble. The reduced I/O patch has been in
place for nearly two weeks, (though it did undergo some development
during the first week or so), on a system with approximately 20,000
users, (though only 1656 of them have used the POP service in the past
two weeks). Of those users that do use the POP service, enough of them
have their client software configured to check mail frequently enough
that it was rendering a 1 GHz dual Alpha system (with 10GB RAM, but
memory was not a problem at all) completely unusable. I upgraded from
Qpopper-3.0.2 to Qpopper-4.0.6b3, then added this reduced I/O
functionality to the non-server mode in Qpopper-4.0.6b3. The difference
in performance has been quite remarkable.
I hope others find this useful, and certainly if anyone finds errors or
other reasons to be concerned they'll bring it up ...
--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca
Systems analyst / Postmaster Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
--- popper/pop_dropcopy.c.original 2004-12-14 21:36:18.000000000 -0500
+++ popper/pop_dropcopy.c 2005-03-18 15:39:59.000000000 -0500
@@ -1485,7 +1485,95 @@
(long unsigned) geteuid(),
(long unsigned) getegid() );
- dfd = open ( p->temp_drop, O_RDWR | O_CREAT, 0660 );
+ /*
+ * 2005/03/10 Sylvain Robitaille: We want the temporary drop to be
+ * opened with the same permission as the real mail spool. Start
+ * by gathering that information.
+ */
+ if ( stat(p->drop_name, &mybuf) == -1 ) {
+ pop_log ( p, POP_PRIORITY, HERE,
+ "[SYS/TEMP] Unable to stat maildrop "
+ "'%s': %s (%d)",
+ p->drop_name, STRERROR(errno), errno );
+ return pop_msg ( p, POP_FAILURE, HERE,
+ "[SYS/TEMP] Failed to stat %s with uid %lu, "
+ "gid %lu. Change permissions.",
+ p->drop_name,
+ (long unsigned) pwp->pw_uid,
+ (long unsigned) pwp->pw_gid );
+ }
+ /*
+ * 2005/03/11 Sylvain Robitaille: Ideally, we can simply link the
+ * temp drop to the mail spool, unlink the mail spool,
+ * then recreate the mail spool, with suitable ownership
+ * and permission. Note that the link() system call
+ * will fail if the target already exists.
+ */
+ int CU_Drop_Linked = 0;
+ if ( link(p->drop_name, p->temp_drop) == -1 ) {
+ pop_log ( p, POP_PRIORITY, HERE,
+ "[SYS/TEMP] Link to temporary maildrop "
+ "'%s' failed: %s (%d)",
+ p->temp_drop, STRERROR(errno), errno );
+ } else {
+ CU_Drop_Linked++;
+ DEBUG_LOG1 ( p, "linked temp drop %s", p->temp_drop );
+ /*
+ * Make sure we lock the mail spool:
+ */
+ DEBUG_LOG0 ( p, "Getting mail lock" );
+ rslt = Qmaillock ( p->drop_name,
+ 2,
+ p->bNo_atomic_open,
+ p->pCfg_spool_dir,
+ p->trace,
+ HERE,
+ p->debug );
+ if ( rslt != 0 ) {
+ /*
+ * Can't get a lock, unlink the temp spool and return
+ */
+ unlink ( p->temp_drop );
+ return pop_msg ( p, POP_FAILURE, HERE,
+ "[SYS/TEMP] maillock error '%s' (%d) on '%s': %s (%d)",
+ Qlockerr(rslt), rslt, p->drop_name,
+ strerror(errno), errno );
+ } else {
+ DEBUG_LOG1 ( p, "Unlinking spool %s", p->drop_name );
+ if ( unlink(p->drop_name) == -1 ) {
+ pop_log ( p, POP_PRIORITY, HERE,
+ "[SYS/TEMP] Unable to unlink old maildrop "
+ "'%s': %s (%d)",
+ p->drop_name, STRERROR(errno), errno );
+ return pop_msg ( p, POP_FAILURE, HERE,
+ "[SYS/TEMP] Failed to unlink %s "
+ "with uid %lu, gid %lu.",
+ p->temp_drop,
+ (long unsigned) pwp->pw_uid,
+ (long unsigned) pwp->pw_gid );
+ } else {
+ int nfd = open ( p->drop_name, O_RDWR|O_CREAT, mybuf.st_mode );
+ if ( nfd == -1 ) {
+ pop_log ( p, POP_PRIORITY, HERE,
+ "[SYS/TEMP] Unable to create new maildrop "
+ "'%s': %s (%d)",
+ p->drop_name, STRERROR(errno), errno );
+ return pop_msg ( p, POP_FAILURE, HERE,
+ "[SYS/TEMP] Failed to create %s "
+ "with uid %lu, gid %lu.",
+ p->temp_drop,
+ (long unsigned) pwp->pw_uid,
+ (long unsigned) pwp->pw_gid );
+ } /* new mail drop creation failed */
+ } /* old mail drop unlinked */
+ } /* we have a lock on the mail spool */
+ } /* temp spool linked to mail spool */
+
+ /*
+ * 2005/03/11 Sylvain Robitaille: this open is Ok, but match
+ * permission.
+ */
+ dfd = open ( p->temp_drop, O_RDWR | O_CREAT, mybuf.st_mode );
if ( dfd == -1 ) {
pop_log ( p, POP_PRIORITY, HERE,
"[SYS/TEMP] Unable to open temporary maildrop "
@@ -1620,6 +1708,14 @@
} /* mybuf.st_size != 0 */
/*
+ * 2005/03/17 Sylvain Robitaille: If the temp spool was linked to
+ * the mail spool, we already have a lock, but it's
+ * reasonable to touch it here.
+ */
+ if ( CU_Drop_Linked ) {
+ Qtouchlock ( HERE );
+ } else {
+ /*
* Always use Qmaillock().
*/
@@ -1639,6 +1735,7 @@
Qlockerr(rslt), rslt, p->drop_name,
strerror(errno), errno );
}
+ }
time_locked = time(0);
/* Open the user's maildrop; if this fails, no harm in assuming empty */
--- popper/pop_updt.c.original 2004-12-14 21:36:18.000000000 -0500
+++ popper/pop_updt.c 2005-03-18 15:24:34.000000000 -0500
@@ -483,8 +483,41 @@
mfd );
} /* server mode */
- if ( p->server_mode == FALSE
- || ( p->msgs_deleted != p->msg_count ) ) {
+ /*
+ * 2005/03/10 Sylvain Robitaille: an attempt to add the "fast-update"
+ * feature in non-server mode: if no updates to the mail spool are
+ * pending, (a common case on systems where users normally "leave mail
+ * on server") rather than recopy the spool one message at a time,
+ * simply rename() it if we can.
+ */
+ int CU_Drop_Linked = 0;
+ if ( p->server_mode == FALSE &&
+ p->dirty == FALSE ) {
+
+ DEBUG_LOG2 ( p, "Renaming %s to %s",
+ p->temp_drop, p->drop_name );
+ nchar = rename ( p->temp_drop, p->drop_name );
+ if ( nchar == 0 ) {
+ DEBUG_LOG2 ( p, "Moved %s to %s",
+ p->temp_drop, p->drop_name );
+ CU_Drop_Linked++;
+ }
+ else {
+ pop_log ( p, POP_NOTICE, HERE,
+ "Unable to move %s to %s: %s (%d)",
+ p->temp_drop, p->drop_name,
+ STRERROR(errno), errno );
+ /* ensure that we'll fall back to copying the spool */
+ p->dirty = TRUE;
+ }
+ } /* !p->server_mode && !p->dirty */
+
+ /*
+ * 2005/03/10 Sylvain Robitaille: if there are pending updates, or
+ * rename() failed, fall back to the original copying
+ * method.
+ */
+ if ( p->server_mode == FALSE && p->dirty ) {
DEBUG_LOG7 ( p, "Server mode=%i; %i out of %i msgs deleted; "
"copying msgs from %s (%d) to %s (%d)",
p->server_mode, p->msgs_deleted, p->msg_count,
@@ -628,7 +661,7 @@
p->drop_size += length;
} /* msg loop */
- /* flush and check for errors now! The new mail will be writen
+ /* flush and check for errors now! The new mail will be written
* without stdio, since we need not separate messages
*/
@@ -827,6 +860,7 @@
Qmailunlock ( HERE );
} /* server mode */
else {
+ if ( !CU_Drop_Linked ) {
DEBUG_LOG2 ( p, "non-server mode; copying any new msgs back from"
"temp drop (%d) to spool (%d)",
fileno(p->drop), mfd );
@@ -867,13 +901,13 @@
/*
* Close the maildrop and empty temporary maildrop
*/
- fclose ( md );
ftruncate ( fileno(p->drop), (OFF_T)0 );
DEBUG_LOG1 ( p, "truncated temp drop (%d)", fileno(p->drop) );
unlink_temp_drop ( p, p->temp_drop, HERE );
fclose ( p->drop );
+ } /* !CU_Drop_Linked */
+ fclose ( md );
Qmailunlock ( HERE );
-
} /* non-server mode */
if ( p->bDo_timing )
--- popper/popper.h.original 2004-09-02 01:24:08.000000000 -0400
+++ popper/popper.h 2005-03-08 15:35:01.000000000 -0500
@@ -101,6 +101,13 @@
#define ALLOC_MSGS 20
#define OUT_BUF_SIZE 512 /* Amount of output to buffer before forcing a write */
+/* ----------------------------------------------------------------- */
+/* 1997/11/21 Sylvain Robitaille: Added ability to record POP access */
+/* in lastlog file, so let's define where the lastlog file is. */
+/* */
+# define LASTLOG "/var/adm/lastlog"
+/* ----------------------------------------------------------------- */
+
#ifndef MAXHOSTNAMELEN
# define MAXHOSTNAMELEN 64
#endif /* not MAXHOSTNAMELEN */
--- popper/pop_pass.c.original 2004-12-14 21:22:23.000000000 -0500
+++ popper/pop_pass.c 2005-03-08 16:40:29.000000000 -0500
@@ -1283,6 +1283,66 @@
#endif /* SPEC_POP_AUTH */
+/***************************************************************
+ * *
+ * Function: update_lastlog(POP *p, uid_t uid) *
+ * *
+ * Description: records the user's login in the system lastlog *
+ * file. *
+ * *
+ * Author: Sylvain Robitaille -- using code borrowed from the *
+ * ssh source. *
+ * *
+ * NOTE: This code is written specifically for Digital Unix on *
+ * an Alpha. No attempts for portability were made. *
+ * *
+ * Date: 1997/11/21 *
+ * 2000/06/01 copied into new version added HERE to *
+ * pop_log call args *
+ * *
+ ***************************************************************/
+void update_lastlog(POP *p, uid_t uid) {
+# include <lastlog.h>
+# include <fcntl.h>
+
+ int fd; /* file descriptor */
+ struct lastlog ll; /* lastlog information held here */
+
+ /* LASTLOG is defined in popper.h to be the path to the lastlog file. */
+ const char *lastlog = LASTLOG;
+
+ /*
+ * extract elements of p
+ */
+ const char *user = p->user;
+ const char *host = p->client;
+
+ /*
+ * Now update the lastlog file.
+ */
+
+ /* Check that things are sane. */
+ if(strcmp(user, "") != 0) {
+ /* Initialize the lastlog structure */
+ memset(&ll, 0, sizeof(ll));
+
+ /* Fill in the data */
+ ll.ll_time = time(NULL);
+ strncpy(ll.ll_line, "pop", sizeof(ll.ll_line));
+ strncpy(ll.ll_host, host, sizeof(ll.ll_host));
+
+ fd = open(lastlog, O_RDWR);
+ if(fd >= 0) {
+ lseek(fd, (off_t)((long)uid * sizeof(ll)), 0);
+ if(write(fd, &ll, sizeof(ll)) != sizeof(ll))
+ pop_log(p, POP_PRIORITY, HERE, "Could not write %.100s: %.100s",
+ lastlog, strerror(errno));
+ close(fd);
+ }
+ }
+}
+
+
/*
* pass: Obtain the user password from a POP client
*/
@@ -1439,6 +1523,14 @@
#endif /* SECURENISPLUS */
/*
+ * 1997/11/19 Sylvain Robitaille
+ * ----------
+ * Right here would be a fine spot for updating the lastlog file.
+ * We need to be sure to do so before dropping priviledges.
+ */
+ update_lastlog(p, pwp->pw_uid);
+
+ /*
* Check if server mode should be set or reset based on group membership.
*/
Date: Wed, 23 Mar 2005 12:45:33 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: patch submission?
On Wed, Mar 23, 2005 at 05:27:13PM -0500, Sylvain Robitaille wrote:
> Earlier, I wrote:
>
> > What I'm wondering is, is this an appropriate place to submit that
> > patch? Are the Qpopper developpers known to use this mailing list?
> > Are other people interested in my patch?
>
>
> Joe Maimon replied:
>
> > Yes
>
...
> For the first patch, pop_dropcopy.c and pop_updt.c are changed as
> follows:
>
> In pop_dropcopy.c, link the mail spool to the temp spool, acquire a
> lock on the mail spool, unlink and recreate the mail spool, and release
> the lock. If the link fails, (either because the temp spool is on a
> different file system than the mail spool, or because the temp spool
> already exists), fall back to the original code that copies the mail
> spool into the temp spool.
>
> In pop_updt.c, if no updates are pending (no messages were read,
> requiring Status: or X-UIDL: header updates, and no no messages were
> marked to be deleted), after the lock has been acquired on the mail
> spool, and any new messages have been appended to the temp spool,
> rename the temp spool to mail spool (overwriting the existing mail
> spool whose contents have already been copied), rather than copying
> the contents back.
Isn't this almost precisely what the "-F" flag or "fast-update"
config file option does?? See the Qpopper 4.0 Manual PDF, p.33
> The second patch permits us to use the system lastlog file to monitor
> which accounts are used regularly, or more to the point, which ones
> haven't been used in any way (interactively, POP, IMAP, FTP, etc.; I've
> made the same mod to IMAP and FTP servers) in some extended period of
> time. I added a function to pop_pass.c to update the lastlog file, then
> added a call to that after the user authentication succeeds.
This sounds like a nice idea.
-- Clifton
--
Clifton Royston -- cliftonr@tikitechnologies.com
Tiki Technologies Lead Programmer/Software Architect
"I'm gonna tell my son to grow up pretty as the grass is green
And whip-smart as the English Channel's wide..."
-- 'Whip-Smart', Liz Phair
From: Greg Earle <earle at isolar dot DynDNS dot ORG>
Subject: Re: patch submission?
Date: Wed, 23 Mar 2005 15:14:03 -0800
On Mar 23, 2005, at 2:27 PM, Sylvain Robitaille wrote:
> Appended below my signature is what actually amounts to two separate
> patches against Qpopper-4.0.6b3: The first to reduce the amount of mail
> spool copying that takes place in "normal" (non-server) mode, and the
> second to have the POP server update the system "lastlog" file when the
> user is authenticated.
Jeez. Where were you with this patch a year ago, when I needed it? :-P
(I've been migrating people off of an old Sun SPARCserver 20/71 mail
server
running Qpopper 4.0.5 to a SunFire V210. Most of the people with big
spool files - that were killing the SS20 - have been moved to the new
V210 already, so my need for this isn't anywhere near what it was a
year ago. Thanks anyway for sending it in though ... )
- Greg
From: "Alan W dot Rateliff, II" <lists at rateliff dot net>
Subject: poppassd (epass) status?
Date: Thu, 24 Mar 2005 16:45:31 -0500
Has anyone done any more work on the poppassd daemon? I'm having issues
with it talking to /usr/bin/passwd on Solaris 8 and wondered if anything had
been done beyond what exists in the QPopper 4.0.5 source.
--
Alan W. Rateliff, II : RATELIFF.NET
Independent Technology Consultant : alan2@rateliff.net
(Office) 850/350-0260 : (Mobile) 850/559-0100
-------------------------------------------------------------
[System Administration][IT Consulting][Computer Sales/Repair]
Date: Fri, 25 Mar 2005 02:06:57 -0500 (EST)
From: Sylvain Robitaille <syl at alcor dot concordia dot ca>
Subject: Re: patch submission?
On Wed, 23 Mar 2005, Clifton Royston wrote:
> Isn't this almost precisely what the "-F" flag or "fast-update"
> config file option does??
I believe that it is, though I had been left with the impression that
this feature requires (or perhaps implies?) that "server mode" also be
used, and that this was not suitable in our environment.
On Wed, 23 Mar 2005, Greg Earle wrote:
> Jeez. Where were you with this patch a year ago, when I needed it?
Using Qpopper-3.something, but acheiving performance milestones with
other parts of the system and different software packages. :-)
The POP server started showing up as a performance "problem" only about
a month or so ago. First I upgraded our installation to 4.0.6b3, to get
a feel for how much it would improve things by itself, then I started
looking for ways to reduce its I/O impact without moving into a POP-only
situation (because we're not a POP-only service).
> Thanks anyway for sending it in though ...
I'm glad to do it. Hopefully, since my performance patch isn't helpful
to you, the lastlog patch might still be ...
--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca
Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Subject: Mail Relay not allowed
From: Roy_Harrison at notes dot rlg dot org
Date: Fri, 1 Apr 2005 12:12:10 -0800
This is stumping me. I have the machine/network I'm sending from in the
/etc/mail/relay-domains..this has worked fine for generic sendmail and I
swear it did on an earlier test of qpopper. Now I get the following back
from my client when I try to send mail to an address outside of my domain
(rlg.org).:
The following addresses had permanent fatal errors -----
<thinkgreen@threeparty.org>
(reason: 550 Mail relay not allowed)
I can send email to another mail server in my network..like the one I'm
sending this email from.
This seems to be a very basic RTFM type of issue but the FM ain't telling
me anything about relaying.
Thanks Ahead of time
Roy
Subject: Re: Mail Relay not allowed
From: Roy_Harrison at notes dot rlg dot org
Date: Fri, 1 Apr 2005 12:24:31 -0800
Duh Roy...this is Qpopper...not sendmail no wonder it doesn;t have
anything about relaying.
I wish I had this conversation before I hit send :-)
Peace
Roy
Roy_Harrison@notes.rlg.org
04/01/2005 12:12 PM
To: Subscribers of Qpopper <qpopper@lists.pensive.org>
cc:
Subject: Mail Relay not allowed
This is stumping me. I have the machine/network I'm sending from in the
/etc/mail/relay-domains..this has worked fine for generic sendmail and I
swear it did on an earlier test of qpopper. Now I get the following back
from my client when I try to send mail to an address outside of my domain
(rlg.org).:
The following addresses had permanent fatal errors -----
<thinkgreen@threeparty.org>
(reason: 550 Mail relay not allowed)
I can send email to another mail server in my network..like the one I'm
sending this email from.
This seems to be a very basic RTFM type of issue but the FM ain't telling
me anything about relaying.
Thanks Ahead of time
Roy
From: "Phil Kemp" <kemp at pkemp dot com>
Subject: I/O EOF Help - I'm stuck...
Date: Mon, 18 Apr 2005 11:50:38 -0700
I am using qpopper on a linux RH 7.1 system and had been having no problems
with it up until a couple of weeks ago.
I typically access the linux machine from a winXP box. Eudora worked fine,
Outlook worked fine, telnet to port 110 worked fine.
Now for some reason that I cannot determine, the pop session abnormally
terminates at the point where the messages are being retrieved. Telnet
sessions to port 110 show that the login process succeeds, the LIST command
shows the messages.
Once I issue the RETR command the connection drops.
I have compiled in and turned on debug and have the log files. I hesitate to
post them in case this is known issue. I have googled it and found spotty
references but nothing definitive..
I should note that this behaviour is seen on two different net interfaces on
the winxp box, with and without the firewall. I am running SP2, but the
behaviour was also present on SP1. Disabling Symantec Virus does nothing
either...
I am completely stumped...
BTW, Eudora happily sends email via SMTP and my web access is fine using
browsers and other program....
Any help would be most appreciated..
Cheers
Phil Kemp
--
Phil Kemp
phil@pkemp.com
From: "Phil Kemp" <kemp at pkemp dot com>
Subject: Re: I/O EOF Help - I'm stuck...
Date: Mon, 18 Apr 2005 12:42:27 -0700
This is a multi-part message in MIME format.
------=OPENWEBMAIL_ATT_0.386403865021752
Content-Type: text/plain;
charset=iso-8859-1
On Mon, 18 Apr 2005 15:23:19 -0400 (EDT), Sylvain Robitaille wrote
> On Mon, 18 Apr 2005, Phil Kemp wrote:
>
> > Now for some reason that I cannot determine, the pop session abnormally
> > terminates at the point where the messages are being retrieved. Telnet
> > sessions to port 110 show that the login process succeeds, the LIST
> > command shows the messages.
> >
> > Once I issue the RETR command the connection drops.
>
> This is when issuing RETR during a telnet session to the POP server?
Yes..
> Does it happen regardless of the message you're asking to RETR, or only
> with one (or more) specific message(s)?
Any message
> Are you able to verify that
> the mail spool isn't corrupted somehow?
Yes the spool is fine. openmail, elm, mutt, and mail all read it fine.
>
> I'll be interested in seeing what more you find about this. I've
> seen what I think is similar behaviour as you describe, but from
> what I'm able to see it has always looked to me as though the
> *client* is dropping the connection ...
See the attached file for the debug log output...
Any guidance is most appreciated...
Cheers
PK
>
> --
> ----------------------------------------------------------------------
> Sylvain Robitaille syl@alcor.concordia.ca
>
> Systems analyst Concordia
> University Instructional & Information Technology Montreal,
> Quebec, Canada
> ----------------------------------------------------------------------
--
Phil Kemp
phil@pkemp.com
------=OPENWEBMAIL_ATT_0.386403865021752
Content-Type: text/plain;
name="pop.log.short"
Content-Disposition: attachment; filename="pop.log.short"
Content-Transfer-Encoding: base64
CkFwciAxOCAxMDo0NTowMiBuYWtpc2thIHBvcHBlclsyNDAxMV06IG5vbi1zZXJ2ZXIgbW9kZTsg
Y29weWluZyBhbnkgbmV3IG1zZ3MgYmFjayBmcm9tdGVtcCBkcm9wICg0KSB0byBzcG9vbCAoNSkg
W3BvcF91cGR0LmM6ODIzXQpBcHIgMTggMTA6NDU6MDIgbmFraXNrYSBwb3BwZXJbMjQwMTFdOiB0
b3VjaGxvY2soKSBjYWxsZWQgW3BvcF91cGR0LmM6ODMxXSBmb3IgL3Zhci9tYWlsL2tlbXAubG9j
ayBbbWFpbGxvY2suYzo2MTJdCkFwciAxOCAxMDo0NTowMiBuYWtpc2thIHBvcHBlclsyNDAxMV06
IHRydW5jYXRlZCB0ZW1wIGRyb3AgKDQpIFtwb3BfdXBkdC5jOjg2NV0KQXByIDE4IDEwOjQ1OjAy
IG5ha2lza2EgcG9wcGVyWzI0MDExXTogVW5saW5rZWQgW3BvcF91cGR0LmM6ODY2XSB0ZW1wIGRy
b3AgKC92YXIvbWFpbC8ua2VtcC5wb3ApIFtwb3BfdXBkdC5jOjE0NV0KQXByIDE4IDEwOjQ1OjAy
IG5ha2lza2EgcG9wcGVyWzI0MDExXTogbWFpbHVubG9jaygpIGNhbGxlZCBbcG9wX3VwZHQuYzo4
NjhdIGZvciAvdmFyL21haWwva2VtcC5sb2NrIFttYWlsbG9jay5jOjU3OV0KQXByIDE4IDEwOjQ1
OjAyIG5ha2lza2EgcG9wcGVyWzI0MDExXTogK09LIFBvcCBzZXJ2ZXIgYXQgbmFraXNrYS5wa2Vt
cC5jb20gc2lnbmluZyBvZmYuIFtwb3BwZXIuYzozNjBdCkFwciAxOCAxMDo0NTowMiBuYWtpc2th
IHBvcHBlclsyNDAxMV06IEkvTyBlcnJvciBmbHVzaGluZyBvdXRwdXQgdG8gY2xpZW50IGtlbXAg
YXQgNjMuMjAwLjczLjIxMSBbNjMuMjAwLjczLjIxMV06IE9wZXJhdGlvbiBub3QgcGVybWl0dGVk
ICgxKSBbcG9wX3NlbmQuYzo2ODldCkFwciAxOCAxMDo0NTowMiBuYWtpc2thIHBvcHBlclsyNDAx
MV06ICh2NC4wLjUpIEVuZGluZyByZXF1ZXN0IGZyb20gImtlbXAiIGF0ICg2My4yMDAuNzMuMjEx
KSA2My4yMDAuNzMuMjExIFtwb3BwZXIuYzozNzddCgo
------=OPENWEBMAIL_ATT_0.386403865021752--
Date: Mon, 18 Apr 2005 15:23:19 -0400 (EDT)
From: Sylvain Robitaille <syl at alcor dot concordia dot ca>
Subject: Re: I/O EOF Help - I'm stuck...
On Mon, 18 Apr 2005, Phil Kemp wrote:
> Now for some reason that I cannot determine, the pop session abnormally
> terminates at the point where the messages are being retrieved. Telnet
> sessions to port 110 show that the login process succeeds, the LIST
> command shows the messages.
>
> Once I issue the RETR command the connection drops.
This is when issuing RETR during a telnet session to the POP server?
Does it happen regardless of the message you're asking to RETR, or only
with one (or more) specific message(s)? Are you able to verify that the
mail spool isn't corrupted somehow?
I'll be interested in seeing what more you find about this. I've seen
what I think is similar behaviour as you describe, but from what I'm
able to see it has always looked to me as though the *client* is
dropping the connection ...
--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca
Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Date: Tue, 19 Apr 2005 13:03:10 -0400 (EDT)
From: Sylvain Robitaille <syl at alcor dot concordia dot ca>
Subject: Re: I/O EOF Help - I'm stuck...
On Mon, 18 Apr 2005, Phil Kemp wrote:
> See the attached file for the debug log output...
Well, it all looks "normal" to me until this line:
Apr 18 10:45:02 nakiska popper[24011]: I/O error flushing output to
client kemp at ...: Operation not permitted (1) [pop_send.c:689]
The relevant code of pop_send.c is:
664 /*
665 * Flush the output that might be buffered to client
666 */
667 void
668 pop_write_flush ( POP *p )
669 {
670 int rslt = 0;
...
681 rslt = fflush ( p->output );
...
684 if ( rslt == EOF ) {
...
689 pop_log ( p, POP_NOTICE, HERE, ... );
...
694 hangup = TRUE;
695 } /* flush failed */
...
700 }
Note particularly lines 681 and 684. I'm still left believing that
Qpopper at least has indications that the client has already left the
connection.
If I read your log extract correctly, this is from after a QUIT has been
issued. Do you have any (debug-level) logs of this happening during a
manual RETR request? Perhaps a similar level log of an entire session?
--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca
Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Date: Wed, 20 Apr 2005 11:23:20 -0700
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: I/O EOF Help - I'm stuck...
The log snippit starts with Qpopper cleaning up the connection. It
would be helpful to see what happened prior to that point, especially
what it was that made Qpopper start cleaning up. Was it a QUIT? A
client disconnect? A HUP singal?
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
It wasn't as easy to get programs right as we had thought.
--Wilkes, 1949
From: "Phil Kemp" <kemp at pkemp dot com>
Subject: Re: I/O EOF Help - I'm stuck...
Date: Wed, 20 Apr 2005 12:15:32 -0700
It was definitley not a QUIT..
I'm beginning to believe that it was a client disconnect. It's very hard to
tell why.... on the client machine ALL POP3 clients fail. Eudora, Outlook
2003, and a Telnet to port 110..
All net traffic is fine... ftp, http, CIFS.. They all work fine and at full
bandwidth..
I'll look into the HUP on linux side...
More when I get more data..
thanks
PK
On Wed, 20 Apr 2005 11:23:20 -0700, Randall Gellens wrote
> The log snippit starts with Qpopper cleaning up the connection. It
> would be helpful to see what happened prior to that point,
> especially what it was that made Qpopper start cleaning up. Was it
> a QUIT? A client disconnect? A HUP singal?
> --
> Randall Gellens
> Opinions are personal; facts are suspect; I speak for myself only
> -------------- Randomly-selected tag: ---------------
> It wasn't as easy to get programs right as we had thought.
> --Wilkes, 1949
--
Phil Kemp
phil@pkemp.com
Date: Wed, 20 Apr 2005 14:26:35 -0700
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: I/O EOF Help - I'm stuck...
At 12:15 PM -0700 4/20/05, Phil Kemp wrote:
> It was definitley not a QUIT..
>
> I'm beginning to believe that it was a client disconnect. It's very hard to
> tell why.... on the client machine ALL POP3 clients fail. Eudora, Outlook
> 2003, and a Telnet to port 110..
Interesting that all clients fail.
I'd suggest a client-side trace or a TCP packet trace. Or, a kernel
trace on the server side (run Qpopper on a new port and run it via
ktrace, truss, or the equivalent on your platform).
To enable client-side tracing in Eudora:
On Macs, drag the "esoteric settings" plug-in (which comes with
Eudora) from the "Extra Plugins" folder to the "Eudora Stuff" folder.
Quit and restart Eudora. Then in your Eudora settings go to
"Logging". Check "all bytes transferred".
On Windows, move the "esoteric.epi" plug-in (which comes with Eudora)
from the "extrastuff" folder to the same folder as the "eudora.exe"
file. Quit and relaunch Eudora. Then in your Eudora settings go to
"Logging". Check "all bytes sent" and "all bytes received".
Date: Wed, 20 Apr 2005 11:51:18 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: I/O EOF Help - I'm stuck...
On Wed, Apr 20, 2005 at 12:15:32PM -0700, Phil Kemp wrote:
> It was definitley not a QUIT..
>
> I'm beginning to believe that it was a client disconnect. It's very hard to
> tell why.... on the client machine ALL POP3 clients fail. Eudora, Outlook
> 2003, and a Telnet to port 110..
This sounds to me like you might still be running into the AV
software issue.
It is possible that Symantec (you did say it was Symantec NAV,
right?) may have changed their MO for clientside POP filtering from
changing the mail client settings in Eudora/etc. as they used to do, to
silently performing TCP redirection to the NAV local proxy and
rewriting the session commands on the fly so that they can do their
spam and AV filtering.
To debug this, or at least to verify if it's happening, you'll need
to run tcpdump on the server POP session, while connecting to POP via
telnet from the suspect box.
If you're typing one thing, but you're seeing something quite
different come across the wire and hit the POP server, then you can be
fairly sure that something like that is going on inside the client
machine.
-- Clifton
--
Clifton Royston -- cliftonr@tikitechnologies.com
Tiki Technologies Lead Programmer/Software Architect
"I'm gonna tell my son to grow up pretty as the grass is green
And whip-smart as the English Channel's wide..."
-- 'Whip-Smart', Liz Phair
Date: Wed, 20 Apr 2005 15:48:56 -0700
From: Ken A <ka at pacific dot net>
Subject: Re: I/O EOF Help - I'm stuck...
What type of net access do you have on this box. I know you said it had
2 interfaces, but what kind? Where's it go between there and the
mailserver? Sounds like plain ole' connection issues to me.
suspected culprits: pppoe mtu or dialup modem line noise if you are on
an internet link.
If it's on a lan, try plugging the XP box directly into the Redhat box
with a crossover cable. If that works, then you've got somewhere to look
next.
Ken
Phil Kemp wrote:
> It was definitley not a QUIT..
>
> I'm beginning to believe that it was a client disconnect. It's very hard to
> tell why.... on the client machine ALL POP3 clients fail. Eudora, Outlook
> 2003, and a Telnet to port 110..
>
> All net traffic is fine... ftp, http, CIFS.. They all work fine and at full
> bandwidth..
>
> I'll look into the HUP on linux side...
>
> More when I get more data..
>
> thanks
> PK
>
> On Wed, 20 Apr 2005 11:23:20 -0700, Randall Gellens wrote
>
>>The log snippit starts with Qpopper cleaning up the connection. It
>>would be helpful to see what happened prior to that point,
>>especially what it was that made Qpopper start cleaning up. Was it
>>a QUIT? A client disconnect? A HUP singal?
>>--
>>Randall Gellens
>>Opinions are personal; facts are suspect; I speak for myself only
>>-------------- Randomly-selected tag: ---------------
>>It wasn't as easy to get programs right as we had thought.
>> --Wilkes, 1949
>
>
>
> --
> Phil Kemp
> phil@pkemp.com
>
>
Date: Wed, 20 Apr 2005 23:21:15 -0400
From: Daniel Senie <dts at senie dot com>
Subject: Re: I/O EOF Help - I'm stuck...
At 05:51 PM 4/20/2005, Clifton Royston wrote:
>On Wed, Apr 20, 2005 at 12:15:32PM -0700, Phil Kemp wrote:
> > It was definitley not a QUIT..
> >
> > I'm beginning to believe that it was a client disconnect. It's very
> hard to
> > tell why.... on the client machine ALL POP3 clients fail. Eudora, Outlook
> > 2003, and a Telnet to port 110..
>
> This sounds to me like you might still be running into the AV
>software issue.
>
> It is possible that Symantec (you did say it was Symantec NAV,
>right?) may have changed their MO for clientside POP filtering from
>changing the mail client settings in Eudora/etc. as they used to do, to
>silently performing TCP redirection to the NAV local proxy and
>rewriting the session commands on the fly so that they can do their
>spam and AV filtering.
Norton intercepts ports 110 and 25, yes. Put up Qpopper on port 109 and see
if that gets you running. If so, put up qpopper on port 995 and SMTP on 465
to work around issues with people running Norton AV. That's what we're
doing to deal with users running Norton AV 2005.
> To debug this, or at least to verify if it's happening, you'll need
>to run tcpdump on the server POP session, while connecting to POP via
>telnet from the suspect box.
>
> If you're typing one thing, but you're seeing something quite
>different come across the wire and hit the POP server, then you can be
>fairly sure that something like that is going on inside the client
>machine.
>
> -- Clifton
>
>--
> Clifton Royston -- cliftonr@tikitechnologies.com
> Tiki Technologies Lead Programmer/Software Architect
>"I'm gonna tell my son to grow up pretty as the grass is green
>And whip-smart as the English Channel's wide..."
> -- 'Whip-Smart', Liz Phair
Last updated on 20 Apr 2005 by Pensive Mailing List Admin