On Thursday 15 September 2005 18:08, Sam Varshavchik wrote: > James Wilkinson writes: > > Guy Fraser wrote: > >> ...snip... > >> Mail servers do not generally accept a DATA command if the RCPT > >> command produces an error, so the rest of the headers are not > >> looked at. The proper response is to respond with a user > >> undeliverable error. > > > > That assumes that the receiving server knows that the address is > > unknown. > > > > Very often (as with westexe.demon.co.uk), the MX (server to which > > e-mails get sent initially) is owned by a big ISP (in my case Demon > > Internet), which doesn't know which addresses on westexe.demon.co.uk are > > valid. So it has to accept all e-mails to westexe.demon.co.uk. > > Tough cookies. > > Poor network design/configuration is not a valid excuse for a > denial-of-service attack. > > I have several thousand IP addresses blacklisted, for trying to flood me > with bounces to forged spam. > > Any mail server bouncing forged crap to me, for any reason, gets > blacklisted. End of story. > > > In this case, the relevant standards (RFC 821 and 2821) say that since > > the e-mail has been accepted but can't be delivered, a bounce message > > *must* be sent. (These days, there's enough spam and viruses about that > > this is no longer considered best practice.) > > Correct. > > > In general, it's not easy to program a MTA to be sufficiently sure that > > an e-mail *is* faked that it can drop it. > > Actually it is. I've designed my mail server so that it should never > generate backscatter. Even due to traditionally difficult to anticipate > situations, such as a mailbox over quota. > > It's not rocket science. It can be done. It has been done. How do I blacklist an I.P. ?
