Re: Akamai Edgekey issues ?
On Mon, Sep 2, 2013 at 7:33 PM, Jorge Amodio jmamo...@gmail.com wrote: Here is another bit of data... www.apple.com not reachable from a machine using Google's NS, reachable from an iPad using TWC NS IP addresses returned by each are different ... could be load balancing, or creative (broken) traffic engineering Far more likely to be simply due to Akamai localizing the IP addresses to be as close to the resolving nameserver as possible; so, when using Google DNS, you end up at an Akamai node close to the Google DNS server; when using the TWC nameservers, you end up pointing to an Akamai node closer to those TWC nameservers. Not a case of broken traffic engineering at all. But for moments packets get lost at ae0.pr1.dfw10.tbone.rr.com this also could be TWC routing/peering issues but I don't know how many more levels of CS I have to go to reach somebody with a clue, after testing my modem zillion times ... Why not just use the TWC nameservers, if thiings work when you use them instead of the Google nameservers? Matt pete@tango:~$ dig www.apple.com ; DiG 9.8.1-P1 www.apple.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 46202 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.apple.com. IN A ;; ANSWER SECTION: www.apple.com. 723 IN CNAME www.isg-apple.com.akadns.net . www.isg-apple.com.akadns.net. 49 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 408 IN CNAME e3191.dscc.akamaiedge.net. e3191.dscc.akamaiedge.net. 9IN A 184.86.141.15 ;; Query time: 42 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Sep 2 21:06:57 2013 ;; MSG SIZE rcvd: 161 pete@tango:~$ dig @209.18.47.61 www.apple.com ; DiG 9.8.1-P1 @209.18.47.61 www.apple.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20041 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.apple.com. IN A ;; ANSWER SECTION: www.apple.com. 1135IN CNAME www.isg-apple.com.akadns.net . www.isg-apple.com.akadns.net. 50 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 442 IN CNAME e3191.dscc.akamaiedge.net. e3191.dscc.akamaiedge.net. 5IN A 23.42.157.15 ;; Query time: 39 msec ;; SERVER: 209.18.47.61#53(209.18.47.61) ;; WHEN: Mon Sep 2 21:07:09 2013 ;; MSG SIZE rcvd: 161 On Sat, Aug 31, 2013 at 7:26 PM, Jorge Amodio jmamo...@gmail.com wrote: Hi There, is anybody having any problems with sites that go through Akamai's CDN ? I'm having problems to connect to many served by them, just two examples. www.ti.com www.newark.com Cheers Jorge
Re: TCP Performance
Try your iperf over port 80 and see if your hitting any website related filters. At least rule it out. Or try HTTP on a different port. If your iperf test is getting link speed then you can rule most things connection related. I really think some device is QoS'ing packets bound tofrom port 80. On Tue, Aug 27, 2013 at 12:22 PM, Nick Olsen n...@flhsi.com wrote: I have indeed tried that. And it didn't make any difference. Functionally limiting each router port to is connected microwave links capacity. And queuing the overflow. However the queue never really fills as the traffic rate never goes higher then the allocated bandwidth. Nick Olsen Network Operations (855) FLSPEED x106 From: Blake Dunlap iki...@gmail.com Sent: Tuesday, August 27, 2013 1:32 PM To: n...@flhsi.com Cc: Tim Warnock tim...@timoid.org, nanog@nanog.org nanog@nanog.org Subject: Re: TCP Performance If you have a router, you can turn on shaping to the bandwidth the link will support. -Blake On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen n...@flhsi.com wrote: I do indeed have stats for TX Pause Frames And they do increment. However, Our router is ignoring them since it doesn't support flow control. I guess my next question would be. In the scenario where we insert a switch between the radio and the router that does support flow control. Are we not only moving where the overflow is going to occur? Will we not see the router still burst traffic at line rate toward the switch, Which then buffer overflows sending to the radio on account of it receiving pause frames? Nick Olsen Network Operations (855) FLSPEED x106 From: Tim Warnock tim...@timoid.org Sent: Tuesday, August 27, 2013 1:08 PM To: Blake Dunlap iki...@gmail.com, n...@flhsi.com n...@flhsi.com Cc: nanog@nanog.org nanog@nanog.org Subject: RE: TCP Performance Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem. -- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624
Re: TCP Performance
I mean programatically speaking your network equipment generally knows no difference between and HTTP packet and an IPerf packet. (Layer 3 packet forwarding only breaks the first 84 bits off the header, Layer 2 gets 52 bits (with a vlan tag)) So, unless QoS of some kind gets brought into the picture the protocol shouldnt make a difference, however, if something is examining the packets further than that it could also be causing your throughput issues. Also, keep in mind some switches ship with QoS enabled for VoIP etc. Might be something to check into further. On Tue, Sep 3, 2013 at 3:18 AM, Bryan Tong cont...@nullivex.com wrote: Try your iperf over port 80 and see if your hitting any website related filters. At least rule it out. Or try HTTP on a different port. If your iperf test is getting link speed then you can rule most things connection related. I really think some device is QoS'ing packets bound tofrom port 80. On Tue, Aug 27, 2013 at 12:22 PM, Nick Olsen n...@flhsi.com wrote: I have indeed tried that. And it didn't make any difference. Functionally limiting each router port to is connected microwave links capacity. And queuing the overflow. However the queue never really fills as the traffic rate never goes higher then the allocated bandwidth. Nick Olsen Network Operations (855) FLSPEED x106 From: Blake Dunlap iki...@gmail.com Sent: Tuesday, August 27, 2013 1:32 PM To: n...@flhsi.com Cc: Tim Warnock tim...@timoid.org, nanog@nanog.org nanog@nanog.org Subject: Re: TCP Performance If you have a router, you can turn on shaping to the bandwidth the link will support. -Blake On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen n...@flhsi.com wrote: I do indeed have stats for TX Pause Frames And they do increment. However, Our router is ignoring them since it doesn't support flow control. I guess my next question would be. In the scenario where we insert a switch between the radio and the router that does support flow control. Are we not only moving where the overflow is going to occur? Will we not see the router still burst traffic at line rate toward the switch, Which then buffer overflows sending to the radio on account of it receiving pause frames? Nick Olsen Network Operations (855) FLSPEED x106 From: Tim Warnock tim...@timoid.org Sent: Tuesday, August 27, 2013 1:08 PM To: Blake Dunlap iki...@gmail.com, n...@flhsi.com n...@flhsi.com Cc: nanog@nanog.org nanog@nanog.org Subject: RE: TCP Performance Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem. -- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624 -- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624
Re: Akamai Edgekey issues ?
- Original Message - From: Matthew Petach mpet...@netflight.com On Mon, Sep 2, 2013 at 7:33 PM, Jorge Amodio jmamo...@gmail.com wrote: Here is another bit of data... www.apple.com not reachable from a machine using Google's NS, reachable from an iPad using TWC NS IP addresses returned by each are different ... could be load balancing, or creative (broken) traffic engineering Far more likely to be simply due to Akamai localizing the IP addresses to be as close to the resolving nameserver as possible; so, when using Google DNS, you end up at an Akamai node close to the Google DNS server; when using the TWC nameservers, you end up pointing to an Akamai node closer to those TWC nameservers. Not a case of broken traffic engineering at all. Sure it is. It's assuming that the geographic location of a customer resolver server has anything whatever to do with the geographic location of the end node, which it's not in fact a valid proxy for. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Akamai Edgekey issues ?
- Original Message - From: Patrick W. Gilmore patr...@ianai.net Not a case of broken traffic engineering at all. Sure it is. It's assuming that the geographic location of a customer resolver server has anything whatever to do with the geographic location of the end node, which it's not in fact a valid proxy for. It isn't? How wrong is this assumption? Be specific. How far off is it, for how many users? Well, the vast majority of wireless users, for one: Sprint can't decide whether I'm in Miami, Orlando, or Lenexa, Kansas on any given day. More properly: people whose websites geolocate and whom I access over Sprint 3g/Wimax/LTE. They're probably geolocating by the actual assigned IP address, but it's roughly the same thing. Perhaps look at the other side. Assumptions must be made. What assumptions would be better in the real world? What percentage of users are closer to anycast nodes? What are the real-world performance differences using this method vs. other methods? I didn't say there was a *good* answer to this, and in fact, I don't think there is. Saying not in fact a valid proxy without hard data is not useful. What data do you have to prove your thesis? Akamai seems to perform well for the vast majority of users. Or so I believe, but I fully admit I am biased. :) Heh. :-) That said, always happy to be educated. If you have data, let us know. Well played, Patrick. No, it's anecdotal. But the percentage of wireless users who are of necessity often nowhere near their DNS resolvers certainly contributes to the percentages. There are people who are manually stuck on the wrong network's servers, or those who are configured to 4.4.4.4/8.8.8.8/4.2.2.1 by IT people (or themselves) or to OpenDNS or the like, but I'd be surprised if those were more than 5% overall. It's mostly wireless. And that's a lot. Is it relevant to Akamai? Possibly not. For Akamai, the proxy may be Good Enough. Just so we remember that not everyone is Akamai. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Akamai Edgekey issues ?
On Sep 03, 2013, at 09:58 , Jay Ashworth j...@baylink.com wrote: From: Matthew Petach mpet...@netflight.com On Mon, Sep 2, 2013 at 7:33 PM, Jorge Amodio jmamo...@gmail.com wrote: Here is another bit of data... www.apple.com not reachable from a machine using Google's NS, reachable from an iPad using TWC NS IP addresses returned by each are different ... could be load balancing, or creative (broken) traffic engineering Far more likely to be simply due to Akamai localizing the IP addresses to be as close to the resolving nameserver as possible; so, when using Google DNS, you end up at an Akamai node close to the Google DNS server; when using the TWC nameservers, you end up pointing to an Akamai node closer to those TWC nameservers. Not a case of broken traffic engineering at all. Sure it is. It's assuming that the geographic location of a customer resolver server has anything whatever to do with the geographic location of the end node, which it's not in fact a valid proxy for. It isn't? How wrong is this assumption? Be specific. How far off is it, for how many users? Perhaps look at the other side. Assumptions must be made. What assumptions would be better in the real world? What percentage of users are closer to anycast nodes? What are the real-world performance differences using this method vs. other methods? Saying not in fact a valid proxy without hard data is not useful. What data do you have to prove your thesis? Akamai seems to perform well for the vast majority of users. Or so I believe, but I fully admit I am biased. :) That said, always happy to be educated. If you have data, let us know. -- TTFN, patrick signature.asc Description: Message signed with OpenPGP using GPGMail
RE: 10G Router
MX80 is a good box. Go for MX104 if you want 2xRE redundancy and ability to oversubscribe MIC slots with 2x10G cards. Do note however: MX80-48T (cheaper variant with 48x tri-rate copper) uses the old MS-DPC and does not scale very well when things like Netflow/IPFix accounting. You should stick to MX80-T variant or MX5-40 mid-range as they are newer Trio architectures and can do more stuff in hardware. james
Re: Akamai Edgekey issues ?
On Sep 03, 2013, at 02:41 , Scott Hulbert sc...@scotthulbert.com wrote: Matthew Petach mpet...@netflight.com wrote: Why not just use the TWC nameservers, if thiings work when you use them instead of the Google nameservers? One reason would be that TWC used to hijack failed DNS requests and show advertisements ( http://netcodger.wordpress.com/2010/09/14/roadrunner-returns-to-dns-hijack-tactics/ ). Without condoning or decrying this practice, I believe TWC allows you to opt-out of that. (Whether they should require you to opt-out, or do it at all, is intentionally not discussed.) Also, Google DNS and OpenDNS helped manually clean up bad records after the NYTimes had their nameservers changed at the TLD registry ( http://blog.cloudflare.com/details-behind-todays-internet-hacks). What makes you think TWC did not do the same? And it was a lot more than the New York Times that had issues, and there was a lot more than a single instance of this. To be clear, Google is Johnny On The Spot when these things happen, and kudos to them for it. But so are lots of other providers (e.g. OpenDNS, who has been doing this a lot longer than Google), they just might not have teh GOOG name to get them in the press blogs. -- TTFN, patrick signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 10G Router
I recently did a search for similar. The full routing table is where you can factor out a lot of devices and specific line cards for others because they can't handle it. That's where you want to make sure your clear with the vendors as you talk to them. I ultimately went with different mx models myself because I couldn't find anyone using something else. *Bryan Socha* Network Engineer 646.450.0472 | *br...@serverstack.com* *ServerStack* | Scale Big On Sat, Aug 31, 2013 at 7:44 AM, sten rulz stenr...@gmail.com wrote: Hello, I am currently looking into a 10G router that will support the below requirements and hopefully not be too costly. Do you know of any models to stay away due to issues or that you would recommend? - 4x+ 10GBE ports - BGPv4/v6 - Small number of RU preferred - Support for 2-4 full routing tables - 2 10GBE ports down to switches - 2 10GBE for up-streams but would prefer more to support IXs. I have been looking into a few options including; Brocade CER 2024C-4X, Broacde MLXE-4 with 10Gx8-X, Juniper MX80, Cumulus Linux, etc. Some quick notes: - 4x 10GBE ports is a bit low for the Brocade CER - Not sure how the CER will handle a few routing tables and 10G+ traffic - The MLX and MX80 is very high costs from what I have seen - The MX80 has 4x 10GBE ports but at less allows an extra 4 via MIC - Decent number of real use case reviews for the MX80 - Possibly use cumulus networks if there are any systems that meet the requirements Thanks Steven
10G Router
Hello, I am currently looking into a 10G router that will support the below requirements and hopefully not be too costly. Do you know of any models to stay away due to issues or that you would recommend? - 4x+ 10GBE ports - BGPv4/v6 - Small number of RU preferred - Support for 2-4 full routing tables - 2 10GBE ports down to switches - 2 10GBE for up-streams but would prefer more to support IXs. I have been looking into a few options including; Brocade CER 2024C-4X, Broacde MLXE-4 with 10Gx8-X, Juniper MX80, Cumulus Linux, etc. Some quick notes: - 4x 10GBE ports is a bit low for the Brocade CER - Not sure how the CER will handle a few routing tables and 10G+ traffic - The MLX and MX80 is very high costs from what I have seen - The MX80 has 4x 10GBE ports but at less allows an extra 4 via MIC - Decent number of real use case reviews for the MX80 - Possibly use cumulus networks if there are any systems that meet the requirements Thanks Steven
Re: Akamai Edgekey issues ?
Matthew Petach mpet...@netflight.com wrote: Why not just use the TWC nameservers, if thiings work when you use them instead of the Google nameservers? One reason would be that TWC used to hijack failed DNS requests and show advertisements ( http://netcodger.wordpress.com/2010/09/14/roadrunner-returns-to-dns-hijack-tactics/ ). Also, Google DNS and OpenDNS helped manually clean up bad records after the NYTimes had their nameservers changed at the TLD registry ( http://blog.cloudflare.com/details-behind-todays-internet-hacks). —Scott
Re: 10G Router
If you require full redundancy, checkout the MX104. It also has a slightly better RE. On Aug 31, 2013, at 6:44 AM, sten rulz stenr...@gmail.com wrote: Hello, I am currently looking into a 10G router that will support the below requirements and hopefully not be too costly. Do you know of any models to stay away due to issues or that you would recommend? - 4x+ 10GBE ports - BGPv4/v6 - Small number of RU preferred - Support for 2-4 full routing tables - 2 10GBE ports down to switches - 2 10GBE for up-streams but would prefer more to support IXs. I have been looking into a few options including; Brocade CER 2024C-4X, Broacde MLXE-4 with 10Gx8-X, Juniper MX80, Cumulus Linux, etc. Some quick notes: - 4x 10GBE ports is a bit low for the Brocade CER - Not sure how the CER will handle a few routing tables and 10G+ traffic - The MLX and MX80 is very high costs from what I have seen - The MX80 has 4x 10GBE ports but at less allows an extra 4 via MIC - Decent number of real use case reviews for the MX80 - Possibly use cumulus networks if there are any systems that meet the requirements Thanks Steven
Re: looking for hostname geographic hint validation
Dear Bradley,
So basically you're asking others to do your homework for you ?
The only useful purpose your list serves is to demonstrate why people
shouldn't try to build fancy algorithms that rely on an entirely
unreliable datasource.
All you end up with are hacked together algorithms that contain a whole
load of assumptions and will be obsolete by the time you release version
1.0 because people will have changed their naming conventions a million
times.
For example, picking one example from your list
iata([^a-z]+[a-z]+\d*){3}.ic.ac.uk
ic.ac.uk = Imperial College. A well known and respected ivory towers
institution in the UK. The vast majority of their campus sites are
located in London and only one or to outside London in South East England.
It is therefore very unlikely they'll be using IATA code, infact, last
time I checked they were using conventions such as
hostname.doc.ic.ac.uk, hostname.ch.ic.ac.uk.
Far from being IATA codes, the intermediate subdomains actually refer to
departments (DepartmentOfComputing and CHemistry in the two I quoted).
Sorry to rain on your parade, but someone had to say it.
Re: 10G Router
On (2013-09-03 12:59 -0400), ja...@towardex.com wrote: Do note however: MX80-48T (cheaper variant with 48x tri-rate copper) uses the old MS-DPC and does not scale very well when things like Netflow/IPFix No it does not, it uses trio just no QX chip for per-vlan QoS. -- ++ytti
Having dropped packets when reaching Cogent Network
Hello, If anyone is from Cogent, can you email me off list. I'm having a problem reaching a website when going through Cogent hops. Looking for any help, thank you! -John-Pierre
Update on Mailman Outage from the NANOG Communications Committee
Hello All, Just wanted to send you all a quick note regarding the mailman outage NANOG experienced this weekend... A couple of changes made in August on the server resulted in an issue when the new month arrived. We have found the issue, fixed, and now have everything up and running properly again. Lists are working as they should and the web user interface is available should you wish to make any changes to your subscription. We apologize for the interruption, and should you experience any other problems/issues, please let us know by sending a message to adm...@nanog.org. Cheers, Valerie Wittkop On behalf of the NANOG Communications Committee
Re: Mail best practices?
What's your greet pause set to? Ted On Tue, 3 Sep 2013, Deepak Jain wrote: Without going to a dedicated list for something like this, I'm looking for a common sense approach. Sep 3 17:55:20 XXX sendmail[155]: r83Lse37000155: rejecting commands from outmail016.ash2.facebook.com [66.220.155.150] due to pre-greeting traffic Sep 3 17:55:22 XXX sendmail[156]: r83Lsg6N000156: rejecting commands from outmail015.ash2.facebook.com [66.220.155.149] due to pre-greeting traffic Isn't this sort of thing supposed to be frowned upon still? I am not trying to name shame here, but I figured this is a pretty big/respectable email sender. Thoughts for balancing sensible network spam management with sensible best practices that affect lots of users? Thanks in advance, Deepak
Re: Is the FBI's DNSSEC broken?
Le 03/09/2013 23:28, John Levine a écrit : On Fri, Aug 30, 2013 at 10:27:36PM +, John Levine wrote: I don't claim to be a big DNSSEC expert, but this looks just plain wrong to me, and unbound agrees, turning it into a SERVFAIL. I heard back, seems like I found someone at the FBI who was able to explain the problem to Neustar (DNS software provider) who say they will fix it. So, what was the problem then? Cheers, mh R's, John
Re: Is the FBI's DNSSEC broken?
In message 52265aa4.6000...@free.fr, Michael Hallgren writes: Le 03/09/2013 23:28, John Levine a écrit : On Fri, Aug 30, 2013 at 10:27:36PM +, John Levine wrote: I don't claim to be a big DNSSEC expert, but this looks just plain wrong to me, and unbound agrees, turning it into a SERVFAIL. I heard back, seems like I found someone at the FBI who was able to explain the problem to Neustar (DNS software provider) who say they will fix it. So, what was the problem then? The main problem is that no one is reading / following up email sent to the advertised contact address for fbi.gov (dns-ad...@fbi.gov). This ultimately is a management problem within the FBI. Cheers, mh R's, John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Is the FBI's DNSSEC broken?
On Fri, Aug 30, 2013 at 10:27:36PM +, John Levine wrote: I don't claim to be a big DNSSEC expert, but this looks just plain wrong to me, and unbound agrees, turning it into a SERVFAIL. I heard back, seems like I found someone at the FBI who was able to explain the problem to Neustar (DNS software provider) who say they will fix it. R's, John
Mail best practices?
Without going to a dedicated list for something like this, I'm looking for a common sense approach. Sep 3 17:55:20 XXX sendmail[155]: r83Lse37000155: rejecting commands from outmail016.ash2.facebook.com [66.220.155.150] due to pre-greeting traffic Sep 3 17:55:22 XXX sendmail[156]: r83Lsg6N000156: rejecting commands from outmail015.ash2.facebook.com [66.220.155.149] due to pre-greeting traffic Isn't this sort of thing supposed to be frowned upon still? I am not trying to name shame here, but I figured this is a pretty big/respectable email sender. Thoughts for balancing sensible network spam management with sensible best practices that affect lots of users? Thanks in advance, Deepak
Yahoo is now recycling handles
Whackiness, predictably, ensues: https://medium.com/editors-picks/46b47d95b957 You can do the math how this might affect you, your services, and your users, if you have those. Will people *ever* start listening when we tell them how Bad an Idea something is? The RISKS are endless... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Yahoo is now recycling handles
The issue was studied thoroughly by a committee of MBAs who, after extensive thought (read: 19 bottles of scotch), determined that there was money to be made. whatcouldpossiblygowrong? - Pete On 9/3/2013 11:09 PM, Jay Ashworth wrote: Whackiness, predictably, ensues: https://medium.com/editors-picks/46b47d95b957 You can do the math how this might affect you, your services, and your users, if you have those. Will people *ever* start listening when we tell them how Bad an Idea something is? The RISKS are endless... Cheers, -- jra smime.p7s Description: S/MIME Cryptographic Signature
Re: Yahoo is now recycling handles
To their (partial) credit they are also supporting a new email header : Require-Recipient-Valid-Since: via draft-ietf-appsawg-rrvs-header-field The idea of this header is that it will allow a sender to control that a user will only receive an email if that email address was valid before a specific date, thus at least stopping someone from using a recycled account to carry out a password reset on another service. Facebook at least is already sending this header on all emails. Overall this is nothing new - Hotmail has been doing the same thing for years. Scott On Tue, Sep 3, 2013 at 8:09 PM, Jay Ashworth j...@baylink.com wrote: Whackiness, predictably, ensues: https://medium.com/editors-picks/46b47d95b957 You can do the math how this might affect you, your services, and your users, if you have those. Will people *ever* start listening when we tell them how Bad an Idea something is? The RISKS are endless... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Yahoo is now recycling handles
On 9/3/2013 11:57 PM, Scott Howard wrote: Overall this is nothing new - Hotmail has been doing the same thing for years. Scott When I used to use Hotmail - Your account was dropped after 30-60 days of non-use. Whereas Yahoo kept accounts active forever until recently. Granted it's been 15 years since I've used a Hotmail account regularly. Microsoft *may* change their policies more often than that.
Re: Yahoo is now recycling handles
On Sep 3, 2013, at 9:12 PM, ML m...@kenweb.org wrote: On 9/3/2013 11:57 PM, Scott Howard wrote: Overall this is nothing new - Hotmail has been doing the same thing for years. Scott When I used to use Hotmail - Your account was dropped after 30-60 days of non-use. Whereas Yahoo kept accounts active forever until recently. as an ex yahoo security guy for many years, my recollection is this isn't the case. starting 8-10 years ago accounts which went dormant for extended times had actions taken on them. e.g. free accounts not logged into for a while (order of a year) had their old email archived, or maybe even erased, i am not recalling exactly which... accounts already in that inactive state could at any point have their names reclaimed, but the process of doing that was (as i recall) a manual and infrequent one. i remember it happening two or three times over about 8 years, so that would make it a big batch about every year or two. (several kinds of accounts, such as paid accounts, accounts managed for partners such as sbc and rogers, and those deactivated for abuse were kept around forever in the deactivated state so they couldn't be ever reregistered and reused for similar abuse.) (yahoo internally understands the difference between the old account and the newly registered eponymous account because account registration date (at the granularity of a week) is logically part of the yahoo id whenever ids are used, exported, compared with other ids, looked up or stored in databases, etc..) (it was a fairly common bug we would find in our security reviews for programmers to ignore the regweek, for example, when exporting lists of ids for some purpose). btw: i don't think it's so unreasonable to treat a free account that hasn't been logged into for 2-3 years as abandoned. i agree it can have unfortunate side effects (particularly domain name takeover of long-registered names). in its early days, one of the reasons people switched to gmail was that they could get a better name there than e.g. blah32...@yahoo.com. (this was slightly exacerbated because for a number of years if someone had m...@yahoo.com, the cohort address in other ccTlds such as blah32...@yahoo.co.uk was also not available to be registered.) approximately 5 years ago, yahoo split out some populous countries into their own name spaces, which made a lot more names available to be registered. there was a land rush, in fact, to register good names, and some people were not-so-amusingly trying to sell them. Granted it's been 15 years since I've used a Hotmail account regularly. Microsoft *may* change their policies more often than that.
