Subject: [Ietf-not43] use case: unwanted email

From: [email-masked] (Liu, Hong)
Date: Fri, 12 Apr 2002 12:44:04 -0500

Andrew,

I have a number of comments regarding this use case:

(1) The real issue in this use case is about finding out the contact
information of a DNS delegation. This is a general problem regarding stale
contact information in a registry. I am not sure the federated name scheme
will solve the problem any better than a thick registry approach. It really
boils down to having all registrants cooperate, be it through their own
servers or through registry policy.

(2) The argument against the thick registry approach is questionable. The
single point of failure can be resolved by a registry that deploys redundant
whois servers.

(3) It seems that the need to collect information from various sources other
than the registry itself is a legacy problem primarily related to thin
registries. We are well aware of this problem in the .us locality space and
we are in the process of consolidating the information using a thick
registry approach. I am not so sure how frequent this happens to domain
names under .us, as opposed to those under other more popular thin
registries. I would suggest that the reference to .us in the use case be
replaced by a more generic term such as "thin registry".

(4) It is possible to associate multiple contacts with a domain in EPP.
There is no limit in the protocol regarding how many contact objects can be
associated with a domain object. So if a registrant so chooses to have a
different contact for handling email abuse, it can create an additional
admin contact for that purpose. Of course, EPP does not define a contact
type as "email abuse", but it does relieve the "single contact problem"
mentioned in your email.

Cheers,

--Hong

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]]
Sent: Friday, April 12, 2002 12:50 PM
To: [email-masked]
Subject: [Ietf-not43] use case: unwanted email

As noted in the BoF minutes, concensus was that 3 use cases be
developed.  Here is the first one.  Comments and questions welcomed.

Use Case: Unwanted E-mail From A Domain

Description:

Actor A is receiving a large amount of e-mail from Actor B.  This e-mail
contains large attachments and is of no use or desire to Actor A. 
Requests to have the e-mail stopped have gone unanswered or bounce with
error messages indicating the mail box for Actor B is full.  Actor A
would like to contact a technical administrator.  Actor A would also not
like to resort to such tactics as blocking all e-mail from Actor B's
domain as it would block very important e-mail from other addresses with
that domain.

Problem Statement #1:

Actor A is unfamiliar with the .us domain and does not know the name of
the administrative information server.  There is no prescribed method
for him to determine the name of any server for any domain.

Possible Solutions to #1:

A) A registering authority for all administrative information servers
can be setup to be the central repository for all the server names.  The
possible risk to this solution is that it places too much power into the
hands of a single organization and also risks being a central point of
failure for all administrative information lookups.

B) A naming scheme could be defined to standardize how the names are to
be found and allow for the use of other advanced features that can be
offered by use of the best common practices of a modern, federated
naming system.

Problem Statement #2:

The contact information held at the registering authority for the
technical contact of Actor B's domain contains only a disconnected phone
number.

Possible Solutions to #2:

A) Defer to a policy statement to fix the problem.

B) Define a mechanism to allow referrals to a registrant's information
server.  Some registrants may opt to run one of these and therefore may
be more inclined to keep it up to date.  In addition, they may decide to
offer more information than would be collected or distributed by the
registering authority, such as a separate e-mail address to send e-mail
abuse or problems versus just an e-mail address for a domain contact.

_______________________________________________
Ietf-not43 mailing list
[email-masked]
http://lists.research.netsol.com/mailman/listinfo/ietf-not43

---

From: [email-masked] (Andrew Newton)
Date: 12 Apr 2002 14:45:20 -0400

> servers or through registry policy.

No, you have mixed two of the problem statements with one of the
solutions.  The first problem is that a user does not know where to
start looking.  The second problem is about the delegations.

> single point of failure can be resolved by a registry that deploys redundant

And who is going to run this uber whois server?  It would make more
sense to take advantage of an existing infrastructure than to build a
new one.  The problem isn't just how I follow the information from
registry to registrar, but also how do I find the proper registry in the
first place.

> replaced by a more generic term such as "thin registry".

First off, I'm sorry that .us slipped in there.  I orginially was going
to use some-country.big-state.us as an example for a problem statement
concerning a non-functioning whois server, but I decided to take it
out.  I guess I missed the references to it.

Second, I just checked with my local Internet historian and he assures
me that thick registries walked the earth first.  This possibly places
them in the category of "legacy".

Third, you are right that the reference to .us should come out (see
above).  However, I don't believe the problem is specific to thin or
thick registries.  I just tried the "smart" whois client that comes with
Mandrake 8.2 on fairfax.va.us.  It's answer "This TLD has no whois
server."

> type as "email abuse", but it does relieve the "single contact problem"

And if registry X decides they don't care to publish such information or
even keep it around...  Besides, what is wrong with allowing registrants
the ability to have their own server in this system?  I know that if I
could do it for my domains, I would be much more likely to keep that
info up to date.  And I'd also have the ability to restrict its use as I
see fit.

-andy