Incidentally, I sometimes get the same symptoms in my unpatched, stock 1.1 dbmail-imapd. While not the same code at work, perhaps there is a similar memory corruption issue to be found.
Roel, you were reportedly looking into problems in the common server parts, but perhaps there's simply an innocent looking memory issue in the imapd code... I'd dig into it, but I don't have any time this week :-\ I think it's time for more-eyes-make-every-bug-shallow ;-) Hope this patch makes it into CVS soon! Aaron On 22 May 2003, Jason Burfield wrote: > Jesse... > > This seems to have fixed all of the problems I was having. It not only > took care of the process taking off on me, but also seems to have fixed > one other small problem I was having. > > I had a few clients that said about 50% of the time they had trouble > getting their mail, and would get errors of the server denying or not > being found. At first I thought it was a DNS error, which didn't make > any sense because some clients with multiple accounts on the same > machine would be able to check one but not another at the same time. > > Anyway...since installing this updated version that problem has also > gone away. > > Many thanks! > > -- Jason > > > On Tue, 2003-05-20 at 16:07, Jesse Norell wrote: > > [Resending, with patch actually included this time.] > > > > Hello Jason, > > > > After a little discussion with Ryan, the purpose of his patch was > > to fix the pop3 state machine when returning from apop (which has no > > plaintext password, creating a problem with a check for password!=NULL > > at a point), but it created a double free() of a pointer. According > > to the man page, that creates undefined behavior, which for Ryan seems > > to be working fine, but for you is quite nasty. :) The attached > > patch handles that case in the state machine, as well as checking a > > couple lengths (and fixing a buffer overrun with long USER arg) ... it > > seems to work fine in a small amount of testing, but give it a try and > > see if it fixes your problem, etc. Please report back with your > > results, as this is something that needs to be fixed in cvs code. > > (Download latest cvs code, and don't use Ryan's patch with this.) > > > > Later, > > Jesse > > > > > > ---- Original Message ---- > > From: Jason Burfield <dbmail@dbmail.org> > > To: dbmail@dbmail.org > > Subject: Re: [Dbmail] High Load Average and dbmail-pop3d ? > > Sent: 20 May 2003 13:34:47 -0400 > > > > > Yeah, I am using that patch that Ryan supplied. Without it all my > > > clients were getting multiple copies of each email. > > > > > > The server really is not that busy. There are about 300 total email > > > addresses handled by the machine with only about 75 or so using POP to > > > actually check for mail. The rest forward off to different places. > > > > > > During the last few times that it took off, there was only one > > > connection to the server. The one before it was 10 seconds before. > > > > > > I set the MAXCONNECTS to 1 and still have the problem. Unfortunately. > > > > > > Also, I know this is strange, but it's true...I have a client that can > > > cause this situation to happen on demand by supplying an incorrect > > > password for his account. HOWEVER, at trace_level 5 it does not happen > > > frequently at all. > > > > > > I just set the trace_level to 1 and had him send an incorrect password, > > > dbmail-pop3d immediately took off on the machine. I then changed the > > > trace_level to 5 and had him try it again, this time it did not run away > > > like it did before. > > > > > > I'm running glibc-2.3.2-4.80 which I believe is standard RedHat 8. > > > > > > I saw the wrong hash being passed in and tried to figure out where it > > > was coming from, but I'm by no means a C programmer so I wasn't having > > > much luck. :o > > > > > > Is there any additional info I should pass along? > > > > > > I was going to try the latest daily snapshot, would that be worth a try > > > you think? However, I would still need Ryan's patch to keep clients from > > > freaking out on me about the multiple copies of each email... > > > > > > Again..thanks for all the help! > > > > > > -- Jason > > > > > > > > > On Tue, 2003-05-20 at 12:33, Jesse Norell wrote: > > > > Hmm... > > > > > > > > Jason, you running non-standard code? :) I've looked all through > > > > the pop3 code for md5 from today's cvs, and I don't see anything > > > > that would be a problem - my next questions were going to be along > > > > the lines of questioning your libc, because you've got values printing > > > > out in variables that are for other things (eg. in > > > > md5_apop_he=[<[EMAIL PROTECTED]>pass] - that variable should > > > > only contain an md5 hash, not the apop_stamp+password). > > > > > > > > > > > > ---- Original Message ---- > > > > From: Ryan Butler <dbmail@dbmail.org> > > > > To: dbmail@dbmail.org > > > > Subject: Re: [Dbmail] High Load Average and dbmail-pop3d ? > > > > Sent: 20 May 2003 11:14:02 -0500 > > > > > > > > > If setting the maxconnect=1 does fix the problem, its quite possibly a > > > > > side affect of the patch I made an believe I sent to the list a while > > > > > back, and recently sent to Jason upon request for apop authentication. > > > > > > > > > > APOP has no password associated with it, and the dbmail-pop3d has a > > > > > state machine that if there is not a valid username and password, it > > > > > will always fail the connection. This was causing anyone using apop > > > > > to > > > > > have problems for us, so my fix (search the archives for the patch) > > > > > was > > > > > to set the session->password on an apop connection = the apop hash > > > > > > > > > > This works for me, but I always have maxconnect=1 since the previous > > > > > bug > > > > > about disconnecting in the middle of a session sent your mail to the > > > > > next person who connected to that process bug... > > > > > > > > > > > > > > > On Tue, 2003-05-20 at 09:51, Jesse Norell wrote: > > > > > > Hello, > > > > > > > > > > > > Right off, this looks quite suspect: > > > > > > > > > > > > > May 19 18:57:27 vault dbmail/pop3d[25871]: pop3(): APOP auth, > > > > > > > username > > > > > > > [EMAIL PROTECTED], md5_hash [EMAIL PROTECTED] > > > > > > > > > > > > There are invalid characters in that md5 hash - the variable is > > > > > > probably getting walked on somewhere. I'll see if I can find > > > > > > anything > > > > > > obvious from the code. Is this a pretty busy server? Can you look > > > > > > at > > > > > > the logs and try to determine if this only happenes when there are > > > > > > multiple users simultaneously authenticating? Also, for testing, > > > > > > see > > > > > > if setting MAXCONNECTS to 1 in dbmail.conf makes the problem go > > > > > > away. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Jesse Norell > > > > > > jesse (at) kci.net > > > > > > > > > > > > _______________________________________________ > > > > > > Dbmail mailing list > > > > > > Dbmail@dbmail.org > > > > > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > > > > > > > > > > -- End Original Message -- > > > > > > > > > > > > -- > > > > Jesse Norell > > > > jesse (at) kci.net > > > > > > > > _______________________________________________ > > > > Dbmail mailing list > > > > Dbmail@dbmail.org > > > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > > > > > > _______________________________________________ > > > Dbmail mailing list > > > Dbmail@dbmail.org > > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > -- End Original Message -- > > > > > > -- > > Jesse Norell > > jesse (at) kci.net > > _______________________________________________ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail >
