RE: SMTP relaying policies for Commercial ISP customers...?

["Ejay Hire" <ejay.hire () isdn net>]

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: owner-nanog () merit edu [mailto:owner-nanog () merit edu]
On 
> Behalf Of Dan Ellis
> Sent: Friday, February 13, 2004 11:55 AM
> To: Andy Dills
> Cc: nanog () merit edu
> 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:andy () xecu net]
> > Sent: Friday, February 13, 2004 12:35 PM
> > To: Dan Ellis
> > Cc: nanog () merit edu
> > 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
> > ---