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

Mailman List Mirror (Read Only)
1

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.

2

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.

Yes, that is a little bit stickier of an issue, IFF your goal is to
somehow continue to provide the would-be spammer with the ability to send
traffic to the net, provided it doesn't transit your mail server. I feel
that you're overlooking the simple solution. Blocking the entire account
so they can't access anything is the proper response to a spamming
incident.

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.

I'm almost positive they would. Hell, many providers will give you a free
NNTP feed if you want it. The goal is to maximize the use of the link
between you and the customer while minimizing the use of the links between
you and other networks. Services like SMTP and NNTP are great for that.

Andy

3

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

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

> 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...?

>
>
>
> > 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? :slight_smile:
>
> 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 :slight_smile:
>
> 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,

4

You wrote:

[...]

Yes, that is a little bit stickier of an issue, IFF your goal is to
somehow continue to provide the would-be spammer with the ability to send
traffic to the net, provided it doesn't transit your mail server. I feel
that you're overlooking the simple solution. Blocking the entire account
so they can't access anything is the proper response to a spamming
incident.

If you block the entire account then the user can't use the account
to download the updates your Abuse Team will responsibly want to
point him/her at. If you want to lose the customer then that's your
business. If you want to keep the customer, helping them fix their
mistakes is probably a painful and thankless task - but important
and useful to the whole Internet community.

Regards,

5

Leo Vegoda wrote:

If you block the entire account then the user can't use the account
to download the updates your Abuse Team will responsibly want to
point him/her at. If you want to lose the customer then that's your
business. If you want to keep the customer, helping them fix their
mistakes is probably a painful and thankless task - but important
and useful to the whole Internet community.

It is probably worth mentioning that numerous malware today make an effort to block an user from accessing AV or windowsupdate sites after infection. Also, if you mirror the software as a courtesy, you�ll run into interesting copyright issues.

Pete

6

What about http://www.nanog.org/mtg-0402/gauthier.html

After seeing that presentation, I wondered if an ISP could get away with
something similar. Eric has the advantage of being the monopoly service
provider for the dorms.

7

RFC1918 is your friend, as is making internal copies of windowsupdate
patches and virus removal tools.

But even then, I would block 100% of access until we establish customer
contact and are sure that the issue will be dealt with. Then, I would
re-enable them on RFC1918 space, assist them in rectifying their problem,
and then re-enable the rest of their account.

This doesn't result in lost customers. This results in appreciative
customers, even if they were blocked when they had the problem. If you
don't block them, most people will never know until they've spewed gigs.

Andy

8

) 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

You may also need to filter inbound packets with a source port of 25, or any
other ports you capture.

As I believe has been mentioned here before, some spammers may use a dialup
account just for its IP address, collecting return packets on the dialup
interface but sending the actual content through some higher-bandwidth,
unfiltered pipe. Filtering what goes out over the dialup account would be
largely ineffective in this case, as nothing actually needs to be sent
through that interface for the transmissions to succeed.

9

I know of at least one ISP that does similar, Onramp.net in Austin
TX. I'm a corporate IT Mgr and one of my remote users is an
Onramp customer that had ancient NAV on his personal PeeCee and
caught whatever worm was in vogue a few months back.

He is not a particularly computer savvy person, but he is not a
luser either. He was quite pleasantly surprised at the service,
once he realized what was going on.