qmail Digest 31 Jan 1999 11:00:05 -0000 Issue 537 Topics (messages 21161 through 21170): Expected failures/deferrals counts 21161 by: Jon Scarbrough <[EMAIL PROTECTED]> 21163 by: "Fred Lindberg" <[EMAIL PROTECTED]> I need to resign from the list for a while 21162 by: Carl Waring <[EMAIL PROTECTED]> 21168 by: Scott Schwartz <[EMAIL PROTECTED]> xdelay and multi-queue'ing 21164 by: [EMAIL PROTECTED] Q re cyrus imapd, qmail 1.03 and procmail (RH 5.2) 21165 by: "Heinz Wittenbecher" <[EMAIL PROTECTED]> 21166 by: Vern Hart <[EMAIL PROTECTED]> 21167 by: "Heinz Wittenbecher" <[EMAIL PROTECTED]> On a private (192.168.x.y) network Qmail host => Sendmail host? 21169 by: "Philip Rhoades" <[EMAIL PROTECTED]> accustamp is a zombie 21170 by: Peter Gradwell <[EMAIL PROTECTED]> Administrivia: To subscribe to the digest, e-mail: [EMAIL PROTECTED] To unsubscribe from the digest, e-mail: [EMAIL PROTECTED] To post to the list, e-mail: [EMAIL PROTECTED] ----------------------------------------------------------------------
What have people been experiencing for their daily count of deferrals and failures on their qmail host that delivers mail to/from the Internet? As I look at the reasons for these counts, it makes me wonder what other people's mail hosts are using. We are averaging around 8000 messages per day to/from the Internet (much more internally) and normally have 150-200 deferrals and 200-300 failures. Do other's see the same results from your mail relay host? Just wanted to make sure we are experiencing "normal" behavior. Thanks. Jon Scarbrough Oakton Community College Des Plaines, IL [EMAIL PROTECTED]
On Sat, 30 Jan 1999 10:14:27 -0600, Jon Scarbrough wrote: >what other people's mail hosts are using. We are averaging around 8000 >messages per day to/from the Internet (much more internally) and >normally have 150-200 deferrals and 200-300 failures. Do other's see the It's extremely hard to tell, and depends on the _reason_ for deferrals/failures: If you run mailing lists that do not have bounce handling, you'll see quite a lot of failures due to bad addresses. If you run e.g. ezmlm which does handle bounces, you'll see much less. If you send "bulk mail" you'll see a lot of failures - the harvested address lists are often of low quality. If you have your own/local DNS, you'll see few lookup failures. If you don't and the connection is variable, you'll see deferrals from this. If you deliver mailing lists with many messages to hosts that can't handle it, you'll see deferrals from the recipient host ("can't fork - out of memory", etc). -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Help, I've tried to resign but it is not having it, anybody ant ideas ? thanks cw
Carl Waring <[EMAIL PROTECTED]> writes: | Help, | I've tried to resign but it is not having it, anybody ant ideas ? What do you mean 'not having it'? What resulted from following the instructions?
Over the last few weeks, I've been setting up relaying for a few high traffic lists of over 1K recipients. As that has moved into a production phase, it struck me that there is quite a demarkation when looking at xdelay stats. I grabbed the approx 10MB of logs I had on hand and ran it through qmailanalog's matchup and zrxdelay. Of the 345 recipients listed, 299 had an xdelay of less than 10. The distribution is even more interesting: 0<= x < 1 6 1<= x < 2 35 2<= x < 3 63 3<= x < 4 60 4<= x < 5 55 5<= x < 6 26 6<= x < 7 20 7<= x < 8 12 8<= x < 9 13 9<= x <10 2 What strikes me is this: I've already segmented the server's regular queue from its relay queue... My goal is to run with the lowest concurrency possible on the relay queue while maintaining decent throughput. The key to successfully lowering concurrencyremote to to eliminate hosts with a large xdelay from the queue. I don't mind having a larger concurrencyremote for a queue if the messages are being sent to hosts with a large xdelay, and have a single recipient. The goal, I guess, is to create a queue which can efficiently handle large numbers of recipients, but smooth out the bursts which characterize a large-recipient mailing list. The advantage of large concurrencies is the ability to deliver a high latency protocol quickly, right? So what if I were to have high concurrency secondary queue for the hosts which have a historically measured xdelay above N, and a lower concurrency primary queue for hosts with a historically measured xdelay below N. Anyone thought about doing something like this? I guess you'd have to abuse the loopback address. -- John White [EMAIL PROTECTED] PGP Public Key: http://www.triceratops.com/john/public-key.pgp
*This message was transferred with a trial version of CommuniGate(tm) Pro* Vern, you hit the nail right on the head. The difference between a direct delivery and one via procmail is the From, Return-Path: and Delivered-To: addition to the header. None of your suggestion worked though. Still trying various and researching docs. At least I now have a place to start. Heinz >On Fri, 29 Jan 1999, Heinz Wittenbecher wrote: >> >> In my /home/user/.qmail file I have: |/var/imap/qmail_deliver_wrapper $LOCAL >> >> This wrapper calls cyrus deliver and processed error codes. >> >> The above works fine. > >Good. > >> The problem: I want to use procmail to filter mail and have not been able to >> figure out how. >> >> Have tried .qmail with: | preline /usr/bin/procmail >> and .procmailrc with: : |/var/imap/qmail_deliver_wrapper $LOCAL > >Well, the error comes from cyrus deliver, not procmail. For some reason >deliver doesn't like the headers. preline puts a From, Return-Path:, >and Delivered-To: header at the top of the message. These are good >things, especially when using procmail to filter messages. > >I don't have cyrus's IMAP so you'll have to do some testing on your own >to figure out exactly what deliver doesn't like. > >preline has three args (man preline) that turn off these headers. Try >'preline -d' and 'preline -r' and 'preline -dr' and see if one of those >works. If it does, you could use formail (man formail) to strip out the >appropriate header. For instance to get rid of the Return-Path:, put: > > |formail -I Return-Path: | /var/imap/qmail_deliver_wrapper $LOCAL > >In your .procmailrc. Or, you could add the formail command to the >qmail_deliver_wrapper. Then you could remove the args from preline so >that those variables are available for other procmail recipes. > >Hope this helps. > >Vern >-- >\ \ / __| _ \ \ | Vern Hart > \ \ / _| / . | [EMAIL PROTECTED] > \_/ ___|_|_\_|\_| > > 1:53am up 48 day(s), 16:02, 17 users, load average: 0.07, 0.09, 0.18 > >
On Sat, 30 Jan 1999, Heinz Wittenbecher wrote: > > Vern, you hit the nail right on the head. > > The difference between a direct delivery and one via procmail is the From, > Return-Path: and Delivered-To: addition to the header. > > None of your suggestion worked though. Still trying various and researching > docs. At least I now have a place to start. I was thinking about it and the deliver program might be having a problem with the From_ header since it doesn't have a colon after the headerfield. Try, in your .procmailrc: |formail -I "From " | /var/imap/qmail_deliver_wrapper $LOCAL And see if that works. If it does, then deliver is broken and should be fixed. Cheers, Vern -- __ _____ ___ _ _ \ \ / / __| _ \ \| | Vern Hart \ V /| _|| / .` | [EMAIL PROTECTED] \_/ |___|_|_\_|\_| 7:09pm up 49 day(s), 9:19, 27 users, load average: 0.16, 0.13, 0.14
*This message was transferred with a trial version of CommuniGate(tm) Pro* <snip> >I was thinking about it and the deliver program might be having a >problem with the From_ header since it doesn't have a colon after the >headerfield. > >Try, in your .procmailrc: > > |formail -I "From " | /var/imap/qmail_deliver_wrapper $LOCAL > >And see if that works. If it does, then deliver is broken and should be >fixed. > That is indeed the culprit. Only other change I gad to make is to replace $LOCAL with actual mailbox. Minor problem, or actually no problem at all as by that time you know where it's going. Thank you very much for the help. Now I can get down to some serious testing. Heinz
Hello all, - I've had a look at the docs and list postings but still can't work it out . . I have a private network with IP adresses 192.168.x.y and have installed qmail (Linux - RH5.2) on one machine (192.168.0.101) and it delivers mail to users on this machine quite happily but I can't send mail to another machine (192.168.0.100 - RH5.1+ Sendmail). There are CNAME error messages in the log whether I have named running or not and I've been messing around with trying to set it up to use UUCP and using virtual domains etc but still doesn't work. Is there a simple fix? Thanks, Philip Rhoades Pricom Pty Limited (ACN 003 252 275) GPO Box 3411 Sydney NSW 2001 Australia Mobile: +61:0411-185-652 Fax: +61:2:9959-4909 E-mail: [EMAIL PROTECTED]
Hi, I'm being a newbie I'm slightly concerned that accustamp has turned into a zombie. Here is what ps -aux says: qmaill 105 0.0 0.0 0 0 ? Z 16:36 0:00 (accustamp <zombie>) qmailq 108 0.0 0.1 832 224 ? S 16:36 0:00 qmail-clean qmailr 107 0.0 0.1 836 232 ? S 16:36 0:00 qmail-rspawn qmails 102 0.0 0.2 876 264 ? S 16:36 0:00 qmail-send I use this in my /var/qmail/rc file: exec env - PATH="/var/qmail/bin:$PATH" \ /var/qmail/bin/qmail-start ./Mailbox /usr/local/bin/accustamp \ | setuser qmaill /usr/local/bin/cyclog -s 5000000 -n 30 /var/log/qmail & and call it with this: csh -cf '/var/qmail/rc &' Also, whilst I'm in paranoia mode, the qmail start process is listed as this: root 106 0.0 0.1 836 232 ? S 16:36 0:00 qmail-lspawn ./Mailbox and there is no mention of cyclog. Which is a shame. Also, looking at the logs, they don't seem to be terribly uptodate :-( I would like to have cyclog rotating my logs, with everything going into /var/log/qmail. Could some one confirm I've managed this? - Mail does appear to being getting through! Thanks Peter -- gradwell dot com ltd - writing the bits of the web you don't see online @ http://www.gradwell.com/ mailto:[EMAIL PROTECTED] "To look back all the time is boring. Excitement lies in tomorrow"