This one time, at band camp, Stephen Frost said: > * Adrian 'Dagurashibanipal' von Bidder (avbidder@fortytwo.ch) wrote: > > On Friday 26 November 2004 03.34, Stephen Frost wrote: > > > * Adrian 'Dagurashibanipal' von Bidder (avbidder@fortytwo.ch) wrote: > > > > > > > > And, of course, postgrey as the very first line of defense. > > > > > > Things which increase the load on the remote mail servers are *bad*. > > > That would include responding with temporary errors unnecessairly and > > > adding unnecessary delays in communication. Things which slow down my MTA are equally bad. > > Add to the the fact that amongst the mail senders big enough so that the > > queue size matters are probably many of those ISPs with badly policed > > (DSL/cable) network, operating the spam zombies which cause me to use > > greylisting in the first place... > > That's a *terrible* and just plain stupid assumption. Queue size makes > a difference to me, both on a machine I run for some friends and in the > part-time work that I do for a small ISP (which, hey, doesn't even > provide DSL or cable modem service). Queue size matters to universities > who are draconian about their policing, and I'm sure it matters to the > 'good' ISPs too. Of course queue size matters. I don't think that's what he's saying though. He's saying that those organizations that are that big are also a source of a lot fo the spam flying about. Not %100 true, but there is some correlation. A sensible greylisting scheme will auto-whitelist a sending IP after so many whitelisted entries (successful retries) - the only point of greylisting is that we know that the remote end won't retry in most cases. Once it's been shown that they do retry, why bother greylisting them anymore? If you do implement this sort of scheme, any extra load you place on the remote end is transient, and will go away shortly, never to be repeated. It's not really a large price to pay for a pretty effective tool. > Let me tell you that if you use that greylisting crap against the > servers that *I* run your mail will get dumped into a secondary queue > which is processed at a much slower rate. I won't slow things down for > others because of a few idiots who can't figure out how to configure > their mail servers. Take a deep breath, and count to ten. I handle some fairly large mail installations at work, and greylisting has been of tremendous benefit to us. If it's done sensibly (as above) it does transiently increase load on remote MTA's for a couple of days until the common sending IPs have been whitelisted, and then it settles back down. > > About pipelining: what postfix does is enforce proper use of pipelining: the > > sender may only start pipelining requests when it has actually seen that > > postfix does support pipelining. Regular mail servers never notice this, > > but some stupid spammers just push the request out without waiting for > > responses at all - these are rejected. > > That'd be why I said that pipelineing isn't really an issue but adding > in random unnecessary delays is bad, which is something that's been > advocated in a number of places and ends up increasing the load on my > mail servers. Introducing delays is usually only advocated for fairly egregious and obvious spam-like tactics (HELO as my IP/hostname, etc). If you're doing that, then you deserve to be a little overloaded. If you're running a reasonably sensible MTA, then you should never trip those kinds of checks. If people are delaying a sensible MTA, then they deserve to be LART'ed for doing something silly, but the practice itself isn't unreasonable. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
pgpGfguDkmpn1.pgp
Description: PGP signature