SMTP relaying policies for Commercial ISP customers...?

Andy Dills andy at xecu.net
Fri Feb 13 22:19:14 UTC 2004


On Fri, 13 Feb 2004, Leo Vegoda wrote:

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

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

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---





More information about the NANOG mailing list