|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: SMTP relaying policies for Commercial ISP customers...?
You could use AOL's tactic and transparent proxy all outbound port 25 traffic. Then it'd be a relatively simple matter to add mr. spammer's ip to a hosts.deny. If you were really big-brother, you could do real-time Beaysean scanning to identify "suspicious" hosts. -Ejay > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Dan Ellis > Sent: Friday, February 13, 2004 11:55 AM > To: Andy Dills > Cc: [email protected] > Subject: RE: SMTP relaying policies for Commercial ISP customers...? > > > Andy, > These are exactly my concerns, and exactly what I feel I'm > going to hear from the staff and the customers. I am going > to go back and make sure there isn't a "better" solution. > Thanks for the input. > > The issue we have as a dynamic IP broadband provider is that > it's a royal pain to shutdown a user - especially in regards > to just mail. Lets say we have a spammer and a script > detects it. We then have to track him back to the MAC address > of the modem, lookup that MAC in the customer DB, shutdown > his access and then reset the modem. And at the end, he > loses all access, not just mail. With AUTH we can just stop > mail access. Yeah, sure we could try to push some access > list to the modem itself, blocking mail, but those modems are > so flaky to start, it'll never work reliably. Can't just > block the IP on the mail server because the user will or > could just get a new IP, and then you are blocking a legit user. > > > I'm still not sure if the norm is for providers to let t1+ > customers relay. I have multiple OC3's and 12's from AT&T, > MCI,... Will they let me relay off their servers without > SMTPAUTH? Probably not. > > As always, comments welcome. > > -- > Daniel Ellis,�CTO, PenTeleData > (610)826-9293 > > "The only way to predict the future is to invent it." > --Alan Kay > > > > -----Original Message----- > > From: Andy Dills [mailto:[email protected]] > > Sent: Friday, February 13, 2004 12:35 PM > > To: Dan Ellis > > Cc: [email protected] > > Subject: Re: SMTP relaying policies for Commercial ISP customers...? > > > > > > On Fri, 13 Feb 2004, Dan Ellis wrote: > > > > > 1) Residential Policy: Enable SMTPAUTH and > disallow relaying > > > unless the customer has a valid username/password. If > you're not paying > > > for a mailbox, you don't get to relay outbound. This > should not break > > > anything except those residential accounts that *should* > be commercial > > > anyway. > > > > > > 2) Broadband commercial: This is the difficult one. > These are the > > > customers that aren't big enough to rightfully run their > own mailserver, > > > but they are big enough to have roaming users on their > networks (coffee > > > shops, branch offices, hotels, SOHO....). They expect > relaying service > > > for either their mailserver or for all their various > PC's. At the same > > > time, they don't have many, if any mailboxes through the ISP. My > > > thought is that they should ONLY be allowed to relay via > SMTPAUTH by > > > using a residential mailbox login/pass OR they need to purchase a > > > commercial relay service (expensive because of the > openness of it) for > > > their IP space. > > > > > > 3) T1+ : These customers should not be allowed to > relay unless > > > they purchase (expensive) relay services for their IP > space. Of course, > > > they can always use a residential mailbox, but will have > to use SMTPAUTH > > > for it and will be restrained by the same policies > residential mailboxes > > > have (low tolerance tarpitting,...). > > > > While the amount of effort you put into this so far is > commendable, I > > really think you're barking up the wrong tree. > > > > At the end of the day, what have you done, besides annoy > your customers > > and increase the load on your support staff? > > > > I don't really see what you're suggesting being anything > other than a huge > > effort, solving the wrong problem. > > > > For any responsible ISP, the problem is the spam coming into your > > mailservers, not leaving. As long as you quickly castrate > the people who > > do relay spam through you, you're not going to have an egress spam > > problem. > > > > Since you seem to have countless hours to invest in this > problem, you'd be > > better off writing a log parser to identify WHEN somebody > is relaying spam > > through you, so you can react. > > > > Something else I've seen implemented is rate limiting. Keep > track of the > > number of messages sent by an IP over a variable amount of time and > > implement thresholds. > > > > > > I'd love to hear some of the conversations you have with > your leased line > > customers, when you tell them they have to pay for > "(expensive) relay > > services" to send mail through your mail server. How many > times will they > > laugh before hanging up on you? :) > > > > That's like the IRS trying to charge you for the forms... > > > > And I'd also like to see the looks on your technical > support staff's faces > > when you tell them they need to assist your ENTIRE USER > BASE in switching > > to authenticated SMTP :) > > > > And then you have to deal with the customers who have MTAs > that don't > > support authenticated SMTP...and on and on. > > > > Whenever the solution is more expensive than the problem, > you need to go > > back to the drawing board. > > > > Andy > > > > --- > > Andy Dills > > Xecunet, Inc. > > www.xecu.net > > 301-682-9972 > > ---
|