Date: Thu, 10 Mar 2005 03:44:33 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Charles Swiger" <cswiger@mac.com> Cc: freebsd-questions@freebsd.org Subject: RE: how to deal with spam for good? Message-ID: <LOBBIFDAGNMAMLGJJCKNAELDFAAA.tedm@toybox.placo.com> In-Reply-To: <c26183b94fad2e2da6b0e029a1e388b1@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Charles Swiger [mailto:cswiger@mac.com] > Sent: Thursday, March 10, 2005 2:17 AM > To: Ted Mittelstaedt > Cc: freebsd-questions@freebsd.org Questions list > Subject: Re: how to deal with spam for good? > > > On Mar 10, 2005, at 4:49 AM, Ted Mittelstaedt wrote: > > This is bullshit, milter-greylist is in the ports. Greylisting > > does not require postfix. Just because YOU are too lazy to > > understand sendmail doesen't mean everyone else is. > > I've paid my dues to sendmail: > > http://groups-beta.google.com/groups? > &as_ugroup=comp.mail.sendmail&as_uauthors=Chuck+Swiger > > ...shows about 900 postings from me. As of sendmail-8.11, and even > early 8.12's perhaps, greylisting via sendmail wasn't possible > because > the MILTER API didn't support it. FreeBSD 4.EIGHT came with Sendmail 8.12.8 out of the box. OK, so now your not too lazy to understand Sendmail, you just have a gigantic chip on your shoulder against it so your going to ignore the most popular MTA on the planet and pretend it doesen't exist. Fine, just don't contaminate anyone else particularly a newbie. > If the situation has been improved > and you can greylist with sendmail now, that's fine. > Not a question of -if-. > What isn't fine is your attitude: FOAD. > I FOAD any technical idea that the cure is as bad or worse than the disease. Spammers waste everyone else's network resources for their own gain. A greylist on a mailserver, particularly a busy one, causes an enormous waste of bandwidth because every legitimate mailserver that is sending to you has to re-initiate the connection to you - meaning they have to send the same handshake packets all over again that you had properly received in the beginning. If you have a small mailserver that processes few mails you might argue that this is of no consequence to the rest of the world and be correct. But if you have a large mailserver, the amount of bandwidth chewed up on the Internet by this kind of a trick, espically if everyone in the world does it, you can perhaps see that greylisting is nothing more than a scheme to waste other people's resources and bandwidth for your own personal gain. The differences between spammers and greylisters is very thin indeed. > > Keep in mind that Greylisting isn't going to be very effective > > for long if a lot of people adopt it. > > Your opinion differs. > Yup, and since my opinion is based on logic, and yours (apparently) is based on emotion, your opinion is worthless and mine is valuable. That's the case until you start substantiating your opinion with some logical explanations of how Greylisting is going to scale to the entire Internet. Remember, unless everyone on the Internet can run a greylist, it is nothing more than an elitist solution that works for a few people at everyone else's expense. > > If our customer's coorespondent cannot get mails from us and from > > hotmail, how long do you think he's going to put up with his ISP > > running a greylist? > > If a customer isn't happy with you, they'll take their business > elsewhere. > Lord knows I wouldn't blame them, either. > Are you being deliberately dense? I'm not talking about OUR customer I'm talking about the coorespondent of our customer and his relationship with his ISP. On the Internet there are a handful of ISPs or ASPs or whatever you call them who send out _enormous_ numbers of _legitimate_ mail. AOL, is one, Hotmail is another, MSN is another. Long, long before greylisting starts wasting too much of our bandwidth it will be wasting huge amounts of bandwidth of these companies. They are not going to want that, and they are going to retaliate. And the easiest way of retaliating is when they identify a greylisting mailserver, to just stop even attempting to send mail to it. Particularly hotmail, which has NOTHING WHATSOVER to lose since they give out e-mail accouts FOR FREE. Do you think that Hotmail gives a shit if some puffed up crumb announces to them that they are pulling their e-mail account out of Hotmail and finding another ISP because Hotmail has stopped delivering mail to greylisters? Of course not. And in the meantime the other 99% of hotmail subscribers that cannot send mail to the greylister - well they are too stupid to understand what good e-mail is (otherwise why do you think they have hotmail accounts to begin with) and they will simply swallow it when Hotmail blames the greylisters mailserver, they will then complain to their coorespondent who is using the greylister, and that coorespondent even if he loves his ISP's greylisting mailserver, if he wants to keep getting mail from the moron hotmail users, he's going to tell his ISP to knock it off with the greylisting. I an sorry you don't seem to understand this. It is possibly all because it is part of what is called SCALABILITY in networking. Greylisting is NOT scalable. It ONLY WORKS if a few people running very low volume mailservers do it. It will fall apart if a lot of people try adopting it, particularly ones that pass a lot of mail. And from a moral standpoint it is almost as wasteful of bandwidth as the spam. > > Long before this happened of course the spammers would mod their > > software to simply start retrying more. If you think about it, if > > they are sending a million mails a minute, and the greylist delay is > > 5 minutes, they merely need to construct a server that stores 5 > > million mails for a set period and then retries. The server > never has > > to store more than 5 million mails at a time. > > Let them retry more. There is more than one way to deal with > UCE, and > shifting the burden to the spammers, making them consume lots of time > for minimal resources is amoung those ways. > And of course, you raise the retry limit on your greylist server, the spammers raise theirs and get past your filter, you raise it again, they raise it again, and on and on. And in the meantime the amount of everyone else's bandwidth that you two are consuming with your urination festival just goes up and up. When does it end? Remember, spammers AREN'T wasting THEIR bandwidth. Spammers today almost always are spamming from hijacked Windows systems on the cable network, or other places. From the spammers point of view they have unlimited free bandwidth available to them. They will always win in any kind of bandwith contest. Filters based on bandwidth pissing matches are doomed to failure. And I see your next argument, it's the fault of those Windows users that didn't patch their OS. yeah, right, it's the fault of the guy who forgot to lock his car that his car got stolen. It's the fault of the woman who walked outside her apartment late at night that she got raped. Sure, greylisting is working great now, because hardly anyone is doing it. Content filters worked fantastic a few years ago when most spam consisted of these gigantic turd e-mails that carried hundreds of lines of encoded gif files, html, and every other damn thing. Oh boy there was tons of content in those mails for a filter to trigger on. Then once everyone started content filtering the spammers started shrinking down their mails until today, half the spam coming in consists of about 4-5 lines of text and a URL, if even that. Content filters don't work so hot anymore when there's hardly any content to filter. Greylisting will go the same way. The difference though is that content filters forced the spammers to consume less bandwidth to compete, which is a desirable side effect. Greylisting on the other hand forces the spammers to waste more and more bandwidth, which is a very undesirable side effect indeed. > > It's just one more anti-spam filter that is utterly dependent on > > nobody else on the Internet doing it. Typical bright idea from some > > tech somewhere that understands just enough of the SMTP standards to > > cause a lot of trouble for people. > > Someone whose SMTP engine is unwilling to retry delivering > email after > the first response is refused with a 4xx code is the one failing to > understand RFC-822/2822. Real mailers retry at a recommended 1 hour > interval for a recommended maximum queue length of 5 days, per RFC. We already have our retries set to every 4 hours - because 90% of the outbound stuff that fails is bounces to bogus mailservers, 9% of it is misspellings of addresses by our customers, and it's a waste of mailserver cycles to bother retrying it. And the few times that a legitimate mailserver is down, it's down for a lot longer than 1 hour - usually because the system admin is putting it back together after some problem. I've also thought of reducing the max queue hold time as well - because today, people send things by e-mail that they consider so incredibly time sensitive that if the mail isn't delivered in one day, they prefer that it gets bounced to them right away so they can resend to the correct address or take other measures. The thing that is holding me back is there are a lot of 3 and 4 day weekends since a lot of businesses move holidays to Friday and Monday. > Once you've whitelisted your clients and covered 95+% of > incoming mail, > up your greylisting time from 5 to say, 59 minutes, works wonders. > Totally unscalable for an ISP. What happens is that your customers are more than happy to give you e-mail addresses of their coorespondents for you to whitelist - but when they stop cooresponding with those people they never tell you. So your whitelist files NEVER get smaller, they just get bigger and bigger and bigger, forever. Once again, this works only if the mailserver is small. Like a personal server. I'm sure that this scheme is great for people running their own mailserver in their home. > > The only long term solution that is going to work is modding the > > DNS records to designate an official SMTP server for each > domain, such > > a plan has been in the works for a while among the standard bodies > > that know what they are doing. > > SPF is another way of dealing with UCE. > > It's not hard to find people who have implemented SPF in their DNS, > either. > I haven't seen it do much good as yet... > No, because it is a solution that requires everyone to participate (or at least most everyone) Fortunately though, the Internet is getting more and more professionally run every day. While it is pretty unrealistic to expect for a solution like SPF to be widely deployed if the Internet is just run by a bunch of amateurs (which was the case from about 1998-2002, when all the wannabes climbed on) nowadays I think most ISP's either have plans for eventual deployment of it, or they have it deployed already. Consider how long it took for blacklisting to catch on. I think that today everyone running a mailserver of any size is using one (most likely more) blacklist server. I remember when we first started using one, and we used the most conservative one in the bunch, orbs. We still got a few complaints from our customers who couldn't receive mail. I spent a lot of time trying to educate other moron sysadmins of other ISP's what an open relay was and why their running one was a Bad Thing. Now, though, years later, orbs is pretty useless and we use a lot more much more agressive blacklists. And we never get customer complaints anymore, except perhaps one every 3-4 months. And when we explain what is going on, they understand immediately, and their coorespondent understands immediately, and their coorespondent's ISP fixes it immediately. In short, blacklist servers are now an accepted thing. Unfortunately, though, the side effect of the blacklist servers has been for spammers to start releasing viruses that create open smtp relays, then building giant arrays of virus-infected systems. Well at least the one good thing that came out of that was to wipe that simper off Mr. Gates face about how secure his cardboard OS was. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNAELDFAAA.tedm>