Log entry: success: did_0+0+0???
Good Morning to all, especially those burning the midnite oil! This evening I caught my qmail/vpopmail server not doing it's job. I would like to keep it from happening in the future, and to help fill in some blank spots as to what really makes this thing work. This server runs about 10 virtual domains, but only handles maybe 20 - 100 messages per hour. Light usage, I would guess. For about the last 30 hours or so, it appears that all incoming mail has been accepted for my domain 'sasnak.net', and then vaporized. All other domains mail has been delivered successfully. All log entries show this for 'sasnak.net' delivery 28: success: did_0+0+0/ and the messages are nowhere to be found. A search of the mailing list caused me to look at permissions/ownerships, so I created a new domain (test.com) and compared these things. Nothing turned up. Out of desperation, I tried echo to: [EMAIL PROTECTED] | /var/qmail/bin/qmail-inject and the messages was delivered properly. I thought maybe tcpserver qmail-smtp might have been causing it, but before going any further, I tried sending myself a message via sqwebmail, and it worked. It previously had not been working. All the incoming mail has been delivered correctly since then. My specific questions are these. Where did the mail go during this time? What caused it to start working? Not my qmail-inject, I'm sure. How do I keep it from happening again? Where is there more info on the "success: did_0+0+0" and "success: did_0+0+1" log messages? I have seen a few other numbers or combinations in here and would like to know what they mean. As a "probably not important" footnote, I had installed BigBrother on this server in the last two weeks, but had made no changes recently. As part of my troubleshooting, I had rebooted the machine and had not restarted BigBrother about one hour before this started working again. Thank You, Sam Laffere Just a clip of the logs: Mar 24 23:10:30 moe qmail: 985497030.206191 info msg 112050: bytes 289 from [EMAIL PROTECTED] qp 980 uid 1008 Mar 24 23:10:30 moe qmail: 985497030.214839 starting delivery 28: msg 112050 to local [EMAIL PROTECTED] Mar 24 23:10:30 moe qmail: 985497030.215062 status: local 1/10 remote 0/20 Mar 24 23:10:30 moe qmail: 985497030.226354 delivery 28: success: did_0+0+0/ Mar 24 23:10:30 moe qmail: 985497030.226584 status: local 0/10 remote 0/20 Mar 24 23:10:30 moe qmail: 985497030.226741 end msg 112050 Mar 24 23:13:19 moe qmail: 985497199.789656 new msg 112050 Mar 24 23:13:19 moe qmail: 985497199.790402 info msg 112050: bytes 291 from [EMAIL PROTECTED] qp 1021 uid 1008 Mar 24 23:13:19 moe qmail: 985497199.798631 starting delivery 29: msg 112050 to local [EMAIL PROTECTED] Mar 24 23:13:19 moe qmail: 985497199.799290 status: local 1/10 remote 0/20 Mar 24 23:13:19 moe qmail: 985497199.26 delivery 29: success: did_0+0+1/ Mar 24 23:13:19 moe qmail: 985497199.889097 status: local 0/10 remote 0/20 Mar 24 23:13:19 moe qmail: 985497199.889254 end msg 112050 Mar 24 23:14:16 moe qmail: 985497256.084798 new msg 112050 Mar 24 23:14:16 moe qmail: 985497256.085545 info msg 112050: bytes 293 from [EMAIL PROTECTED] qp 1041 uid 1008 Mar 24 23:14:16 moe qmail: 985497256.092490 starting delivery 30: msg 112050 to local [EMAIL PROTECTED] Mar 24 23:14:16 moe qmail: 985497256.092706 status: local 1/10 remote 0/20 Mar 24 23:14:16 moe qmail: 985497256.126467 delivery 30: success: did_0+0+0/ Mar 24 23:14:16 moe qmail: 985497256.126758 status: local 0/10 remote 0/20 Mar 24 23:14:16 moe qmail: 985497256.126914 end msg 112050
Re: No,there are 144000 mails in my queue!!!
JF, I just had to deal with the same problem. It was a dictionary spam is what somebody called it. On my server, they where in the remote outgoing queue, but I believe the fix is the same. Keep in mind, I had never worked with python, and the little script was a python script. Luckily, my server already had python installed. The non-existant documentation meant I had to trial and error this, but here is a summary of what I did. Go to this location, and get this script onto your server, I put mine in /var/qmail/bin. http://www.redwoodsoft.com/~dru/programs/mailRemove.py Make it executable. chmod +x mailRemove.py Create the directory filter under qmail/queue. Mine was like this mkdir /var/qmail/queue/filter Next run the script in a test-only mode. You can CTRL-C out of it. python mailRemove.py [search-string] Since all my spam flood was from [EMAIL PROTECTED] my command looked like this, python mailRemove.py registrar If this runs, then you can do this for real. It moves the spam into the filter directory. I halted both qmail-send and smtp before doing this. Like this. python mailRemove.py --real registrar I had 28000 spams, and it took about 5 hours to remove 18000 of these. This server was only a 486/100, 32meg ram. Hopefully it will be lots faster on a better machine. While I am here, I wish to thank Mark and Markus for your help yesterday regarding my problem. Sam - Original Message - From: "jf" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 15, 2000 9:09 AM Subject: No,there are 144000 mails in my queue!!! Most of them are the same. Pls tell me how to deal with it. I have put the mail from address to the badmailfrom,but it wouldn't stop. I hate Sparm === ΪÄã¶ø½¨£¬ÎªÄã¶øÉ裬ÈÃÄã´«µÝÕæÐÄÕæÒâ 163.netºØ¿¨Õ¾£¨http://ecard.163.net£© 163µç×ÓÓʾÖȫзîÏ×£¬¾«²ÊÎÞÏ޵ĵç×Ӻؿ¨Õ¾¡£ ===
Re: Secondary MX (Was: Mail flood in queue)
Thanks for the input. Here is how it turned out, and my summary of the situation. I own both servers, and have been trying to figure out the best implimentation of redundancy. By having the secondary server in place, the primary server was slowed down, but it never failed to accept or deliver mail the whole time. Granted, while the secondary was trying to feed into the primary, some new incoming was pushed off onto the secondary. I feel that this put very little legitimate mail at risk. Keep in mind, I did not know for sure that I could dump the spam, yet. I only knew that if I waited long enuf, it would eventually clear out. My mistake was that I had two virtual domains running on that secondary server throughout all of this. Lack of time(read as lazyness) is the only reason that I had never moved them off of this particular server. Incoming mail for these two domains was working fine, but outgoing mail was being held up in the queue. Lesson here is do not put primary functions on a secondary machine. It removes your ability to just turn it off while you think about the problem. I responded to 'jf' on his problem, and the fix I used is listed there. My feeling is that this old 486 I used as a secondary MX cost me almost nothing and saved my butt by giving some options I would not have had otherwise. It has been great when my dedicated line customers have had to be down for a bit, or their servers have gone down to be able to cache their mail, and tell them that as soon as their server is back up, that I can provide them all their 'lost' mail. Sam - Original Message - From: "Harald Hanche-Olsen" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 15, 2000 6:51 AM Subject: Secondary MX (Was: Mail flood in queue) + "Mark Delany" [EMAIL PROTECTED]: | My qmail server is the secondary MX for domain tri.net. | mx1.tri.net got flooded with about 28,000 invalid user emails, which | overflowed onto my qmail secondary server, mx2.tri.net. | | (As an aside. This re-raises the question of whether it is good | practise to be a secondary MX for another site. I generally think it's | a bad idea...) At least if you do, it's very helpful if the two sites have identical policies with regards to such things as relaying, checking envelope sender domains and the like. And it's a lot better if the primary MX does like qmail and accepts mail even for non-existing users, or else the secondary MX gets saddled with creating bounce messages on behalf of the other domain. And that is bad indeed. Been there, done that, got the T-shirt. - Harald
Mail flood in queue
Help, I've been mail flooded to invalid users. My apologies for the length of this, but I'm trying to be complete. The background is as follows. My qmail server is the secondary MX for domain tri.net. mx1.tri.net got flooded with about 28,000 invalid user emails, which overflowed onto my qmail secondary server, mx2.tri.net. As qmail.remote is sending them from mx2.tri.net to mx1.tri.net, one of two things is happening: 1. Fails because of unavailable socket on mx1.tri.net. 2. Log entry as follows- Dec 14 16:43:14 radius qmail: 976812194.440027 delivery 5510: failure: 205.153.244.6_does_not_like_recipient./Remote_host_said:_550_bail [EMAIL PROTECTED]..._User_unknown/Giving_up_on_205.153.244.6./ My qstat does not seem to be getting smaller. My qread looks as follows. clip 12 Dec 2000 21:58:59 GMT #53728 15374 remote [EMAIL PROTECTED] 12 Dec 2000 22:24:01 GMT #53751 15462 remote [EMAIL PROTECTED] 12 Dec 2000 12:53:05 GMT #53774 1146 [EMAIL PROTECTED] bouncing remote [EMAIL PROTECTED] remote [EMAIL PROTECTED] remote [EMAIL PROTECTED] remote [EMAIL PROTECTED] remote [EMAIL PROTECTED] remote [EMAIL PROTECTED] done remote [EMAIL PROTECTED] remote [EMAIL PROTECTED] done remote [EMAIL PROTECTED] done remote [EMAIL PROTECTED] done remote [EMAIL PROTECTED] done remote [EMAIL PROTECTED] done remote [EMAIL PROTECTED] 13 Dec 2000 00:18:33 GMT #54073 33878 [EMAIL PROTECTED] remote [EMAIL PROTECTED] clip My questions are as follows. Because of the 'giving_up' message, is it still retrying the same bad address again? Is there a 'filter' I can install to prevent qmail-remote from sending the emails from '[EMAIL PROTECTED]' on to mx1.tri.net? What does the 'done' mean on some of the messages in the qread dump? And will they clean out automagicly? Any help will be appreciated. Some 'good' email has been trapped in the queue, such as the last entry in the qread dump. But if I have to, I could completely dump the queue as a last resort. Thanks in advance. Sam
