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.
Re: Discarding mailer_daemon mail....
On Mon, Jun 18, 2001 at 03:15:10AM -0500, Greg Moeller wrote: Is there any way to discard any Email the mailer daemon generates? Each day, the queue on our server builds up between 7000-1 Email in the queue that the mailer daemon's trying to return. (All spam, of course, the return address being bogus in some way) Consider the use of rblsmtpd[1] to block incoming spam. Or maybe some way to limit the 4 day delivery time to maybe 18-24 hours. Set /var/qmail/control/queuelifetime to control the number of seconds a message can stay in the queue (default 604800, i.e. a week). Jörgen [1] http:/cr.yp.to/ucspi-tcp/rblsmtpd.html
RE: Discarding mailer_daemon mail....
i guess you could just put # in /var/qmail/alias/.qmail-mailer-daemon -Message d'origine- De : Greg Moeller [mailto:[EMAIL PROTECTED]] Envoyé : Monday, June 18, 2001 10:15 À : [EMAIL PROTECTED] Objet : Discarding mailer_daemon mail Is there any way to discard any Email the mailer daemon generates? Each day, the queue on our server builds up between 7000-1 Email in the queue that the mailer daemon's trying to return. (All spam, of course, the return address being bogus in some way) I have to run a script every night that deletes all DAEMON mail then restart the queuing system in order to not have the queue utterly overload. (much over 15000-2 in the queue and the system bogs down trying to sort out what Email it's trying to send) If I let the system sort this out on it's own, by the time the 4 day waiting period was up there'd be 45000 Email laying about the queue. Or maybe some way to limit the 4 day delivery time to maybe 18-24 hours. (This system is only for local delivery, it does no outgoing SMTP other than trying to return Email) Greg
Re: Discarding mailer_daemon mail....
Greg Moeller [EMAIL PROTECTED] wrote: Is there any way to discard any Email the mailer daemon generates? No easy, built-in way, but then again, you shouldn't need it. queue management in qmail is completely automatic. Each day, the queue on our server builds up between 7000-1 Email in the queue that the mailer daemon's trying to return. (All spam, of course, the return address being bogus in some way) I have to run a script every night that deletes all DAEMON mail then restart the queuing system in order to not have the queue utterly overload. (much over 15000-2 in the queue and the system bogs down trying to sort out what Email it's trying to send) Your system is misconfigured. What split value are you using? What filesystem on what operating system? What kind of disk/array is the queue on? If your system bogs down because of the number of (basically inactive) messages in the queue, you've configured your system with values which are inappropriate for the load you're trying to serve. Or maybe some way to limit the 4 day delivery time to maybe 18-24 hours. qmail's default queuelifetime is 7 days. You can lower it to whatever you want. However, reducing it too far will cause mail to bounce which would otherwise be delivered successfully. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: Discarding mailer_daemon mail....
I am currently working on a dblbounce manager... Still in testing... but it's just a perl script that automatically add a sender's envelope to badmailfrom if it bounces.
Re: Discarding mailer_daemon mail....
Greg Moeller [EMAIL PROTECTED] wrote: Is there any way to discard any Email the mailer daemon generates? No easy, built-in way, but then again, you shouldn't need it. queue management in qmail is completely automatic. Your system is misconfigured. What split value are you using? What filesystem on what operating system? What kind of disk/array is the queue on? If your system bogs down because of the number of (basically inactive) messages in the queue, you've configured your system with values which are inappropriate for the load you're trying to serve. The system is dual processor Sparc 450, and an A1000 storage array. Qmail is running stock standard, as Dan intended. :) The queue was running on it's own bit of the array, multi spindle, mirrored. I've since moved it to /tmp, performance has gotten much nicer since then, almost a system crash will eat it. (see below for why I don't really care) Also, a large spam hit might eat the machine's RAM/swap(which I care about a bit more) (512 Meg of RAM, 256 of spool) The system delivers locally about 250,000 Email/day. Or maybe some way to limit the 4 day delivery time to maybe 18-24 hours. qmail's default queuelifetime is 7 days. You can lower it to whatever you want. However, reducing it too far will cause mail to bounce which would otherwise be delivered successfully. The only deliveries this server does is local, which I hope wouldn't take more than a few seconds, anything in the queue for remote delivery is a bounce. (which is why I don't care if the queue is lost, since all I lose is bounces) Charles -- Greg
Re: Discarding mailer_daemon mail....
Greg Moeller [EMAIL PROTECTED] wrote: Greg Moeller [EMAIL PROTECTED] wrote: Is there any way to discard any Email the mailer daemon generates? No easy, built-in way, but then again, you shouldn't need it. queue management in qmail is completely automatic. Your system is misconfigured. What split value are you using? What filesystem on what operating system? What kind of disk/array is the queue on? If your system bogs down because of the number of (basically inactive) messages in the queue, you've configured your system with values which are inappropriate for the load you're trying to serve. The system is dual processor Sparc 450, and an A1000 storage array. Qmail is running stock standard, as Dan intended. :) The queue was running on it's own bit of the array, multi spindle, mirrored. I've since moved it to /tmp, performance has gotten much nicer since then, almost a system crash will eat it. (see below for why I don't really care) Also, a large spam hit might eat the machine's RAM/swap(which I care about a bit more) (512 Meg of RAM, 256 of spool) The system delivers locally about 250,000 Email/day. You didn't explicitly answer my question about conf-split, but by stock standard, I'll assume it's the default of 23. This is probably too low for your system -- if you have five or ten thousand bounce messages sitting in the queue, you're getting lots of files in each directory. This is likely what causes your mail system to bog down when there's a bunch of bounce messages waiting in the queue. On a properly configured system, messages which are just sitting in the queue waiting for their next delivery attempt won't have much effect on qmail's performance. qmail's default queuelifetime is 7 days. You can lower it to whatever you want. However, reducing it too far will cause mail to bounce which would otherwise be delivered successfully. The only deliveries this server does is local, which I hope wouldn't take more than a few seconds, anything in the queue for remote delivery is a bounce. (which is why I don't care if the queue is lost, since all I lose is bounces) Once your system accepts a message from the internet, and issues a 2xx code in response to the DATA command of the SMTP conversation, you have agreed to do one of the following things: -deliver the message successfully to its final destination -return a bounce message to the envelope sender stating why delivery failed If you're discarding bounces, you're violating these conditions. That's unacceptable to many/most mail admins. Instead of trying to fix the symptoms (mail system bogs down when lots of inactive messages in the queue, most of which are bounces which have been deferred), why not fix the problem (inappropriate setup of MTA)? Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: Discarding mailer_daemon mail....
On Mon, Jun 18, 2001 at 09:48:02AM -0500, Larry M. Smith wrote: I am currently working on a dblbounce manager... Still in testing... but it's just a perl script that automatically add a sender's envelope to badmailfrom if it bounces. Er, what exactly do you think this will help? Bounces come from , so adding something to badmailfrom won't stop them. --Adam
Re: Discarding mailer_daemon mail....
You didn't explicitly answer my question about conf-split, but by stock standard, I'll assume it's the default of 23. This is probably too low for your system -- if you have five or ten thousand bounce messages sitting in the queue, you're getting lots of files in each directory. This is likely what causes your mail system to bog down when there's a bunch of bounce messages waiting in the queue. On a properly configured system, messages which are just sitting in the queue waiting for their next delivery attempt won't have much effect on qmail's performance. Hmmm, ok, what would a good split be for 7-10 in the queue? (about how many would build up over a weeks time before they started getting tossed anyway) Once your system accepts a message from the internet, and issues a 2xx code in response to the DATA command of the SMTP conversation, you have agreed to do one of the following things: -deliver the message successfully to its final destination -return a bounce message to the envelope sender stating why delivery failed If you're discarding bounces, you're violating these conditions. That's unacceptable to many/most mail admins. Instead of trying to fix the symptoms (mail system bogs down when lots of inactive messages in the queue, most of which are bounces which have been deferred), why not fix the problem (inappropriate setup of MTA)? Well, let's have a look at the queue for today. (it's past 5000 already) There seems to be a few thousand from batfly.net letting non-existant users of ours know about the fact they won the first round of something or other. (wow, so many winners, I'm impressed :) About 3500 of them trying to wing their way back home. There's a bunch from Mike at usa.com trying to sell webhosting.. (Hey, that's special, he addressed it to himself too) There's a heap from netway.com trying to sell masterCD2001. (interesting, one of the received from: lines is about 1000 '.'s Oh, here's an original bunch.. [EMAIL PROTECTED] Trying to sell a XXX biz. (what a shock :) Anyway, yeah, I'd love to care for every one of these Emails, but for some reason I just can't. These wonderful folk have utterly wasted my server too many times by firing tens of thousands of Emails at the server within an hour or two and caused me to have to work for hours trying to clean up the mess. Greg
Re: Discarding mailer_daemon mail....
Greg Moeller [EMAIL PROTECTED] wrote: You didn't explicitly answer my question about conf-split, but by stock standard, I'll assume it's the default of 23. This is probably too low for your system -- if you have five or ten thousand bounce messages sitting in the queue, you're getting lots of files in each directory. This is likely what causes your mail system to bog down when there's a bunch of bounce messages waiting in the queue. On a properly configured system, messages which are just sitting in the queue waiting for their next delivery attempt won't have much effect on qmail's performance. Hmmm, ok, what would a good split be for 7-10 in the queue? (about how many would build up over a weeks time before they started getting tossed anyway) It depends on a lot of factors, including hardware speed and filesystem efficiency. Solaris is particularly disgusting in this regard; on a high-end E4K with 15kRPM RAID, performance degrades unacceptably for an application of ours when there are as few as 200 files per directory. On low-end commodity PC hardware running on a Linux box with the ext2 filesystem, we get good performance with as many as 1000 files per directory. You said you're running on a Sun box. Try increasing conf-split so that your maximum expected queue load puts 200 files in each directory. For 10 messages, you'd need a conf-split of 500 or higher. Okay, that sounds too high to me, even. Let's try a limit of 1000 files per directory -- conf-split then has to be 100 or higher. The first prime after 100 is 101, so I'd try that. Anyway, yeah, I'd love to care for every one of these Emails, but for some reason I just can't. These wonderful folk have utterly wasted my server too many times by firing tens of thousands of Emails at the server within an hour or two and caused me to have to work for hours trying to clean up the mess. A bounce message that never gets delivered uses very little bandwidth. The only resource it's really using is some disk space and a few queue inodes. Can you spare those? Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
