queue is getting larger
Hi i've installed qmail on my SuSE 7.2 running nearly perfectly. Nearly because of one problem: My queue gets larger and larger, the problem is that qmail-send - qmail-remote waits really long (about 1 day in some cases) to start delivery for some messages. (Only some recipent mail servers). I really don't know on what qmail-remote fails (if i telnet to this mail servers on port 25 everthing works really fine). I need something that processes immediadtly all messages in the queue - else i will get realy big problems. QMail is running supervised and qmail-tcpok + svc -a qmail-send doesn't send all messages in the queue. Can anyone help ? (hope this message will be deliverd in the next few hours) Pichler Wolfgang Dialog Austria Software Telekommunikation Ges.m.b.H. Goethestrasse 93 A-4020 Linz Tel +43 (0) 70 662774 37 Fax +43 (0) 70 662774 22 Mailmailto:[EMAIL PROTECTED] Web www.dialog-gruppe.at +++
Re: queue is getting larger
Wolfgang Pichler [EMAIL PROTECTED] wrote: i've installed qmail on my SuSE 7.2 running nearly perfectly. Nearly because of one problem: My queue gets larger and larger, the problem is that qmail-send - qmail-remote waits really long (about 1 day in some cases) to start delivery for some messages. (Only some recipent mail servers). qmail is encountering delivery problems to those servers for some messages. This is normal; some of the bigger mail networks (Yahoo, Hotmail, etc) experience huge surges in demand that they aren't always prepared for, and smaller networks simply sometimes aren't available. I really don't know on what qmail-remote fails (if i telnet to this mail servers on port 25 everthing works really fine). It's not failing; it's simply unable to successfully deliver a message at this time. That delivery is deferred, and qmail will try again later. I need something that processes immediadtly all messages in the queue - else i will get realy big problems. QMail is running supervised and qmail-tcpok + svc -a qmail-send doesn't send all messages in the queue. qmail-tcpok + ALRM to qmail-send will make qmail immediately retry all messages in the queue -- however, this can't guarantee that those deliveries will succeed. If some are deferred, they will (again) be retried later. This is just the way the internet and SMTP work; you can't change it. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
queue help
Hi I have a problem my server has messages in queue: 21738 messages in queue but not yet preprocessed: 21738 the log file is all unable to open todo/(number)/(biger number) these files do not exist. I am runing on a dual 866 system with 1 gig of ram running va linux2.2.14-VA.2.1smp. There are no other logs that have been writen to about this I have also tried to force the queue to send by sending it the alarm sig. I am not shure what elses I can do. Paul Knapp -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS d- s+:++ a-- C+++$ L++$ P+$ E W+ N+ K? w M- PS+ PE Y+ R+ !tv b DI++ D++ e h+ m? UF++ --END GEEK CODE BLOCK--
Re: queue help
Thanks It looks like the queue was corupted I am waiting to see if the fix will fix it or not. Paul Knapp On Fri, Aug 10, 2001 at 09:01:54AM -0600, Charles Cazabon wrote: Paul Knapp [EMAIL PROTECTED] wrote: Hi I have a problem my server has messages in queue: 21738 messages in queue but not yet preprocessed: 21738 Sounds like either qmail-send can't make any sense of your queue, or isn't running at all. the log file is all unable to open todo/(number)/(biger number) these files do not exist. Your queue is corrupted; did you delete files from it by hand? You'll need to fix it. Stop qmail, then try either my queue-repair program (URL below in .sig), queue-fix (see qmail.org), or qmail-qsanity (see qmail.org; it currently will report problems, but leave you to fix them by hand). Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ --- -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS d- s+:++ a-- C+++$ L++$ P+$ E W+ N+ K? w M- PS+ PE Y+ R+ !tv b DI++ D++ e h+ m? UF++ --END GEEK CODE BLOCK--
Re: queue help
Paul Knapp [EMAIL PROTECTED] wrote: Hi I have a problem my server has messages in queue: 21738 messages in queue but not yet preprocessed: 21738 Sounds like either qmail-send can't make any sense of your queue, or isn't running at all. the log file is all unable to open todo/(number)/(biger number) these files do not exist. Your queue is corrupted; did you delete files from it by hand? You'll need to fix it. Stop qmail, then try either my queue-repair program (URL below in .sig), queue-fix (see qmail.org), or qmail-qsanity (see qmail.org; it currently will report problems, but leave you to fix them by hand). Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
How to flush the queue
Hi I am running qmail with the use of the supervise scripts and like to flush the queue immediately. First of all if reseted the Connection Timeout Table with qmail-tcpok, after that i've sended the ALARM SIGNAL (with svc -a qmail-send) to qmail-send. But it doesn't started to send all remote messages in the que. Why ? Pichler Wolfgang Dialog Austria Software Telekommunikation Ges.m.b.H. Goethestrasse 93 A-4020 Linz Tel +43 (0) 70 662774 37 Fax +43 (0) 70 662774 22 Mailmailto:[EMAIL PROTECTED] Web www.dialog-gruppe.at +++
Re: qmail-queue question
Edward McLain [EMAIL PROTECTED] wrote: [...] But I have messages that are getting stuck in the queue sometimes for more than 3 weeks. I have /var/qmail/control/queuelifetime set to 345600 (4 days). Anyone have any idea why this is happening? You broke something. You didn't restart qmail after changing queuelifetime, or you've got buggy patches applied, or you're incorrect about how long these messages have been in the queue, or something else -- stock qmail simply will not do this. Q. What do the logs say about the messages? A. @40003b71c07c05d4d9ec.s:@40003b71ba7b07110754 starting delivery 5: msg 112535 to remote emailTrimmed That is all I can find in the qmail-send logs about it Nope, there's lots more in your logs about that -- like the new msg line, and the delivery result line, and various other things. Either post all the relevant lines from your log, or put the whole log somewhere on the net for an interested party to look at, or hire a qmail consultant. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
RE: qmail-queue question
Edward, I've had problems with qmail-remote hanging - it had nothing to do with the queue lifetime, but with some code in qmail-remote failing, possibly due to an O/S bug. A fix which works for me is to enable socket keep-alives. This will kill the socket if it has died after about 2-3 hours. I've put a patch on the web at http://www.duff.org/qmail/ Richard -Original Message- From: Edward McLain [mailto:[EMAIL PROTECTED]] On a side note, is there any reason that qmail-remote should start up and then just sit there connected to a remote host for like 6 or 7 hours trying to send one email? I get this all the freaking time and I'm just wandering what exactly the freaking thing is doing? (although this problem only really seems to occur with mindspring.com, yet if I telnet to port 25 of mindsprings mail server and send the same message through telnet to the same user, from the same user as the one qmail's trying to send it works just fine and I don't get any errors or return codes.)
RE: qmail-queue question
OK... Let me explain this a little bit better and maybe clear some things up. 1. I've been using unix for about 8 years now and when someone says to restart a service or proggy after changing a config file, by god that service or proggy gets restarted, even if it takes a kill -9 or killall -9 to do it. 2. The only patch on this system is the qmailqueue-patch for the qmailscanner. 3. When the queue shows the message arriving on 30 Jul 2001 15:08:23 I tend to think that it actually arrive at 3:08 on Jul 30 of 2001, that is unless qmail is doing something funking with date and time stamps. ;) 4. I am a freaking consultant and I wouldn't bother this mailing list unless it was something worthwhile. But when all the instructions fail, and searching through code, and rewriting part of qmail-remote output actual logging, this is generally the place to turn to. 5. To get the logs I went to /var/log/qmail/send and did a grep on the message id number like so: grep 112535 * If you know something I don't know, then please tell me, but as far as I know, that scans all the files for that number and outputs the line, but then again, what do I know. 6. You really could try to be just a little bit less of an ass to everyone that may seem new and actually *TRY* to help them, that is what mailing list are for aren't they. Arrogance is nice and all, but what good does it do you an empty room when everyone has left you. Any real help on this issue would be appreciated from anyone. Later, Ed McLain -Original Message- From: Charles Cazabon [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 9:58 AM To: [EMAIL PROTECTED] Subject: Re: qmail-queue question Edward McLain [EMAIL PROTECTED] wrote: [...] But I have messages that are getting stuck in the queue sometimes for more than 3 weeks. I have /var/qmail/control/queuelifetime set to 345600 (4 days). Anyone have any idea why this is happening? You broke something. You didn't restart qmail after changing queuelifetime, or you've got buggy patches applied, or you're incorrect about how long these messages have been in the queue, or something else -- stock qmail simply will not do this. Q. What do the logs say about the messages? A. @40003b71c07c05d4d9ec.s:@40003b71ba7b07110754 starting delivery 5: msg 112535 to remote emailTrimmed That is all I can find in the qmail-send logs about it Nope, there's lots more in your logs about that -- like the new msg line, and the delivery result line, and various other things. Either post all the relevant lines from your log, or put the whole log somewhere on the net for an interested party to look at, or hire a qmail consultant. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Re: qmail-queue question
Edward McLain [EMAIL PROTECTED] wrote: OK... Let me explain this a little bit better and maybe clear some things up. Okay. 2. The only patch on this system is the qmailqueue-patch for the qmailscanner. This can cause qmail-queue to not be run, but not qmail-remote to crash. 5. To get the logs I went to /var/log/qmail/send and did a grep on the message id number like so: grep 112535 * If you know something I don't know, then please tell me, but as far as I know, that scans all the files for that number and outputs the line, but then again, what do I know. That doesn't give all the information about that message; in particular, delivery status lines don't contain the message number, only the delivery number, which you get from the starting delivery lines. 6. You really could try to be just a little bit less of an ass to everyone that may seem new and actually *TRY* to help them, What do you think I'm doing? You're wasting everyone's time by posting incomplete reports -- I'm trying to help you post better reports, so we can _help_ you. You want better service than that? Call Russ Nelson -- he'll come to your house and hold your hand, given sufficient incentive. For free, it doesn't get any better than this. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Re: deleting messages from the queue
eric [EMAIL PROTECTED] wrote: It's ridiculous because if qmail-[smtpd] could do the lookup and reject for invalid users, I would not have hardly any bounced messages. It's ridiculous because if pigs had wings, they could fly. Pigs don't have wings, and qmail-smtpd can't do the lookups. You either need to stop wishing your pig could fly or trade it for a bird. Yep. But getting them to change is gonna be darn near impossible. Do what I did: add them to badmailfrom. Again, getting them to change will be darn near impossible. But, the real point here is that I'm wondering if there is any way to change the default bounce message to something they will process. How would we know? Have you asked them what will work? Let me guess: they don't respond. ... PLUS, there is legitimate mail coming in from both of those servers for valid users. Doing it this way, I'd be blocking that as well. Set up a web page explaining that pm0.net is being blocked until they stop abusing your mail service. Send the prayer-chain granny the URL. -Dave
Re: qmail-queue question
3. When the queue shows the message arriving on 30 Jul 2001 15:08:23 I tend to think that it actually arrive at 3:08 on Jul 30 of 2001, that is unless qmail is doing something funking with date and time stamps. ;) But you didn't show the log entry that corresponds to this message. As a consultant with 8 years experience you have probably deduced that *all* messages inserted into the queue create a new msg log entry. Where is it? 5. To get the logs I went to /var/log/qmail/send and did a grep on the message id number like so: grep 112535 * If you know something I don't know, then please tell me, but as far as I How long does the system keep the logs for? Has it been rolled off by, eg, newsyslog? Any real help on this issue would be appreciated from anyone. We want all the log entries associated with the message. If your log system has rolled them off, then stop the log rolling so you can retain all the information. Then pick an example that shows us the full life-cycle of the message and how it exceeds queuelifetime after the last delivery attempt. It may simply be that the delivery program is not exiting. It's only at the point that qmail-send looks at queuelifetime. Regards.
Re: deleting messages from the queue
dave, all, It's ridiculous because if pigs had wings, they could fly. Pigs don't have wings, and qmail-smtpd can't do the lookups. You either need to stop wishing your pig could fly or trade it for a bird. this comment has the obviously unintended and unfortunate side-effect of implying that qmail is a pig and other, less-well-written, MTAs are more like birds. :-) that can't be what you intended. todd underwood vice president chief technology officer oso grande technologies, inc. [EMAIL PROTECTED]
RE: qmail-queue question
-Original Message- From: MarkD [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 12:23 PM To: [EMAIL PROTECTED] Subject: Re: qmail-queue question 3. When the queue shows the message arriving on 30 Jul 2001 15:08:23 I tend to think that it actually arrive at 3:08 on Jul 30 of 2001, that is unless qmail is doing something funking with date and time stamps. ;) But you didn't show the log entry that corresponds to this message. As a consultant with 8 years experience you have probably deduced that *all* messages inserted into the queue create a new msg log entry. Where is it? There was no new msg log entry. Best I can tell the logs only go back maybe 3 or 4 days and the messages originated 9 days ago.. Thus the problem. 5. To get the logs I went to /var/log/qmail/send and did a grep on the message id number like so: grep 112535 * If you know something I don't know, then please tell me, but as far as I How long does the system keep the logs for? Has it been rolled off by, eg, newsyslog? Any real help on this issue would be appreciated from anyone. We want all the log entries associated with the message. If your log system has rolled them off, then stop the log rolling so you can retain all the information. Then pick an example that shows us the full life-cycle of the message and how it exceeds queuelifetime after the last delivery attempt. It may simply be that the delivery program is not exiting. It's only at the point that qmail-send looks at queuelifetime. Regards. I took Richard's advice and added the socket keep-alive patch and that actually seems to have fixed the problem. The old messages seemed to have mysteriously disappeared after replacing the qmail-remote exec. Not to start anything else, but is there any better way to stop qmail when using tcp-daemonts than svc -d /service/qmail-send ? This doesn't seem to always work and I can't ever seem to get all the daemons to stop loading and running without editing /etc/inittab and commenting out the line that runs the svcscanboot and doing a kill -HUP 1. Then I have to do a kill or killall on all the qmail daemons to actually shut it down. Later, ed
Re: deleting messages from the queue
Todd Underwood [EMAIL PROTECTED] wrote: dave, all, It's ridiculous because if pigs had wings, they could fly. Pigs don't have wings, and qmail-smtpd can't do the lookups. You either need to stop wishing your pig could fly or trade it for a bird. this comment has the obviously unintended and unfortunate side-effect of implying that qmail is a pig and other, less-well-written, MTAs are more like birds. :-) that can't be what you intended. Pigs are fairly intelligent[1], as anyone who knows farm animals will tell you. Birds, on the other hand, are notoriously dim (bird brain, for example). -Dave [1] They're also clean, contrary to popular impression. They do like to wallow in mud, but that's for comfort and protection from the Sun.
Re: qmail-queue question
On Thu, Aug 09, 2001 at 12:39:28PM -0500, Edward McLain allegedly wrote: -Original Message- From: MarkD [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 12:23 PM To: [EMAIL PROTECTED] Subject: Re: qmail-queue question 3. When the queue shows the message arriving on 30 Jul 2001 15:08:23 I tend to think that it actually arrive at 3:08 on Jul 30 of 2001, that is unless qmail is doing something funking with date and time stamps. ;) But you didn't show the log entry that corresponds to this message. As a consultant with 8 years experience you have probably deduced that *all* messages inserted into the queue create a new msg log entry. Where is it? There was no new msg log entry. Best I can tell the logs only go back maybe 3 or 4 days and the messages originated 9 days ago.. Thus the problem. It probably would have been helpful if you'd told us about this at the start. It seemed like you were trying to suggest that the log entry never existed. I guess that's a lesson for next time. I took Richard's advice and added the socket keep-alive patch and that actually seems to have fixed the problem. The old messages seemed to have mysteriously disappeared after replacing the qmail-remote exec. Mysteriously? Since we've stressed the importance of looking at logs for answers, I'm sure you've checked the logs to solve the mystery. What did they say? I'm sure if you bother, you'll see that it's not a mystery at all. Unless of course you kill -9 qmail-send, but no one or no docs have ever told you to do this, right? In any event, as I said in the the last post; queuelifetime applies *after* the last delivery attempt has exited. It's almost certainly the case that you killed qmail-remote (or it exited of its own accord) at which point qmail-send would notice that queuelifetime is exceeded and bounce the mail. The logs show this stuff by the way. Not to start anything else, but is there any better way to stop qmail when using tcp-daemonts than svc -d /service/qmail-send ? This doesn't seem to always work and I can't ever seem to get all the It always works. But qmail-send won't exit until all current deliveries have exited - in fact it logs an entry each time an outstanding delivery completes. Did you see different when you checked the logs? If so, show us. Edward, for someone with 8 years experience, you should rejoice that so many of your mysteries and misunderstandings can be solved by examining and understanding the logs. If the log messages are a mystery to you, there are plenty of archived posts explaining the messages. Regards.
Re: qmail-queue question
Edward McLain [EMAIL PROTECTED] wrote: Not to start anything else, but is there any better way to stop qmail when using tcp-daemonts than svc -d /service/qmail-send ? No -- that is the proper way to stop qmail with daemontools. This doesn't seem to always work [...] Nope -- it always works. If not, you didn't install daemontools and your /service directories properly. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
[OT] Re: deleting messages from the queue
On Thu, Aug 09, 2001 at 02:33:45PM -0400, Dave Sill wrote: Pigs are fairly intelligent[1], as anyone who knows farm animals will tell you. Birds, on the other hand, are notoriously dim (bird brain, for example). That's not very accurate. I keep birds (specifically, parrots) as pets, and I find that they are extremely intelligent. --Adam -- Adam McKenna [EMAIL PROTECTED] | Help stop animal abuse at Petco! http://flounder.net/publickey.html | http://www.mickaboofriends.org GPG: 17A4 11F7 5E7E C2E7 08AA | 38B0 05D0 8BF7 2C6D 110A |
RE: qmail-queue question
Ok.. after searching through the logs for a bit, I have discovered the following about some of the messages getting stuck in the queue.. This is the method I used to do this test, if it's wrong tell me, but this is what I did. First off I ran: [root@mail qmail]# ps ax | grep qmail-remote | wc -l 35 Not a problem. So now I run: [root@mail qmail]# ps ax | grep qmail-remote 1822 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1826 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1827 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1833 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1834 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1836 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1838 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1839 ?S 0:00 qmail-remote msn.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1841 ?S 0:00 qmail-remote msn.com [EMAIL PROTECTED] 1842 ?S 0:00 qmail-remote mindspring.com mcculley@in- prepaid.com [EMAIL PROTECTED] 1843 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1844 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1846 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1847 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1848 ?S 0:00 qmail-remote microsoft.com [EMAIL PROTECTED] 1850 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1851 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] 1852 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1854 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1855 ?S 0:00 qmail-remote msn.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1856 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1858 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1859 ?S 0:00 qmail-remote mindspring.com mcculley@in- prepaid.com [EMAIL PROTECTED] 1860 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1861 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1862 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1863 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1864 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1865 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] 1866 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1868 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1869 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED][EMAIL PROTECTED] 1870 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1871 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] 1872 ?S 0:00 qmail-remote mindspring.com [EMAIL PROTECTED] [EMAIL PROTECTED] [root@mail qmail]# Nothing to weird here except all of the connections to mindspring.com. So I go and do a mailq and look up the message id numbers. Then I go do: [root@mail send]# grep 112603 * | /usr/local/bin/tai64nlocal 2001-08-08 17:42:58.097835500.s:@40003b71ba7b2578952c starting delivery38: msg 112603 to remote [EMAIL PROTECTED] 2001-08-08 20:42:43.879282500.s:@40003b71d96719f67df4 starting delivery44: msg 112603 to remote [EMAIL PROTECTED] 2001-08-08 20:42:43.879282500.s:@40003b71dec231dccf04 starting delivery129: msg 112603 to remote [EMAIL PROTECTED] 2001-08-09 10:17:31.319774500.s:@40003b72a32e0b08b30c starting delivery26: msg 112603 to remote [EMAIL PROTECTED] 2001-08-09 13:41:28.533103500.s:@40003b72c36a2839ff1c starting delivery366: msg 112603 to remote [EMAIL PROTECTED] [root@mail send]# Ok.. so as someone pointed out I have to now search by the deliver number.. So I ran: [root@mail send]# grep delivery 366 * | /usr/local/bin/tai64nlocal 2001-08-09 13:41:28.533103500.s:@40003b72c36a2839ff1c starting delivery366: msg 112603 to remote [EMAIL PROTECTED] [root@mail send]# Ok.. so the last attempt started at 1:41PM.. So what happened to the one before it? [root@mail send]# grep delivery 26: * | /usr/local/bin/tai64nlocal 2001-08-09 10:17:31.319774500.s:@40003b72a32e0b08b30c starting delivery26: msg 112603 to remote [EMAIL PROTECTED] 2001-08-09 13:41:28.533103500
Re: qmail-queue question
Ok.. so as someone pointed out I have to now search by the deliver number.. So I ran: [root@mail send]# grep delivery 366 * | /usr/local/bin/tai64nlocal 2001-08-09 13:41:28.533103500.s:@40003b72c36a2839ff1c starting delivery 366: msg 112603 to remote [EMAIL PROTECTED] [root@mail send]# Ok.. so the last attempt started at 1:41PM.. So what happened to the one before it? [root@mail send]# grep delivery 26: * | /usr/local/bin/tai64nlocal 2001-08-09 10:17:31.319774500.s:@40003b72a32e0b08b30c starting delivery 26: msg 112603 to remote [EMAIL PROTECTED] 2001-08-09 13:41:28.533103500.s:@40003b72c33a3620be2c delivery 26: deferral: qmail-remote_crashed./ [root@mail send]# Ok.. so qmail-remote crashed.. but why? Unless something very unusual is happening to your system, I'd say that someone or something killed it. An unpatched qmail-remote has no record of crashing in the last, oh, 3 years of people using it. It had also been running for over 3 hours? That's not necessarily a problem. Mail is allowed to get stuck. Is any mail getting thru to these sites or are they all failing? Well to test it out I did the following: [root@mail qmail]# telnet mx09.mindspring.com 25 Trying 207.69.200.36... Connected to mx09.mindspring.com. Escape character is '^]'. 220 pickering.mail.mindspring.net EL_3_4_0 /EL_3_4_0 ESMTP Earthlink Mail Service Thu, 9 Aug 2001 16:20:40 -0400 (EDT) helo mail.highspd.net 250 pickering.mail.mindspring.net Hello mail.highspd.net [208.62.90.230], please to meet you mail from: [EMAIL PROTECTED] 250 [EMAIL PROTECTED] Sender ok rcpt to: [EMAIL PROTECTED] 250 [EMAIL PROTECTED]... Recipient ok data 354 Enter mail, end with . on a line by itself this is a test. please disregard . 250 tn5s62.1dc.37kbi14 Message accepted for delivery quit 221 pickering.mail.mindspring.net closing connection Connection closed by foreign host. Ok.. so I can send mail directly just fine.. So what in the heck is going on here? This is what is puzzling me the most..? Hard to say. It could be that the contents of the mail are a problem for mindspring, are they large? Do they have binary data? It could be that qmail-remote is connecting to an MX that's particularly slow or dead. It could be that you have an smtproutes entry for that domain that points incorrectly. BTW.. this was happening with stock qmail also before I patched it with the qmail-queue patch for qmailscanner. If you are saying you are sure that qmail-remote was crashing with a stock qmail install, then I'd be highly suspicious of a library/compiler/OS problem. I know that might sound like a cop-out, but a crashing qmail-remote is virtually unheard of. It's also possible that there is some sort of system resource that is becoming unavailable causing the kernel to kill the qmail-remote. Does this happen to all qmail-remotes or only those sending to mindspring? Does it happen to all qmail-remotes or only those that run for a long time? If you can reliably determine which ones are going to crash in advance of them crashing, then do a system call trace on one of them to see why it's dying. Show us the trace. Regards.
Re: qmail-queue question
Edward McLain [EMAIL PROTECTED] wrote: Ok.. so qmail-remote crashed.. but why? Who knows? Did you kill it? It had also been running for over 3 hours? So? Long messages to a slow host can do this. Well to test it out I did the following: [...] You didn't use proper SMTP syntax, which qmail-remote would have. Who says you connected to the same machine as qmail-remote did? mx09.mindspring.com could be a cluster of machines sitting behind a load balancer. mail from: [EMAIL PROTECTED] rcpt to: [EMAIL PROTECTED] This isn't proper SMTP. Any ideas? Just one: stop worrying until you have evidence of an actual problem. Everything you've described so far can be completely normal behaviour. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
deleting messages from the queue
How to delete a mail from the the queue? ( this messages appear in qmail-qread, qmail-qstat ). Thanks Attila -- - - Mail: [EMAIL PROTECTED]; Debian 2.2 Linux / 2.2.13 / qmail - - PGP key: gpg --keyserver keys.pgp.com --recv-key 0x2cc33acb -
Re: deleting messages from the queue
Attila Csosz [EMAIL PROTECTED] wrote: How to delete a mail from the the queue? ( this messages appear in qmail-qread, qmail-qstat ). What problem are you trying to solve? Having a few messages show up in the qmail-qstat output for a few days is perfectly normal. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Where to store extended envelope info in /var/qmail/queue ?
Vanilla qmail 1.03 stores the envelope sender address (preceded by an F and followed by a NUL) in a file in the directory /var/qmail/info/. RFC 1869 (SMTP Service Extensions) allows one to pass additional information on the MAIL command line after the FROM:address . Some of this information should in principle be passed on to qmail-local and/or qmail-remote for correct processing. (One example is BODY=8BITMIME. Regardless of how one thinks qmail-remote should behave when relaying to a server that doesn't advertise 8BITMIME --- I don't wish to revive *that* discussion --- it may be nice to pass on the 8BITMIME flag to those servers that do claim to support it --- but only if it was set on the inbound message; qmail-remote shouldn't try to compute it from the message content.) In the INTERNALS file, DJB wrote inter alia: Currently info/457 serves two purposes: first, it records the envelope sender; second, its modification time is used to decide when a message has been in the queue too long. In the future info/457 may store more information. Any non-backwards-compatible changes will be identified by version numbers. I think I may have a need to store more information. I would like to do so in a manner that won't clash with future official qmail releases. Would it be OK to store the information after the F...\0 envelope sender, as a (possibly empty) list of P...\0 parameters? Or am I better off creating a separate file xinfo/457 ? Sergio Gelato
Re: deleting messages from the queue
Will someone PLEASE define few. I've got over 400 BOUNCE messages alone in my queue. Some of them for almost a week (I know they'll timeout after a week (and that the timeout is configurable), but this is ridiculous. I have tons of mail in the queue going to pm0.net (see www.postmastergeneral.com). Almost all of it is bounce messages. Almost all of it from where someone who owns a mailing list on postmastergeneral.com is STILL sending email to now-defunct email addresses (email accounts that were cancelled). I have looked at the problem long and hard and have yet to come up with a workable solution. I use qmail-1.03 and vpopmail-3.4.11. It seems that when using virtual doamins, qmail-smtp will NEVER reject a recipient - even if that user does not exist. Instead, it relies on the qmail-local (or in my case, vdelivermail since I'm using vpopmail) to send a bounce. However, it looks like postmastergeneral.com (and others) is not removing addresses from lists based on the bounce messages that I'm sending. I know I can change the default text of the bounce message using the .no-user.msg file, but a) I'm not sure where this file should be (is it global or per virtual domain), and b) I don't know what to put in it so that listservers will properly handle the bounces. One more caveat about my setup. I am using vpopmail with mysql support and all the user/domain information is kept in mysql tables. Anybody got any ideas on how to solve this? Eric - Original Message - From: Charles Cazabon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 09:13 Subject: Re: deleting messages from the queue Attila Csosz [EMAIL PROTECTED] wrote: How to delete a mail from the the queue? ( this messages appear in qmail-qread, qmail-qstat ). What problem are you trying to solve? Having a few messages show up in the qmail-qstat output for a few days is perfectly normal. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Re: deleting messages from the queue
On 08 Aug 2001 14:09:18 +, eric wrote: Will someone PLEASE define few. I've got over 400 BOUNCE messages alone in my queue. Some of them for almost a week (I know they'll timeout after a week (and that the timeout is configurable), but this is ridiculous. I have tons of mail in the queue going to pm0.net (see www.postmastergeneral.com). Almost all of it is bounce messages. Almost all of it from where someone who owns a mailing list on postmastergeneral.com is STILL sending email to now-defunct email addresses (email accounts that were cancelled). I have looked at the problem long and hard and have yet to come up with a workable solution. I use qmail-1.03 and vpopmail-3.4.11. It seems that when using virtual doamins, qmail-smtp will NEVER reject a recipient - even if that user does not exist. Instead, it relies on the qmail-local (or in my case, vdelivermail since I'm using vpopmail) to send a bounce. However, it looks like postmastergeneral.com (and others) is not removing addresses from lists based on the bounce messages that I'm sending. I know I can change the default text of the bounce message using the .no-user.msg file, but a) I'm not sure where this file should be (is it global or per virtual domain), and b) I don't know what to put in it so that listservers will properly handle the bounces. One more caveat about my setup. I am using vpopmail with mysql support and all the user/domain information is kept in mysql tables. Anybody got any ideas on how to solve this? Eric - Original Message - From: Charles Cazabon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 09:13 Subject: Re: deleting messages from the queue Attila Csosz [EMAIL PROTECTED] wrote: How to delete a mail from the the queue? ( this messages appear in qmail-qread, qmail-qstat ). What problem are you trying to solve? Having a few messages show up in the qmail-qstat output for a few days is perfectly normal. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ --- remove /var/qmail/queue and go to qmail source and make setup check again... -- Jake Roersma Network Engineer Triton Technologies Inc. (800)-837-4253/364-8761
Re: deleting messages from the queue
eric [EMAIL PROTECTED] wrote: Charles Cazabon [EMAIL PROTECTED] wrote: Why is it ridiculous? Mail sometimes can't be delivered; hosts are down, networks are down, services are down or busy, users make typos. A few depends on a lot of things; if your server handles a hundred messages a day, maybe a few == 5 or 10. If your server handles millions of messages a day, a few might be in the tens of thousands. It's ridiculous because if qmail-send could do the lookup and reject for invalid users, I would not have hardly any bounced messages. qmail-send doesn't have anything to do with accepting mail over the network; it doesn't care. qmail-smtpd has that job, assisted by tcpserver. qmail-smtpd doesn't know anything about local users or virtual domains or anything; it's part of the security design of qmail to segment/separate the tasks involved. Giving qmail-smtpd knowledge of users, domains, etc violates that separation. Okay, so whoever runs postmastergeneral.com needs to be educated about running mailing lists. No surprise there. Yep. But getting them to change is gonna be darn near impossible. If you (and others) start refusing to accept mail from them (my last suggestion), they may start to care very quickly. I would guess their business depends on it (I know nothing about them). Someone, somewhere must have come up with a workaround/patch for this. Yes; someone did post a patch to the qmail list which basically copied all of qmail-send's checks into qmail-smtpd. I don't think it's commonly used, as I haven't seen it mentioned since. You should be able to find it in the list archives. Instead, it relies on the qmail-local (or in my case, vdelivermail since I'm using vpopmail) to send a bounce. However, it looks like postmastergeneral.com (and others) is not removing addresses from lists based on the bounce messages that I'm sending. So the problem is with them, not qmail. Again, getting them to change will be darn near impossible. But, the real point here is that I'm wondering if there is any way to change the default bounce message to something they will process. It's easy to change the format of the bounce messages, but why do it? qmail's bounces messages are _easier_ to parse than most other MTAs. See http://cr.yp.to/proto/qsbmf.txt for a description of the format. If you do want to change the bounce messages, please adhere to QSBMF. Anybody got any ideas on how to solve this? Use tcpserver to refuse all connections from pm0.net. Voila, no more problem. tcpserver (unless patched) requires IP ADDRESSES. No longer true. tcpserver accepts hostnames just fine, with appropriate syntax. See the documentation for tcpserver for details. And, pm0.net is not the only one I'm having problems with - edirectnetwork.net is another. And I'm sure there are others, but these two are by far the biggest problems. So refuse mail from them as well. There's no law that says you have to accept SMTP connections from everyone on the planet. Perhaps they'll clean up their act if they can't reach half their list members. PLUS, there is legitimate mail coming in from both of those servers for valid users. Doing it this way, I'd be blocking that as well. Yes -- that's the whole idea. Those legitimate users then start complaining to their provider, who probably cares more about the people who send them money each month. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Re: deleting messages from the queue
to explain to an 80 year old woman why she's no longer getting the prayer-chain emails that she lives and dies for... It's not the best long term solution, but if I could get it working, I'd take it for now. vdelivermail currently has two possible options for dealing with no mailbox situations. 1) deliver a copy of the undeliverable message to an actual Mailbox (default to postmaster) or send a bounce message. Looks like I might end up hacking on vdelivermail until it yields a third option... sending undeliverable messages to /dev/null. That still doesn't inform the broken list managers of their problem, but at least it will unclog my outbound queue of wasted bounces. Eric Calvert
Re: deleting messages from the queue
eric [EMAIL PROTECTED] wrote: Use tcpserver to refuse all connections from pm0.net. Voila, no more problem. tcpserver (unless patched) requires IP ADDRESSES. No longer true. tcpserver accepts hostnames just fine, with appropriate syntax. See the documentation for tcpserver for details. [...] Thinking this might be what I was looking for, I tried putting both =.pm0.net:deny and =pm0.net:deny successively into a test.cdb and then ran the following (with results shown (the results were the same in both cases)): $ tcprulescheck test.cdb ofr.pm0.net default: allow connection The tcprules syntax above is the correct one; the problem here is you're not invoking tcprulescheck properly. It takes the remote host information in an environment variable, not as an argument. And, pm0.net is not the only one I'm having problems with - edirectnetwork.net is another. And I'm sure there are others, but these two are by far the biggest problems. So refuse mail from them as well. There's no law that says you have to accept SMTP connections from everyone on the planet. Perhaps they'll clean up their act if they can't reach half their list members. OK, so now the burden is back on me to keep up with who I need to block and who I don't. I'd rather have the software do it automatically if possible, and the easiest way to that would be checking for valid users. Life as a mailserver administrator isn't easy :). vdelivermail currently has two possible options for dealing with no mailbox situations. 1) deliver a copy of the undeliverable message to an actual Mailbox (default to postmaster) or send a bounce message. Looks like I might end up hacking on vdelivermail until it yields a third option... sending undeliverable messages to /dev/null. Perhaps it already works if you specify the default mbox you want it to deliver to is /dev/null? That still doesn't inform the broken list managers of their problem, but at least it will unclog my outbound queue of wasted bounces. The other way to handle this would be to throw away _outgoing_ mail destined to that host (i.e. the bounces you're generating) before they go over the wire. You can do this with virtualdomains and an appropriate dot-qmail file containing only a comment. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
qmail-queue question
Ive got a slight problem here and hoping that someone can help solve this. Due to a high volume of stupid users and mailing list addicts on our network (a small isp) we tend to get a lot of bounced messages, or messages to address that dont exist or what have you. The problem here is that they start to fill the queue up pretty fast. Now this isnt that big of a problem anymore since I raised our connection limit way the hell up there. But I have messages that are getting stuck in the queue sometimes for more than 3 weeks. I have /var/qmail/control/queuelifetime set to 345600 (4 days). Anyone have any idea why this is happening? Just to answer all the simple questions: Q. Is the file readable by qmail? A. -rw-r--r-- 1 root qmail 7 Jul 20 18:06 queuelifetime Q. What do the logs say about the messages? A. @40003b71c07c05d4d9ec.s:@40003b71ba7b07110754 starting delivery 5: msg 112535 to remote emailTrimmed That is all I can find in the qmail-send logs about it Q. Is it bouncing? A. Output from mailq | grep 112535 : 31 Jul 2001 01:01:12 GMT #112535 15511 emailAddressTrimmed On a side note, is there any reason that qmail-remote should start up and then just sit there connected to a remote host for like 6 or 7 hours trying to send one email? I get this all the freaking time and Im just wandering what exactly the freaking thing is doing? (although this problem only really seems to occur with mindspring.com, yet if I telnet to port 25 of mindsprings mail server and send the same message through telnet to the same user, from the same user as the one qmails trying to send it works just fine and I dont get any errors or return codes.) Any thoughts would be appreciated. Later, Ed McLain High Speed Solutions
Re: new message in queue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrique, Try this: http://www.inter7.com/qmailmrtg7 No more - --- Generated by fortune* Aluno de Informática não cola, faz transferência de dados. UIN: 14414330 - http://www.dicaslinux.com.br 9:00am up 1 day 3:29 0 users On Mon, 6 Aug 2001, Henrique Pantarotto wrote: RPT Hello friends, RPT RPT I need to monitor (with MRTG) how many messages successfully delivered RPT per minute and how many new messages goes to queue per minute. RPT RPT To create a graph for messages successfully delivered we count the RPT mailog for the string success: (or accepted_message). RPT RPT But we're having trouble for the new messages going to queue graph. I RPT don't know what string I need to look for. I tried couting for the RPT string new msg or from but they (also?) appear when Qmail is RPT simpling trying to deliver that message, and that's not good for me. RPT RPT Does anybody here know any string that indicates a real new message RPT going to queue? RPT RPT RPT Thanks, Henrique. RPT -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjtv4DMACgkQzW1cKu9OlHcnBACcCu4nmgJ7DgTb/4e/QdIyVh06 H84AoJnfdZKPYjF/hUuX/DljJvjIgldK =sIb0 -END PGP SIGNATURE-
Sporadic preprocessed queue backlog
Hello, I've got a (hopefully) simple to fix problem on my hands. I have a vanilla qmail-1.03 LWQ installation on dual 1Ghz, 1G ram, raid5 RedHat 7.0 server with a 10Mbis Internet connection. It is a dedicated mail server, and is currently under no load that could suggest my problems are related to lack of cpu/memory/hard drive resources. Aside from the sporadic probelm described below, when things are running fine, all deliveries are made once they get past the preprocessed queue. Fairly frequently throughout an average day, my preprocessed queue will begin to grow steadily and not get processed. In most cases, if this is ignored, it resumes processing eventually. Sometimes after 15 or so minutes, sometimes after a couple of hours, but at bad times, it can fail to clear out the preprocessed queue for days. I've checked the logs, and in no case is the concurrency peaked during this problem(in fact, local is usually low at 1/120 and remote usually at about 20 to 40/120), though I'm not sure if that would be related, anyway. The first thing I checked, of course, is the /var/qmail/queue/lock/trigger file, as noted in the archives. As far as I can tell, it looks correct. Here is an example of my problem at 11:14am: qmail-qstat output: messages in queue: 228 messages in queue but not yet preprocessed: 63 trigger file at the time: prw--w--w-1 qmails qmail 63 Aug 6 11:14 trigger Then, I stop and restart qmail at 11:18, after 4 minutes of the queue not handling any preprocessing, and the preprocessed queue is promptly cleared, as follows: messages in queue: 159 messages in queue but not yet preprocessed: 0 prw--w--w-1 qmails qmail 0 Aug 6 11:18 trigger From there, The only piece I note is that trigger has a file size of 63 before and 0 afterwards. Is it normal for this pipe to increase/decrease in size, or is that normal behaviour for a pipe? Also, I've noted that when everything is running smoothly, the date/time on the trigger stays up-to-the-minute, but when I have problems, not only does the size of trigger increase, but the timestamp on trigger does not update. If I'm not on the right track here, what are the other pieces I should be checking here, and what types of scenarios, other than a misconfigured trigger pipe, can cause a preprocessing backlog? Of course, I should not be resorting to stopping and restarting qmail just to get it to process the queue. There must be some small detail I've missed. I've checked the archives, and the only thing I can find that relates to the preprocessing not being done is to check the trigger, but other than confirming that it is a pipe and such, I did not see anything else to try. Thanks in advance for any pointers, Matt Hubbard
Re: Sporadic preprocessed queue backlog
Matt Hubbard [EMAIL PROTECTED] wrote: Fairly frequently throughout an average day, my preprocessed queue will begin to grow steadily and not get processed. In most cases, if this is ignored, it resumes processing eventually. Sometimes after 15 or so minutes, sometimes after a couple of hours, but at bad times, it can fail to clear out the preprocessed queue for days. I've checked the logs, and in no case is the concurrency peaked during this problem(in fact, local is usually low at 1/120 and remote usually at about 20 to 40/120), though I'm not sure if that would be related, anyway. Strange. The first thing I checked, of course, is the /var/qmail/queue/lock/trigger file, as noted in the archives. As far as I can tell, it looks correct. That would ahve been my first suggestion. Here is an example of my problem at 11:14am: qmail-qstat output: messages in queue: 228 messages in queue but not yet preprocessed: 63 trigger file at the time: prw--w--w-1 qmails qmail 63 Aug 6 11:14 trigger Notice 63 unpreprocessed messages and 63 bytes in trigger? Not a coinicidence. qmail-send isn't reading trigger. Is qmail-send still running? If so, strace it. What's it doing? The only piece I note is that trigger has a file size of 63 before and 0 afterwards. Is it normal for this pipe to increase/decrease in size, or is that normal behaviour for a pipe? That's normal pipe behaviour, but it's not normal for qmail-send to not read bytes soon after they're written. -Dave
FW: Sporadic preprocessed queue backlog
Hello again,
Notice 63 unpreprocessed messages and 63 bytes in trigger? Not a
coinicidence. qmail-send isn't reading trigger. Is qmail-send still
running? If so, strace it. What's it doing?
Here are the results of my strace. Let me preempt this with a strong
apology: Aside from cutting it short fro brevity's sake, I have munged the
specific domain data. I _know_ this is bad juju, and could not agree with
everyone more that real data should be used, but my employer has expressly
forbidden me from displaying it. And hopefully, it isn't relevant in
tackling this particular problem(if I ever have a mystery on my personal
servers, you'd better believe I'll give you every detail, including my dog's
name ;-) But, I digress; the strace:
[root@mail2 bin]# /usr/bin/strace /var/qmail/bin/qmail-send
execve(/var/qmail/bin/qmail-send, [/var/qmail/bin/qmail-send], [/* 23
vars */]) = 0
_sysctl({{CTL_KERN, KERN_OSRELEASE}, 2, 2.2.16-22smp, 12, NULL, 0}) = 0
brk(0) = 0x8056288
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, 0xb35c) = -1 ENOSYS (Function not
implemented)
fstat(3, {st_mode=S_IFREG|0644, st_size=13562, ...}) = 0
old_mmap(NULL, 13562, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=4776568, ...}) = 0
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\274..., 4096)
= 4096
old_mmap(NULL, 1196776, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001c000
mprotect(0x40137000, 37608, PROT_NONE) = 0
old_mmap(0x40137000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x11a000) = 0x40137000
old_mmap(0x4013d000, 13032, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4013d000
close(3)= 0
munmap(0x40018000, 13562) = 0
getpid()= 8198
chdir(/var/qmail) = 0
open(control/me, O_RDONLY|O_NONBLOCK) = 3
read(3, mail2.mycompanydomain.com\n, 64) = 18 #Here is a line I
changed#
close(3)= 0
open(control/queuelifetime, O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file
or directory)
open(control/concurrencylocal, O_RDONLY|O_NONBLOCK) = 3
read(3, 120\n, 64)= 4
close(3)= 0
open(control/concurrencyremote, O_RDONLY|O_NONBLOCK) = 3
read(3, 120\n, 64)= 4
close(3)= 0
open(control/envnoathost, O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file
or directory)
open(control/bouncefrom, O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or
directory)
open(control/bouncehost, O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or
directory)
open(control/doublebouncehost, O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such
file or directory)
open(control/doublebounceto, O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such
file or directory)
open(control/locals, O_RDONLY|O_NONBLOCK) = 3
read(3, localhost\nmail2.mycompanydomain.com\n, 64) = 28 #Here is a
line I changed#
read(3, , 64) = 0
close(3)= 0
open(control/percenthack, O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file
or directory)
open(control/virtualdomains, O_RDONLY|O_NONBLOCK) = 3
[...]
followed by approx 1200 lines, similar to the ones in this excerpt(domain
names changed):
[...]
read(3, fobwear-net\nkrut.com:krut-co..., 64) = 64
read(3, practicalvision.com:practical..., 64) = 64
brk(0x806b000) = 0x806b000
[...]
and finally ending with:
[...]
read(3, , 64) = 0
close(3)= 0
chdir(queue) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x8048b8c, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGALRM, {0x8048b9c, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGHUP, {0x8048bac, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, NULL, 8) = 0
umask(077) = 022
open(lock/sendmutex, O_WRONLY|O_NONBLOCK) = 3
flock(3, LOCK_EX|LOCK_NB) = -1 EAGAIN (Resource temporarily
unavailable)
write(0, alert: cannot start: qmail-send ..., 51alert: cannot start:
qmail-send is already running
) = 51
_exit(111) = ?
First off, I note the (Resource temporarily unavailable) just after
lock/sendmutex, so here's an ls -l of my /var/qmail/queue/lock directory in
case I've missed some other permission type issue:
-rw---1 qmails qmail 0 Jul 28 01:47 sendmutex
-rw-r--r--1 qmailr qmail1024 Aug 6 13:39 tcpto
prw--w--w-1 qmails qmail 0 Aug 6 13
new message in queue
Hello friends, I need to monitor (with MRTG) how many messages successfully delivered per minute and how many new messages goes to queue per minute. To create a graph for messages successfully delivered we count the mailog for the string success: (or accepted_message). But we're having trouble for the new messages going to queue graph. I don't know what string I need to look for. I tried couting for the string new msg or from but they (also?) appear when Qmail is simpling trying to deliver that message, and that's not good for me. Does anybody here know any string that indicates a real new message going to queue? Thanks, Henrique.
Re: new message in queue
On Mon, Aug 06, 2001 at 06:39:58PM -0300, Henrique Pantarotto wrote: [snip] But we're having trouble for the new messages going to queue graph. I don't know what string I need to look for. I tried couting for the string new msg or from but they (also?) appear when Qmail is simpling trying to deliver that message, and that's not good for me. Does anybody here know any string that indicates a real new message going to queue? 'new msg' only appears *once* for each message, the moment qmail-send accepts it into the local/remote queue. It is a reliable indicator. 'end msg' is similar, and also appears only *once*, when the message is removed from the queue. Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html
Re: new message in queue
Peter, you're right. The log confused me for a minute, but you've saved me. new msg is really cool and will do it for me. ;-) Thanks, Henrique. -Original Message- From: Peter van Dijk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Mon, 6 Aug 2001 23:43:43 +0200 Subject: Re: new message in queue On Mon, Aug 06, 2001 at 06:39:58PM -0300, Henrique Pantarotto wrote: [snip] But we're having trouble for the new messages going to queue graph. I don't know what string I need to look for. I tried couting for the string new msg or from but they (also?) appear when Qmail is simpling trying to deliver that message, and that's not good for me. Does anybody here know any string that indicates a real new message going to queue? 'new msg' only appears *once* for each message, the moment qmail-send accepts it into the local/remote queue. It is a reliable indicator. 'end msg' is similar, and also appears only *once*, when the message is removed from the queue. Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html
Re: How-best-to: Secondary Queue for Mailing List
On Fri, Aug 03, 2001 at 11:45:00AM -0400, Jeff Hill wrote: When we e-mail a newsletter to our user list (10,000+ e-mail, twice a month), it holds up any other e-mail going into the send queue. What's the best way to avoid this? This question has been asked and answered less than a week ago. (I won't answer it now since Charles already did. This is just a hint: lurk for a while before your first post, and check the archives. Really, it's in there. At least 50 times.) Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html
Re: How-best-to: Secondary Queue for Mailing List
On Sat, Aug 04, 2001 at 05:56:46PM +0200, Peter van Dijk wrote: On Fri, Aug 03, 2001 at 11:45:00AM -0400, Jeff Hill wrote: When we e-mail a newsletter to our user list (10,000+ e-mail, twice a month), it holds up any other e-mail going into the send queue. What's the best way to avoid this? This question has been asked and answered less than a week ago. In fact, less than 30 hours before you posted your question, the previous asker followed-up with 'yes this works' and even explained how he did it. I will stop complaining now. Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html
How-best-to: Secondary Queue for Mailing List
When we e-mail a newsletter to our user list (10,000+ e-mail, twice a month), it holds up any other e-mail going into the send queue. What's the best way to avoid this? The mail to the user list is not time-sensitive; it could take a day to trickle out and it wouldn't matter. But the few e-mail coming later into the queue are very time-sensitive. I've looked at the FAQ, and searched the discussion archive, but I'm not certain the best way to set it off by itself (we do need to keep it on the same machine). Any suggestions appreciated. Jeff Hill P.S. Our dial-up SMTP problem does appear to have been linked to the Aug. 1 change in MAPS servers for rblsmtpd. At least, the problem went away sometime after removing rblsmtpd. -- HR On-Line: The Network for Workplace Issues -- http://www.hronline.com - Ph:416-604-7251 - Fax:416-604-4708
queue 'blocked' by large recipient list
Hello everybody, the ORNL search engine is down, and I've run into a little problem, so please excuse me if the subject has already been discussed when sending a newsletter to ~450K recipients, the queue fills up, the server spawns concurrencyremote qmail-remote processes and starts delivering the newsletter (this takes ~10-14 hours) at the same time, an online application tries to send a subscribal message to new users, this should be processed very fast (the new user is waiting for his account data), but the mail is sent out after the newsletter processing is done is there any way to 'split' the remote queue between different applications (or users) sending mail to get rid of this problem ? or are there any other solutions for this ? regards thanks in advance, Chris
Re: queue 'blocked' by large recipient list
On Thu, Aug 02, 2001 at 01:07:58PM +0200, Christian Rotter wrote: [snip] is there any way to 'split' the remote queue between different applications (or users) sending mail to get rid of this problem ? or are there any other solutions for this ? Run 2 qmail instances on your server - one for mailinglists, one for regular mail. Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html
Re: [Fwd: queue 'blocked' by large recipient list]
On Thu, Aug 02, 2001 at 02:52:01PM +0200, Christian Rotter wrote: Hi Peter, yep, this works reconfigured conf-qmail for a new QMAILHOME and reinstalled the package, added the second rc script to the qmail script in init.d and got it running such a shame - missed that KISS approach :-) thanks (one beer for you), qmail gd. KISS gd. beer gd. :) Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html
Re[2]: qmail-queue and custom reject message
posibly, must be a method to return message to qmail-smtpd from qmail-queue module... but i don't find it at this time. -- Best regards, vlad mailto:[EMAIL PROTECTED]
Re: qmail-queue and custom reject message
On Sat, Jul 28, 2001 at 02:22:59PM -0700, Jon Rust wrote: Print the error message to standard output and the server will return this message. This doesn't work with qmail-queue. I have yet to find anyway to get a message either returned to the sending server or to the logs. I've tried printing to standard out and standard error. Can't be done. qmail-smtpd - which calls - qmail-queue - doesn't listen to anything qmail-queue says except it's exit code. To do what you want, you'll have to write your own qmail-queue program that generates a bounce itself - instead of relying on qmail-smtpd to do it. See Qmail-Scanner URL:http://qmail-scanner.sourceforge.net/ for an example. -- Cheers Jason Haar Unix/Special Projects, Trimble NZ Phone: +64 3 9635 377 Fax: +64 3 9635 417
qmail-queue and custom reject message
hello guys. can anybody review, how i can give to message sender custom message during sending mail via my smtp server? current state is: i wrote custom script which substitute qmail-queue, it unpack received message, starting antivirus and if message infected anyone, return code '111' i.e. temporary problem, and deny message relay via server. but, user cannot understand reason of relay-deny. so, server must return custom error message to sender. how i can made it? -- Best regards, vlad mailto:[EMAIL PROTECTED]
Re: qmail-queue and custom reject message
On Sat, 28 Jul 2001 [EMAIL PROTECTED] wrote: i wrote custom script which substitute qmail-queue, it unpack received message, starting antivirus and if message infected anyone, return code '111' i.e. temporary problem, and deny message relay via server. but, user cannot understand reason of relay-deny. so, server must return custom error message to sender. how i can made it? Print the error message to standard output and the server will return this message.
Re: qmail-queue and custom reject message
On Sat, Jul 28, 2001 at 06:57:33AM -0400, Philip Mak wrote: On Sat, 28 Jul 2001 [EMAIL PROTECTED] wrote: i wrote custom script which substitute qmail-queue, it unpack received message, starting antivirus and if message infected anyone, return code '111' i.e. temporary problem, and deny message relay via server. but, user cannot understand reason of relay-deny. so, server must return custom error message to sender. how i can made it? Print the error message to standard output and the server will return this message. This doesn't work with qmail-queue. I have yet to find anyway to get a message either returned to the sending server or to the logs. I've tried printing to standard out and standard error. jon
Re: qmail-queue and custom reject message
i wrote custom script which substitute qmail-queue, it unpack received message, starting antivirus and if message infected anyone, return Why re-invent the wheel? http://qmail-scanner.sourceforge.net Jeff Palmer [EMAIL PROTECTED]
Managing the Queue
Re all. I just finished reading a 70 page chapter on the qmail queue itself and I have a couple questions. Is it possible to search and destroy messages in the queue that meet certain criteria (with qmail off, of course)? Also, is anyone aware of any projects involving management of the queue? I know there's a webmin module that can list messages in the queue, but that's about the extent of it. Does anyone else know anything that could be of use about the queue? David
Manage queue
Hi, Can you say me how can I remove a message in the qmail queue ? I want to delete the msg 245957, so, I've deleted this file : ./qmail/queue/local/18/245957 ./qmail/queue/mess/18/245957 ./qmail/queue/info/18/245957 ./qmail/queue/remote/18/245957 But now, I've got this message in the logfile : @40003b5ec127122940fc warning: trouble opening local/18/245957; will try again later I've forget something ???
RE: Manage queue
Hi, Can you say me how can I remove a message in the qmail queue ? I want to delete the msg 245957, so, I've deleted this file : ... But now, I've got this message in the logfile : @40003b5ec127122940fc warning: trouble opening local/18/245957; will try again later I've forget something ??? Restart qmail-send and don't touch the queue while qmail is running.
Re: Inode allocation / qmail-queue?
On Mon, Jul 23, 2001 at 02:41:22PM -0600, Mike Hodson wrote: Hello there. I have been noticing slightly out of the ordinary things happening in my qmail-send logs after changing the queue filesystem over to reiserfs. I am seeing the same inode used for multiple messages. Is this normal? Yes, this is perfectly normal. Once a message is delivered, an inode number becomes available. Depending on how a filesystem allocates inodes, this may mean the number is immediately reused. If you have lots of logfiles from qmail running on an ext2fs disk, I guarantee you will see some inode-numbers being used more than once too. Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html
Re: several /var/qmail/bin/qmail-smtpd and bin/qmail-queue
bash-2.05$ ls -al /var/qmail/doc/INTERNALS ls: /var/qmail/doc/INTERNALS: No such file or directory bash-2.05$ - Original Message - From: Greg White [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 23, 2001 10:23 PM Subject: Re: several /var/qmail/bin/qmail-smtpd and bin/qmail-queue On Mon, Jul 23, 2001 at 09:58:04PM -0400, alexus wrote: i was checking something and i founds this my mail server seems to have tons of /var/qmail/bin/qmail-smtpd and bin/qmail-queue running at the same time.. about 30 of them The process actually listening on port 25 forks a qmail-smtpd for every incoming conneciton. qmail-queue is then run to place the mail safely in the queue. any ideas why? Read /var/qmail/doc/INTERNALS. nothin intersting in maillog I find that hard to believe. At the moment you see that many qmail-queues hanging around, qmail-smtpd's logs should read something like so, if logged through tcpserver: @40003b5cd7620a221bcc tcpserver: status: 30/xx where xx is either 40 or whatever is specified in the 'run' file for qmail-smtpd. ISTR that inetd does some sort of logging of how many processes it has opened, but it's been so long since I used inetd for anything that I've forgotten. -- Greg White
Re: several /var/qmail/bin/qmail-smtpd and bin/qmail-queue
On Tue, Jul 24, 2001 at 01:23:13PM -0400, alexus wrote: bash-2.05$ ls -al /var/qmail/doc/INTERNALS ls: /var/qmail/doc/INTERNALS: No such file or directory bash-2.05$ Apologies. Installing those files in /var/qmail/doc is a port-ism from FreeBSD. It's in the source tree only in a default install. GW -- Greg White
Re: Inode allocation / qmail-queue?
Hi Mike, this is a known issue with ReiserFS. As you might now, Ext2 and ReiserFS have many differences and you are just experiencing one of them. The whole problem is documented unter www.namesys.com (the homepage of ReiserFS) so you will find the information you need there. In general you have two options: 1) Moving the qMail partition back to ext2 (probably /var) 2) Patching qMail with the ReiserFS patch. (I think that one is available through a link on www.namesys.com too). Just for your information: I have a linux box running qMail and I have moved /home which contains the pop-boxes to ReiserFS but /var remains ext2. This makes sure that mail is securely stored once it is delivered and if your queue (or the partition) crashed you won't have much chances to restore it anyway. Hope this help, Lordy At 14:41 23.07.2001 -0600, you wrote: Hello there. I have been noticing slightly out of the ordinary things happening in my qmail-send logs after changing the queue filesystem over to reiserfs. I am seeing the same inode used for multiple messages. Is this normal? (other users email has been blanked, as has all senders. mine is known to all of you, so why bother typing to cover mine eh? ) excerpts from my qmail-queue log piped thru tai64nlocal 2001-07-23 14:29:38.294512500 new msg 405006 2001-07-23 14:29:38.294529500 info msg 405006: bytes 2531 from [EMAIL PROTECTED] qp 28395 uid 1016 2001-07-23 14:29:38.388694500 starting delivery 689: msg 405006 to local vdomain-vuser@vdomain 2001-07-23 14:29:38.388713500 status: local 1/10 remote 0/20 2001-07-23 14:29:38.442249500 delivery 689: success: POP_user_does_not_exist,_but_will_deliver_to_/users/catchall/dir/did_0+0+1/ 2001-07-23 14:29:38.442273500 status: local 0/10 remote 0/20 2001-07-23 14:29:38.442278500 end msg 405006 2001-07-23 14:32:30.228899500 new msg 405006 2001-07-23 14:32:30.228916500 info msg 405006: bytes 4242 from [EMAIL PROTECTED] qp 28405 uid 1016 2001-07-23 14:32:30.305868500 starting delivery 690: msg 405006 to local [EMAIL PROTECTED] 2001-07-23 14:32:30.305886500 status: local 1/10 remote 0/20 2001-07-23 14:32:30.376295500 delivery 690: success: did_0+0+1/ 2001-07-23 14:32:30.376313500 status: local 0/10 remote 0/20 2001-07-23 14:32:30.376319500 end msg 405006 2001-07-23 14:32:32.722033500 new msg 405006 2001-07-23 14:32:32.722049500 info msg 405006: bytes 1827 from [EMAIL PROTECTED] qp 28409 uid 1016 2001-07-23 14:32:32.814920500 starting delivery 691: msg 405006 to local [EMAIL PROTECTED] 2001-07-23 14:32:32.814937500 status: local 1/10 remote 0/20 2001-07-23 14:32:32.847071500 delivery 691: success: did_0+0+1/ 2001-07-23 14:32:32.847089500 status: local 0/10 remote 0/20 2001-07-23 14:32:32.847094500 end msg 405006 Mike -- Mike Hodson [EMAIL PROTECTED]
Re: Inode allocation / qmail-queue?
Er whatever other issues may or may not be associated with ReiserFS, re-use of inodes does not present a problem for qmail and is commonly seen on UFS. If you look at the log fragment carefully you'll see that the inode is only reused after the message has been delivered and thus the file deleted. It would be a problem if the same inode was in use at the same time, but the log fragment doesn't show that. By way of an example, on a FreeBSD 4.2 UFS queue I see that the same inode has been re-used over 100 times for some 1200 deliveries. $ grep 'info msg' /var/log/qmail/current | cut -f4 -d' ' | cut -f1 -d: | sort -n | uniq -c | sort -nr 177 8097707 165 8097716 118 8097715 83 8097913 75 8097709 71 8097768 62 8097947 48 8097699 42 8097909 33 8097990 29 8097701 23 8097755 16 8097879 16 8097769 15 8097910 14 8097943 14 8097914 14 8097712 13 8097719 11 8097753 10 8097998 10 8097997 8 8097984 ... Regards. On Tue, Jul 24, 2001 at 01:45:57AM +0200, Lordy allegedly wrote: Hi Mike, this is a known issue with ReiserFS. As you might now, Ext2 and ReiserFS have many differences and you are just experiencing one of them. The whole problem is documented unter www.namesys.com (the homepage of ReiserFS) so you will find the information you need there. In general you have two options: 1) Moving the qMail partition back to ext2 (probably /var) 2) Patching qMail with the ReiserFS patch. (I think that one is available through a link on www.namesys.com too). Just for your information: I have a linux box running qMail and I have moved /home which contains the pop-boxes to ReiserFS but /var remains ext2. This makes sure that mail is securely stored once it is delivered and if your queue (or the partition) crashed you won't have much chances to restore it anyway. Hope this help, Lordy At 14:41 23.07.2001 -0600, you wrote: Hello there. I have been noticing slightly out of the ordinary things happening in my qmail-send logs after changing the queue filesystem over to reiserfs. I am seeing the same inode used for multiple messages. Is this normal? (other users email has been blanked, as has all senders. mine is known to all of you, so why bother typing to cover mine eh? ) excerpts from my qmail-queue log piped thru tai64nlocal 2001-07-23 14:29:38.294512500 new msg 405006 2001-07-23 14:29:38.294529500 info msg 405006: bytes 2531 from [EMAIL PROTECTED] qp 28395 uid 1016 2001-07-23 14:29:38.388694500 starting delivery 689: msg 405006 to local vdomain-vuser@vdomain 2001-07-23 14:29:38.388713500 status: local 1/10 remote 0/20 2001-07-23 14:29:38.442249500 delivery 689: success: POP_user_does_not_exist,_but_will_deliver_to_/users/catchall/dir/did_0+0+1/ 2001-07-23 14:29:38.442273500 status: local 0/10 remote 0/20 2001-07-23 14:29:38.442278500 end msg 405006 2001-07-23 14:32:30.228899500 new msg 405006 2001-07-23 14:32:30.228916500 info msg 405006: bytes 4242 from [EMAIL PROTECTED] qp 28405 uid 1016 2001-07-23 14:32:30.305868500 starting delivery 690: msg 405006 to local [EMAIL PROTECTED] 2001-07-23 14:32:30.305886500 status: local 1/10 remote 0/20 2001-07-23 14:32:30.376295500 delivery 690: success: did_0+0+1/ 2001-07-23 14:32:30.376313500 status: local 0/10 remote 0/20 2001-07-23 14:32:30.376319500 end msg 405006 2001-07-23 14:32:32.722033500 new msg 405006 2001-07-23 14:32:32.722049500 info msg 405006: bytes 1827 from [EMAIL PROTECTED] qp 28409 uid 1016 2001-07-23 14:32:32.814920500 starting delivery 691: msg 405006 to local [EMAIL PROTECTED] 2001-07-23 14:32:32.814937500 status: local 1/10 remote 0/20 2001-07-23 14:32:32.847071500 delivery 691: success: did_0+0+1/ 2001-07-23 14:32:32.847089500 status: local 0/10 remote 0/20 2001-07-23 14:32:32.847094500 end msg 405006 Mike -- Mike Hodson [EMAIL PROTECTED]
Re: Inode allocation / qmail-queue?
On Tue, Jul 24, 2001 at 01:45:57AM +0200, Lordy wrote: Hi Mike, this is a known issue with ReiserFS. As you might now, Ext2 and ReiserFS have many differences and you are just experiencing one of them. The whole problem is documented unter www.namesys.com (the homepage of ReiserFS) so you will find the information you need there. Hmm, according to the ReiserFS FAQ (http://www.namesys.com/faq.html#qmail), the only issue affecting ReiserFS is the same one affecting ext2: namely that link() and unlink() are synchronous operations. I see no special problems... I'm currently about to go live with new ReiserFS based Qmail servers, and haven't noticed any problem. If there is, I'd certainly like to know... :-) -- Cheers Jason Haar Unix/Special Projects, Trimble NZ Phone: +64 3 9635 377 Fax: +64 3 9635 417
Re: Inode allocation / qmail-queue?
On Tue, Jul 24, 2001 at 01:30:01PM +1200, Jason Haar wrote: I'm currently about to go live with new ReiserFS based Qmail servers, and haven't noticed any problem. If there is, I'd certainly like to know... :-) I'm running qmail on several boxen, all ReiserFS-only. Not a single problem to date, though I did use Bruce Guenter's syncdir patch, so that could be construed as cheating. 8-) Also read the Qmail-ReiserFS Integration HOWTO: http://www.jedi.claranet.fr/qmail-reiserfs-howto.html. -- Adrian HoTinker, Drifter, Fixer, Bum [EMAIL PROTECTED] Archived @: http://marc.theaimsgroup.com/?l=qmail Useful URLs: http://cr.yp.to/qmail.html http://www.qmail.org http://www.lifewithqmail.org/ http://qmail.faqts.com/
several /var/qmail/bin/qmail-smtpd and bin/qmail-queue
i was checking something and i founds this my mail server seems to have tons of /var/qmail/bin/qmail-smtpd and bin/qmail-queue running at the same time.. about 30 of them any ideas why? nothin intersting in maillog
Re: several /var/qmail/bin/qmail-smtpd and bin/qmail-queue
On Mon, Jul 23, 2001 at 09:58:04PM -0400, alexus wrote: i was checking something and i founds this my mail server seems to have tons of /var/qmail/bin/qmail-smtpd and bin/qmail-queue running at the same time.. about 30 of them The process actually listening on port 25 forks a qmail-smtpd for every incoming conneciton. qmail-queue is then run to place the mail safely in the queue. any ideas why? Read /var/qmail/doc/INTERNALS. nothin intersting in maillog I find that hard to believe. At the moment you see that many qmail-queues hanging around, qmail-smtpd's logs should read something like so, if logged through tcpserver: @40003b5cd7620a221bcc tcpserver: status: 30/xx where xx is either 40 or whatever is specified in the 'run' file for qmail-smtpd. ISTR that inetd does some sort of logging of how many processes it has opened, but it's been so long since I used inetd for anything that I've forgotten. -- Greg White
Re: several /var/qmail/bin/qmail-smtpd and bin/qmail-queue
i can send you today's log.. but its really nothing intersting there what i found intesting is tcpserver servver shows 0/40 - Original Message - From: Greg White [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 23, 2001 10:23 PM Subject: Re: several /var/qmail/bin/qmail-smtpd and bin/qmail-queue On Mon, Jul 23, 2001 at 09:58:04PM -0400, alexus wrote: i was checking something and i founds this my mail server seems to have tons of /var/qmail/bin/qmail-smtpd and bin/qmail-queue running at the same time.. about 30 of them The process actually listening on port 25 forks a qmail-smtpd for every incoming conneciton. qmail-queue is then run to place the mail safely in the queue. any ideas why? Read /var/qmail/doc/INTERNALS. nothin intersting in maillog I find that hard to believe. At the moment you see that many qmail-queues hanging around, qmail-smtpd's logs should read something like so, if logged through tcpserver: @40003b5cd7620a221bcc tcpserver: status: 30/xx where xx is either 40 or whatever is specified in the 'run' file for qmail-smtpd. ISTR that inetd does some sort of logging of how many processes it has opened, but it's been so long since I used inetd for anything that I've forgotten. -- Greg White
RE: help! thousands of qmail-queue processes!
The vast majority of the qmail-queue processes look to have a parent pid of '1' Maybe 1% of the queue processes have other parent pids, so I'm not too worried about them. The server is still delivering some mail, so I'm making an educated guess that queue processes not attached to init are doing The Right Thing. Thanks, Chris McDaniel -Original Message- From: Alex Pennace [mailto:[EMAIL PROTECTED]] Sent: 19 Jul, 2001 2:51 PM To: Chris McDaniel Cc: '[EMAIL PROTECTED]' Subject: Re: help! thousands of qmail-queue processes! On Thu, Jul 19, 2001 at 10:43:14AM -0600, Chris McDaniel wrote: I'm having trouble with qmail - I have about 500 messages in the queue (usually this number hovers between 50 and 80) and between 1000 and 2000 qmail-queue processes hanging around depending on when I sample. What are the parents of those qmail-queue processes, and what are they doing?
Re: help! thousands of qmail-queue processes!
On Thu, Jul 19, 2001 at 01:07:21PM -0600, Chris McDaniel wrote: The vast majority of the qmail-queue processes look to have a parent pid of '1' Then something is not running qmail-queue properly. Find out what. Shortly after it starts, qmail-queue starts a message file under queue/mess. Even if no content has been passed to qmail-queue yet, it will write out its Received header, which includes the calling uid. Start your investigation there.
Large queue and iowait
Title: Large queue and iowait I'm having some problems with my qmail server. It seems to be taking an abnormally large amount of time to do queue processing. A recent mailing list send of 250k e-mail's to the server had it stuck in queue processing with iowait at 80-100% the entire time, for over 36 hours. I assume this is not a normal timeframe for processing that amount of e-mail. The setup is as follows: Sun Netra t1 - 450mhz ultrasparcII processor 1024MB of memory, 1.5GB of swap 18GB SCSI disk. Solaris 8 qmail 1.03 with DNS and big-concurrency patch If any other information is pertinent, please let me know and I'll provide it. Any insight into what the problem could be would be greatly appreciated. Thanks, Mark -- s/root/Mark
Re: Large queue and iowait
On 2001.07.17 12:47 Mark Douglas wrote: I'm having some problems with my qmail server. It seems to be taking an abnormally large amount of time to do queue processing. A recent mailing list send of 250k e-mail's to the server had it stuck in queue processing with iowait at 80-100% the entire time, for over 36 hours. I assume this is not a normal timeframe for processing that amount of e-mail. The setup is as follows: Sun Netra t1 - 450mhz ultrasparcII processor 1024MB of memory, 1.5GB of swap 18GB SCSI disk. Solaris 8 qmail 1.03 with DNS and big-concurrency patch If any other information is pertinent, please let me know and I'll provide it. Any insight into what the problem could be would be greatly appreciated. Thanks, Mark -- s/root/Mark !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=iso-8859-1 META NAME=Generator CONTENT=MS Exchange Server version 5.5.2652.35 TITLELarge queue and iowait/TITLE /HEAD BODY PFONT SIZE=2I'm having some problems with my qmail server. It seems to be taking an abnormally large amount of time to do queue processing. A recent mailing list send of 250k e-mail's to the server had it stuck in queue processing with iowait at 80-100% the entire time, for over 36 hours. I assume this is not a quot;normalquot; timeframe for processing that amount of e-mail./FONT/P PFONT SIZE=2The setup is as follows:/FONT /P PFONT SIZE=2Sun Netra t1 - 450mhz ultrasparcII processor/FONT BRFONT SIZE=21024MB of memory, 1.5GB of swap/FONT BRFONT SIZE=218GB SCSI disk./FONT BRFONT SIZE=2Solaris 8/FONT BRFONT SIZE=2qmail 1.03 with DNS and big-concurrency patch/FONT /P PFONT SIZE=2If any other information is pertinent, please let me know and I'll provide it. Any insight into what the problem could be would be greatly appreciated./FONT/P PFONT SIZE=2Thanks,/FONT /P PFONT SIZE=2Mark/FONT BRFONT SIZE=2--/FONT BRFONT SIZE=2s/root/Mark/FONT /P /BODY /HTML I would check to see if qmail-send has a defunct process.. You will need to restart it or restart qmail altogether and make sure there are no stray proceses that may interfere. I've had multiple instances where the queue becomes abnormally large because qmail-send is defunct.. It should reload and you will see preprocessed mails grow until it spits everything out. -- Jake Roersma Network Engineer Triton Technologies Inc. (800)-837-4253/364-8761
Re: Large queue and iowait
On Tue, Jul 17, 2001 at 12:47:16PM -0400, Mark Douglas wrote: Solaris 8 ^^^ This is your problem. -- * Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de * * Roedingsmarkt 14, 20459 Hamburg, Germany * Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
RE: Large queue and iowait
Title: RE: Large queue and iowait -Original Message- From: Dave Sill [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 17, 2001 13:32 To: [EMAIL PROTECTED] Subject: Re: Large queue and iowait Jake Roersma [EMAIL PROTECTED] wrote: I would check to see if qmail-send has a defunct process.. You will need to restart it or restart qmail altogether and make sure there are no stray proceses that may interfere. I've had multiple instances where the queue becomes abnormally large because qmail-send is defunct.. That ain't right. qmail-send doesn't doesn't just go defunct. I'd suspect a kernel bug. What OS are you using? -Dave See my original e-mail for this info. (Quick answer: Solaris 8). Mark
Moving queue directory
Title: Moving queue directory I would like to move my queue directory to another location. Is there a feasible way to do this while qmail is running, or should I shut it down and move the directory, and then bring qmail back up? Thanks, Mark
Re: Moving queue directory
On Tue, Jul 17, 2001 at 06:55:51PM -0400, Mark Douglas wrote: I would like to move my queue directory to another location. Is there a feasible way to do this while qmail is running, No. or should I shut it down and move the directory, and then bring qmail back up? Yes. Thanks, You're welcome. Mark I presume that you're moving mount points around, right? Done it, no problem. Just mount /var/qmail/queue (or /var/qmail, or whatever you're doing), 'make setup check' in the source, and away you go (after clearing and deleting the existing queue, of course). -- Greg White
Re: ANN: queue-repair v.0.8.4
Charles Cazabon [EMAIL PROTECTED] writes: queue-repair version 0.8.4 incorporates this fix. You write software faster than I can keep up with reading your mails :)
Re: qmail-queue-patch and qmail-scanner
On Sat, Jul 07, 2001 at 09:19:19PM +0200, Andreas Grip wrote: Well, a smtp-server receiving a lot of mail can reach the limit of maximum allowed simultanius connection. If the smtp server close the connection faster there will be more time over and the server is able to receive more mail. So I think a server, that are faster with closing the connection should be more efficient. If scanning incoming mail takes that long, either upgrade your hardware or push the scanning problem to the end-users (ie. get them to buy an anti-virus package or something). Trying to accept even more mail, when you're already having trouble clearing the mail you've already received, is IMO A Really Bad Idea In A World Full Of Bad Ideas. - Adrian
Re: qmail-queue-patch and qmail-scanner
Charles Cazabon wrote: Andreas Grip [EMAIL PROTECTED] wrote: I don't think this is a great idea; it means you have to accept every message, then scan them, then generate late bounces, instead of rejecting them during the initial SMTP conversation. qmail-scanner do not reject them, it just bounce them. I think you're mistaken, although I don't use qmail-scanner. Issuing a 4xx or 5xx code after DATA _is_ rejecting a message -- it's also a bounce, although if it's done during the SMTP conversation, the sending MTA is responsible for generating the bounce message. Nope, I'm not misstaken. An infected mail is not rejected while my smtp server is receiving the mail, it turn of the connection with an ok. No bounce at this time. And then it sends an bounce to the sender with virus warning message. And what diffrent should that make if the bunce is a few minutes late? It will be late for the sender anyway because they use their ISP:s smtp server and the mail will be sended from that to my smtp server that scan the mail. There's a big difference. See above. Late bounces have to be generated by your MTA and delivered; if the message is bounced during the initial SMTP conversion, the bounce message is the responsibility of the sending MTA, not the receiving one. Maybe there should be an idea to change the behavior of qmail-scanner so it reject the mail instead of accepting it. But then where can not be so much details in the virus report because the sending smtp do not know anything about the virus. What problem are you trying to solve? Why do you think making the SMTP client wait a minute or two is a bad idea? Well, a smtp-server receiving a lot of mail can reach the limit of maximum allowed simultanius connection. If the smtp server close the connection faster there will be more time over and the server is able to receive more mail. So I think a server, that are faster with closing the connection should be more efficient. Profile, don't speculate. You're trying to solve a problem that doesn't exist. I'm not trying to solve a problem that dosen't exist. I'm just trying to make sure that there will not be any problems. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
queue-repair v.0.8.3
-BEGIN PGP SIGNED MESSAGE- Charles Cazabon wrote: queue-repair is another qmail queue diagnostic and repair tool. Details on what makes queue-repair different from other tools are set out in the included BLURB file. Charles - # ./queue_repair.py On a working queue checks out fine. For testing purposes, I deleted /var/qmail/queue, and ran: # ./queue_repair --create queue_repair.py v. 0.8.3 Copyright (C) 2001 Charles Cazabon pqt @ discworld.dyndns.org Licensed under the GNU General Public License version 2 running in repair mode finding qmail UIDs/GIDs... determining conf-split... basic queue directories not found at /var/qmail creating new queue at /var/qmail Traceback (innermost last): File ./queue_repair.py, line 801, in ? File ./queue_repair.py, line 797, in main File ./queue_repair.py, line 690, in check_queue NameError: split Tried again, adding --repair to the command, with the same results. I was hoping to use this tool as a supplement to a localized tarball install of qmail, to enable me to store a binary package to add to a Solaris jumpstart. Am I misunderstanding its purpose and/or usage? Thank you -d - -- David Talkington PGP key: http://www.prairienet.org/~dtalk/dt000823.asc -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 Comment: Made with pgp4pine 1.75-6 iQEVAwUBO0frvb1ZYOtSwT+tAQHgPwgAx7cuW6p4/GWv+OmOqgKWLYNdAOfCTlPv AfsS8U2J5jBEvgP83fJisR9JaUEcQFSFGRIBrn4nU7lGPr+CKTDaX6xkMKmvrjzs 6PS9Yn0qdNqwd3v41q5K2EKOgW7B98Gr8fcpE70rws3cKXyG0b4eJVj9v4sEYkjU vEDduaeK/8SBOA8lRW6A+6ETiNUFZLUvvbflAvqSK2OM6gEK2kX+xRwZHKaliSzd J5qaO5puke3Y1W8fPzqdnUYMm6x7nICcuC2NTjnPkKXLU91NWysKDd7SJg32BC8f kmN8urlCoFYZh4DyzmwPaUKE5Hnx3G+dJWeq7SFNy4oGguJ7tUMSGA== =2Wfu -END PGP SIGNATURE-
Re: qmail-queue-patch and qmail-scanner
On Sun, Jul 08, 2001 at 10:57:08AM +0200, Andreas Grip wrote: Nope, I'm not misstaken. An infected mail is not rejected while my smtp server is receiving the mail, it turn of the connection with an ok. No bounce at this time. And then it sends an bounce to the sender with virus warning message. Absolutely right. I cannot send a SMTP error back during the DATA phase otherwise the sending SMTP server just bounces the Email message with little or no reason. SMTP error messages aren't any good when you're wanting to convey an elaborate reason why it bounced (e.g. it was the KAK worm virus) and in several languages :-) OTOH it is still real-time. An original design decisions behind Qmail-Scanner - which I am still happy with - was that I wasn't going to re-invent the wheel and do post-scanning, and I would then have to design my own queuing system, retries, etc. The way it is designed means all such issues are taken care of by standard SMTP. 10-20 minutes is the standard maximum time a SMTP server expects to be sitting in DATA phase, if a mail message takes longer than that to be scanned by whatever virus scanner you have chosen (that will be where the bottleneck is - not with Q-S), then you seriously have to look at: a your choice of scanner b upgrading your hardware. I have seen thrown around the fact that to run a real-time SMTP virus scanner requires around 10x the amount of hardware that not scanning would. Sounds about right. That isn't as bad as it sounds as we all over-spec SMTP relay servers these days anyway. We run two different virus scanners over each piece of Email entering and leaving our network via Qmail-Scanner. The load on these boxes has increased from a load average of 0.02 to 0.06, and climbs to 30+ when we have hour+ network outages. The sudden onslaught of mail after an outage is the killer. Always spec for outages... Also, don't forget, disk IO is most important for SMTP servers. When you start virus scanning, you must add CPU and RAM to that as well. i.e. Big AV mail servers need lots of RAM, lots of CPU as well as fast disks. -- Cheers Jason Haar Unix/Special Projects, Trimble NZ Phone: +64 3 9635 377 Fax: +64 3 9635 417
Re: queue-repair v.0.8.3
David Talkington [EMAIL PROTECTED] wrote: # ./queue_repair.py On a working queue checks out fine. Good. For testing purposes, I deleted /var/qmail/queue, and ran: # ./queue_repair --create queue_repair.py v. 0.8.3 Copyright (C) 2001 Charles Cazabon pqt @ discworld.dyndns.org Licensed under the GNU General Public License version 2 running in repair mode finding qmail UIDs/GIDs... determining conf-split... basic queue directories not found at /var/qmail creating new queue at /var/qmail Traceback (innermost last): File ./queue_repair.py, line 801, in ? File ./queue_repair.py, line 797, in main File ./queue_repair.py, line 690, in check_queue NameError: split Tried again, adding --repair to the command, with the same results. Try adding an explicit --split 23 (or appropriate split). I was hoping to use this tool as a supplement to a localized tarball install of qmail, to enable me to store a binary package to add to a Solaris jumpstart. Am I misunderstanding its purpose and/or usage? Nope. You found a bug. If you don't supply a split argument, and queue-repair can't find a basic queue structure, it has no way of knowing what conf-split should be. I'll have to think about the right way to fix this. It would be easy to just default to 23, but that's not correct. Thanks for the report. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
ANN: queue-repair v.0.8.4
Charles Cazabon [EMAIL PROTECTED] wrote: If you don't supply a split argument, and queue-repair can't find a basic queue structure, it has no way of knowing what conf-split should be. I'll have to think about the right way to fix this. The right way is to ensure that if the user wants to create a new queue, they have to supply a value for conf-split, and specify whether big-todo should be used or not. queue-repair version 0.8.4 incorporates this fix. It's available for download at: http://www.qcc.sk.ca/~charlesc/software/queue_repair/ Changes since version 0.8.3 include: -when force-creating a queue, ensure the user supplies a value for conf-split and either --bigtodo or --no-bigtodo -change --create to imply --repair as well Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Re: qmail-queue-patch and qmail-scanner
Andreas Grip [EMAIL PROTECTED] wrote: I'm using the qmail-queue-patch together with the qmail-scanner and I'm also thinking about to put some spamfilters before or after the antivirus scanning. [...] Is it ok to let the sending smtp server to wait so long time before [qmail-scanner] has processed the mail? For me it sounds like a bad idea to let them wait. No, a few minutes wait is perfectly fine. So I'm thinking about to create another queue that the mail can be placed in first so qmail can tell the sender that it has ben received and then start to scan and filtering the mail in that queue before it deliver it to the original queue. I don't think this is a great idea; it means you have to accept every message, then scan them, then generate late bounces, instead of rejecting them during the initial SMTP conversation. What problem are you trying to solve? Why do you think making the SMTP client wait a minute or two is a bad idea? Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Re: qmail-queue-patch and qmail-scanner
At 12:27 07.07.2001 -0600, you wrote: Andreas Grip [EMAIL PROTECTED] wrote: So I'm thinking about to create another queue that the mail can be placed in first so qmail can tell the sender that it has ben received and then start to scan and filtering the mail in that queue before it deliver it to the original queue. What problem are you trying to solve? Why do you think making the SMTP client wait a minute or two is a bad idea? hmm iam not sure, but what is, if the connected mta thinks that the remote has gone offline, closes the connection and sets the message deferred, and retries later.. getting the same problem again.. iam not if there exist's a such mta, but its possible that this will cause problems like that -- Lukas Maverick Beeler / Telematiker Project: D.R.E.A.M / every.de - Your Community Web: http://www.projectdream.org Mail: [EMAIL PROTECTED]
Re: qmail-queue-patch and qmail-scanner
Lukas Beeler [EMAIL PROTECTED] wrote: At 12:27 07.07.2001 -0600, you wrote: Andreas Grip [EMAIL PROTECTED] wrote: So I'm thinking about to create another queue that the mail can be placed in first so qmail can tell the sender that it has ben received and then start to scan and filtering the mail in that queue before it deliver it to the original queue. What problem are you trying to solve? Why do you think making the SMTP client wait a minute or two is a bad idea? hmm iam not sure, but what is, if the connected mta thinks that the remote has gone offline, closes the connection and sets the message deferred, and retries later.. getting the same problem again.. iam not if there exist's a such mta, but its possible that this will cause problems like that If there's such an MTA, it's broken. RFC2821 states that the absolute minimum timeout the sending MTA can use while waiting for the response to the end of the DATA phase is 10 minutes: DATA Termination: 10 minutes. This is while awaiting the 250 OK reply. When the receiver gets the final period terminating the message data, it typically performs processing to deliver the message to a user mailbox. A spurious timeout at this point would be very wasteful and would typically result in delivery of multiple copies of the message, since it has been successfully sent and the server has accepted responsibility for delivery. See section 6.1 for additional discussion. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Re: qmail-queue-patch and qmail-scanner
Charles Cazabon wrote: Andreas Grip [EMAIL PROTECTED] wrote: I'm using the qmail-queue-patch together with the qmail-scanner and I'm also thinking about to put some spamfilters before or after the antivirus scanning. [...] Is it ok to let the sending smtp server to wait so long time before [qmail-scanner] has processed the mail? For me it sounds like a bad idea to let them wait. No, a few minutes wait is perfectly fine. So I'm thinking about to create another queue that the mail can be placed in first so qmail can tell the sender that it has ben received and then start to scan and filtering the mail in that queue before it deliver it to the original queue. I don't think this is a great idea; it means you have to accept every message, then scan them, then generate late bounces, instead of rejecting them during the initial SMTP conversation. qmail-scanner do not reject them, it just bounce them. And what diffrent should that make if the bunce is a few minutes late? It will be late for the sender anyway because they use their ISP:s smtp server and the mail will be sended from that to my smtp server that scan the mail. What problem are you trying to solve? Why do you think making the SMTP client wait a minute or two is a bad idea? Well, a smtp-server receiving a lot of mail can reach the limit of maximum allowed simultanius connection. If the smtp server close the connection faster there will be more time over and the server is able to receive more mail. So I think a server, that are faster with closing the connection should be more efficient. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Re: qmail-queue-patch and qmail-scanner
Andreas Grip [EMAIL PROTECTED] writes: connection faster there will be more time over and the server is able to receive more mail. So I think a server, that are faster with closing the connection should be more efficient. Then the backlog is on your server. You still have to scan the mails and this is the time consuming thing. Additionally you get the overhead of two queues. Regards, Frank
Re: qmail-queue-patch and qmail-scanner
Andreas Grip [EMAIL PROTECTED] wrote: I don't think this is a great idea; it means you have to accept every message, then scan them, then generate late bounces, instead of rejecting them during the initial SMTP conversation. qmail-scanner do not reject them, it just bounce them. I think you're mistaken, although I don't use qmail-scanner. Issuing a 4xx or 5xx code after DATA _is_ rejecting a message -- it's also a bounce, although if it's done during the SMTP conversation, the sending MTA is responsible for generating the bounce message. And what diffrent should that make if the bunce is a few minutes late? It will be late for the sender anyway because they use their ISP:s smtp server and the mail will be sended from that to my smtp server that scan the mail. There's a big difference. See above. Late bounces have to be generated by your MTA and delivered; if the message is bounced during the initial SMTP conversion, the bounce message is the responsibility of the sending MTA, not the receiving one. What problem are you trying to solve? Why do you think making the SMTP client wait a minute or two is a bad idea? Well, a smtp-server receiving a lot of mail can reach the limit of maximum allowed simultanius connection. If the smtp server close the connection faster there will be more time over and the server is able to receive more mail. So I think a server, that are faster with closing the connection should be more efficient. Profile, don't speculate. You're trying to solve a problem that doesn't exist. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
ANN: queue-repair v.0.8.3
Greetings, queue-repair v. 0.8.3 has been released and is available for download from http://www.qcc.sk.ca/~charlesc/software/queue_repair/ . queue-repair is another qmail queue diagnostic and repair tool. Details on what makes queue-repair different from other tools are set out in the included BLURB file. Changes since version 0.8.2 include: -enforce checking of prime conf-split. Use --i-want-a-broken-conf-split to force a non-prime split value in repair mode -add explicit -h, --help options -enforce checking of existence of basic queue directories to prevent accidental creation of queue in wrong place due to typos, etc. Use -c, --create to force creation of a new queue -when creating a directory, force create missing parent(s) -fix --no-bigtodo to allow conversion of big-todo queue to non-big-todo; would previously auto-detect big-todo regardless -improve forced conversion of non-big-todo queue to big-todo or vice versa, and improve force change of conf-split for existing queues Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ My opinions are just that -- my opinions. ---
smtproutes and mail still in queue
Hi, My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? Thank you in advance for any help. -- Subba Rao [EMAIL PROTECTED] http://members.home.net/subba9/ GPG public key ID 27FC9217 Key fingerprint = 2B4C 498E 1860 5A2B 6570 5852 7527 882A 27FC 9217
Re: smtproutes and mail still in queue
On Fri, Jul 06, 2001 at 06:36:19AM +, Subba Rao wrote: Hi, My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? What do the logs say? Has qmail-send tried any deliveries to gbnet.net since you altered smtproutes?
Re: smtproutes and mail still in queue
On 0, Alex Pennace [EMAIL PROTECTED] wrote: On Fri, Jul 06, 2001 at 06:36:19AM +, Subba Rao wrote: Hi, My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? What do the logs say? Has qmail-send tried any deliveries to gbnet.net since you altered smtproutes? --- Jun 29 22:15:54 myhost qmail: 993852954.669066 starting delivery 65: msg 197156 to remote [EMAIL PROTECTED] Jun 29 22:15:54 myhost qmail: 993852954.670044 status: local 0/10 remote 1/20 Jun 29 22:15:55 myhost qmail: 993852955.514653 delivery 65: deferral: Connected_to_194.70.126.10_but_connection_died._(#4.4.2)/ Jun 29 22:15:55 myhost qmail: 993852955.515821 status: local 0/10 remote 0/20 Jun 29 22:22:35 myhost qmail: 993853355.538097 starting delivery 66: msg 197156 to remote [EMAIL PROTECTED] Jun 29 22:22:35 myhost qmail: 993853355.538447 status: local 0/10 remote 1/20 Jun 29 22:22:36 myhost qmail: 993853356.268755 delivery 66: deferral: Connected_to_194.70.126.10_but_connection_died._(#4.4.2)/ Jun 29 22:22:36 myhost qmail: 993853356.269908 status: local 0/10 remote 0/20 --- The following is from this morning. --- Jul 6 06:22:35 myhost qmail: 994400555.804312 starting delivery 59: msg 197156 to remote [EMAIL PROTECTED] Jul 6 06:22:35 myhost qmail: 994400555.804480 status: local 0/10 remote 1/20 Jul 6 06:22:45 myhost qmail: 994400565.356285 delivery 59: deferral: Connected_to_194.70.126.10_but_connection_died._(#4.4.2)/ Jul 6 06:22:45 myhost qmail: 994400565.356445 status: local 0/10 remote 0/20 --- The mail is still in the queue. Here is the output of mailq, 29 Jun 2001 22:15:54 GMT #197156 621 [EMAIL PROTECTED] remote [EMAIL PROTECTED] The smtproutes has the following entry: gbnet.net:mail.home.com I have tried the following too: .gbnet.net:mail.home.com -- Subba Rao [EMAIL PROTECTED] http://members.home.net/subba9/ GPG public key ID 27FC9217 Key fingerprint = 2B4C 498E 1860 5A2B 6570 5852 7527 882A 27FC 9217
RE: smtproutes and mail still in queue
My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? Thank you in advance for any help. -- Look at the recipients of mutt list messages. You subscribe to gbnet.net but the message recipients are @mutt.org You can post to @mutt.org too hope this help ~edu
Re: smtproutes and mail still in queue
On Fri, Jul 06, 2001 at 06:36:41AM +, Subba Rao wrote: Hi, My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? qmail does not ignore control files. Verify that /var/qmail/control/smtproutes contains the correct information (and is named correctly), restart qmail, send qmail-send an ALRM signal to retry all queued mail, and watch the mail fly off to your ISP. Thank you in advance for any help. NP. :) -- Greg White
ANN: queue-repair v. 0.8.2
Greetings, Based on user feedback, I have released version 0.8.2 of queue-repair, another qmail queue diagnostic and repair tool. It's available for download at: http://www.qcc.sk.ca/~charlesc/software/queue_repair/ Changes since verison 0.8.0: -fix intd split issues without big-todo. Thanks to Lou Hevly for the report. queue-repair would previously believe all non-big-todo queues were missing split directories in queue/intd. -remove unused user and group from dictionary; eliminate bogus warning on FreeBSD. -whitespace cleanups; easier to read with standard tab width settings Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
ANN: queue_repair v.0.8.0 -- yet another qmail queue repair tool
Greetings, This is the first public release of queue_repair, which is yet another qmail queue repair tool. Features include: -written in Python; no compilation necessary. -automatic, dynamic determination of UIDs and GIDs. -automatic, dynamic determination of conf-split; can be overridden on the commandline to change the conf-split of an existing queue without running a parallel, temporary instance of qmail for queuelifetime. Just recompile and stop qmail, run queue-repair, and restart qmail. -automatic, dynamic determination of use of big-todo; can be overridden on the commandline to change an existing queue as above. -handles basic tasks like fixing a queue restored from backups, incorrect ownership or permissions of directories and files, missing or extra split subdirectories, unexpected files or other direntries, or creating a valid queue from scratch. -can run in repair or test (report-only) modes. The default is test mode. -can also be imported as a library from other Python scripts. All functionality is available for customized uses this way. -licensed under the GNU General Public License version 2. queue_repair is available for download at http://www.qcc.sk.ca/~charlesc/software/queue_repair/ I would appreciate any feedback on queue_repair. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
tcpserver / queue cleaning
Hello, I got too questions about qmail and tcpserver. If the tcpserver program is off topic here, please advise me to the right list. 1. How can I delete every message existing in the queue? 2. I'm using tcpserver to start qmail and it seems to work. But there is a little thing I don't understand. On my FreeBSD 4.2 RELEASE machine I added the follwing configuration file into /etc/rc: /usr/local/bin/tcpserver -p -x /etc/tcp.smtp.cdb -u 82 -g 81 0 smtp \ /var/qmail/bin/smtpd After I added this line I rebooted the machine and it stopped right at the point where it was supposed to excute the line above. It didn't crash and I was able to talk to my server on port 25 it just didn't proccess the rest of the startup scripts. Because it looked the way that /var/qmail/bin/qmail-smtpd was waiting on stdin I added an ampersand at the and of the line so /bin/sh would start it as a background process. It seems to work that way but I'm confused because I read twice in two different docs that no ampersand is needed. At least it wasn't printed there. Can anyone enlighten me? -Moritz
Re: tcpserver / queue cleaning
On Wed, Jul 04, 2001 at 08:26:45PM +0200, Moritz Schmitt wrote: 2. I'm using tcpserver to start qmail and it seems to work. But there is a little thing I don't understand. On my FreeBSD 4.2 RELEASE machine I added the follwing configuration file into /etc/rc: That's not the right place to start services, but that's beyond the scope of this list. /usr/local/bin/tcpserver -p -x /etc/tcp.smtp.cdb -u 82 -g 81 0 smtp \ /var/qmail/bin/smtpd After I added this line I rebooted the machine and it stopped right at the point where it was supposed to excute the line above. It didn't crash and I was able to talk to my server on port 25 it just didn't proccess the rest of the startup scripts. Because it looked the way that /var/qmail/bin/qmail-smtpd was waiting on stdin I added an ampersand at the and of the line so /bin/sh would start it as a background process. It seems to work that way but I'm confused because I read twice in two different docs that no ampersand is needed. At least it wasn't printed there. Can anyone enlighten me? In this case you do need the ampersand, but again this is not a qmail question, but a general Unix question. I'd suggest you read http://www.lifewithqmail.org. Set things up as outlined there, and start svscan from a script in /usr/local/etc/rc.d Chris PGP signature
Re: tcpserver / queue cleaning
On Wed, Jul 04, 2001 at 08:26:45PM +0200, Moritz Schmitt wrote: Hello, I got too questions about qmail and tcpserver. If the tcpserver program is off topic here, please advise me to the right list. 1. How can I delete every message existing in the queue? If this isn't a FAQ, it should be. Stop all qmail processes. Have the compile qmail source handy. 'rm -rf /var/qmail/queue', and 'make setup check' in the qmail source directory. (There are other ways, but this way is, IMHO, the simplest for someone who doesn't understand the architecture of qmail.) 2. I'm using tcpserver to start qmail and it seems to work. But there is a little thing I don't understand. On my FreeBSD 4.2 RELEASE machine I added the follwing configuration file into /etc/rc: /usr/local/bin/tcpserver -p -x /etc/tcp.smtp.cdb -u 82 -g 81 0 smtp \ /var/qmail/bin/smtpd Wow. It's strongly recommended, even in the file itself, not to play with /etc/rc. If you want to stick with files in /etc, use rc.local. I personally am now a big fan of /usr/local/etc/rc.d/*.sh -- FreeBSD now runs any files matching that specification at boot time. I use this method to start svscan, which then starts all the tcpserver processes (qmail-smtpd, qmail-pop3d, et al) for me* -- see Life With qmail: http://www.lifewithqmail.org/ and modify the 'run' scripts to taste. * Of course, it also starts dnscache, tinydns, axfrdns, and publicfile. I love DJBware. ;) After I added this line I rebooted the machine and it stopped right at the point where it was supposed to excute the line above. It didn't crash and I was able to talk to my server on port 25 it just didn't proccess the rest of the startup scripts. Because it looked the way that /var/qmail/bin/qmail-smtpd was waiting on stdin I added an ampersand at the and of the line so /bin/sh would start it as a background process. It seems to work that way but I'm confused because I read twice in two different docs that no ampersand is needed. At least it wasn't printed there. Can anyone enlighten me? -Moritz See above -- if you're going to run tcpserver, I highly recommend that you go whole hog and use daemontools to bring stuff up as well. Can't wait until openssh has an option that runs under daemontools without too much extra overhead! -- Greg White Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F. Kennedy
[OT] RE: tcpserver / queue cleaning
I'm using /etc/rc to start the tcpserver process because I read it in Running qmail; Richard Blum. To quote him on that: Once the qmail-smtpd boot script is created, it must be run from a system boot script. On a FreeBSD system this can be the /etc/rc script. Because the qmail-smtpd script just contained the tcpserver line I thought it's no big deal to write it directly into /etc/rc. Anyways, I or the book, one of us sucks. Maybe both. But thanks for the hint I'm going to read Life with qmail and I'm removing my entries from /etc/rc. -Moritz -Original Message- From: Greg White [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 04, 2001 8:47 PM To: qmail Subject: Re: tcpserver / queue cleaning On Wed, Jul 04, 2001 at 08:26:45PM +0200, Moritz Schmitt wrote: Hello, I got too questions about qmail and tcpserver. If the tcpserver program is off topic here, please advise me to the right list. 1. How can I delete every message existing in the queue? If this isn't a FAQ, it should be. Stop all qmail processes. Have the compile qmail source handy. 'rm -rf /var/qmail/queue', and 'make setup check' in the qmail source directory. (There are other ways, but this way is, IMHO, the simplest for someone who doesn't understand the architecture of qmail.) 2. I'm using tcpserver to start qmail and it seems to work. But there is a little thing I don't understand. On my FreeBSD 4.2 RELEASE machine I added the follwing configuration file into /etc/rc: /usr/local/bin/tcpserver -p -x /etc/tcp.smtp.cdb -u 82 -g 81 0 smtp \ /var/qmail/bin/smtpd Wow. It's strongly recommended, even in the file itself, not to play with /etc/rc. If you want to stick with files in /etc, use rc.local. I personally am now a big fan of /usr/local/etc/rc.d/*.sh -- FreeBSD now runs any files matching that specification at boot time. I use this method to start svscan, which then starts all the tcpserver processes (qmail-smtpd, qmail-pop3d, et al) for me* -- see Life With qmail: http://www.lifewithqmail.org/ and modify the 'run' scripts to taste. * Of course, it also starts dnscache, tinydns, axfrdns, and publicfile. I love DJBware. ;) After I added this line I rebooted the machine and it stopped right at the point where it was supposed to excute the line above. It didn't crash and I was able to talk to my server on port 25 it just didn't proccess the rest of the startup scripts. Because it looked the way that /var/qmail/bin/qmail-smtpd was waiting on stdin I added an ampersand at the and of the line so /bin/sh would start it as a background process. It seems to work that way but I'm confused because I read twice in two different docs that no ampersand is needed. At least it wasn't printed there. Can anyone enlighten me? -Moritz See above -- if you're going to run tcpserver, I highly recommend that you go whole hog and use daemontools to bring stuff up as well. Can't wait until openssh has an option that runs under daemontools without too much extra overhead! -- Greg White Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F. Kennedy
Re: [OT] RE: tcpserver / queue cleaning
Moritz Schmitt [EMAIL PROTECTED] wrote: I'm using /etc/rc to start the tcpserver process because I read it in Running qmail; Richard Blum. To quote him on that: Once the qmail-smtpd boot script is created, it must be run from a system boot script. On a FreeBSD system this can be the /etc/rc script. Because the qmail-smtpd script just contained the tcpserver line I thought it's no big deal to write it directly into /etc/rc. It is a big deal, if you don't understand what you're putting in there. Anyways, I or the book, one of us sucks. Maybe both. No. You're a newbie. You don't suck. The book, from the opinions of knowledgable qmail experts on this list, appears to suck quite badly. The advice you quote above is further evidence of this. But thanks for the hint I'm going to read Life with qmail and I'm removing my entries from /etc/rc. Yes, Life with qmail is definitely the way to go for most novices. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
Q: Queue-limit (was Re: Discarding mailer_daemon mail....)
Greg Moeller wrote Hmmm, ok, what would a good split be for 7-10 in the queue? BTW... I wonder if there are any limits on how many files can be in the queue besides inodes and disk size? -- Bernhard Graf [EMAIL PROTECTED]
Re: Q: Queue-limit (was Re: Discarding mailer_daemon mail....)
On Tue, Jun 19, 2001 at 07:13:42PM +0200, Bernhard Graf allegedly wrote: Greg Moeller wrote Hmmm, ok, what would a good split be for 7-10 in the queue? BTW... I wonder if there are any limits on how many files can be in the queue besides inodes and disk size? Memory. Read THOUGHTS regarding 'qmail-send uses 8 bytes... Regards.
Queue corrupted???
Hi all: The other day a spammer found an open relay in one of our customers' machines (insert here rant about Windows lusers who run toy mail servers in their computers without knowing how to configure them properly), and sent around 5000 mails. Said customer's machine dumped them on my mail server... and of course, since it was allowed to relay, our mail server started to send them out. WHen I arrived in the morning, I had more than 1500 mails in my queue. Anyway, I stop qmail-send (kill (PID of qmail-send) + killall qmail-remote), and start deleting spam from the queue using qmHandle (the Perl script listed in qmail.org). I had previously done also a killall tcpserver to avoid more mails being added to the queue by SMTP while I was messing with it. However, I can't finish deleting all of the spam before users start complaining, so I start qmail again, thinking well, I'll delete the rest later... and here is where the problem with the queue starts. When I later stopped qmail again to delete more spam, I started finding weird inconsistencies. For example, qmail-read would show a piece of junk-mail, but when I tried to view or delete it using qmHandle, it would say that it didn't exist. Or I would go to queue/info and see a certain file (say, 880099), and when I tried to view it using qmHandle, it would say again that it didn't exist. Not only that, but some users started receiving bounce messages for users to which they had NOT send mails, almost as if qmail had mixed up the recipients for the junk mails and the regular ones. For example, here is one reported to me: From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 13, 2001 1:31 PM Subject: failure notice Hi. This is the qmail-send program at mail.ddnet.es. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: 64.136.25.17 does not like recipient. Remote host said: 550 [EMAIL PROTECTED] Account Inactive Giving up on 64.136.25.17. [EMAIL PROTECTED]: 204.127.134.17 does not like recipient. Remote host said: 550 Invalid recipient: [EMAIL PROTECTED] Giving up on 204.127.134.17. [EMAIL PROTECTED]: 64.4.49.7 does not like recipient. Remote host said: 550 Requested action not taken:user account inactive Giving up on 64.4.49.7. [EMAIL PROTECTED]: 64.94.242.241 does not like recipient. Remote host said: 553 5.7.1 No such mailbox.702.776N01e: [EMAIL PROTECTED] Giving up on 64.94.242.241. [EMAIL PROTECTED]: 204.49.54.3 does not like recipient. Remote host said: 550 Unknown user. Giving up on 204.49.54.3. [EMAIL PROTECTED]: 64.4.56.135 does not like recipient. Remote host said: 550 Requested action not taken:user account inactive Giving up on 64.4.56.135. [EMAIL PROTECTED]: 207.217.120.79 does not like recipient. Remote host said: 550 [EMAIL PROTECTED] unknown Giving up on 207.217.120.79. [EMAIL PROTECTED]: 64.4.55.135 does not like recipient. Remote host said: 550 Requested action not taken: mailbox unavailable Giving up on 64.4.55.135. [EMAIL PROTECTED]: 207.217.120.79 does not like recipient. Remote host said: 550 [EMAIL PROTECTED] unknown Giving up on 207.217.120.79. [EMAIL PROTECTED]: 199.221.118.14 does not like recipient. Remote host said: 550 RCPT TO:[EMAIL PROTECTED] User unknown Giving up on 199.221.118.14. [EMAIL PROTECTED]: 206.40.44.3 does not like recipient. Remote host said: 550 5.1.1 [EMAIL PROTECTED]... User unknown Giving up on 206.40.44.3. [EMAIL PROTECTED]: 206.13.28.142 does not like recipient. Remote host said: 550 5.1.1 unknown or illegal alias: [EMAIL PROTECTED] Giving up on 206.13.28.142. [EMAIL PROTECTED]: 207.46.181.13 does not like recipient. Remote host said: 550 5.1.1 [EMAIL PROTECTED] User unknown Giving up on 207.46.181.13. [EMAIL PROTECTED]: 12.10.123.8 does not like recipient. Remote host said: 550 Relaying is prohibited Giving up on 12.10.123.8. [EMAIL PROTECTED]: 207.217.120.79 does not like recipient. Remote host said: 550 [EMAIL PROTECTED] unknown Giving up on 207.217.120.79. [EMAIL PROTECTED]: 207.46.181.13 does not like recipient. Remote host said: 550 5.1.1 [EMAIL PROTECTED] User unknown Giving up on 207.46.181.13. [EMAIL PROTECTED]: 207.55.158.20 does not like recipient. Remote host said: 550 Invalid recipient [EMAIL PROTECTED] Giving up on 207.55.158.20. [EMAIL PROTECTED]: 207.217.120.29 does not like recipient. Remote host said: 550 [EMAIL PROTECTED] unknown Giving up on 207.217.120.29. [EMAIL PROTECTED]: 204.216.215.3 does not like recipient. Remote host said: 550 5.1.1 [EMAIL PROTECTED]... User unknown Giving up on 204.216.215.3. [EMAIL PROTECTED]: 64.4.42.7 does not like recipient. Remote host said: 550 Requested action not taken:user account inactive Giving up on 64.4.42.7. [EMAIL PROTECTED]: 63.221.191.10 does not like recipient. Remote host said: 550 5.1.1
Re: Queue corrupted???
Now *this* is a bug report. I don't have to go back and ask you questions because you've told us what happened, and what you expected to see happen, and what you did and what happened when you did it. Good job, Paulo! Muy bien! Paulo Jan writes: When I later stopped qmail again to delete more spam, I started finding weird inconsistencies. For example, qmail-read would show a piece of junk-mail, but when I tried to view or delete it using qmHandle, it would say that it didn't exist. Or I would go to queue/info and see a certain file (say, 880099), and when I tried to view it using qmHandle, it would say again that it didn't exist. That sounds like a problem in qmHandle. If you can see the file but qmHandle doesn't know about it, that's a problem right there. Not only that, but some users started receiving bounce messages for users to which they had NOT send mails, almost as if qmail had mixed up the recipients for the junk mails and the regular ones. This can happen if you change the queue files while qmail-send is running. It can also happen if the queue is inconsistent. qmail-queue relies on the inode of the message file matching the name of the message file. If it doesn't, then you can get a new message arriving which ends up with the envelope sender and recipients for an existing message. Try running qmail-qsanity: http://qmail.org/qmail-qsanity-0.52 qsanity doesn't fix anything, but it will tell you about problems in your queue data structure. After seeing this, I stopped qmail and ran queue-fix, but the problem still persisted for 2 or 3 days, until the queue ran out of spam (either because they bounced or because we deleted them by hand). My question is: has anbody seen this before? I have a hard time believing that qmail's queue could have been corrupted by just 1500 mails, and I haven't touched the queue by hand in any moment (other than to view (that is, *read*) some files). It certainly looks very odd to me... Well, as you say, qmHandle was confused, so maybe there's a bug in qmHandle? -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | #exclude windows.h Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
