Re: [ga] Some Wild-Card Questions
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