The standard way to remove a large number of files in a directory is to combine the find and xargs commands in a pipe:

find /your/directory -type f -print | xargs rm -f

I know a little bit of how SMTP servers work on *NIX. While I don't use sendmail (because, frankly, it scares me), I believe it's function is similar to the system I use, which is qmail.

There is a daemon part that stays running all the time and handles the delivery of messages to the individual mailboxes on your system and also sends messages heading out of your network to other systems.

There is also the part which "injects" mail messages into your mail queue. When a system makes a connection to your system on port 25, inetd or xinetd (or whatever system you might be using) runs the program which handles the communication session between your system and the remote system, and then puts the new mail message into the queue and then the program quits. Depending on how your system is configured, the daemon does not see the new email message until this injector program puts it into the queue.

That's why it is possible to be mailbombed even though you shut down your daemon. So, if you need to have your system stop accepting new mail messages from the outside world, you need to go into the configuration file(s) for inetd or xinetd and disable it there. All shutting down the daemon does it stop the processing of mail messages in the queue; your system will still keep accepting new emails until you disable it in (x)inetd.

Also, if you do decide to take your SMTP server down to let a mailbomb attack subside, you should probably do it for a week. My experience tells me that, even though you might make your SMTP server unavailable for a couple of days, you will still get those emails that were undelivered during that time. Most SMTP servers have a feature where it will keep messages in it's queue for a little while (usually around 3 days) before it will give up and bounce the message. SMTP is nice that way, because if you need to bring your server down for whatever reason (perhaps to do maintenance or an upgrade), chances are you will not miss any emails while you are down. But if your getting bombed it can be a two-edged sword.

Hope this helps.

Robert...

lol that is funny

Without using a loop in the script the reason you probably got a 1000 emails and counting is because the from and to addresses are the same. This can create an infinite loop, though normally it happens if something is mis-configured.

Note the script is not powerful you are using sendmail to do all the work, all the script does is send information to sendmail, you can do this in any shell scripting language or any language; you are just piggy backing on sendmail.

open(MAIL, "|/usr/sbin/sendmail -t");

Attempts to use the sendmail protocall to send the "print MAIL" lines... Sendmail cannot send them as the proggy is disabled, therefore the "print MAIL" lines go to the mqueue. This is of course, not where perl wants to send them, so it tries again... and again... and again... never reaching the line :


close(MAIL);

correctly the line should read : open(MAIL, "|/usr/sbin/sendmail -t") or die('could not open sendmail');
to kill the process if there is a failure on OPEN. possibly an EVAL statement to see if sendmail is running at all...

still not sure if I would test the script, seeing as how you had soooooo many problems with it... over 4,000 emails waiting to be sent? Perl is supposed to run fast, but WOW!

<steps off soapbox>

There is nothing special about MAIL any name could be used.

It doesn't use the sendmail protocol directly it just prints to the | sendmail defined by MAIL.

sendmail could be replaced with any program, it is just a generic way to maintain a pipe to any program in Perl.

Yes, you should die it though to be fair it does not look like that was the case and sendmail will send a mail without being in daemon mode.

Anyway, even if the MAIL file handler was magical you would still need to loop that many times for it to be the source of the problem.

If you did not loop and you get 1000s of emails then you have triggered an infinite loop in your setup.

It happens like this:

Message gets sent to you@127.0.0.1 (toaddr)
There is a problem with receiving the mail that generates a return message.
That Message gets sent to you@127.0.0.1 (fromaddr)
There is a problem ...
That Message gets sent to you@127.0.0.1 (toaddr)
There is a problem ...
That Message gets sent to you@127.0.0.1 (fromaddr)

Now normally this cycle does not occur if the to and from are different, though it can happen still.

People use to do this quite often to themselves, especially when first trying to work out how to deal with spam, Postfix appears to have cured it happening more recently but I suspect anyone using raw sendmail could quite easily slip up.

Though if you did loop it then that is more likely to be the problem, but if it is the receive problem then you need to address that (forgive the pun) or you are just storing it up for yourself again.