Google is the new Microsoft. Nothing new. Move on.
Who is the new Google then?
What's next Google? Dropping SMTP support?
201–210 of 263 posts
Re: What's next Google? Dropping SMTP support?
#202Earlier quoted context omitted.
I don't think they would kill SMTP, but I also didn't think they would kill CalDav.
I'm starting to think that they don't kill it, just because they can't . But if they had the chance ... :/
Well TBH I hate SMTP and would love to see it replaced.... however, the features I want (native user-to-user encryption preventing Google from reading my mail) Google would not want to add, and unless Google makes it an open standard it's a waste of time.
Re: What's next Google? Dropping SMTP support?
#203Earlier quoted context omitted.
> Plain text means anyone can read your message while it's going over the wire. Plain text is a style of encoding information (e.g. binary, XML, JSON, plain text, etc). Encryption determines if someone can intercept your message. Something can be both plain text and secure, like HTTPS for one example.
It's my understanding that people often use "plaintext" in contrast to "ciphertext", so it's not unreasonable for someone to read "plaintext" and think "unencrypted".
I've been trying to force myself to use "cleartext" instead of "plaintext" to alleviate this ambiguity. It's remarkably hard to do after so long, though.
Re: What's next Google? Dropping SMTP support?
#204I'm using Google apps for my business account and i am really annoyed that they are still not able to provide a sync tool (or a direct exchange access) for Outlook 2013. I know I could use SMTP or IMAP, but I also want to sync calendar and contacts (that is, in fact, the reason I upgraded to the pro version of apps in the first place).
Don't get me wrong, it is completely ok for Google to disable free stuff as they want. I would, however, prefer that they support their paying customers better. Or, at least, offer an option to got premium and pay for the stuff we would like to use.
Re: What's next Google? Dropping SMTP support?
#205Re: What's next Google? Dropping SMTP support?
#206Earlier quoted context omitted.
Coincidentally, only yesterday I installed an XMPP daemon on one of my servers and configured it as a message relay so I can send and receive SMS from my PC via my phone. Facebook chat also uses XMPP. So in answer to your question: yes, there are people still building new stuff on top of XMPP. However I will concede that I'm also a bit IRC advocate - so I'm probably the wrong person to comment on the best newest soci…
I'd love to read how you set that up. Any links you can point me to?
The SMS thing? It's basically just an Android app (gtalksms [1]). But I wanted a private encrypted network to control it from (I actually go further and then hook the XMPP server into bitlbee which is an IRC server for IM clients. So now I can control my phone, Twitter, Facebook Chat and Windows Messenger all from Irssi.
Re: What's next Google? Dropping SMTP support?
#207Earlier quoted context omitted.
I would like to see the replacement of SMTP be designed along with a redesign of e-mails themselves as well. I'd like to see the HTML that is supported in e-mails standardised, so there's no more issues about which clients will render what. I'd like to see the failure notices standardised, so that invalid e-mail addresses produce a standard "404-like" response, and so on. The problem isn't so much that we have multip…
I'd like to see the HTML that is supported in e-mails standardised Count me out. It wasn't even two weeks ago that we had the story here about how The Onion was hacked because somebody clicked on an obfuscated HTML URL in email.
I wonder if this could be fixed by displaying SSL certificate status next to email titles. Much like browsers do for websites. This way before you open or at least before you click anything in the email you can see the validity of the sender.
Re: What's next Google? Dropping SMTP support?
#208Earlier quoted context omitted.
Coincidentally, only yesterday I installed an XMPP daemon on one of my servers and configured it as a message relay so I can send and receive SMS from my PC via my phone. Facebook chat also uses XMPP. So in answer to your question: yes, there are people still building new stuff on top of XMPP. However I will concede that I'm also a bit IRC advocate - so I'm probably the wrong person to comment on the best newest soci…
No one is taking xmpp away from your server or the applications that are using it; but take Facebook: did they do any effort of integrating their chat with the Gmail one?
"but take Facebook"
...
PLEASE!
:-D
(with apologies to Henny Youngman -- http://en.wikipedia.org/wiki/Henny_Youngman)
Re: What's next Google? Dropping SMTP support?
#209Earlier quoted context omitted.
Multiple implementations are a strength. In fact, you won't see a good replacement for SMTP without multiple independent implementations. (What will it look like? I would guess it will look like a two-part service, with one protocol for servers to talk to each other and another for clients to talk to servers. Servers will send tiny notifications to other servers that mail is available for their subscribers; then the…
I would like to see the replacement of SMTP be designed along with a redesign of e-mails themselves as well. I'd like to see the HTML that is supported in e-mails standardised, so there's no more issues about which clients will render what. I'd like to see the failure notices standardised, so that invalid e-mail addresses produce a standard "404-like" response, and so on. The problem isn't so much that we have multip…
I'd like to see it standardized that HTML is not supported in e-mails. Email worked fine before HTML came along and all the good email is still HTML-free... in my experience, only robots use HTML.
Re: What's next Google? Dropping SMTP support?
#210Earlier quoted context omitted.
I would like to see the replacement of SMTP be designed along with a redesign of e-mails themselves as well. I'd like to see the HTML that is supported in e-mails standardised, so there's no more issues about which clients will render what. I'd like to see the failure notices standardised, so that invalid e-mail addresses produce a standard "404-like" response, and so on. The problem isn't so much that we have multip…
I'd like to see the HTML that is supported in e-mails standardised Count me out. It wasn't even two weeks ago that we had the story here about how The Onion was hacked because somebody clicked on an obfuscated HTML URL in email.
While we're at it, let's all abandon HTML5 and have every browser doing their own thing, because people occasional fall for fake anti-virus ads.
We can't stop social engineering like that - it's completely unavoidable. Which is why banks and payment providers regularly tell people not to follow links asking for bank details (etc). Yeah it sucks that The Onion got hacked that way, but your argument is doesn't fix that. Your argument is nothing more than cutting of your nose to spite your face (ie advocating an inconsistent platform for legitimate e-mails despite anchor tags working on every client already).
At least if e-mail was completely redesigned, then we could have banks provide a unique cert that hangs in the e-mail header and can support the authenticity claim of the sender (I'm sure there's ways around that idea I've just presented - but that was just off the top of my head. Any such design would obviously need to be thoroughly thought out)