David and Matt- Congratulations, David, on finding and implementing the best way to deal this issue. I own a hosting company in the DC area, and StarPower here is doing the same thing that you are. Now if only we could get Verizon, Comcast, RR and the others to follow suit, things could be a lot better.
Verizon took the opposite approach. They refuse to provide SMTP transport unless they host the domain, and they leave their entire system open on port 25. This was done in the name of "spam reduction" about two years ago. All it did was force me into the SMTP AUTH business to cut down traffic on their mailservers. And, oh yeah, the marketing implications of the move were not lost on me. We did not lose a single customer to this scam, but it took a lot of effort since we have a large number of customers who use Verizon DSL for access. I thought the RFCs required access providers to provide outbound SMTP transport for all their customers. The access providers, after all, are the only ones who know whether the senders are legit. So either I'm wrong, or Verizon is. Matt, I went through a lot of the same arguments with my StarPower customers. Once they understand that security and spam control requires that they use StarPower's SMTP service, they are very cooperative and happy to make the adjustments. We are fanatical about customer service, and I will have a tech talk a customer through the email setup, even if it takes an hour. We've been in business since 1995, and we never provided SMTP transport until Verizon's move. -Dave Doherty Skywaves, Inc. ----- Original Message ----- From: "David Daniels" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 12, 2003 7:12 PM Subject: Re: [Declude.JunkMail] Outbound Port 25, was -> Virginia Indicts > Dynamic IP's is exactly where it should be done, that's where most of the > spam comes from. As far as serving your customers goes it's easy enough to > open a hole for a customer with a legitimate reason to use a remote mail > server. Any action is going to be a pain for someone, that's the reason spam > is so rampant. In the interest of free and open communication we've let > things get too lax. Sometimes for good reason. It would be great to use > reverse DNS or rather the lack of as a reason to reject mail but this > results in rejecting mail from not only the new or clueless admin but also > the many whose providers don't give them control of their reverse DNS. > Blocking port 25 will accomplish nearly as much with a lot less pain I > believe. Most customers simply don't have the need to use a remote SMTP > server and one line in an access list will take care of those who do. It's > more trouble for the provider for sure yet if enough people did it the > resulting savings in spam control would make up for it many times. > > Road Runner is one that should do it by the way. We get a lot of spam from > their dynamic IPs. They should have no trouble doing a DNS entry and > opening port 25 for a paying business customer. > > David Daniels > System administrator > Starfish Internet Service > [EMAIL PROTECTED] > > ----- Original Message ----- > From: "Matthew Bramble" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, December 12, 2003 5:25 PM > Subject: Re: [Declude.JunkMail] Outbound Port 25, was -> Virginia Indicts > > > > Has anyone considered the trouble this causes to remote mail hosts? > > First this has caused many calls from my fairly small customer base > > whenever someone starts all of a sudden blocking port 25. Secondly, it > > limits my capabilities as I can no longer handle their outgoing E-mail. > > Third, this creates issues where things like slow ISP mail servers, > > blocked E-mail and other issues related to the ISP impact my business > > regardless of my ability to control it. > > > > If an ISP is going to do this as a practice, they shouldn't do it from > > dynamic addresses, and they should have a simple method of asking that a > > static IP be allowed to use port 25. > > > > If Road Runner ever did this to me, I would be gone the next day even if > > I had to deal with slower speeds with DSL. This is a very bad idea, and > > it's a kluge of a fix for what should be done through monitoring and > > action only on those that cause problems. ISP's should be proactive in > > monitoring for zombied machines and shutting off certain ports to them > > when found. I know that some large ISP's do this type of thing already, > > but there needs to be some products that the smaller ISP's also > > integrate so that the blunt-force method doesn't stop companies like me > > from better serving business customers. If the trend keeps up, I'll > > probably look at ways to accept SMTP connections over port 80 as a work > > around, but that expense comes out of my pocket for no good reason IMO. > > > > Matt > > > > > > > > > > Burzin Sumariwalla wrote: > > > > > I was thinking of something much simpler... > > > > > > Verifying that the IP appears in a MX record > > > Verifying that Reverse DNS is set > > > > > > Basically the RFC ignorant stuff... > > > > > > Of course your network would have to deal with traffic before shunning > > > it. :( > > > > > > I like your idea much better. > > > > > > Burzin > > > > > > > > > > > > At 01:10 PM 12/12/2003, you wrote: > > > > > >> If ISPs would block outbound port 25 that would go a long way towards > > >> keeping spam. Right now most of our spam is coming from cable and DSL > > >> IPs. > > >> We block outbound port 25 except from our mail servers and a couple of > > >> customers who have a legitimate reason to use another mail server. If > > >> so we > > >> open a hole to that mail server only. It's done on a case by case > > >> basis. Is > > >> it a pain in the ass? Most certainly but if any spam leaves our > > >> network it > > >> will be easy as hell to track. It really burns my ass to be spammed > from > > >> these networks because the provider is either too lazy or incompetent > to > > >> block these ports. > > >> > > >> David Daniels > > >> Administrator > > >> Starfish Internet Service > > >> [EMAIL PROTECTED] > > >> ----- Original Message ----- > > >> From: "Burzin Sumariwalla" <[EMAIL PROTECTED]> > > >> To: <[EMAIL PROTECTED]> > > >> Sent: Friday, December 12, 2003 1:22 PM > > >> Subject: OT: [Declude.JunkMail] Virginia Indicts Two Men On Spam > Charges > > >> > > >> > > >> > I agree with you. The statement was more general than it should have > > >> > been. Personally I think the ISP route > > >> > is one of the best places to begin active anti-spam measures at.... > > >> (Sorry > > >> > ISP admins). If legislatively, ISPs > > >> > can be forced to have customers adhere to strict RFC compliance and > if > > >> > legislatively ISPs can be forced to take > > >> > consistent and strict measures it might force spammers into smaller > > >> and > > >> > smaller corners. > > >> > > > >> > I don't represent and ISP, so maybe I'm being to optimistic. > > >> > > > >> > > > >> > Burzin > > >> > > > >> > > > >> > > > >> > At 10:59 AM 12/12/2003, you wrote: > > >> > >The only people that will hit the spammers' pocketbooks are the ISPs > > >> getting > > >> > >together and forcing them out of their jobs... or to get people to > > >> stop > > >> > >buying their stuff! > > >> > > > >> > ------ > > >> > Burzin Sumariwalla Phone: (314) 994-9411 x291 > > >> > [EMAIL PROTECTED] Fax: (314) 997-7615 > > >> > Pager: (314) 407-3345 > > >> > > > >> > Networking and Telecommunications Manager > > >> > Information Technology Services > > >> > St. Louis County Library District > > >> > 1640 S. Lindbergh Blvd. > > >> > St. Louis, MO 63131 > > >> > > > >> > --- > > >> > [This E-mail scanned for viruses by Declude Virus] > > >> > > > >> > --- > > >> > [This E-mail was scanned for viruses by Declude Virus > > >> (http://www.declude.com)] > > >> > > > >> > --- > > >> > This E-mail came from the Declude.JunkMail mailing list. To > > >> > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > > >> > type "unsubscribe Declude.JunkMail". The archives can be found > > >> > at http://www.mail-archive.com. > > >> > --- > > >> > [This E-mail scanned for viruses by Declude Virus] > > >> > > > >> > > > >> > > >> --- > > >> [This E-mail scanned for viruses by Declude Virus] > > >> > > >> --- > > >> [This E-mail was scanned for viruses by Declude Virus > > >> (http://www.declude.com)] > > >> > > >> --- > > >> This E-mail came from the Declude.JunkMail mailing list. To > > >> unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > > >> type "unsubscribe Declude.JunkMail". The archives can be found > > >> at http://www.mail-archive.com. > > >> --- > > >> [This E-mail scanned for viruses by Declude Virus] > > > > > > > > > ------ > > > Burzin Sumariwalla Phone: (314) 994-9411 x291 > > > [EMAIL PROTECTED] Fax: (314) 997-7615 > > > Pager: (314) 407-3345 > > > > > > Networking and Telecommunications Manager > > > Information Technology Services > > > St. Louis County Library District > > > 1640 S. Lindbergh Blvd. > > > St. Louis, MO 63131 > > > > > > > > --- > > [This E-mail was scanned for viruses by Declude Virus > (http://www.declude.com)] > > > > --- > > This E-mail came from the Declude.JunkMail mailing list. To > > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > > type "unsubscribe Declude.JunkMail". The archives can be found > > at http://www.mail-archive.com. > > --- > > [This E-mail scanned for viruses by Declude Virus] > > > > > > --- > [This E-mail scanned for viruses by Declude Virus] > > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. > --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
