I wasn't giving any advices to you, obviously you don't need them ;) Other, I know we are a bit off-topic, sorry, but it's interesting topic, isn't?
If you don't piss somebody or make them jealous they won't have a need to attack you either.
Yes. However, sometimes you don't have the choice. E.g. call-centers makes people angry.
Which might mean they cut your service as clearly you will be affecting also the availability of their other clients...
Depends which. Some are fair and able to deal with it, more or less. However, then you can probably sue them.
That, but there is an easier and much more effective DDoS: hit the page that is 'heavy to produce'. The mere simple factor problem: they sent you something small, you need to do a lot of work and/or give a big result. If that can be triggered then the site goes down, because 10.000 hosts asking the heavy page will bring it to its knees. As such, for those heavy ones, have separate infrastructure available.
Oh yes. The slashdot (digg) effect has killed many hosts. However, a good idea is always to host static on a server for static content (with a light, low footprint memory and secure web servers on medium boxes) and host the dynamic on a high-end. We end at the last tip I wrote, if you know your code, you can probably void lots of queries and heavy calculation of page generation with caching (any kind of, proxy, cache, APC, etc).
Won't help you much if you don't actually provide a way to read that mail from the second MX, mail will nicely get queued yes, but you won't be able to read it... (sync between the two MX's and running IMAP on both solves that, maildir filenames are unique, you just need to glue in the sync also in the imap daemon so that the sync doesn't restore files
;)
Loads of hosters pretend having network gears that will stop all attacks (Rackspace, Softlayer, Gigenet, Staminus) to name a few. Some are bulletproof, other just lampoon themselves few days after announcing having, mhh *so-great* protected networks. No trolling..., common I promise ;)
You can indeed strip the 'local' headers so that internal infrastructure is hidden. But then those external relays will still be hit. Better have large amount of them. Also, this basically comes down to doing the distribution of your servers /
If you have a DSL line, leave the public-facing servers to the hosters mentioned ^ they will handle it. They probably have more chances to survive than your poor tiny ZyXEL CPE.
Cheap solution: get some el-cheapo 'root' servers, install bind or your preferred DNS server, install pound (for the record I love it ;) or varnish if you want caching, then hide your master server in a dark corner of the Internet.
That's the concept I was developing before. Have public facing servers somewhere and hide yourself somewhere else when your capacity is small (ok no need to say, don't make sense to host a webserver if you run a DSL line indeed ,).
Now, when somebody attacks one out your 20 cheap ones, just remove them from DNS. They would then have to ddos all 20 have them, possibly at various ISPs to get them all down. Users will only notice a minor annoyance during the time DNS changes. Of course DNS becomes your vulnerability, thus, just register all your hosts as NS glue. The target then becomes the TLD servers (which might not be nice).
SME can't really afford 20 servers. But at least, they can move the weakness a step ahead, they don't have to deal with the packets, hosters will if they pretend it's their job and use it as selling point ;)