[arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's

Mon Mar 30 14:38:43 EDT 2009

> -----Original Message-----
> From: Keith Medcalf [mailto:kmedcalf at dessus.com] 
> Sent: Sunday, March 29, 2009 8:26 AM
> To: Ted Mittelstaedt
> Cc: arin-ppml at arin.net
> Subject: RE: [arin-ppml] Draft Policy 2008-7: Identify 
> Invalid WHOIS POC's
> 
> 
> Ted Mittelstaedt wrote:
> 
> > The valid POCs can be handled by automated e-mail systems with a 
> > specific URL link in the mail sent to the POC.  Network Solutions 
> > already does this for ALL domain name holders in their 
> registrar and 
> > it's completely automated.  ARIN staff can contact Network 
> Solutions 
> > and ask how they do it if they do not understand how to do this.
> 
> Network Solutions does not do this.  My domain is registered 
> with Network Solutions and always has been.  I have nothing 
> to update, nonetheless, the only verification attempt I ever 
> received from them was many a year ago when they did a postal 
> mail validation.  I have never received e-mail attempting to 
> verify my POK data at Network Solutions.
> 

Yes, they absolutely do do this, I have several verification 
e-mails from them in my archives.  The reason you haven't got
mails from them is that they already verified that your domain
resolves.

Here's the text of the last one of these I can find (I usually
delete these):

--------------------------
Return-Path: <partnerprogram at networksolutions.com>
Received: from heron.networksolutions.com (heron.networksolutions.com
[205.178.190.224])
	by mail.ipinc.net (8.13.8/8.13.8) with ESMTP id l5TIprmP030813
	for <hostmaster at ipinc.net>; Fri, 29 Jun 2007 11:51:56 -0700 (PDT)
	(envelope-from partnerprogram at networksolutions.com)
Received: from VAMAIL3.CORPIT.NSI.NET (vamail1.corpit.nsi.net
[10.216.32.25])
	by heron.networksolutions.com (8.12.10/8.12.10) with ESMTP id
l5TIpln7002813
	for <hostmaster at ipinc.net>; Fri, 29 Jun 2007 14:51:48 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C7BA7E.8BC4A0B8"
Subject: Domains in Your Account Require Attention
Date: Fri, 29 Jun 2007 14:51:47 -0400
Message-ID:
<9E93DEC285888046B8949287D8B837640466F285 at VAMAIL3.CORPIT.NSI.NET>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Domains in Your Account Require Attention
thread-index: Ace6fouh27SlVfbqRG2H+J9XFV0t5g==
From: "Network Solutions Partner Program"
<partnerprogram at networksolutions.com>
To: <hostmaster at ipinc.net>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0
(mail.ipinc.net [65.75.192.11]); Fri, 29 Jun 2007 11:51:56 -0700 (PDT)
X-Virus-Scanned: ClamAV 0.90.2/3556/Fri Jun 29 09:23:10 2007 on
mail.ipinc.net
X-Virus-Status: Clean
X-Spam-Status: No, score=0.5 required=4.1 tests=DNS_FROM_RFC_ABUSE,
	HTML_MESSAGE autolearn=disabled version=3.1.8
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail.ipinc.net

Dear Valued Partner:

In the spirit of Internet good citizenship, Network Solutions has looked at
its domain name inventory under management and is making efforts to have all
domains resolve as expected by the Internet community. As a courtesy, we did
an analysis on your inventory and have found 2 domain names that do not
resolve. Our analysis included several checks over time to ensure that the
domain and common third level extensions of the domain such as "www", "ftp",
"mail", did not resolve to any IP address.  To NOT resolve, a query to the
name server of record for a given domain had to either not respond at all or
respond in a manner indicating it had no information for that domain. 

Attached you will find a list of domains that fit the above description at
the time we completed our analysis. We are writing to ask that you make
arrangements to have these resolve properly. Alternately, you may choose to
do nothing and beginning on or about July 29, 2007 Network Solutions will
update the DNS on your behalf to resolve to an under construction page.

