Re: 39,696 emails later...

[lists]

Not sure how to filter... any suggestions?
 
crontab -l shows:
40 * * * * /usr/local/vpopmail/bin/clearopensmtp 2>&1 
> /dev/null
 
Don't see anything about clearopensmtp in 'Running 
qmail'.
 
I'll try the web...
 
Thanks,
 
Shawn

  - Original Message - 
  From: 
  James Stevens 
  To: lists 
  Sent: Wednesday, July 11, 2001 4:06 
  PM
  Subject: Re: 39,696 emails 
  later...
  
  Ok, in that case kill everything again.. Leave it 
  off for a few minutes.. 
   
  Add a filter in to block the zombie.. BTW the 
  only thing that could bring a zombie back is a cronjob 
  hinthint
   
  But if all else fails filer the darn thing till 
  it stops.
   
  --JT
  
- Original Message - 
From: 
lists 

To: James Stevens ; Qmail Mailing 
List 
Sent: Wednesday, July 11, 2001 12:00 
AM
Subject: Re: 39,696 emails 
later...

I did stop qmail and clean the queue using this 
script:
 
for i in bounce info intd local mess remote todo; do 
find /usr/local/qmail/queue/$i -type f -exec rm {} \; 
done
started qmail back up again, and the zombies came alive 
and continued to sent... 
 
Shawn

  - Original Message - 
  From: 
  James Stevens 
  To: lists ; 
  Qmail 
  Mailing List 
  Sent: Wednesday, July 11, 2001 
  3:43 PM
  Subject: Re: 39,696 emails 
  later...
  
  man, if it were me I'd kill all mail services 
  and wipe the queue clean .. Check the qmail home page there are a few 
  queue repair and fix tools avaliable... But simplest way is to rm- R queue 
  and then either (depending on how good you are) retouch the queue to set 
  it up again or the simpler approach just goto the qmail source directory 
  and re-run 'make setup check'
   
  --JT
  Network Administrator
  
- Original Message - 
From: 
lists 
To: Qmail 
Mailing List 
Sent: Tuesday, July 10, 2001 11:30 
PM
Subject: 39,696 emails 
later...

Well, my flood of mails has stopped at 
39,696.
 
My boss and people at the office were also getting the 
mails at the office domain.
I took the office mail server offline when they were 
at about 9,000 mails to prevent them from getting flooded.
After I stopped getting mails at my home address, I 
checked the sending mail server and the zombie processes had 
stopped.
I put the office machine back online and the zombie 
processes kicked in again, and the people at the office began receiving 
the mails again. Should I tell them to just hang in there until the 
total reaches 39,696?
 
The zombie processes look like this:
 
qmailr 26008  0.0  0.5   888  
568  ??  S 3:16PM   0:00.00 
qmail-remote officedom.com query-return-31053-rtagqmailr 26088  
0.0  0.5   888  568  ??  
S 3:17PM   0:00.00 qmail-remote 
officedom.com query-return-31068-rtagqmailr 26097  0.0  
0.5   888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31066-m_ayqmailr 26101  0.0  0.5   
888  568  ??  S 
3:17PM   0:00.01 qmail-remote officedom.com 
query-return-31069-m_ayqmailr 26119  0.0  0.5   
888  568  ??  S 
3:17PM   0:00.01 qmail-remote officedom.com 
query-return-31070-rtagqmailr 26122  0.0  0.5   
888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31070-m_ayqmailr 26124  0.0  0.5   
888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31070-santqmailr 26127  0.0  0.5   
888  568  ??  S 
3:17PM   0:00.01 qmail-remote officedom.com 
query-return-31070-nakaqmailr 26131  0.0  0.5   
888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31067-rtagqmailr 26132  0.0  0.5   
888  568  ??  S 
3:17PM   0:00.01 qmail-remote officedom.com 
query-return-31067-m_ayqmailr 26133  0.0  0.5   
888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31067-santqmailr 26134  0.0  0.5   
888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31067-naka
 (this list shows about half of the 
processes)
 
As I mentioned before, I have removed user 'query' in 
whose name the mails are being sent, stopped qmail, cleared the cache, 
restarted qmail and even rebooted the server itself, but these zombies 
just won't die. Anyone have an oaken stake for 
qmail-remote?
 
Thanks,
 
Shawn
 

Re: 39,696 emails later...

[lists]

I did stop qmail and clean the queue using this 
script:
 
for i in bounce info intd local mess remote todo; do find 
/usr/local/qmail/queue/$i -type f -exec rm {} \; done
started qmail back up again, and the zombies came alive and 
continued to sent... 
 
Shawn

  - Original Message - 
  From: 
  James Stevens 
  To: lists ; Qmail Mailing 
  List 
  Sent: Wednesday, July 11, 2001 3:43 
  PM
  Subject: Re: 39,696 emails 
  later...
  
  man, if it were me I'd kill all mail services and 
  wipe the queue clean .. Check the qmail home page there are a few queue repair 
  and fix tools avaliable... But simplest way is to rm- R queue and then either 
  (depending on how good you are) retouch the queue to set it up again or the 
  simpler approach just goto the qmail source directory and re-run 'make setup 
  check'
   
  --JT
  Network Administrator
  
- Original Message - 
From: 
lists 

To: Qmail Mailing 
List 
Sent: Tuesday, July 10, 2001 11:30 
PM
Subject: 39,696 emails later...

Well, my flood of mails has stopped at 
39,696.
 
My boss and people at the office were also getting the 
mails at the office domain.
I took the office mail server offline when they were at 
about 9,000 mails to prevent them from getting flooded.
After I stopped getting mails at my home address, I 
checked the sending mail server and the zombie processes had 
stopped.
I put the office machine back online and the zombie 
processes kicked in again, and the people at the office began receiving the 
mails again. Should I tell them to just hang in there until the total 
reaches 39,696?
 
The zombie processes look like this:
 
qmailr 26008  0.0  0.5   888  
568  ??  S 3:16PM   0:00.00 
qmail-remote officedom.com query-return-31053-rtagqmailr 26088  
0.0  0.5   888  568  ??  
S 3:17PM   0:00.00 qmail-remote 
officedom.com query-return-31068-rtagqmailr 26097  0.0  
0.5   888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31066-m_ayqmailr 26101  0.0  0.5   
888  568  ??  S 3:17PM   
0:00.01 qmail-remote officedom.com query-return-31069-m_ayqmailr 
26119  0.0  0.5   888  568  ??  
S 3:17PM   0:00.01 qmail-remote 
officedom.com query-return-31070-rtagqmailr 26122  0.0  
0.5   888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31070-m_ayqmailr 26124  0.0  0.5   
888  568  ??  S 3:17PM   
0:00.00 qmail-remote officedom.com query-return-31070-santqmailr 
26127  0.0  0.5   888  568  ??  
S 3:17PM   0:00.01 qmail-remote 
officedom.com query-return-31070-nakaqmailr 26131  0.0  
0.5   888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31067-rtagqmailr 26132  0.0  0.5   
888  568  ??  S 3:17PM   
0:00.01 qmail-remote officedom.com query-return-31067-m_ayqmailr 
26133  0.0  0.5   888  568  ??  
S 3:17PM   0:00.00 qmail-remote 
officedom.com query-return-31067-santqmailr 26134  0.0  
0.5   888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31067-naka
 (this list shows about half of the 
processes)
 
