[arin-ppml] Policy Proposal: Annual WHOIS POC Validation

[Ted Mittelstaedt]

> -----Original Message-----
> From: John Santos [mailto:JOHN at egh.com] 
> Sent: Monday, August 25, 2008 5:58 PM
> To: arin-ppml at arin.net
> Cc: Ted Mittelstaedt; 'Keith W. Hare'
> Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation
> 
> 
> On Mon, 25 Aug 2008, Ted Mittelstaedt wrote:
> 
> > 
> > 
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net
> > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Keith W. Hare
> > > Sent: Monday, August 25, 2008 7:25 AM
> > > To: arin-ppml at arin.net
> > > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS 
> POC Validation
> > > 
> > > 
> > > > If a valid response
> > > >is not received within 14 days, every instance of the 
> unresponsive
> > > >email address will be replaced with "REFUSED RESPONSE" 
> in the whois 
> > > >directory.
> > > 
> > > Since my background is database design and performance, I
> > > cringe at the idea of overloading the email address field 
> > > with what should really be a separate field.
> > > 
> > 
> > Keith,
> > 
> >   Adding a field could possibly break web-whois-lookup 
> forms that are 
> > out there who don't have good parsers.
> > 
> >   Technically, there is no standard for an e-mail address.  
> There's a 
> > standard for a DOMAIN-style e-mail address, but if your database 
> > parser that parses the e-mail address field of ARIN whois 
> is dependent 
> > on seeing an '@' then you already are doing it wrong.
> > 
> >   Because the string "REFUSED RESPONSE" doesen't follow the 
> standards 
> > for domain-style addressing, it isn't going to appear in a 
> legitimate 
> > POC e-mail address.  Because there's a space it isn't a legitimate 
> > UUCP address or BITNET address either.  It is pretty simple for any 
> > COMPETENT programmer writing automated query tools to code 
> for this.  
> > And we want to discourage people from bulk-queries of the whois 
> > database anyway - if you don't know how to code for this, we really 
> > don't want you harvesting e-mail addresses out of whois since your 
> > likely a spammer.
> > 
> >   If we simply remove the POC e-mail address then people 
> don't know if 
> > it was removed because it's bogus or because someone made a mistake 
> > with a SWIP record.
> > 
> >   This is why I did not set it to "unavailable at example.com" or some 
> > such in my proposal from which this proposal is derived.  
> There is no 
> > point in overloading someone's mailserver somewhere by some spammer 
> > trying to send 20,000 mails to a data item that looks like 
> an e-mail 
> > address but isn't.
> 
> How about:
> 
>    No response (was: <original_e-mail_address>)
> 

I agree, I was thinking of something along the same lines myself.
However I will leave it to Chris Grundemann to decide.


> This way no information is lost and it has a space in it so 
> the resulting e-mail address is still invalid, and it makes 
> no presumptions about the type of e-mail address was 
> originally there.  Also, it would be easy to restore the 
> address if it turns out that it is valid but the mail was 
> getting spam-trapped or the recipient was on vacation or 
> otherwise didn't see it promptly.
>

The "whois POC e-mail cleanup" proposal I submitted does not
have the same problem with people being on vacation - since
it is not customary for people to make all e-mail to themselves
to bounce, when they are on vacation.
 
> BTW, any kind of automatic second attempt at contacting the 
> POC should use significantly different wording in case the 
> original had fallen afoul of a Bayesian SPAM filter. 
> 
> I think the details should be left to the ARIN staff, though. 
> Suggestions about specifics probably shouldn't be in the 
> policy itself, but just in the rationale and the discussion.
> 

If you have serious enough concerns about looking for e-mail
responses then I urge you to not support "Annual WHOIS POC Validation"
and support "whois POC e-mail cleanup" instead.

The proposals will be fundamentally identical with the exception
that Chris's proposal requires a response from the POC e-mail
address.  My proposal only requires that the POC e-mail address
be accepting mail, not that the POC actually responds.

Ted