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.