For residential service, smtp outbound is blocked to all but their relay server.
Its been a while since I used Charter's business level service and business level service is an entirely different setup (probably still managed by the good Bresnan component); thus, I would suppose that it still uses different spectrum with end points into different routers where smtp isn't blocked and, presumably, DNS is native.
Even if you use Firefox on Linux, using Charter's "opt-out" feature (on the bottom of the search result page, the "About this page" link, where they warn you they are going to set a cookie) only means that instead of hitting www11.charter.net, you instead end up at search.msn.com as instructed by www11.charter.net;)
The only way to disable it is to reconfig your DNS servers to not use the ones they hacked.
Yes, internal browser redirecting is the lessor of the evils. Companies like Charter should be, IMO, implementing their redirect service within a licensed browser which they ship to new customers.
However, why isn't what MS doing (or my own suggestion to Charter) still not a privacy issue?
Does LiveSearch capture your entire URL or query string?
What happens when you make a typo using an ht-auth encoded URI (user:pass@site), is that getting logged someplace?
Does the browser also send failed https:/// lookups to LiveSearch?
I noticed the author of the linked-to article did not extend his logic to bad host names within a registered domain. I presume MS's LiveSearch intercepts those as well; so doesn't his original logic, which he talked himself out of, apply (trademark theft)?
Verisign's Sitefinder didn't intercept bad host names within registered domains; only unknown TLD's in.COM and.NET.
Charter's DNS hack always returns an A record regardless of upstream MXDOMAIN failures.
If I recall.... way back yonder, MX record or not, smtp delivery still ended up at Verisign's Sitefinder node where it encountered a brain-dead smtp implementation that wanted to simply bounce everything as "unknown user"; creating additional problems...
With Charter, if you are setup as a relay client then MX _probably_ isn't affected because outgoing smtp traffic can only leave the building via their relay server and your client most likely sends all email to the relay before bothering to even check hostnames.
However, Charter's DNS hack could very well affect customers running smarter servers which do depend on MX or A record verification (and then end up using Charter's relay server _after_ name verification) because now, every A record request has an answer. Such email will bounce when the delivering attempt times out, days later, after the customers gateway realizes that Charter's Sitefinder-equivalent never answers smtp traffic.
I would think we'd also want to take manufacturing energy resources into the picture as well; do CFLs need many more resources that aren't necessarily reflected in their final retail price as compared to incadecents?
Though, I'm not entirely sure how relevant the answer is because any amount of production energy to create something which uses less runtime energy is probably desirable in environments where non-renewable resources provide the energy (coal; though, there's still a lot of that dirty stuff). It is similar to the idea of "using the remaining oil to make plastic solar cells so that we still have power when the oil runs out";)
I'm curious why it took 125 years to rework the light bulb -- no one had any bright ideas?;)
The linked story isn't detailed enough to gauge if GE was sitting on the concept and recently pulled out the design papers because of government _or_ if they have been actively trying to discover new design and production methods. I'm curious what GE's level of R&D actually is or if the story isn't simply PR hiding that they've only now (reluctantly) decided to develop previously known research because regulation (not market pressure) forced them.
It is an important distinction because it helps to clarify the difference between efficient and lazy markets vs. useful or bad regulation as either relate to innovation.
Best,
Joey ps: I know it didn't take 125 yrs to rework the light bulb and there has been light bulb innovation since then, especially those wider spectrum bulbs;)
Charter already blocks the smtp port and requires customers to relay via their own smtp servers (I'm setup for smtp.chartermi.net); so there aren't any new MX issues. However, I just checked the other record types and they do return NXDOMAIN properly. It is only the A records they ruin, and ruin badly.
I emailed Charter via their support website form; the first reply was their canned version of "we'll get back to you soon". Having not heard from them, I replied to their automatic email asking when someone was going to contact me. Here's the reply I received:
Thank you for contacting Charter Communications. My name is ___, I would like to assists you.
I understand that you want to disconnect your service. Because email is not a secure form of communication, we are unable to send account sensitive information like; username, password, or account number. For your protection please contact our High Speed Internet department at 1-888-GET-CHARTER (1-888-438-2427) to retrieve this information.
[removed a few lines]
In addition, we would like to inform you that Charter ePay is available in our website for online payments. Registration is for free so start paying online for hassle fee payments!
Note that I had never once hinted at wanting to terminate my account (nor that I didn't know anything about my account); rather, in the previous emails I simply asked to talk to someone about their DNS implementation. So perhaps their new automatic treatment is to talk customers into leaving them? HA!
Note the irony in telling me where to go to terminate my service _and_ then telling me about their Epay system to pay future bills;)
You need to send a Host: HTTP header (which isn't www11.charter.net unless the URI has args) in order to get a meaningful reply from www11.charter.net; it then uses the requested URI for the search. Charter can clearly keep track of your typos.
64.158.56.56
The server (64.158.56.56 or unknown.level3.net) gives different replies based on the request:
What is also interesting is the "opt-out" feature on the "About this page" link sets a cookie which causes subsequent visits to the intercept page to direct you to search.msn.com.
Very odd setup; but easy to figure out how the set it up.
Unlike Verisign's DNS wildcard, from 2003, which only acted on unknown TLD's within.COM and.NET, Charter's implementation acts on _all_ unknown hosts, even within delegated domains. Thus, if you are a Charter customer using their DHCP provided DNS servers, typing "wwwwwww.slashdot.com" resolves to their redirected intercept host; that, when using a browser, makes it look like slashdot.com sent me to Charter's search page.
Regardless of being able to (currently) use other DNS servers, what Charter is doing is still wrong and I wonder when it'll be fine for them to block outgoing port 53. They already block outgoing SMTP and other ports (for good or not, it demonstrates that have the capabilities to block any port they wish--just a warning indicator).
When Verisign messed with DNS, it effected the entire world. Charter doing it only messes with its own customers and it is far harder to organize complaints. Networkcomputing.com and dslreports.com have stories/articles on the problem too.
Best,
Joey
(in Bay City, MI, where DNS wildcarding was turned on last weekend).
Slashdot Mirror
For residential service, smtp outbound is blocked to all but their relay server.
Its been a while since I used Charter's business level service and business level service is an entirely different setup (probably still managed by the good Bresnan component); thus, I would suppose that it still uses different spectrum with end points into different routers where smtp isn't blocked and, presumably, DNS is native.
Even if you use Firefox on Linux, using Charter's "opt-out" feature (on the bottom of the search result page, the "About this page" link, where they warn you they are going to set a cookie) only means that instead of hitting www11.charter.net, you instead end up at search.msn.com as instructed by www11.charter.net ;)
The only way to disable it is to reconfig your DNS servers to not use the ones they hacked.
Yes, internal browser redirecting is the lessor of the evils. Companies like Charter should be, IMO, implementing their redirect service within a licensed browser which they ship to new customers.
However, why isn't what MS doing (or my own suggestion to Charter) still not a privacy issue?
Does LiveSearch capture your entire URL or query string?
What happens when you make a typo using an ht-auth encoded URI (user:pass@site), is that getting logged someplace?
Does the browser also send failed https:/// lookups to LiveSearch?
I noticed the author of the linked-to article did not extend his logic to bad host names within a registered domain. I presume MS's LiveSearch intercepts those as well; so doesn't his original logic, which he talked himself out of, apply (trademark theft)?
.COM and .NET.
Verisign's Sitefinder didn't intercept bad host names within registered domains; only unknown TLD's in
Charter's DNS hack always returns an A record regardless of upstream MXDOMAIN failures.
If I recall.... way back yonder, MX record or not, smtp delivery still ended up at Verisign's Sitefinder node where it encountered a brain-dead smtp implementation that wanted to simply bounce everything as "unknown user"; creating additional problems...
With Charter, if you are setup as a relay client then MX _probably_ isn't affected because outgoing smtp traffic can only leave the building via their relay server and your client most likely sends all email to the relay before bothering to even check hostnames.
However, Charter's DNS hack could very well affect customers running smarter servers which do depend on MX or A record verification (and then end up using Charter's relay server _after_ name verification) because now, every A record request has an answer. Such email will bounce when the delivering attempt times out, days later, after the customers gateway realizes that Charter's Sitefinder-equivalent never answers smtp traffic.
I would think we'd also want to take manufacturing energy resources into the picture as well; do CFLs need many more resources that aren't necessarily reflected in their final retail price as compared to incadecents?
;)
Though, I'm not entirely sure how relevant the answer is because any amount of production energy to create something which uses less runtime energy is probably desirable in environments where non-renewable resources provide the energy (coal; though, there's still a lot of that dirty stuff). It is similar to the idea of "using the remaining oil to make plastic solar cells so that we still have power when the oil runs out"
Ha, great point about marketing and Miser ;)
;)
;)
I'm curious why it took 125 years to rework the light bulb -- no one had any bright ideas?
The linked story isn't detailed enough to gauge if GE was sitting on the concept and recently pulled out the design papers because of government _or_ if they have been actively trying to discover new design and production methods. I'm curious what GE's level of R&D actually is or if the story isn't simply PR hiding that they've only now (reluctantly) decided to develop previously known research because regulation (not market pressure) forced them.
It is an important distinction because it helps to clarify the difference between efficient and lazy markets vs. useful or bad regulation as either relate to innovation.
Best,
Joey
ps: I know it didn't take 125 yrs to rework the light bulb and there has been light bulb innovation since then, especially those wider spectrum bulbs
Charter already blocks the smtp port and requires customers to relay via their own smtp servers (I'm setup for smtp.chartermi.net); so there aren't any new MX issues. However, I just checked the other record types and they do return NXDOMAIN properly. It is only the A records they ruin, and ruin badly.
It is a global wildcard for any IN A error. It does not usurp existing wildcards -- it appears slashdot.com has one in place.
Note that I had never once hinted at wanting to terminate my account (nor that I didn't know anything about my account); rather, in the previous emails I simply asked to talk to someone about their DNS implementation. So perhaps their new automatic treatment is to talk customers into leaving them? HA!
Note the irony in telling me where to go to terminate my service _and_ then telling me about their Epay system to pay future bills ;)
Those are Level 3 machines? I see gtei.net; either way, Charter's intercept host's IP reverse resolves to unknown.level3.net -- an interesting irony.
64.158.56.56 The server (64.158.56.56 or unknown.level3.net) gives different replies based on the request:
http://64.158.56.56/ -- plaintext "404 Not Found"
http://unknown.level3.net/ -- bold "Bad Request (Invalid Hostname)
http://www11.charter.net/ -- what looks like an MS HTTP server error (though, nmap says it is linux)
http://www11.charter.net/search?qo=moo&rn=y1D0mGqA mobwd75 -- the intercept search page; Powered by Yahoo!
What is also interesting is the "opt-out" feature on the "About this page" link sets a cookie which causes subsequent visits to the intercept page to direct you to search.msn.com.
Very odd setup; but easy to figure out how the set it up.
As well as non-existing hosts within domains.... ;(
Regardless of being able to (currently) use other DNS servers, what Charter is doing is still wrong and I wonder when it'll be fine for them to block outgoing port 53. They already block outgoing SMTP and other ports (for good or not, it demonstrates that have the capabilities to block any port they wish--just a warning indicator).
When Verisign messed with DNS, it effected the entire world. Charter doing it only messes with its own customers and it is far harder to organize complaints. Networkcomputing.com and dslreports.com have stories/articles on the problem too.
Best,
Joey
(in Bay City, MI, where DNS wildcarding was turned on last weekend).