Ah, ok - I deleted those last 4 messages that were in the 
queue. I guess they must have had huge bcc's (though I never
saw it in the /var/qmail/queue/mess files) b/c now everything
has disappeared.

chas


>Date: Sun, 19 Mar 2000 12:17:03 +0800
>To: "qmail list" <[EMAIL PROTECTED]>
>From: chas <[EMAIL PROTECTED]>
>Subject: Re: Spam getting through despite closed relay; or even with no
qmail-smtp running ! 
>In-Reply-To: <[EMAIL PROTECTED]>
>References: <Message from chas <[EMAIL PROTECTED]>    of "Sun, 19 Mar
2000 06:08:15 +0800."
<[EMAIL PROTECTED]> >
>
>First and foremost, thank you very much 
>to Andy and Shag for the lightning responses. 
>
>
>Shag wrote :
>------------
>>All those qmail remote processes are sending out that spam mail you
>>thought you got rid of.  My guess is that the stuff is still in your
>>local queue, so use qmail-qstat/qread to check and see.
>>qmail-smtpd/tcpserver do not need to be running for outgoing mail to be
>>sent.
>>
>>What you probably want to do in this case is kill qmail as quickly and
>>safely as possible, clean up the queue, and then restart qmail.  I've
>>had to do this a couple of times when I missed a relay rule or
>>something, so here's my step-by-step list of stuff to do.  Smarter
>>people than me can feel free to correct it :)
>>
>>1) If possible, unplug the box from the network, or ifconfig down the
>>public interface.
>>2) Kill qmail-smtpd.
>>3) Send qmail-send a TERM signal, which will make it exit ASAP.
>>4) kill -9 all the qmail-remote processes that you see.
>>5) At this point qmail should be completely stopped and you can clean
>>out the queue.
>
>Thank you, I did precisely this. Although I cleared the queue
>by setting the queuelifetime to 0 as mentioned by Andy (below).
>(Usually, I'm usually loathe to just delete the files in the 
>subdirectories of  /var/qmail/queue/mess since it's a mess to do
>it and also make the changes in /var/qmail/queue/info etc. I 
>know there's qmHandle to do this for me but I couldn't find it
>at the time ... Mick's site is unavailable)
>
>Bottomline : I've cleared the queue and now have 4 messages there.
>This is proven by digging through /var/qmail/queue/mess and by 
>the program /var/qmail/bin/qmail-qstat as below : 
>
># /var/qmail/bin/qmail-qstat
>messages in queue: 4
>messages in queue but not yet preprocessed: 0
>
>I eventually found an old version of qmHandle (v 0.2.0) and
>that also tells me that I have just 4 messages in the queue.
>
>However, /var/qmail/bin/qmail-qread tells a different story :
>/var/qmail/bin/qmail-qread | more
>17 Mar 2000 17:07:03 GMT  #484107  286058  <[EMAIL PROTECTED]>
>  done  remote  [EMAIL PROTECTED]
>  done  remote  [EMAIL PROTECTED]
>  done  remote  [EMAIL PROTECTED]
>  done  remote  [EMAIL PROTECTED]
>  done  remote  [EMAIL PROTECTED]
>  done  remote  [EMAIL PROTECTED]
>  done  remote  [EMAIL PROTECTED]
>  ... etc etc to thousands !
>
>I've read the man page but I'm just dim, and don't get it.
>What's the difference between these 2 queue stats ? And where
>are all the above messages stored ? I couldn't find them 
>anywhere.
>
>
>Andy wrote :
>------------
>>> I just rebooted the machine and have not yet started 
>>> tcpserver and qmail-smtp, and suddenly I find dozens
>>> of qmail-remote processes running. (see below)
>>
>>If you are certain that none of the daemons have been started, then is 
>>it possible that you were also hacked and he has installed a script 
>>that gets launched either via cron or in one of your system startup 
>>scripts which simply sends email once your system is booted?
>
>That's actually one of my worries. 
>
>>> /var/qmail/queue or any of its subdirectories) 
>>> How can they still be getting through to my box 
>>> if qmail-smtp is not even running yet ? (telneting
>>> to port 25 won't even get you a connection). And how
>>> can I get rid of them ? 
>>
>>You could set control/queuelifetime to 0, disconnect your network for a 
>>minute or so and restart qmail-send.
>>
>>Remember to change control/queuelifetime again to something reasonable 
>>or simply delete it if the default is fine.
>
>Thanks, this was very useful.
>
>
>Chas

Reply via email to