Gmail Moves To HTTPS By Default 275
clone53421 writes "Although Gmail has long supported HTTPS as an option, Gmail announced their decision yesterday to switch everyone to HTTPS by default: 'We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data. Over the last few months, we've been researching the security/latency tradeoff and decided that turning https on for everyone was the right thing to do.' I wonder if this has anything to do with the reports of Chinese users having their accounts hacked? 'Only two Gmail accounts appear to have been accessed, and that activity was limited to account information (such as the date the account was created) and subject line, rather than the content of emails themselves,' said David Drummond in that blog update. That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers."
Hang on... (Score:2, Funny)
That does sound like it perhaps could be a result of insecure HTTP traffic being intercepted in transit between the users and Gmail's servers."
If someone can intercept your traffic how will this help? They can intercept all your secret handshake bits too.
Re:Hang on... (Score:5, Informative)
Might as well scoop up the mod points if someone's going to get them. This, moron [wikipedia.org].
Re: (Score:3, Informative)
the man in the middle would have to have a valid mail.google.com certificate for the attack to be seamless.
yes, we know how effective "invalid certificate" prompts are, but this is not a failure of the encryption mechanism.
Re: (Score:2, Insightful)
Maybe that cert has been compromised by a Chinese insider. Maybe that is why google are so upset with China at the moment. I know that in some corporate environments https is a big issue for IT security. They don't like employees punching through their filters with SSL. China may have a similar attitude and may have been trying to get their hands on the certs for some big companies.
Re: (Score:3, Interesting)
> Maybe that cert has been compromised by a Chinese insider.
i don't see mail.google.com's cert on any revocation lists, so it's probably ok.
given the approach google has taken in other aspects of the unfolding drama,
i think it's a fairly safe bet that it would've been revoked by now if there was any doubt that it may have been compromised.
Re: (Score:3, Informative)
You don't need to compromise the original cert, you just need to get one of the many certification authorities that are trusted by the major browsers to create you one with the right name on it.
Afaict some of the certification authorities are very lax about checking that the person applying for the certificate is the legitimate owner of the domain and I have no doubt that if the Chinese government wanted they would have no trouble procuring such a certificate.
Re:Hang on... (Score:4, Insightful)
Have you see what root CA certs are in a browser? I'm sure that if one pulls it up and sees the list of trusted root certificates, there are offshore companies that people have not heard of, but yet not just hold charge of what is valid or not, but can delegate to people unknown who gets a green toolbar, and who doesn't. To boot, all it takes is just one of these to be compromised, and someone can start doing bogus certificates. Combine this with using Unicode text (the Cyrillic "C" is not the ASCII "C"), and one could completely spoof a legit site in an advanced phishing attack... or just threaten that legit site with the spoofing so they would pay protection fees.
What I'd like to see in Web browsers is perhaps something similar to what is done in ssh, where the Web browser keeps track of the SSL certificate that the bank uses. If it changes, the browser will pop up a notice, and perhaps show some pertinant info, showing that this is either legit, or maybe show that someone spoofed a CA and the cert is completely bogus.
Re: (Score:2)
You haven't been around here very long, have you?
Encrypted data doesn't travel across web as quick (Score:3, Funny)
We need network neutrality for encrypted packets!
iGoogle support? (Score:5, Informative)
Re:iGoogle support? (Score:5, Informative)
Re: (Score:2, Insightful)
Re: (Score:3, Informative)
The problem with this which Google hasn't fixed yet, despite lots of screaming users, is that when you try to search from that search box, it
Other than that, however, it's fine!
Re: (Score:2)
Re: (Score:2)
u cannot mix http and https content in a page,
<Kyle's Mom>Wha-wha-wha?</Kyle's Mom>
Sure 'u' can.
Re: (Score:2)
I guess I should be more specific. Two documents that were sent over differing protocols cannot interact. A frame or iframe has its own document.
Or are you referring to my use of 'you' as a genderless third person?
Re: (Score:2)
I believe it does. I'm not sniffing, so I could be wrong here. Do you have any explanation for this statement?
Re: (Score:2)
Every two weeks or so Google asks you to reconfirm your password. If the app hits this, it will give you the https error. All you have to do is manually log in and the app will work again.
Sniffing? I disagree. (Score:5, Informative)
Re: (Score:2)
Given that connecting a new POP3 client, or new IMAP client, and syncing up your data is likely to grab everything in your relevent folders, including "All Mail" if you're not careful, I doubt that such transactions would normally be noticed. And given the incredible amount of logging involved, I doubt that Google hangs onto those logs for very long. Can anyone attest to how long individual transaction is preserved for at Google?
Great! (Score:4, Informative)
Re: (Score:2, Interesting)
Great move by Google,
Especially considering yahoo & hotmail don't have any option for https.
Wait, what? (Score:2)
encrypted data doesn't travel across the web as quickly as unencrypted data.
Why on earth would that be? Routers don't know whether your data is encrypted or not. The one difference I can think of is that encrypted data can't be compressed. But that wouldn't have any effect on latency, just throughput. And that can be taken care of by compressing the data before you encrypt it anyway.
Re: (Score:3, Informative)
1. Encrypted data generally has a percentage overhead
2. Encrypted data, if the algorithm doesn't suck, is not easily compressed.
Re:Wait, what? (Score:4, Informative)
3. Encrypted data has two processing phases, one at each end of the connection that do not apply to unencrypted data: encryption and decryption. By "not as quickly" they were probably referring to end-users' perspective more than network transmission time.
Re: (Score:2, Funny)
4. Profit!
Not really informative (Score:3, Interesting)
1a - If your email is encrypted with IPSEC, then there's a per-packet overhead from the extra packet header; it's not really a percentage, though you could think of it that way for average packet sizes. It's not significant for most applications except VOIP, which typically has very small data wrapped in lots of RTP/UDP/IPSEC/IP headers.
1b - If your email is encrypted at or above the transport layer, there's typically minimal overhead. The data encryption doesn't take extra space, except sometimes for t
Re:Wait, what? (Score:4, Insightful)
That is why you always apply compression before encryption. Not exactly rocket science.
Re: (Score:3, Funny)
I will be really scared when encryption systems do comprehension.
Re: (Score:2, Insightful)
I suspect they were just dumbing down all the overheads of using encryption into one catchall sentence.
Re:Wait, what? (Score:4, Informative)
Routers don't know whether your data is encrypted or not.
Neither does your browser, or the server. HTTP is a stateless protocol. Every encrypted request requires setting up the encryption all over again.
Re: (Score:2)
Re: (Score:3, Informative)
Not always the case anymore. Web browsers and servers have implemented persistent connections (keep-alive) for a while. It's in the RFC [ietf.org].
You're both right, but the GP is righter. Yes, persistant connections have been around since 1999. But it still DOES starts the encrypted request all over again.
It is persistent, but it is also stateless. Makes sense when you think about it.
Re: (Score:2)
Hmm, I wonder if I should try to finish my old project:
An AES encrypted packet-based bytestream connection between the client and the server, implemented in pure JavaScript (client) and Java (server).
With JSON inside the packets. And most importantly: One standing connection. (A single HTTP request that does not time out.)
I already did the basic framework. Back then I had already a “network card” and a “network file system” protocol and object. Also compression is built-in into HTTP
Re: (Score:2)
Re:Wait, what? (Score:5, Informative)
If you're using keep-alive at the HTTP layer you're most certainly not closing and re-opening the underlying SSL socket -- in typical implementations the HTTP code is only vaguely aware that SSL even exists.
Now not every server or client supports or uses keep-alive. But if you do then SSL is only negotiated once per session, not once per HTTP request.
Re: (Score:3, Insightful)
The reason why encrypted data tends not to travel as quickly (other than the fact that it is incompressible) is that a lot of DPI filters in a number of links throttle anything encrypted, assuming if it is encrypted, then its P2P traffic.
Re: (Score:2)
A couple years ago, I migrated a company to a new mail host and set up all of their clients to use encrypted connections. A few months later, I got reports that people all over the main office were reporting problems sending and receiving mail. Turn off the encryption, everything flows fine. Turn it on, throttled to uselessness. Remote offices weren't seeing this problem and the mail host said their systems were running fine. All I could figure was some BOFH between the main office and the mail hosting
Re: (Score:2)
Apart from the CPU of encrypting there is the issue of compression. Perhaps some physical network links use compression, and encrypted traffic can't be compressed?
Re: (Score:3, Informative)
The article is imprecise, but HTTPS is higher latency, even when network and CPU capacity are sufficient -- setting up an SSL connection requires several more round trips than raw HTTP, so if your latency is higher than 0 it can be noticeably slower to use encrypted connections.
Encrypted connections also typically have some per-datagram overhead, though that's typically pretty small, and not strictly necessarily on streams if you're willing to give up integrity checks. And there is a CPU load. The CPU facto
Intercepting emails (Score:5, Informative)
Actually, I read somewhere that hackers gained access to a system designed to give law enforcement access to people's emails, presumably under warrant. [sarcasm]Who could have ever imagined the same loopholes intended for use by law enforcement could possibly be exploited by hackers as well?[/sarcasm]
Found the source (Score:5, Informative)
I found the source. It's from PC World [pcworld.com]:
Re:Found the source (Score:4, Insightful)
And that right there, proves we're at war with China--much more than Al Qaeda. Just like George Washington's crossing of the Delaware, their attacks happen on Christmas eve.
People say it's kolluj students with time off, and to a certain extent--near uni holidays, you can see port scans and other crap go up. But the real--nasty brutish attempts, the subtle ones--happen christmas, easter, labor day--right when people aren't paying close attention. They're diabolical, they're automated--and tools like fail2ban don't catch the ssh brute force attempts, because they come from thousands of hosts one at a time--just trying to sneak in. And that's in addition to the web application attacks.
I haven't finished writing my fake SSH server yet to see what people do when they get in, but I'm betting the entire medium is just one giant funnel to beijing intelligence looking to slurp down as many usernames and passwords as they can.
They're in our network, they've been in our networks. They've compromised the DoD, and hundreds of defense contractors, and the national labs. And because they're all corporate, it hardly ever makes the news--people that reveal it are sued and/or fired under suspicious circumstances.
Make no mistake--this is war, and China is winning because we refuse to even admit it.
Re: (Score:3, Interesting)
But please do tone down the rhetoric. Nobody is being killed. Even knock on effects can't be called a "war".
We're all just chillin' here hk0ring each other's shti.
Re: (Score:2)
The end users feels safe as they are using the "s" and no more plain text in the wild.
Google would have never offered "s" unless they have a backdoor.
Re: (Score:2)
While true that it wasn't interception - I am sure the recent involvement with the Chinese security issues has simply brought into focus how much Google is being attacked, also knowing that they are dealing with some relatively skilled hackers. Whether the attacks were designed to sniff out people not using HTTPS or not - better to just remove that option altogether.
The beginning of HTTPS for everything by default? (Score:5, Insightful)
I've long held that the only answer to pervasive surveillance is to encrypt everything.
It won't stop them from cracking things that attract their attention, but for most things it won't be worth the hassle.
Encrypt everything.
Re:The beginning of HTTPS for everything by defaul (Score:3, Interesting)
Encrypt everything.
I agree, and let me add I always thought Freenet's model was onto something. It's very failure proof and it caches static content. Which unfortunately is everything. But there's probably a way to get something wiki-like using the current message board implementation, providing one had an application that could interpret the data from a dedicated board.
Re: (Score:2, Insightful)
I've often wondered why email clients don't make it easier to set up encryption, and use it as the default if your recipient and you have exchanged keys (preferrably automatically if both have the capacity.) Sure, if you're semi-clued up it's not that hard to set this up manually, but to the average user it's way out of their comfort zone.
Re: (Score:2)
I deal with the vast unwashed neo-luddites who are happy with their on button and cup holder. They can with some effort open and read emails. Asking them to manage a secure public key system is beyond their fragile minds. At least their mail is harder to hack.
Having terrified them that they would lose everything including pension if they did anything with banking or 401k or bought anything at least my parents are safe.
Though to my dismay they used a debit card for the first time last year. When they told it
Re:The beginning of HTTPS for everything by defaul (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:The beginning of HTTPS for everything by defaul (Score:5, Insightful)
I don't know, I think there are some things that don't need encryption. I don't think I will ever need encryption to read google news, for example, or to watch youtube movies.
Actually yes you need to encrypt that too.
If you are selective about what you encrypt, then the best assumption to make is that the things you don't want/need to hide are plain text, and the things you want/need to hide are encrypted.
Now when I am watching your data stream and see some google news, a youtube video, and finally an encrypted block of data, it is almost certain that whatever is in that encrypted block of data is worth my while to try and crack, as it is clearly data you want hidden.
If you encrypt everything all the time, then I would always wonder what you are hiding (if anything!)
I could take some of your encrypted data and try to crack it. Say it works once or twice, and all I see are you reading your daily news, and some video of a kitten falling over on youtube. Well hell, suddenly not only did I waste a lot of time cracking that encryption for nothing, but I would assume (possibly mistakenly) that you very well might not have anything to hide, and there is no reason to specifically look into anything you are doing.
Even if I don't assume that, and either assume or just know that you DO have something to hide... Well as a hacker, where would I start? I don't have all the time and processing power in the world to brute force everything you do. I would always be very behind your 'now' traffic. By the time I eventually did get to decrypting the part you really wanted hidden, it could be years or decades later. How much use would that data be so long after the fact? More often than not, the older the data, the less useful it is.
Encrypt everything. Nothing looks suspicious and out of the norm, so if/when you do something that you do want/need hidden from hackers, a hacker wouldn't even know it happened let alone know where to start looking for it.
Not encrypting everything just paints a huge target on the exact data you are wanting to hide in the first place.
Re: (Score:2)
Re: (Score:3, Insightful)
You are exactly right. This is for the very same reason that we need to start making encryption standard for everyone; if your scenario was to take place under current circumstances, you would already be under suspicion and under greater focus since most people don't encrypt everything... when everyone encrypts everything, it will finally be the case that no pattern can be deduced from the presence of encrypted data
Re: (Score:3, Insightful)
> Not encrypting everything just paints a huge target on the exact data you
> are wanting to hide in the first place.
Right. So just encrypt the kitten videos and send lots of tantalizing stuff in the clear. That'll fix 'em.
Re:The beginning of HTTPS for everything by defaul (Score:2, Interesting)
The day someone implements DNSSEC based server key delivery in a popular browser, there will be a grass-roots effort to make your dream come true.
Re: (Score:2, Interesting)
How big an effort is that to do in, say, WebKit? Firefox? Why isn't anyone working on it? Or are people? What are the benefits?
Forgive my ignorance, I truly didn't know. Is it something that a few thousand dollars of programming time would buy?
Re: (Score:2)
Since when is HTTP(S) “everything”? Maybe for those who have never seen something else than HTML and webapps.
Just set up VPN-like connections. Or think it to the end, and use a Darknet by default. ;)
Re: (Score:2, Interesting)
How do you effectively search your email history if it's all encrypted? Are there algorithms for indexing encrypted data without giving too much away?
Re: (Score:2)
Google probably only (at least intentionally) offers that service to governments. So while it might not protect you from the biggest threats out there, there sure as hell would be a point to it.
Really? (Score:2)
I wonder if this has anything to do with the reports of Chinese users having their accounts hacked?
Really? No, I'm sure it's just a coincidence.
Next step: encryption at rest (Score:3, Interesting)
Now the next feature we all need is encryption of the content of our data when it is at rest on disks in Google's data center. That way even Google employees cannot read our mail. Not for serving up ads. Not for any reason whatsoever.
And after that, Facebook and Twitter...
Nah, I'm dreaming.
Re: (Score:2)
Hushmail does exactly this. If you use the Java (as opposed to the Javascript/SSL) client, the only place E-mail gets decrypted is on your personal computer. I use Hushmail for both secure E-mail (PGP encrypted), as well as aliases that I can dispose of, such as when I'm posting to Craigslist and only want the address to last the duration of the buy/sell/work transaction.
(Yes, Hushmail did have to give information to LEOs a couple years ago, but that doesn't mean that anyone and everyone has access to one
Not through sniffing (Score:5, Informative)
Re:Not through sniffing (Score:5, Interesting)
That access is actually provided in a ton of places you wouldn't expect.
Did you know that Xbox Live encrypts everything by default?
Did you know the one and only exception is... voice communication? Hmm...
Will Yahoo! follow suit? (Score:3, Interesting)
Anyone care to guess if Yahoo! will so the same thing?
I really hope so. I use a Yahoo account and I know how easy it is to sniff Ethernet. I hate to read mail at cafes and other places where I'm not certain of the LAN security.
Re:Will Yahoo! follow suit? (Score:5, Funny)
I hate to read mail at cafes and other places where I'm not certain of the LAN security.
Weird, I love reading mail at insecure cafes... you can sit in the corner and play games like "match the email to the person" and "convince the businessman that you're a replacement representative for his meeting" :-)
No Brainer (Score:3, Interesting)
Encryption has some overhead, but so what? It's not like modern hardware isn't up to it.
Anybody who cares about security has stopped using open protocols to send sensitive data. FTP is out, SFTP is in. Goodbye Telnet, hello SSH. And anybody who sends passwords over an open HTTP, SMTP, or IMAP connection is begging to be hacked. (POP? You're still using POP?) The issue is not security versus performance, it's the usual case of people not going to the trouble of upgrading their technology until they can't ignore the problem any more.
As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues, or making sure you the resources to properly support your latest product. They need to hire fewer geniuses and start hiring more ordinary drudges with the patience to make things work in the real world.
Re: (Score:3, Insightful)
> As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues
and now you show me another free mail service of any significance that has IMAPS, POP3S, SMTPS and now HTTPS (yes, all with *S, because Gmail requires you to use SSL for SMTP, POP3 and IMAP, and has been doing so since the very beginning, HTTPS was available for use for a while, though not required or offered by default).
if google is dead last,
Re: (Score:3, Interesting)
Yeah, GMail is pretty good — now. Do you recall that it was in beta mode for 3 years? Any other software company would have hired some QA people and gone final in 6 months. But QA is boring, and beneath the dignity of the geniuses they insist on hiring.
I have a Google Voice account. If it were a mature product, I'd switch over in a heartbeat — it's got tons of free features that I'm currently paying PhoneTag and Skype to receive. But the UI is cranky and tends to freeze, and there are a few othe
Re: (Score:2)
I didn't say that you shouldn't use SMTP. I said you shouldn't send a password over an open SMTP connection. There are ways to encrypt the login transaction, and even the contents of your messages. Alas, too many SMTP providers don't support this.
Re: (Score:2)
Re: (Score:2)
Sigh. I never said "open protocol". I said "open connection". I believe the word "open" can have more than one meaning, depending on context. If not, I suggest you avoid expressions such as "open door", "Broadway opening", "don't open your damn piehole", etc.
Re: (Score:2)
Keep in mind that SSL-enabled versions of both POP and SMTP (with authentication) are very widely supported.
Wait, what? (Score:2, Redundant)
'We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.'
Huh? Encrypted bits are asthmatic and can't run as fast as unencrypted ones? Coming from someone at Google this statement is quite the WTF. Is it too technical now to say that encrypting data requires extra calculations which introduce delays so gmail will respond somewhat slower?
Re: (Score:2)
Yeah, I thought the same thing. Being that several years ago my coworkers determined that using sftp (or ftp through stunnel? - I forget) added slight compression as well as encryption over regular ftp. So, even though a secure transfer was unnecessary (public weather data) and despite the cpu hit, we'd actually be saving quite a lot in bandwidth since the data was on the order of terabytes.
The best reference to this I could find was this wikipedia article [wikipedia.org].
Re: (Score:2)
Is it too technical now to say that encrypting data requires extra calculations
Speaking as someone who has recently been providing tech support for his mother -- yes, that is *far* too technical for the average non-IT person :-(
HTTP sends more than just subject line... (Score:3, Informative)
No, if that were the case they would have been able to see *everything* the user received as part of the data response, including message bodies.
Re: (Score:2)
Unless the user only looked at their inbox without opening any particular message.
pochta.ru / smtp.ru (Score:3, Informative)
Some free mail providers have been offering HTTPS for a long time, for example the Russian https://www.pochta.ru/ [pochta.ru] . Their web mail interface is decent too. Unfortunately they've been bought out by or merged with "qip" and have dropped their English language option since. It's still usable though and a good option if you need a free mail account with secure authentication outside of the western countries for some reason.
So does Wikipedia... (Score:3, Informative)
Gmail gadget for iGoogle (Score:4, Interesting)
I removed the Gmail gadget for iGoogle from my iGoogle homepage, because despite the iGoogle being loaded via HTTPS, the Gmail gadget would use plain HTTP.
Have they changed the Gmail Gadget to also use HTTPS? I couldn't find anything about it.
Huh? HTTPs? (Score:2)
Dont’ you mean IMAPS and SSMTP?
Correction to summary (Score:5, Interesting)
"Only two Gmail accounts appear to have been accessed"... by attacking Google systems directly. Using other methods, the attackers were highly successful.
Google disclosed that upon investigating users suspected of being attacked, they found "dozens" of Chinese human rights activists who had been compromised through phishing, malware or other systems that allowed security forces (presumably) to read their mail via a valid authentication. So, while Google itself may be mostly reliable on the backend, the security ecosystem as a whole is deeply flawed.
Google: "as part of this investigation but independent of the attack on Google, we have discovered that the accounts of dozens of U.S.-, China- and Europe-based Gmail users who are advocates of human rights in China appear to have been routinely accessed by third parties. These accounts have not been accessed through any security breach at Google, but most likely via phishing scams or malware placed on the users' computers."
http://googleblog.blogspot.com/2010/01/new-approach-to-china.html [blogspot.com]
So go change your passwords.
Use HTTPS on the authentication only? (Score:2, Interesting)
Is it obvious to everybody that encrypting everything is good only for privacy but doesn't seem to add much to security when compared to encrypting just the authentication data then using a session ID? Or rather, could the gurus please clarify where's the security increase in putting everything over https?
Ouch. (Score:3, Funny)
encrypted data doesn't travel across the web as quickly as unencrypted data
That just hurts my brain.
Re: (Score:3, Interesting)
encrypted data doesn't travel across the web as quickly as unencrypted data
That just hurts my brain.
Actually, that is possible. Encrypted data doesn't generally compress as well as plaintext, and it's quite common for web servers to compress data before sending it to the client.
Re:Ouch. (Score:4, Insightful)
Encrypted data doesn't generally compress as well as plaintext, and it's quite common for web servers to compress data before sending it to the client.
...and it's quite common for security libraries to compress data before encrypting it. For instance, it's the default in GPG, and SSLv3 and TLSv1 support configuring compression in the handshake.
I hope they keep Google Apps in the clear! (Score:3, Informative)
If they make Google Apps HTTPS only, I'll be screwed, because my little embedded devices can't handle HTTPS stack.
Re: (Score:3, Informative)
In TFA:
Was it really about that? (Score:3, Insightful)
We initially left the choice of using it up to you because there's a downside: https can make your mail slower since encrypted data doesn't travel across the web as quickly as unencrypted data.
Bullshit.
Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster. That would be why it's taken until now for them to take this step.
Of course, it's still fairly useless if I stay logged in -- then my session could still be hijacked from vanilla Google searches...
What about slashdot? (Score:5, Interesting)
I really want EVERY site I visit to use https. Why doesn't slashdot?
Re: (Score:3, Insightful)
Because there's no reason to. What are you trying to protect, valuable mod points?
Oh, and don't say "I want to encrypt everything, so the hackers don't know what's important". HTTPS doesn't hide the IP you're accessing. If you want that kind of protecting, you should get a secure VPN or Tor.
Re: (Score:3, Interesting)
What is SSL complicated or something?
Why even have logins at all? Why require passwords? Why not let anyone post under whatever name they want?
Slashdot is a service with accounts and authentication, all of which is made useless when nothing is encrypted. People said the same bullshit about freenode, and then lilo got his password popped because he logged into freenode, in cleartext, at a coffee shop, and the GNAA ran freenode for a week. Remember that? And freenode still doesn't support encryption.
I wo
Re: (Score:3, Informative)
Because Google ignores periods in account names, and have been for many years.
Re: (Score:2)
Strange, because they didn't complain when I signed up.
Where's that from then? What says I shouldn't use periods? I couldn't find a reference in the SMTP rfcs
Doesn't exist (Score:2, Interesting)
The standard e-mail addressing scheme for nearly all institutions is firstname.lastname@blahblah... It is most certainly valid.
Google just - being a service where anyone can register - wanted to ignore dots so that johnsmit@gmail couldn't impersonate john.smith@gmail and the other way around. In addition, google only allows a-z, . and 0-9, so you can't register john-smith@gmail, john_smith@gmail... etc... You actually need to have different letters and number combination than anyone else.
Re: (Score:3, Insightful)
-1 Wrong. Dots have been widely used in the user part of email addresses along with some other punctuation characters. From the Wikipedia article: [wikipedia.org]
The local-part of the e-mail address may use any of these ASCII characters:
* Uppercase and lowercase English letters (a-z, A-Z)
* Digits 0 to 9
* Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
* Character . (dot, period, full stop) provided that i