qmail Digest 1 Feb 1999 11:00:17 -0000 Issue 538
Topics (messages 21171 through 21199):
syslog.mail
21171 by: [EMAIL PROTECTED] (James R Grinter)
21177 by: Peter van Dijk <[EMAIL PROTECTED]>
21183 by: "Eric Dahnke" <[EMAIL PROTECTED]>
21197 by: Tommi Virtanen <[EMAIL PROTECTED]>
Email addresses with .'s in
21172 by: root <[EMAIL PROTECTED]>
21174 by: Russell Nelson <[EMAIL PROTECTED]>
21175 by: Mate Wierdl <[EMAIL PROTECTED]>
21179 by: Peter van Dijk <[EMAIL PROTECTED]>
21181 by: Russell Nelson <[EMAIL PROTECTED]>
21192 by: Peter van Dijk <[EMAIL PROTECTED]>
21199 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
On a private (192.168.x.y) network Qmail host => Sendmail host?
21173 by: Dustin Marquess <[EMAIL PROTECTED]>
21182 by: "Justin M. Streiner" <[EMAIL PROTECTED]>
xdelay and multi-queue'ing
21176 by: Peter van Dijk <[EMAIL PROTECTED]>
accustamp is a zombie
21178 by: Peter van Dijk <[EMAIL PROTECTED]>
21180 by: Peter Gradwell <[EMAIL PROTECTED]>
Performance
21184 by: David Villeger <[EMAIL PROTECTED]>
21185 by: Mark Delany <[EMAIL PROTECTED]>
21186 by: Matthew Kirkwood <[EMAIL PROTECTED]>
21187 by: David Villeger <[EMAIL PROTECTED]>
21188 by: [EMAIL PROTECTED]
21189 by: David Villeger <[EMAIL PROTECTED]>
21191 by: Mark Delany <[EMAIL PROTECTED]>
21194 by: Russell Nelson <[EMAIL PROTECTED]>
21198 by: [EMAIL PROTECTED] (Lorens Kockum)
Mangling From: headers by recipient domain
21190 by: Keith Burdis <[EMAIL PROTECTED]>
21193 by: Mate Wierdl <[EMAIL PROTECTED]>
On a private (192.168.x.y) network Qmail host => Sendmail host? - Success
21195 by: "Philip Rhoades" <[EMAIL PROTECTED]>
Return-path header
21196 by: [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]
----------------------------------------------------------------------
Peter van Dijk <[EMAIL PROTECTED]> writes:
> > How can I move the syslog.mail file and make a new one safely?
>
> mv syslog.mail syslog.mail.1
you must also create the syslog.mail file, before restarting
syslogd. It will only append to an existing file.
James.
On Sun, Jan 31, 1999 at 01:13:54PM +0000, James R Grinter wrote:
> Peter van Dijk <[EMAIL PROTECTED]> writes:
> > > How can I move the syslog.mail file and make a new one safely?
> >
> > mv syslog.mail syslog.mail.1
>
> you must also create the syslog.mail file, before restarting
> syslogd. It will only append to an existing file.
Not with the default linux syslogd.
Greetz, Peter.
--
.| Peter van Dijk
.| [EMAIL PROTECTED]
I believe fairly standard practice for syslog files is to do a cp to a
new file
cp maillog maillog.bak
then
cp /dev/null /var/log/maillog
That is what I do at least.
chau - eric
>> Peter van Dijk <[EMAIL PROTECTED]> writes:
>> > > How can I move the syslog.mail file and make a new one safely?
>> >
>> > mv syslog.mail syslog.mail.1
>>
>> you must also create the syslog.mail file, before restarting
>> syslogd. It will only append to an existing file.
>
>Not with the default linux syslogd.
>
>Greetz, Peter.
>--
>.| Peter van Dijk
>.| [EMAIL PROTECTED]
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
On Sun, Jan 31, 1999 at 11:44:21AM -0800, Eric Dahnke wrote:
> I believe fairly standard practice for syslog files is to do a cp to a
> new file
>
> cp maillog maillog.bak
>
> then
>
> cp /dev/null /var/log/maillog
>
> That is what I do at least.
Bzzzt. You lost. You miss everything logged between
the first and the last cp.
mv maillog maillog.0
touch maillog
chmod maillog # if necessary
kill -HUP `pidof syslogd`
--
foo | +358505486010 | [EMAIL PROTECTED] | mknod /dev/trash c 1 3
HELP!
How do i get qmail to route email address's with .'s in, i.e.
user@domain userid1
user.surname@domain userid2
Sendmail used to route these to the individual addresses, i.e. userid2 or
userid1, with qmail all email destined for userid2 goes into userid1's
account.
Is there a solution
Gavin
root writes:
> How do i get qmail to route email address's with .'s in, i.e.
>
> user@domain userid1
> user.surname@domain userid2
echo 'userid2' > ~alias/.qmail-user:surname
qmail replaces dots with colons when searching for a .qmail file.
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
What is your concrete example? Are you trying to use .qmail files?
To route
user.surname@domain userid2
You can put
&userid2
in ~alias/.qmail-user:surname. So use colon instead of dot.
Mate
On Sun, Jan 31, 1999 at 02:31:44PM -0000, Russell Nelson wrote:
> root writes:
> > How do i get qmail to route email address's with .'s in, i.e.
> >
> > user@domain userid1
> > user.surname@domain userid2
>
> echo 'userid2' > ~alias/.qmail-user:surname
>
> qmail replaces dots with colons when searching for a .qmail file.
Why is that, anyway?
Greetz, Peter.
--
.| Peter van Dijk
.| [EMAIL PROTECTED]
Peter van Dijk writes:
> On Sun, Jan 31, 1999 at 02:31:44PM -0000, Russell Nelson wrote:
> > qmail replaces dots with colons when searching for a .qmail file.
>
> Why is that, anyway?
It's a security measure, to keep people from sending mail to
user-../../etc/passwd (e.g.). Qmail-local used to replace slashes
with colons, until it was seen that slashes were useful to allow
subdirectories, so now the dots are replaced with colons.
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
On Sun, Jan 31, 1999 at 06:51:36PM -0000, Russell Nelson wrote:
> Peter van Dijk writes:
> > On Sun, Jan 31, 1999 at 02:31:44PM -0000, Russell Nelson wrote:
> > > qmail replaces dots with colons when searching for a .qmail file.
> >
> > Why is that, anyway?
>
> It's a security measure, to keep people from sending mail to
> user-../../etc/passwd (e.g.). Qmail-local used to replace slashes
> with colons, until it was seen that slashes were useful to allow
> subdirectories, so now the dots are replaced with colons.
I understand the security part (feeling stupid today after reconfigging one win95
machine just over 15 times. I never knew that I could actually feel stress...).
But where would you use directories in that? Creating .qmail-bla/duh and mailing to
peter-bla/duh doesn't really do the job.
Hmm.. too little caffeine here.
Greetz, Peter.
--
.| Peter van Dijk
.| [EMAIL PROTECTED]
- Peter van Dijk <[EMAIL PROTECTED]>:
| On Sun, Jan 31, 1999 at 06:51:36PM -0000, Russell Nelson wrote:
| >
| > It's a security measure, to keep people from sending mail to
| > user-../../etc/passwd (e.g.). Qmail-local used to replace slashes
| > with colons, until it was seen that slashes were useful to allow
| > subdirectories, so now the dots are replaced with colons.
|
| I understand the security part (feeling stupid today after
| reconfigging one win95 machine just over 15 times. I never knew that
| I could actually feel stress...).
|
| But where would you use directories in that? Creating .qmail-bla/duh
| and mailing to peter-bla/duh doesn't really do the job.
No, but at the time Russell is talking about, dots were *not*
replaced. There are only three reasonable ways to foil the /../
attack, and those are (1) replace slashes by something else, (2)
replace dots by something else, and (3) recognize the substring /../
and either replace it by something else or bounce the mail.
Personally, I think I would prefer (3) because it confuses users less,
but OTOH (1) and (2) are simpler to implement, whick makes it less
likely for a security bug to creep in.
| Hmm.. too little caffeine here.
I hope you know the remedy for that.
- Harald
On Sun, 31 Jan 1999, Philip Rhoades wrote:
> 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?
Yes.. there's probably CNAME error messages for a reason.
Can you lookup the other machines via DNS? Qmail uses DNS only, no
/etc/hosts.
-Dustin
On Sun, 31 Jan 1999, Philip Rhoades wrote:
> 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.
Do you have a DNS server running on this private network, or failing that
are running a NAT gateway or firewall to an external network?
jms
On Sat, Jan 30, 1999 at 03:17:42PM -0800, [EMAIL PROTECTED] wrote:
> 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.
qmail still has no per-host concurrency (not by default anyway). Doing what you
suggest is _another_ step. I think per-host concurrency should have intelligence like
the deferral handling: wait longer if last success was long ago (you get my point :).
That's what you're saying, actually :)
Greetz, Peter.
--
.| Peter van Dijk
.| [EMAIL PROTECTED]
On Sun, Jan 31, 1999 at 10:27:43AM +0000, Peter Gradwell wrote:
> 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 &
Is setuser in the PATH at that moment? Try putting /usr/local/bin/ before setuser
too.
Greetz, Peter.
--
.| Peter van Dijk
.| [EMAIL PROTECTED]
At 4:08 pm +0100 31/1/99,the wonderful Peter van Dijk wrote:
>> 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 &
>
>Is setuser in the PATH at that moment? Try putting /usr/local/bin/ before
>setuser
>too.
ah, brilliant.
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"
Hello.
I'd love some suggestions, advice, comments,...
First:
- I am not a spammer. The email I send are _not_ unsolicited.
- I do send several millions emails a month. I want to send 20,000 unique
emails per hour per machine. Each email is unique but program generated
(e.g. personalized news update).
- I use Solaris 2.6 on mono processor PCI-based Sun machines, 128 megs of
ram, lots of disk space, as much network bandwidth as I need.
My questions:
- event though the concurrencyremote is set to 120, the number of
qmail-remote never gets higher than 40. If some other program runs at the
same time (like a bouncer handler, or a mail generator), the number of
qmail-remote drops to 5! What should I increase to bump it up? (memory,
cpu,...)?
- The todo and intd directories get very big under high load. On one
machine, I've seen it reach 1.5 megs (just the directory file, not the
content of the directory). How does this impact performance?
- Because of the ease in administration, all the machines have the same
configuration. That means that one machine does different things (create
the unique emails and then call qmail to send them). Would it really make
sense to split these functions on separate machines and have them
communicate with qmqpc/qmqpd? It seems to me that with the same number of
machines, I will get the same performance overall (not just qmail).
Besides, the email creation is a sporadic process and I don't want to see
any machine idle while the others are working. Am I completely wrong?
- What is the cost of forking a qmail-inject for each email sent? What
would I gain by opening a qmqp connection to another machine and
continuously feed it with emails to send? Is this possible, or easy?
- What would I gain (in terms of performance) by getting rid of fsync in
qmail-send? What would I lose in practice (not in theory)? These machines
practically never crash.
- Is there any code modification that would significantly speed up qmail,
even at the cost of less reliability (to a reasonable extent)?
Well, that's all I can think of for now. Thanks for reading!
David.
______________________________________
David Villeger
(212) 972 2030 x34
http://www.CheetahMail.com
The Internet Email Publishing Solution
At 03:35 PM 1/31/99 -0500, David Villeger wrote:
>Hello.
>
>I'd love some suggestions, advice, comments,...
>
>First:
>
>- I am not a spammer. The email I send are _not_ unsolicited.
>- I do send several millions emails a month. I want to send 20,000 unique
>emails per hour per machine. Each email is unique but program generated
>(e.g. personalized news update).
>- I use Solaris 2.6 on mono processor PCI-based Sun machines, 128 megs of
>ram, lots of disk space, as much network bandwidth as I need.
>
>My questions:
>
>- event though the concurrencyremote is set to 120, the number of
>qmail-remote never gets higher than 40. If some other program runs at the
>same time (like a bouncer handler, or a mail generator), the number of
>qmail-remote drops to 5! What should I increase to bump it up? (memory,
>cpu,...)?
That it never gets higher than 40 is one thing, that it drops precipitously
low is another.
The former may be because of process limits inherited by qmail-rspawn at
startup. If so (and your mail logs will give a hint) then put this in your
qmail start-up script you may want to put:
ulimit -n 256
>
>- The todo and intd directories get very big under high load. On one
>machine, I've seen it reach 1.5 megs (just the directory file, not the
>content of the directory). How does this impact performance?
A lot. And deterimentally so. I'm guessing that your inject rate is
exceeding the ability of qmail-send to process the todo queue.
If these todo files are all your outbounds, I suggest that you put a delay
in your program after each 'n' injects. Say, inject 40 mails, then wait 10
seconds.
Having said that, at 20K per hour I'd be having a close look at your system
performance figures to see how your resources are going. How do you
interpret the results from iostat and vmstat?
>- What is the cost of forking a qmail-inject for each email sent? What
>would I gain by opening a qmqp connection to another machine and
>continuously feed it with emails to send? Is this possible, or easy?
You won't gain anything if the target qmqpd is a sole machine with the same
performance as qmqpc/qmqpd simple creates a network pipe to a remote
qmail-queue. If you spread this across multiple systems, well, that's a
different story.
>- What would I gain (in terms of performance) by getting rid of fsync in
>qmail-send? What would I lose in practice (not in theory)? These machines
>practically never crash.
>
>- Is there any code modification that would significantly speed up qmail,
>even at the cost of less reliability (to a reasonable extent)?
I'd be looking to see where your system is bottle-necked before assuming too
much about which strategies will make it run better.
>Well, that's all I can think of for now. Thanks for reading!
It'll be interesting to hear what you make of your performance analysis of
those systems.
Regards.
On Sun, 31 Jan 1999, David Villeger wrote:
> - event though the concurrencyremote is set to 120, the number of
> qmail-remote never gets higher than 40. If some other program runs at the
> same time (like a bouncer handler, or a mail generator), the number of
> qmail-remote drops to 5! What should I increase to bump it up? (memory,
> cpu,...)?
Your processes have probably inherited the ulimit of whoever started them.
Run "ulimit -u some_big_number" before running qmail-start (perhaps this
is a FAQ?)
> - The todo and intd directories get very big under high load. On one
> machine, I've seen it reach 1.5 megs (just the directory file, not the
> content of the directory). How does this impact performance?
Sort of depends upon the filesystem (and disk). With a decent disk and
enough RAM, you're not likely to see too many problems here from Solaris.
I'll be interested to see some qmail benchmarks on reiserfs + Linux 2.2.
> - Because of the ease in administration, all the machines have the same
> configuration. That means that one machine does different things (create
> the unique emails and then call qmail to send them). Would it really make
> sense to split these functions on separate machines and have them
> communicate with qmqpc/qmqpd? It seems to me that with the same number of
> machines, I will get the same performance overall (not just qmail).
> Besides, the email creation is a sporadic process and I don't want to see
> any machine idle while the others are working. Am I completely wrong?
Depends upon how intensive your email generation is, I guess. qmail
places a very low load on CPU.
> - What is the cost of forking a qmail-inject for each email sent? What
Under Sparc Solaris? Quite high, but not unacceptable. Under Intel
Solaris? Very high, but not quite unacceptable.
> would I gain by opening a qmqp connection to another machine and
> continuously feed it with emails to send? Is this possible, or easy?
> - What would I gain (in terms of performance) by getting rid of fsync in
> qmail-send? What would I lose in practice (not in theory)? These machines
> practically never crash.
Win: a little less disk activity.
Lose: A few mails turn out truncated, as junk or not at all. Not to dis'
your service, but I get a few "personalised" emails, and if a few went
missing, I'm sure I could cope.
> - Is there any code modification that would significantly speed up qmail,
> even at the cost of less reliability (to a reasonable extent)?
Most qmail patches add functionality, rather than increasing efficiency.
I'm not aware of any which significantly increase throughput..
Matthew.
At 09:02 PM 1/31/99 +0000, Matthew Kirkwood wrote:
>On Sun, 31 Jan 1999, David Villeger wrote:
>
>> - event though the concurrencyremote is set to 120, the number of
>> qmail-remote never gets higher than 40. If some other program runs at the
>> same time (like a bouncer handler, or a mail generator), the number of
>> qmail-remote drops to 5! What should I increase to bump it up? (memory,
>> cpu,...)?
>
>Your processes have probably inherited the ulimit of whoever started them.
>Run "ulimit -u some_big_number" before running qmail-start (perhaps this
>is a FAQ?)
Yes, I forgot to mention it and this is what puzzled me in the first place:
I have "ulimit -n 512" in my startup script (I got the 512 number from some
FAQ that mentioned that this number should be twice concurrencyremote + 5,
I think).
Thanks anyway for the quick response.
David.
______________________________________
David Villeger
(212) 972 2030 x34
http://www.CheetahMail.com
The Internet Email Publishing Solution
On Sun, Jan 31, 1999 at 03:35:26PM -0500, David Villeger wrote:
>
> My questions:
>
> - event though the concurrencyremote is set to 120, the number of
> qmail-remote never gets higher than 40. If some other program runs at the
> same time (like a bouncer handler, or a mail generator), the number of
> qmail-remote drops to 5! What should I increase to bump it up? (memory,
> cpu,...)?
>
You need to do a few more tests, but the culprit is generally disk
io.
before a batch of mail injections, run:
iostat 1 >> /tmp/io.tmp
And see the amount of time spend in cpu wait.
Hmmm.. the solaris "top" will also report this if you're running it
during the "slowdown" period.
> - The todo and intd directories get very big under high load. On one
> machine, I've seen it reach 1.5 megs (just the directory file, not the
> content of the directory). How does this impact performance?
Slows it down. :)
Some things to try:
1) Buy a -new- scsi hdd for the exclusive use of the /var/qmail/queue
You want one of the latest, fastest, cool running, fast seeking
things from Seagate. The 4GB size (smallest you can find) will
run $500 for the 10k rpm Cheetahs and $400 for the 7.2k rpm Barracudas.
2) Upgrade the OS to Solaris 7, which comes with Sun's version of a
journaling file system, ufs logging.
--
John White
[EMAIL PROTECTED]
PGP Public Key: http://www.triceratops.com/john/public-key.pgp
At 07:57 AM 2/1/99 +1100, Mark Delany wrote:
>At 03:35 PM 1/31/99 -0500, David Villeger wrote:
>>- event though the concurrencyremote is set to 120, the number of
>>qmail-remote never gets higher than 40. If some other program runs at the
>>same time (like a bouncer handler, or a mail generator), the number of
>>qmail-remote drops to 5! What should I increase to bump it up? (memory,
>>cpu,...)?
>
[...]
> ulimit -n 256
Yes, I know, I had "ulimit -n 512" in /etc/init.d/qmail (where I start
qmail-send).
>>- The todo and intd directories get very big under high load. On one
>>machine, I've seen it reach 1.5 megs (just the directory file, not the
>>content of the directory). How does this impact performance?
>
>A lot. And deterimentally so. I'm guessing that your inject rate is
>exceeding the ability of qmail-send to process the todo queue.
That's true. But so what? Shouldn't qmail just queue these messages?
What is the function of these directory anyway (todo, intd, mess, ...). I
couldn't find any info on this. Why don't todo and intd have the same
multidirectory structure as remote,...?
>If these todo files are all your outbounds, I suggest that you put a delay
>in your program after each 'n' injects. Say, inject 40 mails, then wait 10
>seconds.
Interesting suggestion.
However, I'd like the program(s) to finish as soon as possible so that
qmail can do its job with no interference (remember, the number of
qmail-remote processes drops to 5 when these programs run).
I'll try your idea to see if it makes a difference.
>Having said that, at 20K per hour I'd be having a close look at your system
>performance figures to see how your resources are going. How do you
>interpret the results from iostat and vmstat?
The disks seem OK.
Memory is certainely an issue. Each qmail-remote eats 1.5 megs (virtual
mem, 1 megs resident) and there is only 128 megs on the machines.
>It'll be interesting to hear what you make of your performance analysis of
>those systems.
I'll keep you posted. Thanks Mark.
Regards,
David.
______________________________________
David Villeger
(212) 972 2030 x34
http://www.CheetahMail.com
The Internet Email Publishing Solution
>>>- The todo and intd directories get very big under high load. On one
>>>machine, I've seen it reach 1.5 megs (just the directory file, not the
>>>content of the directory). How does this impact performance?
>>
>>A lot. And deterimentally so. I'm guessing that your inject rate is
>>exceeding the ability of qmail-send to process the todo queue.
>
>That's true. But so what? Shouldn't qmail just queue these messages?
Correct. But mails are "staged" in 'todo' by qmail-queue. qmail-send moves
these mails into the queue-proper when it gets a chance. If todo grows
large, it's a sure sign that qmail-send isn't getting enough resources to
move these mails.
>What is the function of these directory anyway (todo, intd, mess, ...). I
>couldn't find any info on this. Why don't todo and intd have the same
>multidirectory structure as remote,...?
The INTERNALS doc explains how mails are moved into the queue, along with
plenty of discussion in the mail archives I suspect.
>>Having said that, at 20K per hour I'd be having a close look at your system
>>performance figures to see how your resources are going. How do you
>>interpret the results from iostat and vmstat?
>
>The disks seem OK.
How many tps? How close is that to the max for the disk(s) in question?
>Memory is certainely an issue. Each qmail-remote eats 1.5 megs (virtual
>mem, 1 megs resident) and there is only 128 megs on the machines.
How much paging? If any, is it to the same disk as the queue?
Certainly you want to make sure you have sufficient memory. What did vmstat
tell you about your paging?
Regards.
David Villeger writes:
> That's true. But so what? Shouldn't qmail just queue these messages?
That's what it's doing. That *is* the entry point to the queue. It's
where qmail-queue dumps new messages.
> What is the function of these directory anyway (todo, intd, mess, ...). I
> couldn't find any info on this. Why don't todo and intd have the same
> multidirectory structure as remote,...?
Don't know. I have a patch on www.qmail.org to fix it. I think that,
in theory anyway, todo and intd are intended to be small holding
areas. Essentially they're there so that qmail-send knows what mail
it has and hasn't routed. Dan let drop a hint that in qmail 2.0,
there won't be a distinction between local and remote mail, so perhaps
he's fixing this problem?
Where it kills you is when qmail-queue dumps mail faster than
qmail-send can take it out, or when qmail-send isn't running.
> The disks seem OK. Memory is certainely an issue. Each
> qmail-remote eats 1.5 megs (virtual mem, 1 megs resident) and there
> is only 128 megs on the machines.
Wow. That's a lot. On a customer's Linux server, it's only 800 and
368. I'd heard that sparc binaries are bigger, but 2X bigger sounds
like a lot. Sounds like you need a machine with *lots* more memory.
Are you *ever* swapping to disk? Add memory until it stops swapping.
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
On the qmail list [EMAIL PROTECTED] wrote:
>David Villeger writes:
> > The disks seem OK. Memory is certainely an issue. Each
> > qmail-remote eats 1.5 megs (virtual mem, 1 megs resident) and there
> > is only 128 megs on the machines.
>
>Wow. That's a lot.
David, you did compile these on your machines, didn't you?
Make sure the binaries are stripped.
--
#include <std_disclaim.h> Lorens Kockum
On Fri 1999-01-29 (22:33), Paul Halliday wrote:
> Hi folks,
[snip]
> What's the best strategy to approach this with qmail?
>
> Thus far I'd decided on a virtualdomain as follows:
>
> companydomain:alias-companydomain
>
> and in ~alias/.qmail-company-domain:
>
> | preline -d -f swap_from | qmail-remote relay.ourdomain $SENDER
> $RECIPIENT
>
> 'swap_from' is obviously a program to explicitely change the From: field
> to the company required one one.
I think what you need is new-inject from Dan's mess822 package. It rewrites
mail addreses according to rules that you specify and then reinserts the
message into the queue. You can get the package from:
http://pobox.com/~djb/software.html
Take a look at the new-inject(1) and rewriting(5) man pages. I've not used it
before but as I understand it you'd put:
| newinject
in ~alias/.qmail-company-domain, putting the rewriting rules in
control/rewrite.
> This solution works OK in normal circumstances but is not at all robust
> because if the relay is down then the mail gets lost. It seems as though
> qmail-send isn't designed to listen to what a virtualdomain returns - it
> just deletes it from the queue and assumes the piped programs will know
> what to do with it(?)
I think reinserting the rewritten message into the queue will solve the
problem of the remote relay not being available.
> I hope someone can tell me that I'm doing it all wrong and that there's a
> simpler and more robust way of solving this header re-writing problem
> efficiently!
The mess822 package is even cooler than I though it was :-)
> Many thanks in advance,
> Paul
- Keith
--
Keith Burdis - MSc (Com Sci) - Rhodes University, South Africa
Email : [EMAIL PROTECTED]
WWW : http://www.rucus.ru.ac.za/~keith/
IRC : Panthras JAPH
"Any technology sufficiently advanced is indistinguishable from a perl script"
Standard disclaimer.
---
| newinject
in ~alias/.qmail-company-domain, putting the rewriting rules in
control/rewrite.
Typo: it is `|new-inject'. In any case, I think the problem somehow
is that if he just does what you suggest, the message would again be
sent to companydomain, that is back to the local machine (since the
companydomain virtualdomain points there).
The message the qmail server gets is just simply relayed to
relay.ourdomain and now he wants to rewrite the From: header.
Mate
Thanks to John White and others who replied.
Of course the answer was simple - just get the syntax right in smtproutes ie
nsw.chu.com.au:192.168.0.100
- for a private domain (no DNS) to forward from one machine to another.
qmail is looking good!
Regards,
Phil.
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]
Harald Hanche-Olsen <[EMAIL PROTECTED]> writes on 26 January 1999 at 23:34:25 +0100
> - [EMAIL PROTECTED]:
>
> | I don't seem to be getting a return-path header added to messages
> | coming in over the net.
>
> It is added on maildir and mailbox delivery. When delivering to a
> program, it is not added automatically, but is available in an
> environment variable ($RPLINE) for the program to use if it so wishes.
> When forwarding, it is (of course) not added, but the envelope sender
> is preserved, so it can be duly noted on final delivery.
>
> If you find any departures from these rules, let us know the details.
Nope, don't seem to have. Thanks.
--
David Dyer-Bennet [EMAIL PROTECTED]
http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon
http://ouroboros.demesne.com/ The Ouroboros Bookworms
Join the 20th century before it's too late!
