You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Neidhart <th...@gmail.com> on 2012/12/11 09:58:41 UTC
[VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Hi,
thanks for looking into it.
I will fix the issues wrt build page, release notes and findbugs warnings.
Regarding the unit test failure:
I have not seen the problem before, and just validated it. The unit test
tries to open a connection to an invalid url: http://example.invalid
For some reason this seems to succeed in your environment. Could it be that
you have a custom hosts entry for this domain?
Thomas
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by Siegfried Goeschl <sg...@gmx.at>.
Unfortunately I do remember ... :-(
Siegfried Goeschl
On 11.12.12 22:08, Mark Struberg wrote:
> we had this over here at UPC as well. This did cost Sigi a release as well if you remember ;)
>
> Most times this can be disabled by your provider. Just phone them and explain that they are breaking your computer and this creates costs by them not acting standard conform ;)
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: sebb <se...@gmail.com>
>> To: Commons Developers List <de...@commons.apache.org>
>> Cc:
>> Sent: Tuesday, December 11, 2012 9:18 PM
>> Subject: Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
>>
>> On 11 December 2012 12:11, Gary Gregory <ga...@gmail.com> wrote:
>>> On Tue, Dec 11, 2012 at 6:56 AM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 11 December 2012 08:58, Thomas Neidhart
>> <th...@gmail.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > thanks for looking into it.
>>>> >
>>>> > I will fix the issues wrt build page, release notes and findbugs
>>>> warnings.
>>>> >
>>>> > Regarding the unit test failure:
>>>> >
>>>> > I have not seen the problem before, and just validated it. The
>> unit test
>>>> > tries to open a connection to an invalid url:
>> http://example.invalid
>>>> > For some reason this seems to succeed in your environment. Could
>> it be
>>>> that
>>>> > you have a custom hosts entry for this domain?
>>>>
>>>> Or it could be a faulty DNS server.
>>>>
>>>> I used to have this exact problem with the OpenDNS server.
>>>> They resolve unknown hosts to their home page (extra advertising).
>>>> They used to do this for *.invalid as well, but after years of
>>>> complaints that this behaviour was contrary to the RFC they fixed the
>>>> issue.
>>>>
>>>> Try pinging example.invalid and then do an nslookup on the IP address.
>>>>
>>>
>>> That is what Cox must be doing indeed:
>>>
>>> Pinging example.invalid [72.215.225.9] with 32 bytes of data:
>>> Request timed out.
>>> Request timed out.
>>> Request timed out.
>>> My browser redirects this IP to http://finder.cox.net/dnserror.html
>>
>> So Cox are violating the RFC.
>>
>> Perhaps you could direct them to the relevant RFC:
>>
>> There are several TLD names which are reserved by RFC 2606, section 2.
>> Amongst them is the TLD "invalid".
>>
>> <quote>
>> ".invalid" is intended for use in online construction of domain
>> names that are sure to be invalid and which it is obvious at a
>> glance are invalid.
>> </quote>
>>
>> Note the phrase "that are sure to be invalid".
>> An invalid domain name cannot have an IP address.
>> No DNS server should ever resolve addresses in the TLD "invalid".
>>
>>> Gary
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by Mark Struberg <st...@yahoo.de>.
we had this over here at UPC as well. This did cost Sigi a release as well if you remember ;)
Most times this can be disabled by your provider. Just phone them and explain that they are breaking your computer and this creates costs by them not acting standard conform ;)
LieGrue,
strub
----- Original Message -----
> From: sebb <se...@gmail.com>
> To: Commons Developers List <de...@commons.apache.org>
> Cc:
> Sent: Tuesday, December 11, 2012 9:18 PM
> Subject: Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
>
> On 11 December 2012 12:11, Gary Gregory <ga...@gmail.com> wrote:
>> On Tue, Dec 11, 2012 at 6:56 AM, sebb <se...@gmail.com> wrote:
>>
>>> On 11 December 2012 08:58, Thomas Neidhart
> <th...@gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > thanks for looking into it.
>>> >
>>> > I will fix the issues wrt build page, release notes and findbugs
>>> warnings.
>>> >
>>> > Regarding the unit test failure:
>>> >
>>> > I have not seen the problem before, and just validated it. The
> unit test
>>> > tries to open a connection to an invalid url:
> http://example.invalid
>>> > For some reason this seems to succeed in your environment. Could
> it be
>>> that
>>> > you have a custom hosts entry for this domain?
>>>
>>> Or it could be a faulty DNS server.
>>>
>>> I used to have this exact problem with the OpenDNS server.
>>> They resolve unknown hosts to their home page (extra advertising).
>>> They used to do this for *.invalid as well, but after years of
>>> complaints that this behaviour was contrary to the RFC they fixed the
>>> issue.
>>>
>>> Try pinging example.invalid and then do an nslookup on the IP address.
>>>
>>
>> That is what Cox must be doing indeed:
>>
>> Pinging example.invalid [72.215.225.9] with 32 bytes of data:
>> Request timed out.
>> Request timed out.
>> Request timed out.
>> My browser redirects this IP to http://finder.cox.net/dnserror.html
>
> So Cox are violating the RFC.
>
> Perhaps you could direct them to the relevant RFC:
>
> There are several TLD names which are reserved by RFC 2606, section 2.
> Amongst them is the TLD "invalid".
>
> <quote>
> ".invalid" is intended for use in online construction of domain
> names that are sure to be invalid and which it is obvious at a
> glance are invalid.
> </quote>
>
> Note the phrase "that are sure to be invalid".
> An invalid domain name cannot have an IP address.
> No DNS server should ever resolve addresses in the TLD "invalid".
>
>> Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by sebb <se...@gmail.com>.
On 11 December 2012 12:11, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Dec 11, 2012 at 6:56 AM, sebb <se...@gmail.com> wrote:
>
>> On 11 December 2012 08:58, Thomas Neidhart <th...@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > thanks for looking into it.
>> >
>> > I will fix the issues wrt build page, release notes and findbugs
>> warnings.
>> >
>> > Regarding the unit test failure:
>> >
>> > I have not seen the problem before, and just validated it. The unit test
>> > tries to open a connection to an invalid url: http://example.invalid
>> > For some reason this seems to succeed in your environment. Could it be
>> that
>> > you have a custom hosts entry for this domain?
>>
>> Or it could be a faulty DNS server.
>>
>> I used to have this exact problem with the OpenDNS server.
>> They resolve unknown hosts to their home page (extra advertising).
>> They used to do this for *.invalid as well, but after years of
>> complaints that this behaviour was contrary to the RFC they fixed the
>> issue.
>>
>> Try pinging example.invalid and then do an nslookup on the IP address.
>>
>
> That is what Cox must be doing indeed:
>
> Pinging example.invalid [72.215.225.9] with 32 bytes of data:
> Request timed out.
> Request timed out.
> Request timed out.
> My browser redirects this IP to http://finder.cox.net/dnserror.html
So Cox are violating the RFC.
Perhaps you could direct them to the relevant RFC:
There are several TLD names which are reserved by RFC 2606, section 2.
Amongst them is the TLD "invalid".
<quote>
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
</quote>
Note the phrase "that are sure to be invalid".
An invalid domain name cannot have an IP address.
No DNS server should ever resolve addresses in the TLD "invalid".
> Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Dec 11, 2012 at 6:56 AM, sebb <se...@gmail.com> wrote:
> On 11 December 2012 08:58, Thomas Neidhart <th...@gmail.com>
> wrote:
> > Hi,
> >
> > thanks for looking into it.
> >
> > I will fix the issues wrt build page, release notes and findbugs
> warnings.
> >
> > Regarding the unit test failure:
> >
> > I have not seen the problem before, and just validated it. The unit test
> > tries to open a connection to an invalid url: http://example.invalid
> > For some reason this seems to succeed in your environment. Could it be
> that
> > you have a custom hosts entry for this domain?
>
> Or it could be a faulty DNS server.
>
> I used to have this exact problem with the OpenDNS server.
> They resolve unknown hosts to their home page (extra advertising).
> They used to do this for *.invalid as well, but after years of
> complaints that this behaviour was contrary to the RFC they fixed the
> issue.
>
> Try pinging example.invalid and then do an nslookup on the IP address.
>
That is what Cox must be doing indeed:
Pinging example.invalid [72.215.225.9] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
My browser redirects this IP to http://finder.cox.net/dnserror.html
Gary
>
> > Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
Posted by sebb <se...@gmail.com>.
On 11 December 2012 08:58, Thomas Neidhart <th...@gmail.com> wrote:
> Hi,
>
> thanks for looking into it.
>
> I will fix the issues wrt build page, release notes and findbugs warnings.
>
> Regarding the unit test failure:
>
> I have not seen the problem before, and just validated it. The unit test
> tries to open a connection to an invalid url: http://example.invalid
> For some reason this seems to succeed in your environment. Could it be that
> you have a custom hosts entry for this domain?
Or it could be a faulty DNS server.
I used to have this exact problem with the OpenDNS server.
They resolve unknown hosts to their home page (extra advertising).
They used to do this for *.invalid as well, but after years of
complaints that this behaviour was contrary to the RFC they fixed the
issue.
Try pinging example.invalid and then do an nslookup on the IP address.
> Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org