I've just today been reading up on SPF records. My problem is that mail coming from a new server we've set up is being spammed by Big Mail (Gmail, Hotmail, etc.).
The server has a primary domain (domain.com) but many other domains are hosted on it too (eg. mine.com). When I try to send mail with the from field set to me@mine.com (as opposed to me@domain.com) it gets spammed.
We're not on any blacklists, the A records for mine.com point to domain.com as do the MX records, domain.com has PTR records, and I've just put in a SPF record for mine.com.
So far no luck. Sigh.
I'm also a bit confused. I've never used PGP to make an encrypted zip file, but I use GnuPG to encrypt emails all the time and I, too, was under the impression that it was infeasible in practice to brute force the encryption.
Is the difference that with PGP/GnuPG email encryption, our passwords are merely decrypting our keys which are themselves fully 128 or 256 bits long or whatever? Whereas in this situation with the ZIP file there was no separate key - the password was the key? (I haven't read all of TFA)
Based on my reading of the article, it will detect congestion at any point along the route. If you have several computers behind a NAT router all sharing the same internet connection, and one of those computers is using this new BT protocol, it'll detect if it's congesting the gateway and reduce its speed.
So, yes, it'll improve the network performance of any non-BT apps on any of the other computers in your local network.
I feel compelled to correct your signature:
I believe it's "for all intents and purposes", which would make more sense too.
It's all about the IP and the patents!
If h.264 were royalty free, no doubt it would be supported. But as it stands, only those with deep pockets can pay the licensing fees — and that goes for both those providing the decoders as well as those simply hosting (broadcasting) h.264 encoded content.
The hardest part of climbing the ladder of success is getting through the crowd at the bottom.