SMTP relaying policies for Commercial ISP customers...?
Ejay Hire
ejay.hire at isdn.net
Fri Feb 13 21:30:33 UTC 2004
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 at merit.edu [mailto:owner-nanog at merit.edu]
On
> Behalf Of Dan Ellis
> Sent: Friday, February 13, 2004 11:55 AM
> To: Andy Dills
> Cc: nanog at 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 at xecu.net]
> > Sent: Friday, February 13, 2004 12:35 PM
> > To: Dan Ellis
> > Cc: nanog at 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
> > ---
More information about the NANOG
mailing list