Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Feb 1999 02:12:12 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        jooji@webnology.com (Jasper O'Malley)
Cc:        tlambert@primenet.com, billf@chc-chimes.com, Cy.Schubert@uumail.gov.bc.ca, freebsd-chat@FreeBSD.ORG, onemo@jps.net
Subject:   Re: ports/9864: make rblcheck use relay.orbs.org instead  of
Message-ID:  <199902040212.TAA16218@usr02.primenet.com>
In-Reply-To: <Pine.LNX.4.02.9902031913001.22594-100000@mercury.webnology.com> from "Jasper O'Malley" at Feb 3, 99 07:45:29 pm

next in thread | previous in thread | raw e-mail | index | archive | help
] > Not at all.  ISP's that provide dynamic IP instead of static IP
] > just have to provide a relay server with a static IP for their
] > customers.
] 
] What prevents someone from spamming through the relay then?

The fact that they agreed to penalties when they obtained their
account, one of which is losing their account, and therefore
subsequent net connectivity.


] What does the DUL provide, then, that the RBL cannot?

Among other things, it provides severe tire damage to the thin
server market, and screws people out of the two legitimate
uses for relay, while at the same time requireing an impossibly
large static IP address space.

On the plus side, it promotes deployment of IPv6 (years away, in
any case, even with breaking legitimate users email), and promotes
deployment of a RADIUS/DDNS connection.

Unfortunately the only RADIUS/DDNS connection product on the market
is Microsoft's IAS, and it looks like it is going to be a long time
before there is a pubblic reference implemetnation, given the
various licensing issues of the varius RADIUS implemetnations.


So I guess the DUL also provides a nice incentive for legitimate
ISP's to implement using Microsoft products, instead of UNIX
products.


] > The only "prejudice" here is against non-accountable IP addresses.
] 
] They're non-accountable whether or not the DUL exists. Whether or not you
] spam directly from a dialup or through a relay, it's equally easy (or
] difficult) to catch you.

No it isn't.  There is a header footprint for the whole route.  If
you can't read it, give it to someone competent, or download one of
the freeware ustilities, like the "tracker"(sp?) Perl script.

If the source ISP won't enforce AUP against the sender, then throw
the ISP in the hole.  Otherwise the sender is blown, and the problem
is solved.


] > Really, Paul needs to not be running RBL, per se, but instead signing
] > weekly certificates for mail servers that aren't in the database.  If
] > someone SPAMs, then they don't get their certificate signed.
] 
] An opt-in for every mail server on the Internet?

No.  Mail servers that don't opt in will fail to send the certificate
to servers that have opted in.  Part of opting in for these servers
is to be configured such that they ask the RBL "if this host had
asked for a certificate, would you have signed it?".  In other words,
the exchanges is either:

-----------------------------------------------------------------------
	SMTP		|	Opt-in			| Certificate
	client		|	server			| Authority
-----------------------------------------------------------------------
	EHLO		->
			<-	...
			<-	250-CALLERID
			<-	...
	CALLERID ...	->
			<-	250 Certificate is current
	MAIL FROM:	->
			<-	250
			...

or it's:

	EHLO		->
			<-	...
			<-	250-CALLERID
			<-	...
	MAIL FROM:	->
				Trust this schmo?	->
							<-	Yes
			<-	250
			...
-----------------------------------------------------------------------

Pretty obvious, once it's spelled out.

Clients that don't upgrade can send mail, but it takes them longer
to get their "MAIL FROM:"'s "250" response than it would have had
they been upgraded to get the certificates themselves.


Things like the RBL really aren't that scalable to the entire
Internet, until they become non-protocol centric (e.g., they
are integrated to deny *all* services, not just SMTP) and they are
widely deployed (perhaps as many RBL servers as normal DNS servers).

People will always be able to "tunnel" information through "free
email" providers like "HotMail".  Burning a free email account
from a shell account logged in via a dialup address is little
different than burning an ISP account directly from a dialup
address.

How does DUL address account burning?  A certificate approach
causes netblock burning, which in the long run is a hell of a lot
more expensive than account burning.

					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902040212.TAA16218>