ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [ga] Some Wild-Card Questions

  • To: "Jeff Williams" <jwkckid1@xxxxxxxxxxxxx>
  • Subject: RE: [ga] Some Wild-Card Questions
  • From: "Chuck Liggett" <chuckl@xxxxxxxx>
  • Date: Wed, 17 Sep 2003 12:28:16 -0400
  • Cc: <ga@xxxxxxxx>
  • Importance: Normal
  • In-reply-to: <3F67B8A4.E1CAE2EA@ix.netcom.com>
  • Sender: owner-ga@xxxxxxxxxxxxxx

Here are two specific problems related to the Wild-Card functionality as
implemented by Verisign:

1.  Anti-spam Problems
	
	One of the methods of filtering out a portion of UCE is to verify that
	the envelope sender address of a mail message resolves to a valid
	domain name.

	The Wild-Card functionality now renders that test useless for .com and
	.net domain names.


2.  Mail Routing Problems

	Consider this scenario:

	My e-mail address is:   user@xxxxxxxxxxxx

	Mail routed to somehost.com is specified as follows:

		MX 10	  mail.3rdparty.com
		MX 20	  mail.backupserver.com


	This means that mail that is destined for my mailbox will be accepted
	by the mail server "mail.3rdparty.com".

	If, for any reason, their mail server is not reachable, the mail will
	be spooled up on the backup mail server, "mail.backupserver.com".

	The order of processing is determined by the value after the MX -- the
	lowest number MX (Mail Exchanger) record is the ``Primary'' mail server,
	and all larger numbered MX record are ``Backup'' mail servers.


	** BEFORE WILD-CARD FUNCTIONALITY **

	If the domain name 3rdparty.com would expire and not be resolvable,
	mail would properly spool on the backup mail server, mail.backupserver.com.

	Then, when the owner of 3rdparty.com realizes that they aren't getting any
	incoming mail they investigate and give the registrar money, and then a day
	or two later, the spooled mail gets delivered.


	** AFTER WILD-CARD FUNCTIONALITY **

	If the domain name 3rdparty.com would expire and not be resolvable,
	it would now be resolvable -- mail.3rdparty.com would equate to IP address
	64.94.110.11.

	The Internet would then try to send the mail to that server.
	** VERISIGN HAS A MAIL SERVER RESPONDING ON THAT SERVER **
	Header: 220 snubby4-wcwest Snubby Mail Rejector Daemon v1.3 ready

	They will take the mail and reject it with a permanent 550 error, completely
	ignoring the backup mail server.

Sincerely yours,
Chuck Liggett
Operations Manager
N2Net
(216) 619-2000 x.116




-----Original Message-----
From: owner-ga@xxxxxxxxxxxxxx [mailto:owner-ga@xxxxxxxxxxxxxx]On Behalf
Of Jeff Williams
Sent: Tuesday, September 16, 2003 21:28
To: Michael D. Palage
Cc: ga@xxxxxxxx
Subject: Re: [ga] Some Wild-Card Questions


Michael and all former DNSO GA members or other interested parties,

  Glad to answer your questions below.  However this was an issue
last june-aug. and I have to wonder why the ICANN BoD and staff
ducked it than or did not listen to the comments solicited and provided.

Answers to your questions below...

Michael D. Palage wrote:

> Hello All:
>
> Because the ICANN Board may be required to address this issue in the future,
> I will not comment publicly at this time. Listed below are some of the
> questions that I have identified as relevant in my personal analysis, and
> which I would like input from the community.
>
> (1) Does the use of wild-cards threaten the stability of the Internet, if so
> how (specific examples not generalization)?

  No.

>
> (2) Does the use of wild-cards adversely impact competition in the
> marketplace, if so how?

 No.

>
> (3) Can these stability/competition issues be addressed by best practice
> standards that would still permit the use of a wild card service by a
> registry operator?

 No.

>
> (4) How is the use of wild-cards similar or different to the WLS service
> previously proposed by VeriSign?

  I can't see any that are significant. However WLS is a bad idea.

>
> (5) What protocols does the use of wild-cards violate? Specifically, does
> the use of Wild Cards violate RFC 1034, 1035, and 2182 as VeriSign is
> required to comply with these RFCs in Appendix C of its Registry Agreement.

  None that I am aware of.  However there may be a need for such
should be generated if the stakeholder/user community believes that
and RFC to prevent the use of wild cards or allow under certain
specific conditions.

>
> (6) If the use of wild-cards threaten the stability of the Internet why did
> ICANN allow the incorporation of a wild card service into the .MUSEUM
> registry contract?

  Who know why ICANN allowed .MUSEUM as a TLD to be created
in the first place...

>
> (7) If the use of the wild-cards threaten the stability of the Internet, why
> do several ccTLD operators currently utilize this feature?

  Because they want to?

>
> (8) If the use of wild cards threaten the stability of the Internet, should
> their prohibition be enforced across gTLD and ccTLD registries, if so how?

  No.

>
>
> Best regards,
>
> Michael D. Palage
>
> P.S. And in response to Andy Gardner's question
> http://any-signs-of-life-within-icanns-current-board-of-directors.net/ I
> would submit that the answer is yes :-)

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard
===============================================================
CEO/DIR. Internet Network Eng. SR. Eng. Network data security
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@xxxxxxxxxxxxx
Contact Number: 214-244-4827 or 214-244-3801






<<< Chronological Index >>>    <<< Thread Index >>>