[arin-ppml] Policy Proposal: Annual WHOIS POC Validation
tedm at ipinc.net
Tue Aug 26 13:39:59 EDT 2008
> -----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
> > > >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
> > for domain-style addressing, it isn't going to appear in a
> > 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.
More information about the ARIN-PPML