[67592] in North American Network Operators' Group
RE: SMTP relaying policies for Commercial ISP customers...?
daemon@ATHENA.MIT.EDU (Dan Ellis)
Fri Feb 13 12:55:19 2004
Date: Fri, 13 Feb 2004 12:54:42 -0500
From: "Dan Ellis" <ellis@corp.ptd.net>
To: "Andy Dills" <andy@xecu.net>
Cc: <nanog@merit.edu>
Errors-To: owner-nanog-outgoing@merit.edu
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. =20
As always, comments welcome.
--
Daniel Ellis,=A0CTO, 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...?
>=20
>=20
> On Fri, 13 Feb 2004, Dan Ellis wrote:
>=20
> > 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,...).
>=20
> While the amount of effort you put into this so far is 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 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 is relaying =
spam
> through you, so you can react.
>=20
> 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.
>=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 "(expensive) relay
> services" to send mail through your mail server. How many 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 support staff's =
faces
> when you tell them they need to assist your ENTIRE USER BASE in =
switching
> to authenticated SMTP :)
>=20
> And then you have to deal with the customers who have MTAs that don't
> support authenticated SMTP...and on and on.
>=20
> Whenever the solution is more expensive than the problem, you need to =
go
> back to the drawing board.
>=20
> Andy
>=20
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
