On Wed, Jul 10, 2002 at 03:39:34PM -0400, Dean Anderson wrote: > I think that there isn't a lot of open relay abuse, relative the the > amount of spam in general. Occasionally I get spam with relays, or with > apparently obviously forged headers, but those relays don't appear to be > unauthorized. That is, the spam is sent though relays run by the spammers
Your experience isn't everyone's experience, but even if only 20% of spam were sent through open relays, blocking them at the SMTP level would save you from having to deal with that 20%... > There are number of false claims promoted by the open relay people: Its > tough to argue with these people because then they abuse your servers, so > you don't see much of this disputed on a "spam" forum. But that doesn't > make it true. And accusing all "open relay people" of "abusing your servers" in a forum doesn't make it true either. > 1) Open relay are free. I've spoken with a lot of open relay operators, > and none are free. I don't know where these free relays are. I have found You haven't spoken to anyone in Asia ... There's a lot of open relays there (I block most netblocks in China for this,) mostly unprotected Solaris boxes with an ancient version of sendmail running. Open relays, on average, are free. Some aren't, they're aborations. > a few non-spammers using our relays without permission. They have said > they found our relay on the 'net. The only places I could find with our > servers were the open relay rbls. You do realize the RBLs are public, so if someone wants to find an open relay they can just make a few queries and get listings, right? I mean, heck: lynx --dump http://www.kluge.net/mailfiltering/access.txt | grep 'open relay' | awk '{print $1}' That'll get you a list of over 700 IPs which are open relays. It's not difficult to find these things if you search around a little. > Consider these: > > Customer has leased line from us. so they'll have a certain netblock you can restrict relaying for, don't need an open relay. > Customer wants backup domain service for its domain on our servers. We > won't have accounts for all employees. We just queue any mail for that > domain until their servers come up. That's not an open relay. > Next consider: > > Customer has employees who travel, use their clients access, but want to > send mail with their domain, not clients domain to make sure replies go to > them not client. > Customer needs open relay, but doesn't want hassle of protecting open > relay server. > We provide customer with open relay. Unless they block what mail gets sent out of their network, you don't need an open relay for this. > Next consider: > > Customer has DSL Line from provider Vzn > Vzn doesn't give static IP > Vzn doesn't allow relay for non-vzn domain. > We provide open relay for Customer. > In this case, if the customer is one or two people, SMTP Auth could be > used, or a web client could be used. More than that and its impractical, > and stupid if you already have open relay. Circular reasoning: If I already have an open relay, I don't need to think about how to solve it without an open relay. "Vzn doesn't allow relay for non-vzn domain" implies "Vzn requires mail to go through their mail server". If so, your open relay is useless. If they don't require using their server, the can't restrict who you send mail to -- good candidate for relay after pop/imap. > Note that domain restrictions are still open relay. The only way to > "close" open relay is by address restrictions, smtp auth, or pop before > smtp. Correct on domain restrictions, correct idea on closing open relays (there are many ways to close them, mostly leaving it closed and opening it only as necessary.) > I'll bet most of the 293 were actually generated by the open relay people. I think all 293 were from you. I can't prove it, and you can't prove your statement either. There's really no point in continuing this discussion. -- Theo Van Dinter, [EMAIL PROTECTED][EMAIL PROTECTED] Consultant, Collective Technologies (www.collectivetech.com) Systems Administrator, bblisa.org/kluge.net --- Send mail for the `bblisa' mailing list to `[EMAIL PROTECTED]'. Mail administrative requests to `[EMAIL PROTECTED]'.