As I mentioned before, I have removed user 'query' in 
whose name the mails are being sent, stopped qmail, cleared the cache, 
restarted qmail and even rebooted the server itself, but these zombies just 
won't die. Anyone have an oaken stake for qmail-remote?
 
Thanks,
 
Shawn
 

39,696 emails later...

[lists]

Well, my flood of mails has stopped at 39,696.
 
My boss and people at the office were also getting the mails 
at the office domain.
I took the office mail server offline when they were at about 
9,000 mails to prevent them from getting flooded.
After I stopped getting mails at my home address, I checked 
the sending mail server and the zombie processes had stopped.
I put the office machine back online and the zombie processes 
kicked in again, and the people at the office began receiving the mails again. 
Should I tell them to just hang in there until the total reaches 
39,696?
 
The zombie processes look like this:
 
qmailr 26008  0.0  0.5   888  
568  ??  S 3:16PM   0:00.00 
qmail-remote officedom.com query-return-31053-rtagqmailr 26088  
0.0  0.5   888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31068-rtagqmailr 26097  0.0  0.5   
888  568  ??  S 3:17PM   
0:00.00 qmail-remote officedom.com query-return-31066-m_ayqmailr 26101  
0.0  0.5   888  568  ??  S 
3:17PM   0:00.01 qmail-remote officedom.com 
query-return-31069-m_ayqmailr 26119  0.0  0.5   
888  568  ??  S 3:17PM   
0:00.01 qmail-remote officedom.com query-return-31070-rtagqmailr 26122  
0.0  0.5   888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31070-m_ayqmailr 26124  0.0  0.5   
888  568  ??  S 3:17PM   
0:00.00 qmail-remote officedom.com query-return-31070-santqmailr 26127  
0.0  0.5   888  568  ??  S 
3:17PM   0:00.01 qmail-remote officedom.com 
query-return-31070-nakaqmailr 26131  0.0  0.5   
888  568  ??  S 3:17PM   
0:00.00 qmail-remote officedom.com query-return-31067-rtagqmailr 26132  
0.0  0.5   888  568  ??  S 
3:17PM   0:00.01 qmail-remote officedom.com 
query-return-31067-m_ayqmailr 26133  0.0  0.5   
888  568  ??  S 3:17PM   
0:00.00 qmail-remote officedom.com query-return-31067-santqmailr 26134  
0.0  0.5   888  568  ??  S 
3:17PM   0:00.00 qmail-remote officedom.com 
query-return-31067-naka
 (this list shows about half of the 
processes)
 
As I mentioned before, I have removed user 'query' in whose 
name the mails are being sent, stopped qmail, cleared the cache, restarted qmail 
and even rebooted the server itself, but these zombies just won't die. Anyone 
have an oaken stake for qmail-remote?
 
Thanks,
 
Shawn
 

Re: qmailr processes

[lists]

Sorry, I meant sending 'me' mail as in sending mail to my graycastle.com
address.

I originally sent an email to [EMAIL PROTECTED]
I was listed as
&[EMAIL PROTECTED]
in query's .qmail file.

I sent a test message to [EMAIL PROTECTED] , and have received over 30,000
emails to [EMAIL PROTECTED] so far.
I have deleted user query, his home directory, his .qmail file, and anything
'query-like' on the system.
I have flushed the queue, restarted qmail, rebooted.

Every time qmail starts up, I get those same qmailr processes sending mail
to [EMAIL PROTECTED] .

Shawn

- Original Message -
From: "Daniel Kelley" <[EMAIL PROTECTED]>
To: "lists" <[EMAIL PROTECTED]>
Cc: "Qmail Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, July 11, 2001 12:47 PM
Subject: Re: qmailr processes


>
> > and restarted qmail, but I still get these processes sending me mail:
> >
> > qmailr  1071  0.0  0.5   888  568  ??  S12:27PM   0:00.01
qmail-remote
> > graycastle.com query-return-28234-
> > qmailr  1080  0.0  0.5   888  568  ??  S12:27PM   0:00.00
qmail-remote
> > graycastle.com query-return-28236-
> > ...
>
> that's not incoming mail; qmail-remote send mail from your machine ->
> remote domains.
>
> if this machine is supposed to be the primary MX for greycastle.com, you
> have a comfiguration problem.
>
> dan
>
>

Re: Forwarding Nightmare

[lists]

Adrian,

The logs look fine. Messages are being sent for delivery as normal... just a
lot faster than normal. :-)

I stopped qmail, cleared my queue with this script:

for i in bounce info intd local mess remote todo;
do find /usr/local/qmail/queue/$i -type f -exec rm {} \;
done

restarted qmail, no good.
Tried it again and rebooted, no good.

Whenever qmail starts up, I get about 15 of these showing up:
qmailr 12991  0.0  0.5   888  568  ??  S12:43PM   0:00.00 qmail-remote
graycastle.com query-return-29905-

I keep getting mail from 'query', even though that user is long-dead.

Shawn

- Original Message -
From: "Adrian Ho" <[EMAIL PROTECTED]>
To: "Qmail Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, July 11, 2001 12:32 PM
Subject: Re: Forwarding Nightmare


> On Wed, Jul 11, 2001 at 11:37:10AM +0900, lists wrote:
> > I then sent a test message to the user.
> > qmail has continually been sending messages to [EMAIL PROTECTED] all
> > night at a frightening speed.
> > I estimate around 25,000 mails have been sent so far.
>
> What Do The Logs Say?  It sounds like the to.forward.to MX is botching the
> SMTP conversation.
>
> - Adrian
>

qmailr processes

[lists]

Hi,
 
I have stopped qmail, cleared the queue with:
 
 
and restarted qmail, but I still get these processes sending 
me mail:
 
qmailr  1071  0.0  0.5   888  
568  ??  S    12:27PM   0:00.01 qmail-remote 
graycastle.com query-return-28234-qmailr  1080  0.0  
0.5   888  568  ??  S    
12:27PM   0:00.00 qmail-remote graycastle.com 
query-return-28236-
...
 
I have totally removed the user 'query', even rebooted the 
machine, but these processes keep coming up and bombarding me with mail. Any 
ideas?
 
Thanks,
 
Shawn

Forwarding Nightmare

[lists]

Hi,
 
Last evening I tried to set up a .qmail file to forward 
messages to a remote address.
I created a user testuser, and in his directory put a .qmail 
file with 
&[EMAIL PROTECTED]
 
I then sent a test message to the user.
qmail has continually been sending messages to [EMAIL PROTECTED] all night at a 
frightening speed.
I estimate around 25,000 mails have been sent so 
far.
 
I deleted testuser completely, home directory, .qmail file and 
all, but messages continue to pour in to [EMAIL PROTECTED] .
I am guessing my queue needs to be flushed? Can I wait it out, 
or could something be happening where it will continue to send even though 
testuser no longer exists?
 
Any help appreciated,
 
Shawn

Re: tcpserver: end xxxx status 256

[Lists Servers Email]

I found the problem, tcpserver for pop3 was not running as root.

But I have another problem!!! there is mail in the queue but it's not get
deliver local.

Thanks Kevin.

- Original Message -
From: "Vincent Schonau" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 07, 2001 12:43 AM
Subject: Re: tcpserver: end  status 256


