[63685] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Wired mag article on spammers playing traceroute games with trojaned boxes

daemon@ATHENA.MIT.EDU (Jeremy T. Bouse)
Thu Oct 9 12:56:08 2003

From: "Jeremy T. Bouse" <Jeremy.Bouse@UnderGrid.net>
Date: Thu, 9 Oct 2003 09:35:27 -0700
To: nanog@merit.edu
Mail-Followup-To: nanog@merit.edu
In-Reply-To: <6.0.0.22.2.20031009121657.02df7760@mail1.tellurian.com>
Errors-To: owner-nanog-outgoing@merit.edu



--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	I can kinda agree with this idea for the most part. In past ISP
environments I've worked in and had input in decisions we did redirect
SMTP traffic back to our mail servers or blocked out-right access to
mail servers outside our control but there were always some special
cases. Just as stopping residential broadband customers from hosting
servers. I know in my personal situation I do have servers hosted on my
residential ADSL connection, but this is known by the provider and I'm
also paying for a static subnet that they're hosted on. I think for the
general dynamically addressed broadband connections this might be a wise
idea, but for those that are paying for static IPs or even static
subnets those blocks should be left alone. Granted this would probably
include most cable modem and a fair amount of DSL customers.

	Regards,
	Jeremy T. Bouse

On Thu, Oct 09, 2003 at 12:19:37PM -0400, Vinny Abello wrote:
> Personally, I think preventing residential broadband customers from hosti=
ng=20
> servers would limit a lot of that. I'm not saying that IS the solution.=
=20
> Whether or not that's the right thing to do in all circumstances for each=
=20
> ISP is a long standing debate that surfaces here from time to time. Same =
as=20
> allowing people to host mail servers on cable modems or even allowing the=
m=20
> to access mail servers other than the ISP's.
>=20

--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/hY5OzbdYcZyFNB8RAp+jAJ0Yu8lRsKKO6LKCSCOkhEo6xWi32QCcCPL8
SVisW4lTZRKvdWOxCILIXag=
=5ZWM
-----END PGP SIGNATURE-----

--vkogqOf2sHV7VnPd--

home help back first fref pref prev next nref lref last post