[67596] in North American Network Operators' Group
RE: SMTP relaying policies for Commercial ISP customers...?
daemon@ATHENA.MIT.EDU (Ejay Hire)
Fri Feb 13 16:34:42 2004
From: "Ejay Hire" <ejay.hire@isdn.net>
To: "'Dan Ellis'" <ellis@corp.ptd.net>,
"'Andy Dills'" <andy@xecu.net>
Cc: <nanog@merit.edu>
Date: Fri, 13 Feb 2004 15:30:33 -0600
In-Reply-To: <E989917C9FF25240A201E888E83DF32F01462981@EXCHANGE5.corp.ptd.net>
Errors-To: owner-nanog-outgoing@merit.edu
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=20
> 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...?
>=20
>=20
> 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=20
> to go back and make sure there isn't a "better" solution.
> Thanks for the input.
>=20
> The issue we have as a dynamic IP broadband provider is
that=20
> it's a royal pain to shutdown a user - especially in
regards=20
> to just mail. Lets say we have a spammer and a script=20
> detects it. We then have to track him back to the MAC
address=20
> of the modem, lookup that MAC in the customer DB, shutdown
> his access and then reset the modem. And at the end, he=20
> loses all access, not just mail. With AUTH we can just
stop=20
> mail access. Yeah, sure we could try to push some access=20
> list to the modem itself, blocking mail, but those modems
are=20
> so flaky to start, it'll never work reliably. Can't just=20
> block the IP on the mail server because the user will or=20
> could just get a new IP, and then you are blocking a legit
user.
>=20
>=20
> 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,=20
> MCI,... Will they let me relay off their servers without=20
> SMTPAUTH? Probably not. =20
>=20
> As always, comments welcome.
>=20
> --
> Daniel Ellis,=A0CTO, PenTeleData
> (610)826-9293
>=20
> "The only way to predict the future is to invent it."
> --Alan
Kay
>=20
>=20
> > -----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...?
> >=20
> >=20
> > On Fri, 13 Feb 2004, Dan Ellis wrote:
> >=20
> > > 1) Residential Policy: Enable SMTPAUTH and=20
> 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=20
> should not break
> > > anything except those residential accounts that
*should*=20
> be commercial
> > > anyway.
> > >
> > > 2) Broadband commercial: This is the difficult
one.=20
> These are the
> > > customers that aren't big enough to rightfully run
their=20
> 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=20
> 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=20
> SMTPAUTH by
> > > using a residential mailbox login/pass OR they need to
purchase a
> > > commercial relay service (expensive because of the=20
> openness of it) for
> > > their IP space.
> > >
> > > 3) T1+ : These customers should not be allowed
to=20
> relay unless
> > > they purchase (expensive) relay services for their IP=20
> space. Of course,
> > > they can always use a residential mailbox, but will
have=20
> to use SMTPAUTH
> > > for it and will be restrained by the same policies=20
> residential mailboxes
> > > have (low tolerance tarpitting,...).
> >=20
> > While the amount of effort you put into this so far is=20
> commendable, I
> > really think you're barking up the wrong tree.
> >=20
> > At the end of the day, what have you done, besides annoy
> your customers
> > and increase the load on your support staff?
> >=20
> > I don't really see what you're suggesting being anything
> other than a huge
> > effort, solving the wrong problem.
> >=20
> > For any responsible ISP, the problem is the spam coming
into your
> > mailservers, not leaving. As long as you quickly
castrate=20
> the people who
> > do relay spam through you, you're not going to have an
egress spam
> > problem.
> >=20
> > 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=20
> is relaying spam
> > through you, so you can react.
> >=20
> > Something else I've seen implemented is rate limiting.
Keep=20
> track of the
> > number of messages sent by an IP over a variable amount
of time and
> > implement thresholds.
> >=20
> >=20
> > 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=20
> "(expensive) relay
> > services" to send mail through your mail server. How
many=20
> times will they
> > laugh before hanging up on you? :)
> >=20
> > That's like the IRS trying to charge you for the
forms...
> >=20
> > And I'd also like to see the looks on your technical=20
> support staff's faces
> > when you tell them they need to assist your ENTIRE USER=20
> BASE in switching
> > to authenticated SMTP :)
> >=20
> > And then you have to deal with the customers who have
MTAs=20
> that don't
> > support authenticated SMTP...and on and on.
> >=20
> > Whenever the solution is more expensive than the
problem,=20
> you need to go
> > back to the drawing board.
> >=20
> > Andy
> >=20
> > ---
> > Andy Dills
> > Xecunet, Inc.
> > www.xecu.net
> > 301-682-9972
> > ---
