Re: [ga] Some Wild-Card Questions

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

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

  First off RFC's and not standards, they are Requests for Comments,
which begs a couple of your other "Examples" Below.

  Second TTL can be set.MX records is one likely approach, but
not the only one, to be sure...

  Third, yes changing

Chuck Liggett wrote:

> Jeff and All:
>
> Please see my rebuttal of Jeff's comments regarding my previous
> mail on how the Verisign implementation of Wild-Carding has
> damaged Internet Mail processing.
>
> As you will see by my final comment in this message, Verisign
> can correct the Mail Routing problems that they are introducing
> by their implementation of Wild-Carding.
>
> > -----Original Message-----
> > From: owner-ga@xxxxxxxxxxxxxx [mailto:owner-ga@xxxxxxxxxxxxxx]On Behalf
> > Of Jeff Williams
> > Sent: Wednesday, September 17, 2003 21:38
> > To: Chuck Liggett
> > Cc: ga@xxxxxxxx
> > Subject: Re: [ga] Some Wild-Card Questions
> >
> >
> > 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...
> >
>
> Let me give you this example:
>
> Suppose I work for a small company, and I have outsourced my E-mail
> services to a Mail Hosting Provider.  My company has registered the
> domain name 'somehost.com', and the Mail Hosting Provider that I have
> contracted to perform the services of running an Internet mail server
> has assigned the handling of mail for my domain to the mail server
> 'mail.3rdparty.com'.
>
> Suppose I want a different Mail Hosting Provider to handle backup mail
> services, and that provider has assigned the mail server
> 'mail.backupserver.com' to provide backup mail services for me.
>
> > >
> > >
> > >         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.
> >
>
> Lets assume that the mail hosting provider I contracted to perform backup
> mail services is smart enough to properly configure their server.
>
> With that assumption, then it is highly probable that if the primary
> mail server is not reachable, the population of Internet mail servers as a
> whole will attempt to contact the backup mail server -- assuming
> that all are in compliance with Internet Standard RFC974 (Mail Routing and
> the Domain System) available via: ftp://ftp.isi.edu/in-notes/rfc974.txt and
> as it is clarified by Internet Standard RFC1123 (Requirements for Internet
> Hosts) available via: ftp://ftp.isi.edu/in-notes/rfc1123.txt.
>
> > >
> > >
> > >         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.
> >
>
> This could not be overcome without changing the DNS MX records that are
> responsible for mail routing.
>
> Furthermore, any changes to the DNS records would be subject to a DNS
> propagation delay of up to the value of the DNS Time To Live (TTL)
> setting for the records, typically 24 hours.
>
> > >
> >
> > >
> > >
> > >         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..
> >
>
> The wildcards themselves do not break the backup mail functionality -- what
> breaks this functionality is that Verisign has a mail server (SMTP) live
> on the address where the wildcarding is directing the Internet.
>
> If Verisign would remove the mail server from that IP Address, then
> automatic backup mail functionality would be restored.
>
> Sincerely yours,
> Chuck Liggett
> Operations Manager
> N2Net
> (216) 619-2000 x.116
>
> > >
> > >
> > > 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
> >
> >

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