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
