[29884] in North American Network Operators' Group
Re: RBL-type BGP service for known rogue networks?
daemon@ATHENA.MIT.EDU (Dana Hudes)
Sun Jul 9 00:56:45 2000
Message-ID: <013501bfe961$ca43be40$3d5cdcd1@hudes.org>
From: "Dana Hudes" <dhudes@hudes.org>
To: <rmeyer@mhsc.com>
Cc: <nanog@merit.edu>
Date: Sun, 9 Jul 2000 00:54:39 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: owner-nanog-outgoing@merit.edu
The solution is not to open relays but to use an IPSEC tunnel into the =
internal network. Or you could use SSH port forwarding to accomplish the =
same thing.
If you open relays, the spammers will find and abuse them.
IPSEC clients and servers are available commercially. Nortel Networks =
Contivity Extranet Gateway is one, and Nortel use it themselves.
Shiva have a similar product.
----- Original Message -----=20
From: "Roeland M.J. Meyer" <rmeyer@mhsc.com>
To: <rdobbins@netmore.net>; <petervd@vuurwerk.nl>; <nanog@merit.edu>
Sent: Sunday, July 09, 2000 12:24 AM
Subject: RE: RBL-type BGP service for known rogue networks?
>=20
> Roland (first off, you're missing an 'e' <g>),
>=20
> I agree. MHSC lost an entire market plan, hosting third-party
> secure mail, becasue third-party mail services must allow
> relaying that is at minimum semi-open. At the time SMTP AUTH
> didn't exist (Until it's use becomes more wide-spread it still
> isn't real useful). The anti-relay bunch are killing a valid
> business model. Even for internal use, we have staff, on
> client-site, that need to send/recieve their mail from our
> servers, even when their lap-top is DHCP attached to another
> net-block. Every week we find ourselves having to open the relays
> more and more. Next week, I am travelling to the EU on business.
> That's yet more net-blocks that I have to allow relaying from.
>=20
> A single ORBS forged header, with the right source info in it,
> will pass right through our mail system, like it was greased. The
> whole anti-relay jihad is a fallacious rat-hole populated by
> rabid self-righteous rats who don't have a clue. If they don't
> need it then it must not be a valid feature <humph!>. ORBS itself
> should be RBL'd, IMHO.
>=20
> Using the same sort of mind-set to subjectively BL script-kiddee
> networks is dangerous, as the ORBS bunch has shown. It is all too
> easy for it to get out of hand, vigilante-style. What are the
> criteria and who has the over-sight?
>=20
> That said, having had a few of our production hosts "owned", by
> mwsh in the past, I am NOT fond of script-kiddies and agree that
> something needs to be done. But, I am seriously resistant to yet
> another ORBS style regulator bunch. That is NOT the answer.
> Please, let's all look for another solution.
>=20
> ---
> R O E L A N D M . J . M E Y E R
> CEO, Morgan Hill Software Company, Inc.
> Tel: (925)373-3954
> Fax: (925)373-9781
> http://staff.mhsc.com/rmeyer
>=20
>=20
>=20
> > rdobbins@netmore.net: Saturday, July 08, 2000 11:03 AM
> >
> > ORBS forge headers (thereby violating the RFC) to look as if
> > they're coming
> > from domains you host, then if it goes through, they put you
> > in their little
> > black book for being an 'open relay'. No notice, nothing.
> >
> > The problem with this is that for hosting-only providers like
> > my firm, it's
> > blatantly unfair. We have thousands of users residing on
> > networks (lots of
>=20
> > encourage them to use IMAP, it's like herding cats to get any
> > substantial
> > percentage doing anything other than basic POP and SMTP.
> >
> > POP-before-SMTP isn't viable for the same reason that it's
> extremely
> > difficult to get people to use IMAP; to wit, users tend to
> > resist change.
> > In a corporate environment, you can force remote users to use
> > additional
> > authentication mechanisms, as long as you're willing to set
> > them up and
> > train the users. Out here in the world, though, if you come
> > down on people
> > over something which forces them to change the way they do
> > things in any
> > substantial way, they vote with their feet and go to some
> > other provider who
> > not only doesn't secure his mail relay, but ignores spam
> > complaints, as
> > well.
>=20
>=20