Regards, 

Network SolutionsR Partner Program
--------------------------

In the above case, what generated this was a domain name that
a customer owned who went bankrupt that was pointing to a set of
old nameservers that we abandoned.

Apparently NetSol assumes that a domain name with servers that
are resolving for that name has a contact reachable via e-mail.
Which makes sense - if a nameserver resolves anything, even a
SOA, for a domain, that means someone is paying the operator of
that nameserver to respond to queries, and thus if the published
WHOIS data for the domain is bogus, you still can reach the
person who owns the domain via their host of the nameservers that
are responding to queries for it.

But, for Netsol to know this, they still had to scan through
their list of registered names.  Just because you didn't get
a verification e-mail, doesn't mean they didn't do some kind
of address verification.  Maybe they just connected to your
mailserver, did a HELO, MAIL FROM, RECPT TO, and when the
server responded with an OK, disconnected.  That's how the
spammers dig up e-mail addresses, after all.

> Of course, it is possible that they (NetSol) [have] 
> attempt[ed] to use SMTP transported web-pages sent from a 
> non-RFC compliant SMTP server, in which case I would have 
> never received the messages (and they would not qualify as 
> "e-mail" anyway).
> 

Um, did you note the X-Spam-Status: line above?  The header is
a most interesting read.

> Thus my requirement that any policy authorizing e-mail (SMTP 
> transported) verification of POK data have a very narrow 
> definition of what qualifies as "e-mail".

You could also greatly expand the "Invalid WHOIS POC" policy
proposal by stating that any POC attached to a currently-advertised
netblock is reachable if their upstream is reachable.

But, this shifts the focus on the netblocks.  Keep in mind that
a netblock may have multiple POCs attached to it, some legitimate,
some old and stale and bogus.  It is not a 1-to-1 ratio.  Thus,
deleting and invalidating a POC does not necessarily affect a
netblock.

You could easily have a POC that is just one contact on a block
that has multiple POCs on it, the rest of which are legitimate and
responding, get deleted as a result of our policy proposal.  This 
is behavior we WANT!  Why have stale POC entries cluttering up WHOIS?

And, what about POC's that were tied to a netblock that was later
returned, and ARIN made a mistake and didn't delete the POC and it's
still bouncing around in WHOIS?

We just did not want to clutter up the proposal with these kinds of
details.

> In order to 
> qualify as e-mail, the message MUST be text/plain and MUST be 
> sent from a strictly RFC compliant SMTP host which has (a) 
> proper forward and reverse DNS; (b) proper MX records for the 
> sending domain; (c) must be sent from the ARIN.NET domain 
> (not a third party mailer); and, (d) must have correct SPF 
> records if any.
> 
> The interpretation of "e-mail" must be strictly specified.  
> Interpretation of what consititutes e-mail MUST NOT be open 
> for interpretation by the unwashed, particularly those 
> members of the unwashed who believe that web-pages by SMTP is 
> somehow "e-mail".
> 

Keep in mind that every SUCCESSFUL delivery of a verification
email results in LESS WORK for ARIN staff in following up.  Thus,
there's a built-in incentive to figure out how to get their 
verification message, and it's follow-ups, accepted.

Your objection is basically against SMTP connections to your
mailserver that are "more spammmy" ie: more like those coming
from a spammer, and less like those coming from a legitimate
mailserver.  Since lots and lots of sites these days are running
all kinds of spam filters that rank incoming mail as more and
less spammy, the less spamlike that ARIN's verification mails
are, the greater chance for acceptance by everyone.  In short,
you and they would have the same goals, thus why write these
details into the policy?

Maybe ARIN will find some sites so messed-up that the initial verification
e-mail that's strict RFC is ignored, while a second "more spamlike"
mail that is a HTMLized "web-page SMTP" would be responded to.
Are you so hostile to HTMLized mail that you would want to
deny these sites the ability to respond?  After all the goal is
POC verification, not to make people suffer who are too dumb to read
plain text mails.

Ted