He doesn't run the business, just the pipes.

I'll elaborate a little.

The impression I have formed is that gmail will have whatever features google's gmail-for-businesses product needs. If a considerable percentage of customers (ie. the ones who pay per month and user) use a particular feature, then that feature stays and is maintained.

Does not the ol' Don't-Be-Evil corporation owe it to society to maintain features that support the common good?

I know from my experience in hwops that plenty of people on the corp domain DO believe that they are working towards a better world--and that making more money will only accelerate progress towards that goal.

The question is: are they wrong? Has Google lost its way?

Let's look not just at this IMAP issue but also at the OP as we ponder that.

XMPP is even better example than IMAP.

Rumour had it that they tore down the federation due to an unmanageable spam wave. Something about friend requests from spam puppets. I've never heard details. Has anyone else here?

His/her superiors.

Aren't you saying that despite the observable part of the moon being rock, the unobservable part is cheese?

Google management is neither unobservable nor unobserved.

Judging by the actions of Google's people in IETF, any feature that's used by paying mail customers seems to have management support. Management seems to like income, as far as I can tell.

I'm saying that while the technical lead may not be hostile towards IMAP, the "higher ranks" may decide it's not a business priority anymore and ask to get rid of it.

The effing rotating TLS keys. You missed that?

Cite RFC?

Back when I set up a client to pull from Gmail it would break twice a year: when the changed their TLS cert, and when the later changed it BACK.

My conclusion at the time was that they wanted to keep the percentage of users of the IMAP service below some value, and every time the jerked the config around, they'd see a dip in the graph on their end. My setup is currently non-functional. The maintenance cost was too high. Mission accomplished.

Note: now that I think about it, maybe the cert rotation issue was on (e)SMTP, not IMAP. Same diff.

In addition, what Google claims is an "SMTP server" does surprising things in violation of the relevant RFCs, in furtherance of Google's business models:

http://lee-phillips.org/gmailRewriting/

That blog posting is from 2012, so I think it's surprising that its author clearly hadn't read RFC 4409, published in 2006.

The first paragraph about message modification is: "Sites MAY modify submissions to ensure compliance with standards and site policy. This section describes a number of such modifications that are often considered useful." From is typically modified to comply with SPF and/or DKIM.

RFC 4409 is obsoleted by RFC 6409 (Nov. 2011), which is the one I refer to. The sections therein on header rewriting do not allow the modifications that Google makes to the From: header, which can, as I point out, lead to mismatches of personal names and email addresses and falsification of sender identity, with all the easily foreseeable damage that may result.

6409 contains the same wording: "MAY modify submissions to ensure compliance with standards and site policy" and gives examples.

The sections on header rewriting are essentially examples of what the document describes as "modifications that are often considered useful", they're not an exhaustive list. The only MUST NOT rule that concerns email address rewriting is about destination addresses.

Is it your opinion that a reasonable interpretation of 6409 is that a submission agent may falsify the sender of an email? Or create false associations between personal names and email addresses?

No RFC rule prevents that, and as far as I know no RFCs even try to define what constitutes a true or false association between a personal name and an email address. But RFC 6409 gives site policy unrestricted permission to allow or deny that.

(Well, almost unrestricted. The results have to be syntactically valid.)

I don't think your interpretation of the RFCs is natural or remotely reasonable; in fact it leads to absurd consequences. We'll have to leave it at that. I stand by everything in the article.

I've seen IMAP certificates changing back and forth, too.

There's an explanation of this phenomenon that doesn't assume malice: there are N (> 1) servers with different certificates, and you're not hitting the same one every time.

Why did changing the TLS cert break things? Were you pinning it in your client?

I don't remember. Oh, it was this: http://comments.gmane.org/gmane.mail.imap.offlineimap.genera...

But what that doesn't show is that they then changed it back, and forth... for a while. It was just a UX issue that only affected computer literate people. THE BEST KIND. :(

I remember when some combination of Gmail features* enabled me to upload my old mbox with years of personal email into my GAFYD account... emails from before Gmail publicly existed. And now I could SEARCH them! The future was bright.

I certainly felt confident that I would be a gmail user for life. I certainly didn't consider the possibility that they'd one day just deny my access to the whole thing because I spoke ill of them in a HN comment. ;)

* access external pop3 account and auto-rewrite message headers so messages would be associated with my gmail address even though they were originally delivered to a different domain... Brilliant.

>> "I certainly felt confident that I would be a gmail user for life. I certainly didn't consider the possibility that they'd one day just deny my access to the whole thing because I spoke ill of them in a HN comment. ;)"

Sorry I'm being a bit thick, but did this happen, or does the emoticon at the end mean it's hypothetical?

Did not happen. Hopefully it's even less than hypothetical.