Re: [ga] Some Wild-Card Questions

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Chuck and all former DNSO GA members.

Chuck Liggett wrote:

> 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.

  perhaps.  And than again perhaps not.  Any wild card can be part of any
potential Domain name, ergo making it a valid one.

>
>
> 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".

  I am not sure what you are talking about here...

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

  Ah.  No not necessarily depending on how the mail.backupserver.com is
configured.

>
>
>         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.

Understood.  But this too is overcomable also as I think you know.

>

>
>
>         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.

  This should not and need not occur simply because of the use of Wild Cards.

  Understand however I am not advocating using wild cards...  I do
believe that stakeholders/users need to make this decision as a matter
of policy or practice...  Hence my original response..

>
>
> 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

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