I think this feature is already in there,
change bounce-no-mailbox to delete. So for example
.qmail-default would contain.
| /home/vpopmail/bin/vdelivermail '' delete
Ken Jones
Matt Simerson wrote:
I would like to see a new option available to the vdelivermail program.
Currently it can be given a parameter such as "bounce-no-mailbox" or a
directory to deliver messages to. I'd like to be able to deliver messages
that have no match in the vpasswd file to a filename (/dev/null in
particular). Here's why:
On Friday afternoon a domain that we host email for started getting pounded.
This is an older system running sendmail and we had over 50 different SMTP
servers connecting to this customers IP. We were seeing about 3 sendmail
processes per second and sendmail, being the bloated pig that it is, brought
the machine to it's knees when scores of sendmail instances were being
opened. The machine was hammered so hard that we couldn't even get a couple
of the messages through to see what was being delivered and causing the
problem.
My boss asked me what could be done about it. Since there wasn't any quick
easy fix I had him update the DNS for the domain and point all the mail for
that domain to my new, about to be implemented, mail system running qmail,
vpopmail, and friends. I set up his domain, created the six email users he
had and sat back and watched. Within minutes the SMTP traffic on my machines
started picking up and within 5 minutes I was seeing 30 concurrent
connections so my mail server. Since it wasn't sweating, I decided to see
how high I could go with it and cranked up the limit to 1000 sessions.
Within minutes my dual PIII650 machine was starting to get sluggish. I shut
down qmail and changed the limit to 300 and fired it back up. I was handling
300 connections OK and I took a peek at the queue. In a few minutes I had
accumulated over 13,000 messages in the queue.
Rather than letting the messages accumulate in the queue (it was trying to
bounce the message but there wasn't a valid reply-to) I created a "spam"
account for the domain as the default delivery box. This worked quite nicely
as it routed all the messages into the spam box and gave us a chance to take
a look at what was bombarding us. However, it would only take a couple
minutes for before "rm *" failed bacause there were too many files in the
directory.
Since I couldn't bounce the messages and we wanted this poor customers mail
to work despite the DOS attack (of sorts), I decided to route all the
messages to /dev/null. This way we're not queueing them or making a huge
mess to clean up. My first attempt was to put a filename (/dev/null) in the
.qmail-default file as a vdelivermail parameter. This caused vdelivermail to
core dump so I speculated that that wasn't such a good idea. All I wanted to
do was get the spam users mail routed to /dev/null instead of a mailbox.
What I ended up doing was creating a new .qmail-user1, .qmail-user2, etc..
file for each of the users that had the same contents of the stock
.qmail-default that calles vdelivermail. This got each of the users mail
accounts working and then I created a new .qmail-default that contained the
name of the file I wanted to deliver mail to "/dev/null" and my problem was
worked around. However, I'd like some method of doing this that doesn't
require a person to ssh into the server and manually create files in order
to do this.
Ultimately what was happening was a spammer sent a LOT of mail out using
bogus reply-to addresses containing our customers domain. As the spam got
bounced, it returned to his mail server and brought the thing to it's knees.
So, we couldn't just deny the connections, RBL that I'm using can't catch
them because the connections are from valid non-relaying mail servers, and I
can't bounce them because they don't have a valid from/reply to header. :-(
I'm going to patch qmail-smtpd to not accept emails that don't have a valid
return address but the only other solution I can see is just accepting and
routing to the bit bucket any emails known to be invalid.
Comments? Ideas?
Matt
