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"
