This one time, at band camp, Stephen Frost said: > * Stephen Gran (sgran@debian.org) wrote: > > 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. I wouldn't really advocate using secondary MX's these days, and certainly not ones not ones not under your control. If you need redundancy, I'd use a load balancer with a server farm behind it. They can all share access to the same database for greylisting purposes that way, and you get better failover. Secondary MX's tend to just be spam targets and rarely serve any real use. If you must have a seperate secondary MX (you don't have the hardware resources, or whatever) I would really strongly advocate that you find a way to get a list of valid users from the primary onto the secondary - all the bounces when the primary comes back up and spam starts failing are part of the problem. > > 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. We did pre-whitelist about 50 or so known good hosts, determined the old-fashioned way, with grep, sed, sort, and uniq -c. As always, we missed several, but they got added automagically. This is one of those situations where it is hard to always know programatically what's going to come up, and so that's where the importance of an auto whitelister come in. For instance, we had almost no hits from Southwest airlines MX before the switchover, and then they opened a hub in Philadelphia. We started getting a ton of emails from them, since they're so cheap - they're the US answer to Ryan air. They also happen to use VERP for their notification emails, so _all_ of their mail was delayed until the auto whitelister added them after a day or two. > > 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. That is just stupid, and he probably shouldn't be bothering to try and run a mail server, much less complain that people are hitting his secondary. There are other good reasons for introducing delays, and they are effective, but the above idea is just retarded. > 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. I can't disagree there. I guess what I'm trying to say is, I understand your misgivings, beause people implementing most anything can manage to do it in a really stupid, painful and harmful way. That doesn't necessarily mean the idea is unsound. Greylisting is, itself, a one-trick pony. It will lose it's effectiveness whenever spammers get around to implementing queues on their zombie clients. OTOH, admin'ing an MTA these days is an arms race, and a new weapon can be a lot of help. Take care, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
pgp2u29kXmXWR.pgp
Description: PGP signature