* Stephen Gran (sgran@debian.org) wrote: > This one time, at band camp, Stephen Frost said: > > 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. The problem is that it's probably not even 20% true. There really isn't any correlation. There are lots of good ISPs and other service providers who are big enough that queue size matters to them but which aren't sources of spam. > 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. A system which didn't increase the load on the remote mail servers would be better. Having whitelisting w/ greylisting is better but I still don't like it. What about secondary MX's? How is the greylist going to work with those, a seperate list, or will they be unified? Will it correctly pick up on and whitelist a server that goes for a secondary MX after getting a temporary error at the first? Of course, I've run into people who have had secondary MX's configured incorrectly to the point where it drops mail, or refuses to forward the message on, etc. You can understand that I'd have my doubts about the ability of people to implement a scheme such as this. > > 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. Hey, it's how my mail servers are configured- if you're too slow to respond or the mail doesn't leave the main queue fast enough for whatever reason it'll get dumped into a slower queue that's run less often. It wasn't a threat. :) > 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. Perhaps it would have made sense to look at your logs and whitelist those hosts ahead of time. Sounds like you know what you're doing- that wouldn't be hard. > > > 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. Unfortunately I had someone complain at me that my mail servers kept going to their secondary MX, turns out it was because he had a forced 2 minute delay before responding to HELO and my mail server wasn't waiting around that long. He had it because some website (the mailer was exim, iirc) was advocating it and encouraging people to do it for all incoming connections. The problem is that some people *are* silly, or stupid, and schemes like this often end up misused, misconfigured, and implemented wrong. That's why I don't like them. Stephen
Attachment:
signature.asc
Description: Digital signature