RE: [ga] Some Wild-Card Questions

["Chuck Liggett" <chuckl@xxxxxxxx>]

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