> On Fri, Jul 06, 2001 at 10:07:11PM -0700, Lists Servers Email wrote:
> > Does any know what causes this error:
>
> > Server:
> > tcpserver: end  status 256
>
> A program that was called by tcpserver exited non-zero. What you obscured
is
> a pid.
>
> > Client:
> > user xxx
> > +OK
> > pass xx
> > -ERR unable to write pipe
>
> > Connection to host lost.
>
> I'm guessing (since you haven't shown us your tcpserver command-line) that
> qmail-popup has a problem with whatever problem it's trying to call.
>
>
> Vince.

tcpserver: end xxxx status 256

[Lists Servers Email]

Does any know what causes this error:

Server:
tcpserver: end  status 256

Client:
user xxx
+OK
pass xx
-ERR unable to write pipe

Connection to host lost.


Kevin

Re: Error deferral: Unable_to_chdir_to_maildir._(#4.2.1)/

[lists]

I am having the same problem...

(I send an email to the list earlier with the contents of all files I
thought might be relevant, but I haven't seen that mail come up. Can anyone
confirm that it was sent to the list? Perhaps I made a mistake in
sending...)

Shawn

Qmail tries to deliver to /home/usr/Maildir

[lists]

Hello,
My saga continues...
I'm having a problem where qmail is attempting to deliver 
mail to/home/usr/Maildir instead 
of/usr/local/vpopmail/domain/mydomain/user/Maildir.Most of the users are 
vpopmail users and therefore do not have a /home/usrdirectory, so I get the 
dreaded 'Unable_to_chdir_to_maildir' on incomingmail to them.After 4 hrs 
sleep in the last 24 hrs straight trying to get this problemsolved, I'm 
getting a little frustrated. Any feedback would be appreciated.Here are 
my files:warabi# cat 
/usr/local/etc/rc.d/svscan.sh#!/bin/sh -e# 
startup script from:# http://www.flounder.net/qmail/qmail-howto.html#8#ln 
-s /var/qmail/supervise/qmail-pop3d /service/qmail-pop3dcase "$1" 
in 
start)    echo -n "Startng djb 
services: svscan "    cd 
/service    env - 
PATH="/usr/local/bin:$PATH" svscan 
&    echo $! > 
/var/run/svscan.pid    echo 
"."    ;; 
stop)    echo -n "Stopping djb 
services: svscan "    kill `cat 
/var/run/svscan.pid`    echo -n 
"services "    svc -dx 
/service/*    echo -n " logging 
"    svc -dx 
/service/*/log    echo 
"."    ;; 
restart|reload|force-reload)    $0 
stop    $0 
start    
;; *)    
echo 'Usage: /usr/local/etc/rc.d/svscan 
(start|stop|restart)'    exit 
1;esacexit 0warabi#   
cat /service/qmail-send/run 
(->/var/qmail/supervise/qmail-send/run)#!/bin/shexec 
/var/qmail/rcwarabi# cat 
/service/qmail-smtpd/run 
(->/var/qmail/supervise/qmail-smtp/run)#!/bin/shQMAILDUID=`id 
-u qmaild`NOFILESGID=`id -g qmaild`exec /usr/local/bin/softlimit -m 
200 \ /usr/local/bin/tcpserver -v -p -x 
/usr/local/vpopmail/etc/tcp.smtp.cdb \ -u $QMAILDUID -g $NOFILESGID 0 
smtp /var/qmail/bin/qmail-smtpd 
2>&1warabi# cat 
/service/qmail-pop3d/run 
(->/var/qmail/supervise/qmail-pop3d/run)#!/bin/sh env 
- PATH="/var/qmail/bin:/usr/local/bin" \ /usr/local/bin/tcpserver -H -R 
-u vpopmail -g vchkpw 0 pop3/var/qmail/bin/qmail-popup 
\ warabi.nca.or.jp /usr/local/vpopmail/bin/vchkpw 
\ /var/qmail/bin/qmail-pop3d Maildir 
2>&1warabi# cat 
/var/qmail/rc#!/bin/shexec env - 
PATH="/var/qmail/bin:$PATH" \qmail-start "`cat 
/var/qmail/control/defaultdelivery`" 
2>&1warabi# cat 
/var/qmail/control/defaultdelivery./Maildir/warabi# 
cat 
/var/qmail/control/defaultdomainwarabi.nca.or.jpwarabi# 
cat 
/usr/local/vpopmail/etc/tcp.smtp127.0.0.1:allow,RELAYCLIENT=""warabi# 
cat 
/var/qmail/users/assign+nca.or.jp-:nca.or.jp:1227:65535:/usr/local/vpopmail/domains/nca.or.jp:-::
.All files/dirs under 
/usr/local/vpopmail are chown vpopmail.vchkpw.All subdirs are chmod 
755.
According to http://www.lifewithqmail.org/lwq.html ,
"3.6.2. Wildcard assignmentA wildcard assignment looks 
like:
 
+prefix:user:uid:gid:directory:dash:prepend:
 
What this means is that messages received for addresses of the 
form prefixrest will run as user user, with the specified uid and gid, and the 
file directory/.qmaildashprependrest will specify how the messages are to be 
delivered."
 
I have the following file:warabi# cat 
/usr/local/vpopmail/domains/nca.or.jp/.qmail-default| 
/usr/local/vpopmail/bin/vdelivermail '' 
/usr/local/vpopmail/domains/nca.or.jp/1/04awano
 
Which I assume means that bounced mail goes to [EMAIL PROTECTED] . Is this 
correct?I still don't see why qmail is trying to put the 
mail in /home/usr/Maildir instead of under the vpopmail/domains 
directory...
Can anyone see what I am missing here?Thanks for 
any help.Shawn

Re: qmail-remote

[lists]

- Original Message -
From: "Charles Cazabon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 05, 2001 4:00 AM
Subject: Re: qmail-remote


> > > Post an exact copy of the script you use to start qmail -- the one
that
> > > actually calls qmail-start.  We need to see what you're supplying as
an
> > > argument to qmail-start -- if that argument is read from a file, post
the
> > > contents of that file as well.
> >
> > chicken# cat /var/qmail/rc
> > #!/bin/sh
> >
> > exec env - PATH="/var/qmail/bin:$PATH" \
> > qmail-start "`cat /var/qmail/control/defaultdelivery`" 2>&1
>
> You missed one of the instructions -- we need the contents of the
> defaultdelivery file -- I think it's got invalid contents.
>
> Otherwise, things look okay.

Thanks Charles.
Output of defaultdelivery is as follows:

chicken# cat /var/qmail/control/defaultdelivery
./Maildir/

Last night I had messed up my queue by removing messages without bringing
down qmail-send and qmail-smtpd first (DOH!!).
I fixed the queue with queue-fix (found on the qmail.org homepage), and that
seemed to help.
Right now I am getting this in /var/log/qmail/qmail-send/current :

@40003b43d1272bf647b4 delivery 105: deferral:
Unable_to_chdir_to_maildir._(#4.2.1)/

I think this is because it is trying to deliver to /home/user/Maildir when
the user is actually a vpopmail user whose Maildir is in
/usr/local/vpopmail/domains/splat.or.jp/user/ .

Thanks,

Shawn

Re: qmail-remote

[lists]

Hello again,

- Original Message -
From: "Charles Cazabon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 05, 2001 4:00 AM
Subject: Re: qmail-remote


> > > Post an exact copy of the script you use to start qmail -- the one
that
> > > actually calls qmail-start.  We need to see what you're supplying as
an
> > > argument to qmail-start -- if that argument is read from a file, post
the
> > > contents of that file as well.
> >
> > chicken# cat /var/qmail/rc
> > #!/bin/sh
> >
> > exec env - PATH="/var/qmail/bin:$PATH" \
> > qmail-start "`cat /var/qmail/control/defaultdelivery`" 2>&1
>
> You missed one of the instructions -- we need the contents of the
> defaultdelivery file -- I think it's got invalid contents.
>
> Otherwise, things look okay.

Thanks Charles.
Output of defaultdelivery is as follows:

Re: svscan help

[Lists Servers Email]

Redhat  7.1


Kevin

- Original Message -
From: "Adam McKenna" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 28, 2001 3:07 PM
Subject: Re: svscan help


> On Thu, Jun 28, 2001 at 02:32:53PM -0700, Lists Servers Email wrote:
> > +
> >
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/u
> > sr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X
> > 11R6/bin:/root/bin:/usr/local/bin:/var/qmail/bin
> > + echo -n 'Starting djb services: svscan'
> > Starting djb services: svscan+ cd /service
> > + env -
> >
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/u
> > sr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:
> > /usr/X11R6/bin:/root/bin:/usr/local/bin:/var/qmail/bin svscan
> > + echo 1546
> > + echo .
> > .
> > + exit 0
> > [root@salem bin]# env: invalid option -- P
> > Try `env --help' for more information.
> > env: invalid option -- P
> > Try `env --help' for more information.
> > env: invalid option -- P
> > Try `env --help' for more information.
> > env: invalid option -- P
> > Try `env --help' for more information.
> > env: invalid option -- P
> > Try `env --help' for more information.
> > env: invalid option -- P
> > Try `env --help' for more information.
> > env: invalid option -- P
>
> Weird.  What OS is this running on?
>
> Try getting a new copy of the script at
http://flounder.net/qmail/svscan-init
>
> --Adam

Re: svscan help

[Lists Servers Email]

+
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/u
sr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X
11R6/bin:/root/bin:/usr/local/bin:/var/qmail/bin
+ echo -n 'Starting djb services: svscan'
Starting djb services: svscan+ cd /service
+ env -
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/u
sr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:
/usr/X11R6/bin:/root/bin:/usr/local/bin:/var/qmail/bin svscan
+ echo 1546
+ echo .
.
+ exit 0
[root@salem bin]# env: invalid option -- P
Try `env --help' for more information.
env: invalid option -- P
Try `env --help' for more information.
env: invalid option -- P
Try `env --help' for more information.
env: invalid option -- P
Try `env --help' for more information.
env: invalid option -- P
Try `env --help' for more information.
env: invalid option -- P
Try `env --help' for more information.
env: invalid option -- P

- Original Message -
From: "Adam McKenna" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 27, 2001 11:55 PM
Subject: Re: svscan help


> On Wed, Jun 27, 2001 at 11:25:55PM -0700, Kevin Roberts wrote:
> >
/usr/local/sbin:/usr/sbin:/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lo
> > cal/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bi
> > n:/root/bin
>
> try:
>
> # sh -x /etc/init.d/svscan start
>
> and paste the output here.
>
> --Adam

Re: url of sqwebmail too long!!!!

[The Lists I'm on]

A

Meta http-equiv="refresh" content="0;url=http://mail.somewhere.com/cgi-bin/somewhere";

tag in the index of a virtual host would do the trick.

Also,

An alias would work in only this case:

UseCanonicalName On #is specified in your httpd.conf file for the master host with 
aliases to all other domains mail.x.y

And you copy the login page the CGI gives you and in the form action
paramater, you put an SSI using the environment variable SERVER_NAME, to
reference a symlink (or the directory itself) to the right file. If you
uuse a symlink you need Options FollowSymlinks also for the host.

Thanks,
Justin M. Shomo

On Fri, 8 Jun 2001, Alex Le Fevre wrote:

> > I hope I understand what your asking.
> 
> Actually, I think what he's trying to do is the same thing I've been trying 
> to do -- make mail.domain.com equivalent to 
> www.domain.com/cgi-bin/sqwebmail. In that case, an alias wouldn't work, 
> because that would require www.domain.com/alias/, not mail.domain.com. Of 
> course, it's probably a question more for an Apache list, but if you or 
> someone else knows how to do that, it would make both of us quite happy. :-) 
> 
> Alex Le Fevre
> 

-- 
===
Justin M. Shomo, CEO
TransWan Corporation
[EMAIL PROTECTED]
http://www.transwan.com
303-466-9626
910 15th St. Ste. 751
Denver, CO 80202
---

TransWan Corporation

IP and ATM Based Communication protocols, software, and services.

===

Re: Local Deliveries Slow

[lists-mail-isp-qmail]

In article <001001c09bc6$2f6434a0$[EMAIL PROTECTED]> you wrote:
> Hi,
> I am having a tough time migrating to qmail. I  have applied the concurrency
> patch and set the concurrency limit to 250. Inspite of that I do not see the 
> qmail-lspawn forking more than 2 or 3 processes at any given point of time.
> What could be the problem? My local queue is currently at 8.
> Due to this my users are unable to get mails. However they are able to send out
> mails fine.
> 
> However remote deliveries seem to be going fine and I can see multiple 
> qmail-remote being forked.

H, I've only come across this once before and it turned out that
the /var/qmail/queue/lock/trigger pipe was "broken".   It happened when
I tried a cheapo (tar cvf qmail.tar qmail; copy qmail.tar file to diff
server and untarred) install of qmail ;-)

Qmail would work but would only process local deliveries every 30 minutes.

I resolved it by doing a proper "make setup check" install (though
remember to backup your control/* files - it will trash some of them).

Btw, concurrencylocal max is 120

Paul.

Re: Open Today.

[lbudney-lists-dns]

Russell Nelson <[EMAIL PROTECTED]> wrote:
> 
> Len, you've sent me mail directly; no problem.  Yet I block on the DUL.
> I think the reason you haven't had any problems is because your ISP
> hasn't listed its dialups with the DUL.

Ah, that explains it! Well, bully for my ISP! They're cool for reasons
other than running qmail I see.

Len.

--
Frugal Tip #17:
Visit the Ford Foundation while disguised as a large, charitable
organization.

Qmail & AtDot

[Lists]

more on last post to lists.

I am running Qmail on a FreeBSD 3.3 server and have qpopper setup. Qmail
is using ~/Mailbox and all is running fine.
I have no external SMTP access but would like to have AtDot be able to
send.
The problem is that it comes back with the error of:
An error was encounted sending your mail. Please try again.

This comes up all the time.

I can send to all my domains in the control/rcpthosts but if it is not in
there I can't send it. I have tried a test and added a host external I
wanted to send email to and it completed with out errors. Can someone help
me with this. This is the only form of access that we want on this server.

Thanks for all of you help

David Uzzell

List Bot account for 1st Penshurst Scout Group.
http://www.1stpenshurst-scouts.asn.au

Re: compile error

[lbudney-lists-qmail]

"Chris L. Mason" <[EMAIL PROTECTED]> writes:
> 
> Technically it's a bug.  main() should always return int...

Dan always calls _exit(stat), so main() _does_ return an integer,
regardless of the declaration.

> I always just assumed Dan was trying to make a statement of some
> kind as he certainly wouldn't have done this by mistake.  :)

In 1996, Dan said,

  ``In case anyone's curious: I use void main() because it shuts gcc
  up. If there is ever a compiler dumb enough to break void main(), I
  will happily advise everyone to use a different compiler.''

>From this we can infer that some version(s) of gcc, on some platform(s),
made a lot of noise over "int main()"; perhaps when it contains no
return statements. "void main()" works identically, with fewer complaints.

Len.

Re: Anal-ness

[lbudney-lists-qmail]

Russell Nelson <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] writes:
>  > Richard "Source code for the workers or we shoot you" Stalin.
> 
> ...what RMS actually says these days.

Granted; he's doing much better. As an ethic, his ideas are wonderful; as
potential laws, they would amount to socialized software.

>  > ...Dan seems to define "forking" differently...
> 
> The Debian standards put configuration files under /etc for a particular
> reason (this has *always* been the standard place for Unix configuration
> files).

With plenty of exceptions; /var/spool/*, /usr/lib/*, /sbin/init.d (on HP/UX).

> qmail does not, also for a particular reason.

True; but I don't see the objection. Dan's licence permits any variant
on the following (or their reverses):

  # ln -s /var/qmail /etc/qmail

OR

  # ln -s /var/qmail/bin /usr/local/qmail/bin
  # ln -s /var/qmail/control /etc/qmail
  # ln -s /var/qmail/queue /var/spool/qmail
  ...

So the Debian folks can have anything they want in /etc, as long as they
keep <12 symlinks under /var.

> The reasons differ and one could argue which is the best reason...

Granted.

> ...but because qmail is not open source, Dan wins the argument without
> need for persuasion.

But I haven't heard of anything people can't accomplish with qmail,
obeying Dan's license, except possibly ``Never have a /var directory
on any of our machines.'' Which was my original point; concerns over
Dan's licensing seem to be a tempest in a teapot.

Len.

Re: Anal-ness

[lbudney-lists-qmail]

Russell Nelson <[EMAIL PROTECTED]> writes:
> 
> An OSI-approved Open Source license...And RMS (Richard M. Stallman)

Note that many things are good and right, though unblessed by OSI and
Richard "Source code for the workers or we shoot you" Stalin.

Qmail's restrictions may be a "moral" downer for some. However, in a
practical sense the restrictions don't prevent any desired use of
qmail--except including a forked qmail in distributions.

Note, too, that Dan seems to define "forking" differently than Eric
Raymond. Changing the locations of vital files (usually for no
particular reason) counts with Dan as a "fork".  This may not matter
for atomic programs, but for complete systems, like qmail, it does.

As Dan pointed out before (and I hadn't realized till then), the author
is responsible for supporting his product on every OS that runs it--RedHat
and Debian, but also FreeBSD, Solaris, AIX, HP/UX and Unixware.

Dan doesn't want to be ``faced with a support nightmare---forever'', and
I can't say I blame him.

Len.

Relay management in Qmail with AtDot webmail.

[Lists]

We have qmail running with AtDot webmail and have recive working fine but
when it comes to sending email out of the local domain it has an error. I
also have the same trouble with external mail programs like Outlook not
being able to send email. Can someone help. Thanks in advance.

System is FreeBSD3.3 and current Qmail of the web site and current Atdot
webmail of the web site with Qpopper as the pop3.


List Bot account for 1st Penshurst Scout Group.
http://www.1stpenshurst-scouts.asn.au

Re: big rcpthosts file

[lbudney-lists-qmail]

Frank Greven spake unto me and said:
> 
> Should I only use rcptshosts or not?

You should use morercpthosts, because Dan knows what he's doing.

> If it's a question of memory - because of what you called in-memory
> cdb - what is the needed size of RAM?

I can't answer that; this is a case of 'profile, don't speculate.' If you're
using just rcpthosts, and your performance is acceptable, then obviously you
_can_ just keep doing what you're doing.

> Or maybe the whole diskussion is wasted time because either a small
> Linux Pentium system with 128 MB RAM and let's say 10,000 mails per
> day will never run into a performance leak?

Could be (see above). However, total throughput isn't the only test of
load. You should install qmailanalog, if you haven't already. Look at
your average concurrency. If it is high, then you should _definitely_
use morercpthosts--and also use concurrencyremote to allow more
concurrent deliveries.

If your concurrency is very low, you probably don't have to change
anything.

HTH,
Len.

Re: big rcpthosts file

[lbudney-lists-qmail]

Peter Gradwell spake unto me and said:
>
> - searching a fairly empty (5 lines) rcpthosts file and then
>   searching morercpthosts, or

Um, that should be '(50 lines)', meaning 'your 50 most commonly used
domains' (man qmail-smtpd). When a domain is found in rcpthosts, then
morercpthosts is not touched. Depending how common 'most common' is,
morercpthosts will not be used much.

> - just searching a large rcpthosts file.

Um, qmail-smtpd doesn't actually search the rcpthosts file. It parses
the file into an in-memory cdb, and searches that. qmail-newmrh parses
morercpthosts into an on-disk cdb, which qmail-smtpd searches from the
disk _when necessary_.

So your choice really is:

  - searching a fairly small (50 domains) in-memory cdb, and then
searching a large on-disk cdb when necessary, or

  - just(!) searching a large in-memory cdb. (Remember, large in-memory
structures are paged, so disk I/O is required in either case, with
a suitable definition of 'large'.)

Looking at the source code suggests that search speed is not the issue;
memory is. Smaller qmail-smtpd processes mean more qmail-smtpd (and
qmail-remote) processes, which means greater concurrency. No doubt Dan
has profiled this, and seen that the bottom line is greater overall
throughput.

Len.

Re: Server cluster

[lbudney-lists-qmail]

Michael Boman spake unto me and said:
> Let me see if I get this right, it is OK to share the /home/vpopmail
> directory, but not the others? Anyone have ideas how to keep the qmail
> controlfiles etc up-to-date on each computer, or can I just share that
> directory (/var/qmail/control and maybe /var/qmail/alias).


/var/qmail/queue

  /var/qmail/queue is the one thing you simply CANNOT share; qmail cannot
  queue messages through NFS. (Read INSTALL.maildir; you'll see that Dan
  takes a dim view of NFS.)


/var/qmail/control

  Sharing /var/qmail/control is possible, if you're careful. It probably
  means that home directories are NFS mounted, and passwords are NIS
  shared.  This in turn means:

  1. mbox delivery is deprecated; use Maildir.  See INSTALL.maildir,
 INSTALL.mbox and INSTALL.vsm.

  2. Mail will bounce unless you follow the steps in FAQ 4.9: "How do
 I make qmail defer messages during NFS or NIS outages?"

  An alternative to sharing is to use sed and rsync (with "-e ssh").
  The qmail Makefile contains an elegant use of sed for that purpose.


/var/qmail/bin

  You certainly can share /var/qmail/bin if you want. Make sure the
  qmail users and groups have the same IDs on every host. Also, paths
  need to agree: for example /var/qmail/queue should always get you to
  the right place.


/var/qmail/alias

  Can be shared. Remember, it's a home directory; use Maildir. Also,
  it's your problem to make sure that .qmail-* files work everywhere.


HTH,
Len.

Mail abuse

[lbudney-lists-qmail]

"David L. Nicol" spake unto me and said:
> 
> what keeps spammers from faking envelope-from and using
> include-in-bounce features to relay spam content?  

Nothing; see  for this and other
more heinous possibilities.

> Is it possible that a subject of "failure notice" will
> some day not be sufficient to prevent this possibility?

It's not clear what you mean. If you destroy bounces, you prevent that
attack; however you also prevent people from seeing legitimate bounces.
In general, it is impossible to make bounces unforgeable.

Len.

Re: 3 quickies!

[lbudney-lists-qmail]

Paul Schinder spake unto me and said:
> At 10:24 AM -0500 12/23/99, [EMAIL PROTECTED] wrote:
> >
> >Check out  for a good example of spam
> >filtering which is _customer_ approved.
> 
> ...the example is poor, IMHO.  I have a pobox account for non-work 
> related mail, and I had their spam filtering on for a while before 
> finally turning it off.  It tagged things as spam that weren't. It 
> missed tagging most real spam.  In short, it wasn't any help at all. 

Oh, I agree completely! I let pobox mark my "spam" emails, and it's
hideously inaccurate. All I meant was that their bad spam "protection"
is truly optional, which is good.

> ...what I'd pay extra for, and what they don't offer (at least the
> last time I checked), is RBL+DUL+RSS on my incoming mail stream...

Agreed; that might be handy. What I've been doing for a while is sending
BCCs to a separate folder. Once a month or so I glance through the
folder. It usually contains about two dozen emails, almost all spam. No
fuss, no muss, and I've only seen about half a dozen pieces of spam get
through it in about 2 years.

I guess spam doesn't send me into a killing rage, when I get to meet it
on my own terms. (But if you're lynching spammers, do invite me along.)

Len.

Re: 3 quickies!

[lbudney-lists-qmail]

"Marc-Adrian Napoli" spake unto me and said:
>
> What i'm after is a solution that falls into place at the
> qmail-send/qmail-local stage that will quickly check the
> headers of the message to be delivered locally first for
> any particular strings. (Silly email addresses or anything
> with the word "buy now" or "sell now" etc)

I recommend that you be _VERY_ careful with this idea,
especially if you are an ISP. In particular, bouncing
emails may anger your customers, and destroying emails
can get your butt sued off.

Suppose one of your customers is sent an email from his stock
broker, saying "Sell Now" Your customer never gets the
email, and loses his shirt, because of your spam "protection".
You will deserve whatever happens to you.

Other than RBL-blocking, and making sure _your_ relay is closed,
I recommend that you only use filters which are _explicitly_
approved by _each_ affected customer. Deciding for your
_customer_ which emails look "bad" to _you_ is very foolish.

Check out  for a good example of spam
filtering which is _customer_ approved.

Len.

UNSUBSCRIBE budney-lists-qmail@peregrine.maya.com

[budney-lists-qmail]

UNSUBSCRIBE BBDB-INFO

Re: New qmail list et al

[budney-lists-qmail]

"Alex Miller" <[EMAIL PROTECTED]> writes:

> But, currently, it IS permissible on this list to post messages that
> say things like "your an idiot" or "this is off topic", "this has
> nothing to do with qmail".

Here's just $.02, since I think I was the latest one to say "You're an
idiot" on this list.

If you consult the qmail archives, you will find occasional posts by
me going back about two years. Some of those questions were so
breathtakingly idiotic that nobody bothered to reply at all. Yes, if
someone had pointed out that I was an idiot I would have felt rather
hurt. Hopefully, I am a less idiotic qmail user today. In general,
idiocy is not necessarily a terminal, nor a permanent, condition.

Sadly, there is such a thing as idiocy. Posting a question, ignoring
several answers, and then complaining that nobody is helping, is just
plain idiotic. If the fellow in question objects to being
characterized as an idiot, he has at least two choices. One is to
shove off; another is to behave less idiotically.

Other choices include a series of posts indicating that Qmail (or its
documentation) sucks, or interjecting remarks like "I'll simply
privately curse djb (et all) and wait...", or complaining that people
trying to help are just "[spouting] a bunch of baseless crap"
etc.. Oh, that's right! The idiot in question also did all of those
things.

Len.

-- 
Spool and process your email with maildircmd.

Re: Perhaps I missed it the first time ...

[budney-lists-qmail]

"Scott D. Yelich" <[EMAIL PROTECTED]> writes:

> On Tue, 29 Jun 1999, Adam D. McKenna wrote:
> > I wonder what you could have done to piss someone off this badly.
> 
[blah blah blah]

Let's see, now. You post a question. DJB answers it. You post again,
whining that nobody had answered you. Then you explain yourself by
further whining that you can't find the answer in your deluge of
email, and that hackers are beating you up.

Why ask again, if you know you can't find the answer? Since the answer
was in your mailbox, and can be found using 1) grep, 2) a threading
mailreader, or 3) procmail, why would you ask for a second answer
that, presumably, you would also not find in your overstuffed mailbox?

And why SHOULD anyone care about your hacker troubles, and your lack
of a firewall, and your overwhelming email traffic? Would you like
someone to read your email to you, or build you a firewall?

You really are an idiot.

-- 
A whip for the horse, a bridle for the ass, and a rod for the fool's
back. --Proverbs 26:3

Q: getting a virtual domain

[budney-lists-qmail]

Please pardon this off-topic question!

I'm about to lose my static IP--then it's back to dialup from
home. The problem is that I'm hosting an ezmlm mailing list, and want
to keep doing so.

Where should I look for a service which will rent me an MX record, and
spool my incoming mail for delivery when I am online? Autoturn would
be preferred, but any arrangement which preserves envelope information
is okay. I just don't want to grok headers, for all the obvious
reasons.

I've checked several ISPs, the Qmail archives, and DejaNews to no
avail.

Thanks in advance,
Len.

-- 
19. Let your Countenance be pleasant but in Serious Matters Somewhat
grave.
  -- George Washington, "Rules of Civility & Decent Behaviour"

Re: dialup w/ qmail

[budney-lists-qmail]

<[EMAIL PROTECTED]> writes:

> However, since I don't have a real domain, I can't seem to receive
> anything.

People should not be addressing mail directly to your server, unless
it has a sufficiently stable presence on the Internet (static IP,
DDNS, etc.). They should be sending mail to you c/o your ISP.

> I try to send mail to the server from a remote host, and it gripes
> that the address (whataver.ppp-mfc.etc..) isn't in the rcpthosts
> file.

Right, because you're addressing the mail to the dialup on which
you're connected. Qmail only accepts mail for hosts listed in
/var/qmail/control/rcpthosts. There are two solutions:

  1. Add all of your ISP's dialups to rcpthosts (yuck!).

  2. Get the mail-delivery-agent to connect to your machine, but
 address the mail to [EMAIL PROTECTED] You'll find
 that quite tricky; indeed impossible in general.

> I also can't seem to receive pop mail (via fetchmail) due to the
> same problem.

Fetchmail can do the job; you should scan your mail log and see, when
running fetchmail, _exactly_ what the error message is. Paste them
into your email's to this list.

I'll guess that they say, "localhost" is not in rcpthosts. You could
just add it; alternately run fetchmail with "-S
localhost.localdomain", or add "smtphost localhost.localdomain" to
your .fetchmailrc file. Presumably, "localhost.localdomain" IS in your
rcpthosts.

Good luck,
-Len.

-- 
Corrupt: In politics, holding an office of trust or profit.
-- Ambrose Bierce

Re: Mass migration off of qmail because of lack of DSNs?

[budney-lists-qmail]

Tasos Kotsikonas <[EMAIL PROTECTED]> writes:

> Thanks everyone for the responses.  Indeed our need for DSNs is
> simply TREMENDOUS...With so much volume of email going out we need
> to cut down on the number of bounces.  As we expect megabytes of
> bounces each day coming back from each such list, we need to keep
> our lists as clean as possible.  Nothing else other than DSNs will
> allow us to be 100% successful.

Forgive the (possibly ignorant) question, but why won't VERPs allow
you to be 100% successful? There are exactly two things that MTA's
cannot mess with, and still work: the envelope sender, and the
envelope recipient. Any other header munging is possible, and probably
happens at least sometimes.

With VERP, if you receive a bounce, then it will be addressed in such
a way as to completely specify what bounced. Period. Handling that
automatically is certainly no trick.

Of course, at the moment I believe that implies you must use both
qmail and ezmlm.

-Len.

-- 
Corrupt: In politics, holding an office of trust or profit.
-- Ambrose Bierce

Re: Qmail to procmail and back again?

[budney-lists-qmail]

Stig Sandbeck Mathisen <[EMAIL PROTECTED]> writes:

> If all you want is to deliver mail to a maildir, you can
> use procmail to do this. Use the procmail maildir patch...

Or, if you'd rather not patch procmail, you can use safecat in recipes
under procmail without any patches. You can get safecat at
.

-Lenm.

-- 
Scornful men bring a city into a snare: but wise men turn away
wrath. --Proverbs 29:8

Re: procmail->~/Maildir

[budney-lists-qmail]

John Conover <[EMAIL PROTECTED]> writes:

> Is there a way of executing procmail do ~/.procmailrc, and if email
> is not rejected for a user, it is delivered into a ~/Maildir?
> 
> BTW, eg., use my standard spam filter for users that want it, but
> want to fetch mail via POP3 in a Maildir.

If I understand you correctly, you want mail to be pumped through
procmail--and to be delivered to a maildir if it falls through all of
your procmail filters.

The qmail way to do that is to put something like this in your
.qmail-ext file:

   |preline procmail
   ./Maildir/

To make this work, your "rejecting" recipes must return exit code 99,
telling qmail to ignore the next instruction(s). Be aware that
procmail itself has a default delivery instruction, for mails that
"fall through", and you don't want to trigger it. A recipe like this,
as your last recipe, should do the trick:

   :0
   /dev/null

On the other hand, there is an easier way (YMMV). You can use the
patched procmail which can do maildir deliveries, and make your last
recipe a maildir delivery--or set $DEFAULT appropriately in the rc
file.

If you'd rather not use a patched procmail (my preference), there is a
program which does maildir delivery of messages posted on stdin--just
what you need. It's called "safecat", and it's available at the URL:


To use it, make your last recipe the following:

   :0w
   |safecat $HOME/Maildir/tmp $HOME/Maildir/new

Used in this way, procmail+safecat should be as safe as qmail's own
maildir delivery.

Len.

-- 
45. Being to advise or reprehend any one, consider whether it ought to
be in publick or in Private; presently, or at Some other time in what
terms to do it & in reproving Shew no Sign of Cholar but do it with all
Sweetness and Mildness.
  -- George Washington, "Rules of Civility & Decent Behaviour"

Re: mail filtering

[budney-lists-qmail]

[EMAIL PROTECTED] writes:

> Are there any filters like procmail available that can deliver to
> mailboxes in maildir format? The most important purpose is to
> redirect some mails, as from this list, for example, to appropriate
> directories.

I posted one solution earlier today: safecat. It's a small program
which duplicates the standard input to a file in a maildir. I wrote it
as an exercise in understanding DJB code, and worked very hard to make
it as reliable as qmail's own delivery. You can get it at the URL:
<http://www.pobox.com/~lbudney/linux/software/safecat.html>.

It can be used under an unpatched procmail, using a recipe like the
following:

   :0w
   |safecat $HOME/Maildir/tmp $HOME/Maildir/new

Your example, filtering mailing lists, is also pretty easy--especially
if you use qmail extensions. For example, I'm subscribed under the
address "[EMAIL PROTECTED]". To deliver to a
maildir called "$HOME/Mail/qmail", I just put the following in
.qmail-lists-default:

   |safecat $HOME/Mail/$EXT2/tmp $HOME/Mail/$EXT2/new

As you can see, I can subscribe to as many mailing lists as I want,
and qmail+safecat will deliver each list's traffic to the right place.

The reason safecat takes two arguments, is so that you can (for
example) make the first argument "$HOME/tmp". It's a minor violation
of the maildir algorithm, but makes no difference as long as both
directories are on the same filesystem.

Len.

-- 
40. Strive not with your Superiers in argument, but always Submit your
Judgment to others with Modesty.
  -- George Washington, "Rules of Civility & Decent Behaviour"

Re: Procmail and Maildir?

[budney-lists-qmail]

Chris Johnson <[EMAIL PROTECTED]> writes:

> On Wed, Apr 28, 1999 at 09:23:47AM -0500, Andy Walden wrote:
> > 
> > Is there anyway to fudge procmail into writing things to a
> > Maildir?
> 
> There are some patches available to make procmail deliver to
> maildirs.

If you like procmail, and don't want to patch it, then I recommend
safecat. You can download it at my web page:
.

Safecat takes stdin and writes it to a file in a Maildir, using the
same algorithm as qmail. You can invoke it from procmail (patched or
not) with a rule like:

  :0w
  |safecat $HOME/Maildir/tmp $HOME/Maildir/new

With the 'w' flag, above, procmail+safecat should be as reliable as
qmail itself.


~~~
Len Budney |  There are many good reasons to ignore
Maya Design Group  |  this cipher...So why bother with 
[EMAIL PROTECTED]|  nitpicks about the code style?   
   |  -- Prof. Dan Bernstein
~~~

Re: .qmail-

[budney-lists-qmail]

"Petr Novotny" <[EMAIL PROTECTED]> writes:

> > Why not [set conf-break to] a   \0
> 
> :-) I was not sure if it doesn't break the sources in some place - 
> like strcpy() and stuff.

You think DJB would use strcpy()? Or indeed anything in libc?

Qmail should do just fine with \0 as a conf-break. Hold on...yep, it
builds just fine. Someone else will have to try running it, though.

Len.

-- 
8. At Play and at Fire it's Good manners to Give Place to the last Commer,
and affect not to Speak Louder than Ordinary.
  -- George Washington, "Rules of Civility & Decent Behaviour"

Re: .qmail-

[budney-lists-qmail]

Andy Walden <[EMAIL PROTECTED]> writes:

> I'm also the kind of guy that keeps the bat book on top of the
> toliet for regular study.

Push it in! Push it in!

-- 
I'm criticizing one program. That program is disgustingly insecure. It
shouldn't just be ridiculed---it should be taken out and shot.
-- Prof. Dan Bernstein
   Author of qmail

Re: [Q] qmail speed "again"

[budney-lists-qmail]

Marc Slemko <[EMAIL PROTECTED]> writes:

> On Mon, 12 Apr 1999, Timothy L. Mayo wrote:
> 
> > If you cannot limit the number of connections you will accept to
> > something your system can handle, you need to re-think your setup.
> 
> Erm... you just described a classic DoS attack.  You put a limit of
> x connections in.  One remote system uses all or nearly all of them.
> No one else can connect.

Erm... DoS may be a sensitive subject on this list!  :-)

I think DJB has given a mathematically rigorous proof that "program
which is vulnerable to DoS" is one definition of "server". When a
server is serving all it can, it will refuse to serve any more. QED

The upshot is that _preventing_ a DoS is not at all possible. Any
rate-limiting, or other countermeasures you adopt, merely adjusts the
parameters within which a DoS must be conducted.

Limiting concurrency, ulimits, etc., are not about _preventing_ DoS,
which is impossible, but about ensuring that even under maxed-out
conditions the mail server will not die or become unstable.

> ...the root problem is qmail's rudeness in this area.

You may have a point here. Is there a well-defined rubric within which
we can assert, "It is ill-mannered to consume all available
connections to a remote server, just because those services are
needed?" Could be, I suppose--that's a question for admins.

Given that all service requests were legitimate, I would not mind my
server being pegged with connections from one host. When such
conditions become routine, from particular hosts, taking appropriate
action is why Sys Admins get paid. Of course, that's just MHO.

Len.

-- 
103. In Company of your Betters be not longer in eating than they are
lay not your Arm but only your hand upon the table.
  -- George Washington, "Rules of Civility & Decent Behaviour"

Re: qmail speed

[budney-lists-qmail]

[EMAIL PROTECTED] writes:

> If neither gets over 100K deliveries per hour then I'll have to
> write my own "gattling gun" SMTP delivery thingy and just feed
> messages to qmail that have problems.

Are you sure you're not a spammer? You're performance needs seem to be
mind-boggling, yet you refuse to throw more hardware at the problem
(which I would expect any large, legitimate business to do).

-- 
103. In Company of your Betters be not longer in eating than they are
lay not your Arm but only your hand upon the table.
  -- George Washington, "Rules of Civility & Decent Behaviour"

Re: qmail speed

[budney-lists-qmail]

[EMAIL PROTECTED] writes:

> That's the one problem when mathematicans start to program. 
> Usually very little attention is being paid to performance
> optimizations.

Cough.

I take exception to that! Though I'm no DJB, the PhD after my name
means I can claim to be a mathematician. The performance of qmail is
quite impressive--and a major reason for qmail 2 is to improve it even
more. Suggesting that DJB doesn't pay attention to performance is just
stupid.

> One can actually see that in qmail. Well thought out and
> very modular. Lots of performance expensive design decisions though.

Like what? Do I smell the fork/exec flame war smoldering afresh?

> If SPAMmers can do 200K messages per hour then we should be able to
> do that as well when sending legit stuff!

You can. Just make sure that you send a single email, with a CC list
of size 200K. Then you can get performance comparable to spammers.

Len Budney, PhD

-- 
I wasn't talking about sendmail+shell versus sendmail. I said you
would need dozens of subshells to make _qmail_ as slow as sendmail.
-- Prof. Dan Bernstein

Re: keyserver

[budney-lists-qmail]

"Scott D. Yelich" <[EMAIL PROTECTED]> writes:
>
> How many [rock solid, secure, fast, small, multi-use] programs does
> qmail have? I've lost count...  I have qmail, ezmlm, dotforward,
> accustamp, cyclog, tcp-env, tcpserver, setuser...

As a side note, I use accustamp, setuser, cyclog and tcpserver all the
time. Any boot-script I write uses them in preference to more
"standard" tools. And you did miss a few...

You missed supervise, which comes in the daemontools package with
accustamp. Thanks to supervise, writing flexible reliable daemons is a
snap. Thanks to accustamp, splogger and cyclog, interacting with the
system logger is cake. Thanks to tcpserver and tcp-env, building
internet services is a breeze.

Err, did you miss the point that modularity means flexibility? Those
many tools exist because of the many different tasks that need doing?

> Sure, it works...  eventually...  maybe.  It might be efficient (as
> long as you're not on a serial line?).

That's FAQ 2.4. RTFM.

> And, to top all of this off, the docs suck! I mean, it's not that
> qmail is bad, really, it isn't! It's the docs.

Terse != sucky.

Try this, when you have questions in the future:

  1. man qmail (Follow cross-references, including:)
 a. man qmail-start (addresses resource limits)
 b. man qmail-control (Indexes ALL control files. Follow references.)

  2. less /usr/doc/qmail/FAQ (better keep the FAQ somewhere...)

  3. lynx|netscape http://www-archive.ornl.gov:8000/ (Search the archive)

  4. lynx|netscape http://www.qmail.org/


> You can find a doc on sendwhale to do just about anything you need. 

It's there for qmail; it's just not said twelve ways for every kind of
wizard and dummy, true...

> Besides, I can grok sendmail.cf -- I kinda like it.  I have often
> thought of writing an AI/Expert-System that uses many of its techniques. 

Good idea. Make a mission-critical, 100% reliable, secure system using
those techniques. Good luck to you!

Len.


-- 
44. When a man does all he can though it Succeeds not well blame not
him that did it.
  -- George Washington, "Rules of Civility & Decent Behaviour"

Doc Wars (was: keyserver)

[budney-lists-qmail]

Forgive me plunging into the fray, but...

Mr. Yelich, I doubt a sould would disagree with you if you said,
"Golly, wouldn't a nice comprehensive O'Reilly book be great?
Something like the great classics--the expect book and the Perl camel
book." BTW, such a book is in progress.

You set up a straw man, however, when you slam "the
documentation". True, there is not yet a rich literature, including a
dummies book and a nutshell book, but "the documentation" is quite
complete.

"Scott D. Yelich" <[EMAIL PROTECTED]> writes:
> On Wed, 24 Mar 1999, Adam D. McKenna wrote:
> > ...I went to www.qmail.org and I read man pages for 3 hours.  So
> > when someone tells you to RTFM, it might not be because they're
> > trying to be hostile, but that RTFM'ing is really what you need to
> > do in order to start grasping the concepts that go along with this
> > piece of radically different software.
> 
> We've addressed this.  What do you do when the FM isn't enough?

Straw man. You wrote this mailing list; apparently you do comprehend
that this is a qmail resource. Are you unaware that it is archived?

Having asked questions so inane that they were completely ignored by
the nice folks of this list, I learned through personal shame that TFM
includes the archive of this mailing list, and to a lesser extent
bugtraq and dejanews.

Had you employed those resources, you would have had your
answer--without needing to post a rather obnoxious rant, and starting
a flame-war.

> when is djb coming out with his own unix?

Are you asking, or ranting? Can't quite tell. You should know that
beside qmail, DJB is a regular contributor to bugtraq, faq-keeper of
comp.security.unix and sci.crypt, and writes crypto software. Unlike
Stallman, he doesn't want to replace everything with DJB-ware; just
the stuff that is insecure or faulty.

> Also, what is part of qmail and what isn't?

You downloaded qmail, right? Look very carefully inside the
tarball. There's your answer. Is that RTFM? Or merely the moral
equivalent?

> Does anyone have a list of what is "official" and what is not?  does
> anyone care?

The "patch culture" evolved because DJB will not risk qmail's
security, reliability and speed by folding in everyone's pet projects.
Everyone thinks their pet, unlike everyone else's pet, is beautiful
and necessary, and belongs in qmail. DJB resists.

Hence "official patch" is rather an oxymoron. Use what you like, at
your own risk. Personal responsibility is rather bracing--try it out.

Len.

-- 
26. In Pulling off your Hat to Persons of Distinction, as Noblemen,
Justices, Churchmen &c make a Reverence, bowing more or less according
to the Custom of the Better Bred, and Quality of the Person. Amongst
your equals expect not always that they Should begin with you first,
but to Pull off the Hat when there is no need is Affectation, in the
Manner of Saluting and resaluting in words keep to the most usual Custom.
  -- George Washington, "Rules of Civility & Decent Behaviour"