In article <telecom24.256.11@telecom-digest.org>,
TELECOM Digest noted in response to Joseph <JoeOfSeattle@yahoo.com>:
> On Tue, 07 Jun 2005 03:27:55 GMT, [Telecom Digest Editor] writes:
>> [TELECOM Digest Editor's Note: I would like to ask you just one
>> question: _Why_ can't a registrar be expected to screen potential or
>> actual spammers? If registrars started doing that, they'd be heros
>> in the eyes of most netters. PAT]
> If you're going to use that logic you might as well use it on the
> telephone company for selling service to fly-by-night boiler room
> scamsters in South Florida and Montreal as well.
> [TELECOM Digest Editor's Note: One small problem with your logic.
> Telco is a common carrier; they are required by law to supply service
> to _anyone_ asking for service on the condition the potential
> subscriber has demonstrated an ability and willingness to pay for
> the service. Registrars are not common carriers, they are free to
> accept or reject customers at will; for most of them, all that seems
> to matter is getting the ten dollar fee every couple years or so. That
> should not be the case. Registrars could be our front line defense
> against spammers/scammers/phishers if the netters and or ICANN
> demanded it. But of course, ICANN won't demand anything. They _like_
> things the way they are now. And of course there is always some
> idiot who will speak out and say "oh, but if we were to impose on
> Itzy-Pooh Corporation and refuse to carry their traffic because of
> the huge amount of spam they overlook, why then Itzy-Pooh may sue
> some registrar or something like that." All I can say to that is
> God Bless America and God Bless ICANN. Lets begin to turn the screws
> on the registrars and get them contractually committed to a few
> simple facts: If Itzy Pooh gets bounced by some registrar for
> malfeasance, no other registar can touch him until whatever got him
> bounced in the first place gets cured. PAT]n
Of course, spammers/scammers/phishers can, and *do* use raw IP addresses,
without having domain-names attached. So can anybody else. e.g.
http://208.31.42.81/index.html or mailto:esteemedmoderator@[208.31.42.98]
Thanks to the wonders of HTML, unsophisticated readers need never _see_
the above forms, you do something like
a href=http://208.31.42.81/>Telecom Digest or
a href=mailto:esteemedmoderator@[208.31.42.98] email Patrick Townson </a>
or fatuously:
email a href=mailto:esteemedmoderator@[208.31.42.98]
AlGore@whitehouse.gov/
Domain-names are not necessary. They are simply a 'convenience'.
Is 'directory assistance' (a non-common-carrier, *non-regulated*
ancillary service for the PSTN) responsible when you get telemarketing
calls? or harassment calls?
Is _directory assistance_ responsible for checking out the 'history'
of the person who buys into having their name 'indexed' in the
database? ILEC telephone service usually includes getting entered
into the database. CLEC telephone service often does *NOT*.
Frequently you have to order that separately, sometimes via the CLEC,
sometimes directly from the ILEC. Just like the way you can get your
non-ILEC, or even VOIP number listed in the ILEC 'white pages' phone
book.
Registrars serve an essentially identical function to 'directory
assistance'.
[TELECOM Digest Editors' Note: No, directory services are not
responsible for that type of phone call. But we can and do prevent
that type of phone call by having our numbers unlisted/non-pub. And
I do not agree that the registrar serves an 'essentially identical'
function. One difference might be that telco makes the number assign-
ment and _forwards_ that information to the various directory services
where no single entity tells the registrar what numerics will be
applied; the registrar simply assigns the requested name and tells
the root servers to deal with the names. If no registrar ever listened
to you and assigned the name you wanted, thus no root servers would
ever know of that name, then how would anyone be able to reach you
_by number only_ if the root servers did not know what to do with
the number?
Robert Bonomi (bonomi@host122.r-bonomi.com)