Email is your electronic memory | Hacker News Reader

Email is your electronic memory

blog.fastmail.com

1,248 pointsbrongondwana282 comments

I've ranted here before about the complexity of email and the difficulty of even existing as a startup in the email space (see my bio). The single team that has navigated the insanity of the email space well as a small company is Fastmail. They are brilliant, ethical, and pragmatic. I sincerely hope the folks at Google who are behind this AMP-for-email idea will take the time to chat with the Fastmail team about it before pulling the trigger.

Having lived through the last DOJ/Google 10-month battle royale (the sale of ITA Software, now called Google Flights), I think this is an absolutely terrible idea for Google from an antitrust standpoint. The upside for them, while obvious, pales in comparison to the downside they face by leveraging their email and search dominance to create a new walled garden. I'm amazed this got past legal.

Not unique to Google: I think many legal departments have realized that the FTC is currently basically disabled, as far as the United States goes. It's likely most companies feel like if they do something right now, it'll probably be accepted/standard practice before the FTC remembers it has a job to do.

Yeah the EU is really the savior of last resort now.

Only on HN would someone describe FTC as "disabled".

I think we are living in a time when companies are being frequently trusted. Because when they claim that mergers reduce costs, the automatic thought is the cost will trickle to the consumer.

The other outcome we are eager to see is the innovation that occurs at the extra large scale level. Do we see the more robots make it in to industry? Or intensive AI? The opportunities and imaginations have exploded after Facebook and Google utilized their dominance for the greater good.

Lastly, enforcement against unethical illegal behavior has become easier. Reducing the need of cynical and paranoid reasons to prohibit mergers. Only when there is actual concern of legal unethical actions negatively causing market consolidation and preventing startup incubation, the FTC will not be doing any of the things the paranoid want it to do.

The FTC isn't even staffed fully, much less doing their jobs: https://theintercept.com/2018/01/31/trump-ftc-google-faceboo...

Highlights:

“It’s extremely odd for the FTC to operate with only two commissioners for this long,” antitrust attorney Reed Freeman told the National Law Journal. And even more so when the two commissioners are essentially lame ducks.

“The Justice Department’s antitrust division is doing stuff,” said Matt Stoller, a fellow with the Open Markets Institute, a leading antagonist of the tech platforms. “Ajit Pai is a bad man, but the [Federal Communications Commission] is doing stuff. The FTC’s silence is embarrassing.”

“The FTC really hasn’t used its authority in decades and has tried to rein in its own authority,” said Sandeep Vaheesan, a regulatory counsel for the Consumer Financial Protection Bureau.

> Lastly, enforcement against unethical illegal behavior has become easier. Reducing the need of cynical and paranoid reasons to prohibit mergers. Only when there is actual concern of legal unethical actions negatively causing market consolidation and preventing startup incubation, the FTC will not be doing any of the things the paranoid want it to do.

Let me just reply instead of downvoting.

It is clear from a slew of radical movements by the new US administration that it has contempt for consumers and has zero interest in enforcing existing laws against big corporations. It's all about growth at all costs, and government agencies that have explicit charters to protect consumers, the environment, and the marketplace, have been or are in the process of being gutted.

You're being downvoted because you labeled everyone who offers resistance to mergers as paranoid and cynical. That's perjorative and unhelpful. Very many people have valid reasons for being distrustful of big, unrestrained corporations. Reasons based on a long track record of them stomping on consumers and their employees.

> It is clear from a slew of radical movements by the new US administration that it has contempt for consumers and has zero interest in enforcing existing laws against big corporations. It's all about growth at all costs, and government agencies that have explicit charters to protect consumers, the environment, and the marketplace, have been or are in the process of being gutted.

You reply to a comment and say it is pejorative and unhelpful but then politicize your own response as well. Your paragraph here is equally unhelpful.

> Because when they claim that mergers reduce costs, the automatic thought is the cost will trickle to the consumer.

Please explain how trickle-down nonsense can work when the cost is already zero.

No, the cost benefits will go to investors. That's why the investors approve the merger.

I agree completely.

Email is a foundational technology within the business space. It exists in common formats, with slow-changing protocols widely compatible with their forbears, and similar across the marketplace. It is the deep, slow-moving tectonic plate on which we build a myriad of other business. It is a (largely) immutable record agreed to across a range of servers. Sure we can resend an email to a customer, but we can't edit the email they have already received. It is trusted, and it is shared.

I have no problem with an app that makes reading emails easier, something which combines long threads of back and forth argument into a simple list of shared understanding, but it is important that all that back-and-forth exists because, years from now, we might want to know how we reached that consensus. We might want to know those rationalisations.

With AMP-for-email we might just need to rely on Google's slick design and their simple response of "Don't worry about why you agreed, just trust us that you did."

> It is the deep, slow-moving tectonic plate on which we build a myriad of other business.

I agree. I think it is worth considering the concept of Shearing Layers [1] - where successful artefacts (buildings, systems, organisations) tend to be composed of layers that change at different rates, and this confers stability and adaptability. Layers that change rapidly (tech-mediated culture, web technology, etc) need lower layers that move slower (net infrastructure, http, email, etc.)

[1] https://en.wikipedia.org/wiki/Shearing_layers

Exactly - The fast learns, the slow remembers.

> The single team that has navigated the insanity of the email space well as a small company is Fastmail. They are brilliant, ethical, and pragmatic.

I'm curious to know if you have also examined Posteo, Mailbox, Tutanota and ProtonMail in this respect. At least the first two of those seem to be handling things quite well while charging a fraction of what Fastmail charges (per mailbox). Posteo has many other things going for it on the social responsibility, privacy and ethical angles. I haven't seen another email provider match that.

I understand why Posteo doesn‘t allow you to use your own domain (customer lock-in), but I don‘t find it particularly ethical how they lie about it („technically impossible“).

OTOH, I like that Posteo is not a corporation, but actually run by a natural person with full personal liability.

I don't know where you got that "lie" from. Posteo doesn't allow custom domains in order to have as less information about the customer as possible (what it calls "data economy", meaning it doesn't want to store data wherever it can be avoided). I have seen the FAQ multiple times, where Posteo has had this answer for not allowing the use of one's own domain. [1] I don't like that Posteo doesn't offer custom domains, even if someone is willing to make the tradeoff that Posteo believes it to be. But I don't see anything wrong in its ideological position.

_____

> Can I use Posteo with my own domains?

> No. We are an email provider with a particular, privacy-oriented model – and this is not compatible with incorporating own domains. One of our emphases is data economy: we do not collect any user information (names, addresses, etc) of our customers. We always answer requests from authorities for user information in the negative. On the other hand, own domains need to be registered to the name and address of a person. If you were able to use own domains with us, this would affect the entire concept of Posteo: we would need to start saving user information for all customers who use their own domains with us – and to provide these to the Federal Network Agency to be provided on request to the authorities.

> Even if only the MX record pointed to us, we would still need to store the assignment of the domain in your Posteo account as user information. Thus we would possess your user information and be required to give it out. For this reason, we have decided not to offer this possibility and instead to use data economy. We certainly understand that having your own domain is very important in the commercial industries, but from our privacy-oriented perspective, the disadvantages prevail. It is, however, possible to add various other email addresses with external domains as senders in the webmail interface and thereby to send emails with Posteo using external domains. In order to be able to read replies to these messages, you need to set up forwarding to Posteo for the external address.

_____

Also please see its stance on privacy [2], where it emphasizes minimizing the data collected from the customer.

[1]: https://posteo.de/en/site/faq

[2]: https://posteo.de/en/site/privacy

> We always answer requests from authorities for user information in the negative.

This has got to be bollocks, right? Always?

If they're served a warrant or subpoenaed or whatever the correct legal procedure is called, they're going to have to comply, right? And all they need is an IP address and you're hosed... unless you're taking multiple other steps to hide.

If I put my TFH (Tin Foil Hat) on, anyone who uses language that strongly is probably a CIA front.

WITPOUAAOSATSWISFWYAOGTUIO? (What is the point of using an acronym of something and then saying what is stands for when you are only going to use it once?)

Typically, acronyms wouldn't contain the initial letters of words such as is, of, an, and, for etc.

WPUASTSWSWYOGTUO

But to you point, my primary motivation in this instance was dramatic effect. Additionally, I'm hoping it will catch on.

Storing IP addresses of users in logs can be considered PII under German law already, so it’s likely Posteo isn’t even storing those.

Interesting, thanks you adding this.

My mind is telling me no. But my body, my body's telling me yes.

The lock-in provided by not using a custom domain is very convenient.

They told me by mail. This FAQ entry came later and is obviously a rather misleading answer.

How is storing the domain part of the mail address so very different from storing the local part?

Please read the cited FAQ entry again:

> On the other hand, own domains need to be registered to the name and address of a person. If you were able to use own domains with us, this would affect the entire concept of Posteo: we would need to start saving user information for all customers who use their own domains with us – and to provide these to the Federal Network Agency to be provided on request to the authorities.

That sort-of makes sense for why they do not offer you domains, but not why they do not have a "bring your own domain" plan (like e.g. mailbox does). There somewhere being a registrar knowing who I am doesn't change what they have to do, they do not need to have or look at that data in any way.

I think they're arguing that, if you bring your own domain, they still know what domain they're storing email for (by checking the reverse lookup) and they could look up the name behind it in the registry.

They don't want to be put in the position where they know what natural person a certain email belongs to.

They could also put the e-mail address in Google and find out who I am...

I get and respect that they want to provide a way to use their service without identifying yourself, but stopping a customer from voluntarily identifying themselves is fairly futile, and counter to how many people intend to use e-mail. (Indeed, they offer payment by bank transfer or paypal, so clearly they do not insist on full privacy)

Well, luckily they have direct competitors that offer the full range, so while I'd love more players in this segment I'm not directly affected by them not wanting such customers (and I find the argument questionable enough to reconsider recommending them in the future)

Even the payments part is addressed in the FAQ link I shared previously [1] and in a separate page about payments. [2]

While I'm sure that we would have to take certain things with a pinch of salt, since Germany is a Fourteen Eyes country, for me this amount of attention is something I haven't seen elsewhere (and not at this price). As I mentioned above, the social responsibility and other factors also heavily influenced me when I did the switch to Posteo.

From the FAQ: [1]

> "How can Posteo be anonymous, when I’m paying by bank transfer or PayPal?

> Credit is always added to your Posteo account anonymously – regardless of whether you pay by bank transfer, PayPal, credit card or in cash. We do not attach the data we receive with payments to the email accounts. We developed our own system for this in 2009, with which all payment processes are anonymised.

> The payment system is the core of our concept of data reduction, above all, because we keep payment information strictly separate from our customers' email accounts, we do not attach any user information to the accounts – and can thereby ensure the fundamentally anonymous use of our email service. You can find out in detail how the anonymisation of payment processes occurs at Posteo on our payment info page."

[1]: https://posteo.de/en/site/faq

[2]: https://posteo.de/en/site/payment

The point is, it's their company and they get to decide their features, not you. They don't owe you any kind of explanation.

Of course it's their right to decide the features. Just as it is my right to talk about how their given reasons for their decisions don't seem to make sense and let that influence my view of the company. Which is all we're doing here: talking about the companies to inform each other.

What on earth gives you the impression it's appropriate for you to prevent other users from wanting a company to have/build certain features?

It's neither the user's wish, nor the company as the company most certainly wants user feedback. Your post quite literally is only there to satisfy yourself.

Touched a nerve did I? Sorry to puncture your sense of entitlement.

No, they can't. If I wanted to protect my privacy I'd use a service like RespectMyPrivacy that hides my name.

Just as a rhetorical question: do they decline local parts in the form of firstname.lastname? Thought so.

Not sure I got what your rhetorical question is about. You don't have to provide any first name or last name or a real name. I've also linked to the FAQ and the payments explanation in another comment above, which go into more detail about what information they avoid collecting, storing and processing.

>I don't know where you got that "lie" from. Posteo doesn't allow custom domains in order to have as less information about the customer as possible (what it calls "data economy", meaning it doesn't want to store data wherever it can be avoided).

Sounds like a BS marketing answer.

Could you explain what you mean by the "complexity" you're talking about?

I've been using the same email address with my provider from Berlin, Germany for the past 20 years and there has never been any problem with it . They also have a working webmail interface, and I doubt they're very exceptional. There are also reliable free email providers that work very well for the past 20 years or longer, e.g. German gmx comes to my mind.

Hosting your own email server is maddening. There are so many new things on top for validating that your email server is legit and does not send spam. On top of that, some email providers will derivate from the "standard" way of doing things right now and proceed to block you for mundane reasons. The only way you find out is one of your customers frantically telling you that their emails are not received by the other party.

It will take you a few months to fix all those problems and even then it could be that some email provider decides to put new requirements in place.

I agree with you in practice, though there's no reason that it has to be this way. Email, like other protocols of its age, is simple. What's difficult is navigating the forest of roadblocks set up by the big email providers to excuse them not accepting your mail (or not sending their users' mail to you).

Most of these are alleged to have some purpose in preventing spam, but I think experience doesn't bear that out. They may prevent Joe jobs[1], and it may be reasonable to use the suspicion they create of a message being forged as one factor in deciding if a message is spam. But nothing really deals with spam except statistical analysis of messages.

The real point is that the major providers are anticompetative, and that's not really the fault of email as such.

[1] https://en.wikipedia.org/wiki/Joe_job

DKIM, SPF, DMARC is all pretty simple, though. I’m running my own mail server with all those properly configured, and it wasn’t much work.

But they are not all the same! I'm not even sure this cryptographic signed sender stuff is a good idea for email.

But good look getting through to postmaster@gmail|outlook etc.

But they'll hold you to some arbitrary standard that's supposed to mean "less spam" when they should have more than enough traffic to get by with statistical/ml methods anyway... /rant

This cryptographically signed sender stuff is extremely important.

DKIM+SPF+DMARC means you can prevent anyone else from impersonating your domain.

Every MTA will reject mails that violate the DMARC policy you specify in your DNS, if you have any.

All the old From: support@paypal.com scams are gone, impossible.

This means spammers either have to use hacked servers, or their real From: address.

And as soon as they have to use their real From: address, it becomes trivial to block spam.

Blocking spam is only so hard because From: was basically meaningless until now.

Yeah well. It's email. Either the postcard is (cryptographically) signed by a personally trusted sender, or it's unsigned.

It's not like impersonation is dead. When I signed up for the Gmail roll-out, security@gmail.com was reserved, but you can email me at sikkerhetsansvarlig@gmail.com - a poor Norwegian translation equivalent. More importantly, I can email you from that address, and tell you there's a problem with your account, could you please verify that your password is "hunter2", if not email your current password so we can verify that your account is secure (not that I ever have, or will, I got the account for a laugh).

Federated trust (s/mime) or Web of trust/direct trust(gpg) secures email. All this domain pseudo secure dns nonsense... I'm not sure I accept it's better than static analysis.

The point isn't to verify the account, the point is to validate that the account belongs to a certain server.

If I get email from alice@example.tld, then I now know it's from example.tld. If the mail is spam, I can ask example.tld to block alice, or I can simply blacklist example.tld.

The important part in this is spam prevention, and that if I get an email from @paypal.com, knowing that it's real.

What you're complaining about is another question, but not really relevant. Google always uses @google.com for employees, and if you get an email from that, it's real.

This is about enforcing identification, not verification, security, trust, or anything else.

> If I get email from alice@example.tld, then I now know it's from example.tld. If the mail is spam, I can ask example.tld to block alice, or I can simply blacklist example.tld.

Is this better than graylist+whitelist? Is it better than content based filtering? I'm not convinced.

Is it better than requiring tls with valid cert for smtp? I can't see how.

Rather than all this mess, I think I'd prefer we start at tls/ssl required for smtp...

Yeah I'm talking more about how every other mail provider has their own rules and you have to set it all up. Like one requires your mail domain to me an AAAA record (where I've used a CNAME) and other things.

That's not just one, most require AAAA or A records.

With SPF, DKIM, DMARC correctly set up, correct IPv4 and IPv6 reverse DNS, only A or AAAA or NS or GLUE records used in the entire resolution path, correct from and reply-to addresses, you should usually be good to go, though.

If you think RFC822 based mail is complex you obviously haven't worked with x.400 and x.500.

Though your right Google is having delusions of grandeur and the board should have stopped this for anti trust reasons and also I am not sure Googles developers have the required mind set to properly implement this

I was going to say "and pobox.com", but then ... they're now part of Fastmail, so I guess it's all good :-)

> I sincerely hope the folks at Google who are behind this AMP-for-email idea will take the time to chat with the Fastmail team about it before pulling the trigger.

Why would they? Surely AMP for Gmail is a sweet revenue opportunity for Google, who are answerable to shareholders?

> brilliant, ethical, and pragmatic

In case it's news to others, as it was to me, Fastmail routinely acquires SSL certificates for its customers' domains without their knowledge or consent.

https://www.fastmail.com/help/files/secure-website.html

Not routinely, it was done once as part of the plan to support SSL for all websites, and when we hit some limits with letsencrypt, we shelved the plan for a bit. There are currently 4 unsolved issues, which the team are looking in to.

We still need to find a way to provide automatic SSL for customer domains though - because we allow our customers to create arbitrary websites inside either their domains or their personal subdomain on our domains (username.fastmail.com).

The alternative of NOT doing something with SSL certificates is having insecure websites for customers by default, which will be more and more punished (and rightfully so) by browser interfaces. Setting up SSL for the domains which are hosted with us is the right thing to do.

You either trust them or not. I believe most customers wouldn't even know what a domain is, but still need it. It's kinda ironic that you want control, privacy and security but give away control of your domain to a 3rd-party. I get your point and I agree that anything involving this kind of behavior should be opt-in with clear red text warnings.

This seems largely practical/beneficial, and not of a significant downside. If you are pointing your domain at them for DNS, they are arguably canonically "that server" until you sent it somewhere else, and they're securing the connection for you.

The short-term nature of Let's Encrypt also works out well for this, because if you take your domain elsewhere, FastMail loses the certificate to claim to be that domain very quickly due to rapid expiration.

From the TechCrunch article [1]:

> What is the vast majority of “live” content on the web, stuff that needs to call home and update itself? Not articles like this one, or videos or songs — those are just resources you request. Not chats or emails. Cloud-based productivity tools like shared documents, sure, granted. But the rest — and we’re talking like 99.9 percent here — is ads.

Truer words have never been spoken. Shame on you Google.

[1] https://techcrunch.com/2018/02/13/amp-for-email-is-a-terribl...

Brilliant article, to be fair. One small piece of internet history.

Bron, I am so happy to see a blog from you guys about this... I was actually planning to ask.

In the light of Google being a monopoly-scale actor, I understand that you may need to support AMP. But if I might offer a note of implementation suggestion, if you add AMP: Make sure AMP, like remote images, is off by default. Perhaps allow the user to whitelist certain services or addresses to show AMP content without the extra click. That way, if AMP provides me a benefit in the way I use emails from a particular provider, I can turn that on... but my email client is never assuming I want to load their dynamic content.

I can see interesting use cases, as someone who pipes all my notifications at my email. I'd love to Favorite and Retweet right from my Twitter notifications, for example, without leaving FastMail. But I definitely don't ever want dynamic content loading from the latest marketing email from a store I've bought stuff from.

We definitely would do something like that with address-book whitelisting or other controls! I expect everybody will. Remote content, even via a proxy, can still identify exactly who has opened the email (also when, unless content is cached - but the whole point with content that might change is that you can't cache the resources and still be dynamic)

It's also going to mess pretty badly with offline mode when we get to that, unless we pre-fetch resources when downloading data for offline.

Can you freeze or un-AMP emails? Have your servers pre-download stuff or even strip it (somewhat akin to a browser's reader mode)?

text/x-amp-html is intended as an optional enhancement over an email that other clients will still be able to cope with. So un-AMP-ing is mostly just called using the text/html part instead of the text/x-amp-html part.

Pre-downloading or proxying content is theoretically quite possible with AMP (its limitations make that possible where it would not be readily possible with freeform JavaScript), but some modes of doing so will probably play hob with its interaction models. But it’s too early to reasonably review that aspect of it—better to wait until we can see what people actually do with AMP.

Make no mistake: AMP is all about making emails applications instead of static messages. That is its raison d’être.

Wasn’t text/html intended as an optional enhancement too? But most of the emails I receive are only text/html - no text/plain alternative, which would be displayed if available.

I fully expect text/x-amp-html only emails in the future, and so should you.

FastMail, please give me a way to permanently block AMP only emails. Just throw them away with a Mailer Demon reply. If there’s other versions, strip away the AMP version.

"most" (of the mail you want to read/reply to) sounds a bit extreme - afaik both Google and outlook/exchange/office365 will supply a semblance of a text part unless you go out of your way to avoid it. As we as most real mail clients.

You could always just bounce mail w/o a sensible text part...

>bounce mail w/o a sensible text part

Hmm... I’d like to, but I’m not sure how I’d do that on FastMail.

Eventually I may host my own emails, but until that day, I can’t really do much about this problem.

Maybe I could have an IMAP client on a server that is constantly connected to FastMail and looks at incoming emails to file them into an “HTML only” mailbox if they don’t contain a text/plain version?

I can read those emails from the FastMail Web Interface

I've not used sieve, but afaik fastmail supports sieve, and according to this: https://tools.ietf.org/html/rfc5173

It might be possible to match on non-empty text/plain?

> But most of the emails I receive are only text/html - no text/plain alternative

Care to elaborate on that? Virtually every email I get has a plain text version (I can't even see HTML email). I don't think the email I get is particularly selective. The only pure HTML email that I ever get is spam.

Sorry for the delay in replying, I don’t check my comments very frequently. Usually only in the morning.

I use mutt for emails, so believe me — I know when I get a text/html only email as mutt can’t display the text/plain version. Most emails I get from friends and so on are in text/plain as mail clients do a decent enough job at including that.

However most of my mail isn’t from people I know, it’s from newsletters and notifications. A lot of it is text/html only, either because the programmer who created and sent that email didn’t want (or know) to include a text/plain version, or didn’t care to.

Why does it matter if email content changes, if that's the intention the author?

Clearly one of the biggest benefits of email is that it's the only medium that's acceptable for memorializing agreements / decisions / roadmaps / plans / etc. At the same time, I don't really care if some clothing company's monthly marketing email changes if they run out of something, as long as it's clearly marked as ephemeral.

"as long as it's clearly marked as ephemeral" - yep, you hit the nail on the head there. The ecosystem danger is that ephemeral becomes the default. Who doesn't love the ability to silently fix mistakes.

And when it becomes the cultural norm to send editable email, then people will do it because it's a nice experience as a sender if you have the choice. I sure enjoy being able to edit my posts on HN when I get something wrong. I'd love to be able to take back and "fix" emails that I've sent too!

But having to stand by exactly what you sent when it comes to email is really a valuable part of how email works. If you made a mistake, you send a correction, but the recipient still has your original mistake too. They don't see it, then have it disappear when they go back to look at it again.

I, for one, cannot wait until someone is able to alter a few words to a contract I've signed after I've signed it.

FWIW, this is effectively what tech companies already do with the Terms of Service. They state that you must agree to them to use their product, and then state that they can amend them at any time, often without notifying you.

Had that happen to me. I'd "electronically signed" a PDF of a contract, and returned it to the other party with some minor questions.

The other party marked up the PDF I had signed with some changes, based on my questions. All of the changes were agreeable to me (or not worth fighting about, I can't recall). But I still insisted we start with the changes made to an unsigned PDF, and then I signed that PDF with the changes.

My thought was that socially/culturally green-lighting "after signature" contract changes was a path to madness and misunderstanding.

AMPHTML Email is designed to sit beside the text/plain and text/html parts as just another alternative, with type text/x-amp-html. So in theory, any senders of AMPHTML Email should also include a regular HTML part that is semantically equivalent, and any client that doesn’t support text/x-amp-html should simply get the less fancy version.

In practice, if something gets popular enough then the alternative that is supposed to work properly side-by-side gets neglected. (Some email senders cop out on text/plain these days, leaving it out, or worse, empty, as in Dropbox Paper’s document update notifications.)

But I don’t think AMPHTML Email is likely to be sufficiently broadly supported that this becomes a problem. (It’s only likely to happen at all if all the major providers and major email clients support it.) If at any point we do end up supporting AMPHTML Email, any remote content will be handled like remote images.

Yes, this might become an embrace, extend, extinguish like scenario, which is scary.

Google did the same thing with XMPP and Google Talk. They adopted an open standard when it was cool for them. When they gained mass adoption, they switched to Hangouts and the whole Allo mess. And before that they crippled XMPP federation.

While I don't like regulations too much, it might be desirable to penalize these behaviors as they are monopolistic.

Google Talk never gained mass adoption. Google was punished by their competitors by adopting open standards, like XMPP and OpenID, when some competitors implemented "one way" interoperabilility to siphon off users.

I favor federated open standards, but let's not rewrite history. Google Talk was never mass adopted or a market leader, MSN, Yahoo Messenger, AOL Messenger always had way more market share.

I mean, good lord, you're calling for regulations to penalize Google over failed messaging products, why don't you call on regulations to force Apple and Facebook who own the world's most popular messaging platforms, to open up their protocols to federation?

If you want to propose legislation to require Apple and Facebook to allow interoperability, I will get it in front of federal legislators.

I've been pondering this for a while. The standard thinking is if everyone federated (e.g. XMPP in Facebook, Gmail) it would be good. But look at it from another perspective. Then your main account, your identity would be permanently tied to one provider (Facebook, Google) as your JID would end with @facebook.com.

The only true solution is to use your own domain and then, if possible, delegate to hosted server. If the provider does something that you don't like you just change provider or host your own. And one's @gmail.com address will always be hosted by Google.

how exactly does one siphon users by implementing one-way federation in XMPP?

The same way iMessage siphons from SMS. You embrace-and-extend, crafting a proprietary protocol closed service with a bridge to an open one. You gain users by allowing people to inter operate with friends outside your proprietary service: normally a "cost" and impediment to your users, all the while creating incentives to onboard their friends. Once they're onboarded, they become locked in, and gradually you can reduce interoperability with the federation.

Well, I would say that applies to open protocols themselves, like SMS and XMPP - in fact Google did it also. But when two service providers interoperate and build more features to entice users to move to their platform, I would call it fair competition not siphoning; there is no "one way" aspect, you either federate or not.

What I want to say is that killing XMPP federation was a deliberate stab against a competitive market, not some reasonable defense against being taken advantage of, it's exactly the final "reduce interoperability" step you talk about. Unless competition regulators disagree, it's fair game for Google, but the consumers certainly stand to lose.

I get marketing emails all the time where the HTML part carries the message and the text/plain part... is last month's message. Or last year's. Or lorem ipsum.

I used to tell companies about this problem, but it turns out that of the thirty or so I contacted, only one was interested in fixing it. Now I just mark them as clueless.

I get emails where the text/html part is fully fleshed out, and then the text/plain part is just the string, "Can't see the formatting? Click here!" where the last two words presumably lead to an HTTP served version of the email text.

Hey, I can see the formatting. I just choose not to. If you, on the other hand, can't even attempt say what you want to say with plain text, it's probably not something I care about anyway...

Ah, this explains why that text is so often the preview in Gmail. I always wondered why I couldn't see that text in the mail itself.

The more time spent on optimizing for one email client, the less time spent on optimizing for an other.

Hands up if you (like me) have skipped coding the text/plain part of an email template and sent out multipart emails with no or empty text/plain.

Developers are lazy, but business minded people will push amphtml because they think it's an edge. If it becomes a thing, people will create webpages instead of emails and skip proper testing. (Again, myself probably included).

We've done the opposite. After ten years in operation we've only just begun to add html parts to our emails. Its just easier to render plain text, and no one has the time to be spending hours templating and testing emails, we've got better things to do.

And the really amusing aspect of that is that text-focused emails (be they text/plain or deliberately simple and barely styled text/html) tend to get better engagement than fancy branded emails—the data I’ve seen from a variety of sources is quite conclusive about that.

I wish more people published data about it.

I like everything about plain text emails except for hard wrapping, which looks awful on screens that are too small or too wide.

To a large extent, hard wrapping is a combination of choices made by the sender (to hard wrap the text, because it doesn’t trust clients to soft-wrap properly) and receiver (to soft-wrap or not).

There was a standard to handle it nicely, format=flowed; sadly, it didn’t make it: https://blog.fastmail.com/2016/12/17/format-flowed/

But even without that, the quoted-printable content-transfer-encoding means that the hard wrapping isn’t actually necessary—you can have lines as long as you like. Some email clients do thereby send text/plain with arbitrarily long lines, which will cause overflow in some clients (typically where plain text is shown in a monospace font), and be wrapped in others (most, these days, I think; these are typically where plain text is shown in a proportional font).

Then too, some email clients ignore the 78 character limit (it is, after all, only a SHOULD [1]) and write longer lines in the MIME message. (Not sure what they do after 998, which the spec says they MUST not exceed [1].)

But the inability to specify the desired semantics of proportional-with-wrapping versus monospace is probably the part of text/plain email that makes me saddest.

[1]: https://tools.ietf.org/html/rfc5322#section-2.1.1

I co-founded a business, specifically around email testing, largely for the reason you mentioned. When developing we often skipped things like plain text, and usually only did a cursory glance over other aspects, very much less did we automate anything. It came back to bite us so many times (presumably countless times that we weren't alerted too also).

Obviously I'm entirely biased, but to your point on business-minds pushing for edge I'm even more convinced that manual testing alone is never going to cut it going forward.

Shameless plug at the bottom as it's rare that email testing gets limelight on HN :) https://mailosaur.com

HTML email is supposed to be just another part alongside plain text as well. Anybody who uses a plain-text email client knows that nowhere near 100% of HTML emails are sent with a sane plaintext part. A fair portion of the time, there just is no plaintext part, other times there claims to be but it is just the HTML source stuffed into it. I've even seen some marketing mails (Delimiter promotional emails are the ones I'm thinking of, but there are others) where the plaintext part is just a completely different older message, apparently because they forgot to update that part before sending it out.

Now, I know plaintext users are in the majority, but I don't think you can reasonably expect the same not to happen to AMP for emails if they ever become widespread.

Email represents three important abstractions of the real life:

First, it's a task queue. And you're the worker that processes the tasks. Anything that helps an email service to be that abstraction is very good for users -- prioritizing, postponing, auto-processing, branching, delegating, etc.

Second, it's a log. As the article rightfully says -- an immutable one. Again, anything that helps email be a good log is very good for the user -- search, filtering, archiving, etc.

Third, it's a file storage. This is the most overlooked part, unfortunately. Search, sharing, organizing into collections -- all that would be of great help to users.

Yet, Google pushes that silly AMP :\

Bah - file storage. Yep, it certainly is. And to a large degree, because it's a log. Once you email something as an attachment (even to yourself) it's like a version control commit. That copy is locked in, and won't change. You can find it and refer back to it later. It has a timestamp on it, and it's probably stored in the cloud somewhere with backups and such.

Hence "memory" - because that's how people use it :)

>And to a large degree, because it's a log.

I agree. Although, it's more than just a log. For instance, it would be great to have the ability to see a collection of all files sent by a particular sender, with file versions (with dates and links to according emails) stacked under one file name.

Another suggestion -- view a collection of files in all emails with particular label.

Finally, in some cases it can be helpful to have a local read-only copy of files in a particular collection. It's like one-way read-only Dropbox. This would make automated processing of email attachments so much simpler. (BTW, a product idea, anyone?!).

So one of the smartass login messages in our internal slack is "JMAP will fix it".

Interestingly enough, JMAP will make this kind of thing much easier - and we have thought about it in the design! Our Cyrus server already internally keeps a blobId which is a digest of the binary content of each MIME part. Which means you can easily tell that two attachments are identical without reading the contents or guessing based on size and name.

And it's easy to search for messages with file attachments and fetch just the file attachement details via JMAP, making this kind of interface relatively easy to write.

The usual caveats about "we haven't got a particular timeframe in mind" apply - but once JMAP is standard, anyone can write a client to that standard!

Hi Bron. JMAP is a great design for what it is (a much better IMAP). Thanks for creating it. I can see JMAP becoming a great standard for email-oriented client/server communications.

That said, I'd still encourage you to think bigger to make a more general system. Of course, the risk of thinking bigger is you may end up with either nothing or a monstrosity no one wants to use. And also you'd likely have to adapt your business model eventually if the bigger picture changes through your actions. So, it's fair to think smaller too.

From a related post I made to the Thunderbird Planning list in April 2017 on what I see as the bigger picture: https://mail.mozilla.org/pipermail/tb-planning/2017-April/00... "My perspective is from wanting to create tools to support a "social semantic desktop" of which email is a subset of the items. Other types of items include news messages, RSS feed messages, chat messages, notification messages, IoT messages, blog posts, pingbacks, saved web pages, commands constructing complex shared documents, VR world update messages, code snippets, notes, and more. Email is a special case of a much larger world of messages. So, for me, a good assumption is that people will eventually have billions of message items comprising terabytes of data in their local (shared-with-email) store. Eventually each user would be part of a global federation of users that together have billions of times that number of messages as a federated semantic web. I understand that such a vision of messaging on that scale is not yet the goal of most people in this discussion right now. But I'd still urge people to think a little beyond redoing Thunderbird as-it-is and try to imagine a personal messaging system that processes, archives, indexes, and recalls vast numbers of items every day in interaction with a user and automated systems as part of a larger federation of similar systems using shared semantic standards."

I've been beating my head against that wall for years with very limited progress (as have others) -- so I can't say it isn't a high risk endeavor with a low probability of success. But the benefit for humanity could potentially be huge if such an effort succeeded. Maybe it might just take a few tweaks to JMAP to generalize it enough to realize some of that big picture?

JMAP is pretty generalizable to other datatypes! It's a large part of why we split it into Core and Mail. We also have Calendar and Contacts modules in a reasonable state already.

We also use JMAP-style APIs for Files, for Notes, and for all the extra Preferences and group management stuff in both FastMail and Topicbox.

Neat! Yes, I see the potential there, which is why I an interested in JMAP. Just wondering how it might could get even better at all that.

As related market research, Kolab uses IMAP as a general-purpose data store: https://github.com/pdfernhout/Twirlip2/blob/master/design/ma...

> I'd still encourage you to think bigger to make a more general system.

No! It's a trap!

I'm not sure if jmap is all that great (but pretty sure it's in the "all email protocols suck, but jmap socks less..."-bucket ;-)

Someone did think bigger, and the best of them begat lotus notes. And/or the original couchdb. Walk får enough down that path and you come up with distributed executable objects. And while the vision is pretty, it's anything but simple - or something that can survive for 40 odd years. Today, you'd probably get something like urbit. Cool research: yes. Might be useful: yes. Something that'll work well to access email from an iPhone, a mainframe, your openbsd firewall and a windows 10 tablet... Not yet - probably not ever. In fact, even the modest goals of jmap puts it at peril in this case.

Yeah, "thinking bigger" about JMAP might be a trap, sigh. I'd have to agree that JMAP may be better just being email-focused as we could really use something like that right now. Still, at the very least, it's always good to have some versioning to have a way of upgrading the protocol. I also wonder if there is some "low hanging fruit" for generic data exchange that JMAP could perhaps address better -- but I agree sometimes the low hanging fruit is dangling over a fast-moving river filled with alligators on a branch that would break if you put too much weight on it.

Lotus Notes and CouchDB (designed by someone with Notes development experience and related aspirations) are projects that do have quite a bit of alignment with what I am talking about. And they can be useful systems even with their limits. Notes suffers from being proprietary and having warts from its evolution (including how apps are implemented). CouchDB suffers the limits of trying to be both a database and a server at the same time and hitting limitations in both areas. It also unfortunately had a logo that could be misinterpreted as something offensive. That said, I do like CouchDB a lot as an inspiration and seven years ago or so I wrote a small app that runs on top of it.

Thanks for mentioning Urbit. After a brief perusal of their mission and code and a HN article on it ( https://news.ycombinator.com/item?id=8578151 ), it seems to me at first glance (perhaps not doing it justice) like a new flavor of Lisp (but with math limited to increments to produce a functional-ish Flux-like model) crossed with a bunch of techno-utopian aspirations about personalized distributed computing backed with some code and a lot of hand-waving. One can also see the economic model in there to please investors by creating an artificial scarcity of address space that is auctioned off. So it is a set of sense and nonsense it would take a while to sort through -- but so often the challenge in life is doing that for our own beliefs given everyone believes many useful things and a few problematical things. Certainly a lot of things it points to are worthwhile aspirations (like having more control over your own data) whatever one may think of the implementation. Some of its aspirations (the ones I'd tend to agree with more) are reminiscent of the FreedomBox project -- but without FreedomBox's practical grounding in mostly repackaging existing Linux technology.

In practice, these days I'm thinking more about a set of npm packages that make it easy to create your own personal server with a combination of "npm install" commands to add new capabilities (including perhaps a JMAP server for some of your data that could be interpreted as email-like messages). Ideally, that personal server could be federated with servers from other people using some standardized APIs (some of which may be very CouchDB-like). And if people need a unique identity (or several), that could be done by people providing public keys to others as their "identity" and using such keys for signing messages. That's a way to realize some Urbit-like aspirations in a more down-to-Earth way, but leveraging the Node ecosystem instead of how FreedomBox leverages the Linux ecosystem.

Here is a message I sent in 2010 to the Diaspora project along similar lines: "Raising the bar to supporting a Social Semantic Desktop" https://groups.google.com/forum/#!msg/diaspora-dev/TNNpvfFqN... "So, you can take all of my technical comments with a grain of salt in the sense of all that ambition (or whining or paranoia. :-) I acknowledge these suggestions are pretty ambitious, as above, and such ambitions would ask that the Diaspora team learn a lot about emerging ideas and do some really difficult things involving some bleeding-edge semantic stuff beyond the new (and good) stuff it is already doing -- and that it is possible such ambitious and risky efforts might fail for all sorts of reasons. Still, I contacted the Chandler/OSAF project about the Pointrel system semantic approach and they went another more mainstream way and failed anyway (well, it's still ongoing, but it lost its way and most of its funding somewhere along the line). But, I learn more each time, so maybe the above might seem more coherent and approachable than what I sent the Chandler/OSAF people years ago, and that in private, not in public where at least others could learn from it. :-) It's quite reasonable for anyone to say that, for now, a Semantic Web is not what Diaspora is about, as no one can do everything. But somehow, I feel, the really big future for something like Diaspora is going to be integrating semantic web concepts. So, at the very least, if Diaspora was built in such a way as to support future modules in that semantic direction, it might be an even more successful thing that totally and rapidly eclipses Facebook and many other technology platforms as well."

I wish I had more time to pursue these ideas in an open way other than as a hobby taking too much time away from family -- and involving unhealthily spending way too much time on the computer overall on top of regular 9-5 work time. I'm obviously personally invested in these ideas and enjoy programming in this area. But it's also a tough moral choice about spare time given the need for such systems to have a happier singularity factored against the very real costs to any individual/group and a very low probability of success for each specific effort. But collectively, if enough people try (alone or in small groups) in their own ways, likely somebody will succeed -- and then a larger group can build on that success in a stigmergic way. https://en.wikipedia.org/wiki/Stigmergy

Still, while such an effort to create an alternative may indeed be a trap of wasted effort for no results, what we have now with global use of (anti-)social media -- media designed to addict people and provide 24X7 surveillance and control of information flow via a few centralized services -- is a trap we're already collectively in.

Unfortunately, some people who I might otherwise think should know better -- like Paul Jones, UNC professor in the School of Journalism and Mass Communication and the School of Information and Library Science and of ibiblio fame -- seem to promote the centralized social media technology of this trap. They have given up on email due to spam, information overload, and other issues like asynchronicity -- and replaced email by collection of mostly commercial web services rather than try to make something better inspired by email's good aspects including local archiving and local search. See: "UNC professor Paul Jones went from pioneering to protesting email" http://www.dailytarheel.com/article/2014/02/unc-professor-pa...

While centralized services do have some benefits over current email (including editing and moderating), it is not like the centralized services don't have their own new problems -- whether various forms of spam including low-quality duplicate content driven by monetization, having less time for reflection in a torrent messages with immediate response expected in some services, or even new problems where "unfriending" someone is a lot more complicated and stressful than not including someone on an email CC list.

I've posted a few comments over the years on Paul Jones' #noemail blog ( http://www.ibiblio.org/pjones/blog/category/noemail/ ) agreeing with him about email's problems -- while also pointing out obvious new problems with trusting all your communications to a few centralized services and suggesting working towards better alternatives. But those posts seem to have disappeared in what may have been a purge of most comments from that blog. That is an example of one of the perils of entrusting your messages to someone else for publication and archiving -- and a reason to consider a federated architecture as an alternative.

Still hoping he might someday promote a solution that keeps email's many benefits (including as a personal "electronic memory") while addressing the valid concerns he raises about email.

Anyway, stuff I like to think about and discuss and implement. Even though I may be reaching the point where, like many others before me, "The point of being done is not to finish but to get other things done." See: http://www.manifestoproject.it/bre-pettis-and-kio-stark/

And one might then hope for continued co-evolutionary bootstrapping improvement of concepts, artifacts, services, culture, and practices like Doug Engelbart talked about. And we can see that now, like in using the web right here and now on HN to discuss something better.

So, I can totally get where JMAP-as-it-is becoming a big success would move things forward, and we could then use JMAP to discuss the next generation of changes. So, I'm raising the issue of a broader aspiration -- while accepting it might not be best for JMAP right now.

Sounds like jwz's "intertwingle"[1] strawman with a smidge of "unity of interface"[2], or JetBrains's old Omea information manager[3].

1. https://www-archive.mozilla.org/blue-sky/misc/199805/intertw...

2. https://www-archive.mozilla.org/unity-of-interface.html

3. https://www.jetbrains.com/omea/features/

Thanks for those links, especially the first to Jamie Zawinski's 1998 post on "vast volumes of email" and interwingled data. Yes, that is the sort of concepts and implementation I am talking about (and had hoped perhaps to move Thunderbird towards). Though I might prefer a different UI than JetBrain's Omea -- as well as a FOSS one. In one sketch of some ideas, I was thinking of that all more as a set of plugins: https://github.com/pdfernhout/Twirlip2

Jamie is obviously a brilliant and humane guy -- and his Lisp roots really show in his design of general purpose systems. Looking at Jamie's website, I was hanging around the CMU Robotics Labs around 1986 when he was too so I wonder if we may have ever talked in passing then?

LISP as a programming mindset encourages such generalized designs about information handling, transformation, and linking -- as does inspirations from early AI research (thinking about thinking). For example there is the book Representation and Meaning by Herbert Simon and Laurent Siklossy from 1972 -- as one of many early AI books. I have that one because Professor Simon was nice enough to give me a copy back then during a few conversations we had in his office. Before that, in high school circa 1980 I did an independent study project using Patrick Winston's book on AI. William Kent's 1978 book "Data and Reality" (the first edition -- the third edition was dumbed down by someone else) is another great inspiration. There is a sort of cross over between AI-inspired design and human-centric "augmenting" design.

An interesting comment on the AI/IA crossover by Brad Neuberg (who worked on Open HyperScope): http://codinginparadise.org/ebooks/html/blog/ia_vs__ai.html "I‘ve traditionally been in the IA camp my whole career; I’ve spent the last year going deep into the AI camp. Traditionally these have been opposite worlds but I’m wondering if there might be some powerful, interesting ways to combine them together. One is humanistic and and design focused, the other tends to be more analytical; the space between them is where I’m interested in exploring in the future."

Back around 1988 I applied to be in the NeXT developer program with a concept for an application (embarrassingly called "Orgi" back then, but I was young and reckless/foolish) where the idea was that any data item could hook up with any other data item (using triples). That application never got acted on until I met Steve Jobs when he gave a talk at Princeton and asked him personally about the developer program. And such ideas came out of my earlier interest in triplestores -- ideas that contributed to the roots of WordNet by my undergraduate advisor at Princeton, George A. Miller started just as I was graduating.

In any case, as I said, "I've been beating my head against that wall for years with very limited progress (as have others)". :-)

Jamie was obviously smart enough to connect with such ideas and move on to a happier life selling beer, pizza, and conversational ambiance. Obviously a much smarter guy than I am. :-) And I did not realize his early interest before, so thanks. I knew of another person who became much happier leaving contentious academia after his PhD and being a professor to run a hardware store. See also Matthew B. Crawford's "The Case for Working with Your Hands" written by someone with a PhD who left the non-profit public policy sector to do motorcycle repair: http://www.nytimes.com/2009/05/24/magazine/24labor-t.html

That said, maybe if Jamie had run Mozilla we would not have seen such a tragic waste of billions of non-profit dollars mostly pissed away -- including by mostly abandoning Thunderbird? Or, maybe his voice would have just been ignored? Hard to day. Innovation is such a complex thing. Some ideas I've collected for supporting innovation at such places: https://github.com/pdfernhout/High-Performance-Organizations...

Doug Engelbart and many people he inspired are others near the root of this "intertwingled" data ideas (including "Open HyperScope" as a successor to "Augment" http://hyperscope.org/ ). Ted Nelson and people he inspired with Xanadu. Alan Kay and Dan Ingalls with Smalltalk and its implications as a thinking tool (Dan ran a family hotel for years afterwards). Ward Cunningham with the Wiki server idea and now the Smallest Federated Wiki idea. Mitch Kapor and the Chandler Project. The recent Dat Project by Max Ogden and others also connects with all this somewhat. There is this great book called "Design and Memory" from 1980 by Peter Huyck and Nellie Kremenak exploring such ideas. And of course "As We may Think" by Vannevar Bush. But the roots go further back though annotated scrolls (and the Talmud) and millennia of libraries -- and even back to the first "Standing Bear" cave paintings (see the book, "The Walking People").

This issue of (re)creating a decentralized alternative based around an email-ish feeling of interlinked locally-searchable information is increasingly important because it potentially is a way to move beyond negative aspects of centralized (anti-)social media.

But, hey, my wife and I have more than 5000 books in our house, so all this might just be my hoarding tendencies trying to justify themselves? :-)

Well, off to an unrelated job. And it is unrelated precisely because most of the big paying players in this space (e.g. Google and Facebook) want to get between people and their data -- and typical startups make deals with investors which limit their ability to do FOSS. Still, I can hope there will eventually be, say, an "Automattic" of this "intertwingling" equivalent of WordPress. I actually had hoped Automattic might itself become such a company, but they sadly seem to now see themselves just as a Wix/Squarespace competitor (e.g. adopting Slack for internal communications -- and not even Mattermost or Matrix.org if they want to let someone else own that space and cooperate with another FOSS system).

At least it is nice to think about these things in my spare time -- although sadly at the cost of other experiences. Maybe it is all just a mistake to use my non-job time like that, like Piotr Solnica suggests: https://twitter.com/_solnic_/status/953578620617920513

> it's like a version control commit.

As an alternative to mbox/maildir/whatevs I've been toying with a prototype of email storage that works in a content-addressed way with objects very much like how git operates internally.

> Our Cyrus server already internally keeps a blobId which is a digest of the binary content of each MIME part. Which means you can easily tell that two attachments are identical without reading the contents or guessing based on size and name.

This deduplication property then comes naturally from the above design, and not just for attachments but also for email headers and bodies.

Many other things come easily such as rsync "just working" for fetching, or making use of git packs[0]

[0]: https://git-scm.com/docs/pack-format

You're not the first person to think of using git-like storage for email, and you won't be the last!

Sadly deduplication isn't quite that easy - while the binary formats might be the same, MIME is very un-roundtrip-friendly when you start from the MIME structure. There are many ways to encode the same bytes, so if you need to reconstruct the raw bytes (FETCH RFC822) then you need a way to recover those original bytes. I've started work on that a few times, but it's never been worth the effort to make it stable.

>> Third, it's a file storage. This is the most overlooked part, unfortunately.

When gmail first launched I remember it having such relatively high storage space that my friends and I used it extensively as a music sharing/storage system. An mp3 was just small enough to make it a comfortable email attachment and the storage space was great in an age without infinite cloud hosts.

Huge amounts of gmail's early utility to me was simply the file storage. Lots of people would give you a free email address. Google made a big deal out of the massive space they offered.

A while back, Gmail began blocking .js file attachments, but I didn't realize until today that this means my old JavaScript file attachments would be retroactively blocked. I tracked down an email from two years ago with a JavaScript file attached that I needed, but I couldn't download it!

I was eventually able to get it by doing "Show Original" in Gmail and copy/pasting the base64-encoded attachment data and decoding it. But it made me nervous about using Gmail as a way to hang on to files, since things I attach now might not be available later.

I had this same issue. Google also blocked .jar and .zip if I remember. I had lost some old school projects that I tried to recover, which we're turned in via email. I couldn't download the attachments for this, despite the fact I sent them in the first place! Much less, why couldn't I allow someone to send me a .js file I wanted it? It's a weird restriction to not even be given a choice.

Someone even went so far as to build a FUSE filesystem: https://en.wikipedia.org/wiki/GmailFS

You nailed it. And if AMP jeopardizes this core idea of "email as a reliable log", which is how many people use it, it will slowly eat away at the usefulness of the service itself. People will stop trusting it and using it as such.

> Search, sharing, organizing into collections

All these features does gmail already have for years. And yes, people also use gmail for file storage. AMP is a stupid idea, but it doesn't mean they do it instead of other features. The other features are there already.

The great thing is that email is so flexible it can be many things to different people. It may not do any of those things really well but it allows the user the freedom to use it in creative ways.

The possibility that email content could change after receiving a message is worrying.

Is there going to be a way to reject AMP emails? I won't accept any emails that require loading JavaScript or content from CDNs.

If other email providers reject AMP emails with a bounce message explaining why, it might stop a disaster from taking hold. "Please resend your email in standard HTML or text format without JavaScript or external resources."

Anyone sending text/x-amp-html should still be including a text/html part, which won’t have JavaScript et al. Unless just about everyone starts supporting AMPHTML Email, the text/html parts will still be necessary.

Like most emails send nowadays use HTML but still include a text/plain part. Here's a live example from my INBOX: https://svkt.org/~simias/mail-hp.png

Notice that this is from HP, not some small shop. Nowadays people expect you to be able to parse HTML emails and don't bother to have it work in plain text (I'd actually prefer if they got rid of the text/plain in this situation, this way mutt would know to display the HTML instead).

If AMP becomes popular enough and gets integrated by the big players I have no doubt that we'll see the same thing. Then it means you won't be able to process email in any significant way without a full blown Web engine (probably including JS).

First they ported everything to the web, now they're porting the web to everything else. I don't want the web. The web is bloated crap. Stop it. Please. Stop it.

Embrace, Extend, Extinguish, then walled garden and/or broken things.

Emails should not include any JavaScript. It would give anyone a way to send immediately executing code into your inbox. CSS animation in email is already bad enough.

Maybe an AMP filter could check the plain text content against AMP and HTML content and bounce the email with a custom message if there is no plain text or standard-HTML way to read the content.

There are many companies that try to force you to load external resources in an HTML version by putting the content in images. The same thing could happen with AMP, where only an AMP version contains the actual content.

There is always the "mark as spam" button.

Be careful with that spam button: it probably won’t do what you want, but will instead make your spam filter worse.

Eventually a sufficiently capable filter will be likely to figure out that the thing these emails have in common is a poor text/plain part and adjust its weighting appropriately, but I’d expect it to take somewhere between “quite some time” and “a long time” to figure that out; in the mean time, it’ll mostly just serve to confuse the poor filter.

(How customised spam filters work, in a nutshell: take your various signals—e.g. has HTML, has remote images, has no text, is sent from a known-spammy IP address, mentions large sums of money—and figure out which factors occur more often in spam than ham, and increase the importance assigned to them; if the email reaches a chosen threshold, it’s showing sufficient characteristics of a spam message to be considered probably spam.)

SpamAssassin is probably the most widely-used spam filtering platform; I’m not certain that its standard rules are capable of deciding to filter on this sort of thing directly. I believe it has something around detecting overly short or non-representative text/plain parts, which is probably the primary signal this would coalesce around.

Or you can just configure your client to not run js. Seems easier and less dramatic.

Given that most of these mails will probably be the sort of e-mails one doesn't want (i.e. mostly newsletters, maybe some notifications, but _zero_ 1:1 human-to-human messages), I'd say such a filter could be pretty helpful.

If you block JS from loading from CDNs on AMP pages it literally takes 8 seconds to load the AMP page.

I don't understand. Can you not load the page normally and just not invoke your js interpreter at all? Just don't run any js. How can that take more time than normal loading and running?

I didn't look closely, but give it a try. I counted about 8 seconds, and there is some CSS in AMP pages that says `8s`, so it's probably the CSS.

If I click on an AMP link (usually only via HN), and I get a blank page without any loading indicator, it's usually because someone posted an AMP link.

I don't get it. All we have so far is a very short spec sheet, and already people are starting to assume so much about how it will work.

Is there any proof that it'll be able to run arbitrary JS? Or that it'll be mutable? Or that there will be no way to turn it off?

A "very short spec sheet" is an invitation for people to start assuming things about how it will work. In the absence of details, speculation is inevitable.

That's fair, though if you do read said spec sheet, there's a few things you can infer. For one, they give a list of whitelisted AMP component, and none of them allow for arbitrary JS, so that's out.

Furthermore, at the bottom, they specify: > All fetchable attributes like src and href must be static and > All network requests must be proxy-able to ensure that user anonymity is preserved

This implies that anonymity is big focus (so your information will not be leaked), and that things will be fairly static.

Almost all the "speculation" happening goes contrary to that, leading me to believe that no one has actually taken the time to read up, and are just blindly expressing their existing preconceptions and hatred about AMP.

Let's just bet that majority of AMP emails will have a tracker in a form of a personally identifiable resource - image, component, whatever.

Emails have that now, though, with tracking pixels and the like. Google prefetches them all; marketers have no idea if you actually looked at it.

GDPR couldn't be coming any sooner.

I went through a phase a couple of years ago when I was with Fastmail and looked around for alternatives [1]. I ended up staying with Fastmail and have adjusted to some of it's UI quirks in the admin interface.

Posts like this remind me why I decided to stick with Fastmail. Do one job well. Fastmail do email really well for me.

(Disclosure: Fastmail user on paid plan, unsolicited review/pat-on-the-back)

[1] https://news.ycombinator.com/item?id=11319298

Agreed, with similar disclaimer. I’ve used so many email providers, and none have had my love and loyalty like Fastmail. The highest praise I can offer these days, they earn: Fastmail treats me like the customer, and not the product.

Fastmail is hands down the best email provider I've found. Been a customer for 7 years now, and I'll probably be a customer for many years to come. Their web UI is exceptional, very fast and solid, and their IMAP support is top notch. After 7 years I'm still mind blown of how fast their IMAP is.

Excellent point. I'm a happy fastmail user, and actually I'd like to see the ability to 'fetch and save images' in addition to the 'show images' button, so that I can archive some of those remote-image-wrap emails.

Remote image links are a bane - look how many forums have been effectively ruined because they relied on 3rd party image hosting, that has now changed it's policy, or gone away, etc.

Another annoyance are the dynamic links to other stories that you see at the bottom of news sites. I often spy a link I'd like to follow just as I leave the page, and then when I reload, the links have all changed! Super annoying.

Outside marketing, HTML has no place in email IMHO.

Personally I run my self coded all in one mail server(SMTP & web & IMAP) binary and only use the text parts, or convert them to text.

Any marketing email gets blacklisted(sender or domain) and don’t have to worry about them anymore.

Last time I was on Gmail I remember that no matter how many times I would report something as spam(and unsubscribe) it would somehow still land in my inbox next time.

Look, I'm for plaintext emails as much as the next guy but there is a value in something that provides formatting. Users, very reasonably, would like to use bold, underline, strike-though, highlighting, section headers, lists, tables, inline images, etc.. HTML was a convenient choice of format at the time and it worked well enough with budding webmail clients.

In a forum of tech enthusiasts we might be able to get away with emails exported from groff but we can't throw out all the useful features users like along with it.

If only they have decided to use something like markdown or rtf at the time. (Some mail clients do support it).

IMO the problem with choosing HTML is that then it becomes tempting to embed a complete HTML rendering engine and try blacklisting elements or restricting it. This opens up a door for vulnerabilities. If e-mail used some format which only does formatting then it would be easier to avoid security problems.

A simple Markdown dialect would have been perfect, but Markdown's ability to embed HTML would just lead to abuse.

For emails, headings, quotes, code blocks, hyperlinks, images and bold/italic/strikethrough is surely enough. Perhaps tables.

Unfortunately, that ship has sailed.

Well, the advantage is that since e-mail is a plain text medium, it could be "forced" if clients started supporting it.

And it would require zero hacks like this AMP thing and would also be 100% retro compatible if a markup language with sensible plain text legibility were chosen.

Up to your ability to modify the client there's absolutely nothing that prevents you from sending a multipart email with text/markdown as one of the options. Shoudln't break any existing email clients.

Obviously very few clients will be able to read it, or even acknowledge that it exists but it's something. Maybe someone on the other end will appreciate it.

I think bold and links are enough. If you need more formatting just attach a document.

You say "all in one mail server(SMTP & web & IMAP) binary". Any chance that code is open source or available somewhere online? I think we are sorely missing some more integrated e-mail solutions that are easy to manage.

Jmap lives (a little unfortunately IMNHO) as a Perl proxy for imap, mainly.

I've thought about trying to put a jmap face on the postgres schema of dbmail.org - but so far it's just an idea. And the next idea is that if jmap is so great, why no go straight for "graphql mail" on top of a postgres schema with solid lmtp/smtp support...

Yes, I do plan to make the source available as soon as it is something more than a toy and can be used by someone else other than me.

I agree 100%. All of this fancy stuff is used to 99% percent for marketing, and that seems to be about the only thing Google cares about. There is no need for dynamic email content at all, on the contrary, it will significantly impede the work flow of many people.

Google is one of the most destructive forces on the web for at least the past 10 years or so, they have extinguished Usenet and even try to replace http with their own proprietary technology. I have a feeling that their embrace & extinguish strategy will also work this time. Then again, I can't be the only one who marks all those newsletters and company info mails as spam and aggressively filters them out. No Facebook, Google, Apple, or other web site "news" reaches my eyes unless I want to.

Paper trails. Absolutely. The concept of keeping a recipient-owned copy of a message is as ancient as the invention of money and writing itself - it's absolutely critical for messages with legal effects, like receipts. Imagine if a fraudster could change the content of their original messages after the scam was done! Yes, Google could implement an audit trail mechanism, but that would be obscure and extremely confusing.

I'm a fan of FastMail and their philosophy. I believe you have to own your data. It is hard to find companies with core values so deeply entrenched in the product. I think it gets a little hard to stick by it when there are variables like investments, hockey stick growth involved. There is an easy incentive to not make your product open. I recently had to think about that.

That's the reason FastMail is small company. It's our collective responsibility to support the company as best as we could. Of course, not many people would have the mindspace to think about data ownership.

One of the examples I can give is, I can easily pull up a polaroid from the 70s from the attic. I'm not sure we can do that 30 years from now in the digital space, unless we make a conscious effort.

I've built a small email backup app[1] for the Mac a few years ago. I try to make the product as open as possible with open standards. I work with IMAP a lot. I love how they are spearing heading the movement (JMAP) to finally update a 20 year old protocol.

[1] https://thehorcrux.com/

I checked out your webpage, and I like the product, but it seems Mac only. Any plans for a Win version?

I'd love to have a Windows version. As of now, I only have enough bandwidth to support the Mac version.

I'm so happy to see this blog. I've been a happy, paying customer of fastmail since . . . I honestly don't know how long it's been. I never think twice about it. Fastmail is the ideal of, "It just works" that Apple strives to be. No offense to Apple or their employees, and it's a limited problem area, but these guys are really, really good at it.

Yeah, I have a gmail account. It's mostly a spam folder at this point. Because if you were able to get a good name when it was in beta in 2004 or so, it's a shitshow, even with google's pretty good filtering.

Fastmail is one of the best examples of why you should pay for online services. When you work with this kind of company, it's clear who the customer is: me. They aren't mining me for data; they aren't trying to trick me into anything. They reliably get my x dollars/year, and I pay them gladly.

A thousand thumbs up for the Fastmail team. It's probably not the most glamorous thing in the world. But cheers to a company that is making a profitable living without hype, without bullshit product marketing, and without closing off access. By just being better at something than anyone else is.

I'm hoping to start a company in the next year or so, and I want to do things the way Fastmail does them. You guys really are a beacon in the tech industry.

I’ve been trying to switch to fastmail about once a year for the last few years and checked it again to refresh my memory. My main gripe is still here: if you are on a bad connection (or with no connection at all), Fastmail’s mobile app cannot load interface and so can’t show your emails. Which makes it reeeeally painful at times when an app is most useful in the first place. :)

Of course, I could connect native mail.app, but that makes your ui on desktop and mobile too different...

Hi Bron, not related to TFA but I am a happy fastmail user and just wanted to say thanks. I really appreciate Fastmail's stable standards based services. These are increasingly hard to come by.

Thanks! We aim to please :)

I'm moving email providers in the near future and was looking at Google. AMP for Gmail ensured that I won't touch it.

You should read the top comment here before you move to fastmail, and fastmail's response.

https://news.ycombinator.com/item?id=15855081

I'm a founder of a company, and I use fastmail for my personal email and gmail for my professional email. I like fastmail more, but I need the security of gmail + yubikey because that professional email can manage DNS/domains/bank accounts.

You should also be aware that fastmail doesn't really integrate that well on Android phones. Eg in order to access calendars hosted on fastmail, you will have to use a third party caldav program. I currently used caldav-sync, which fastmail recommends. It's a piece of shit that stops working approximately every other week on a stock HTC 10. The symptom is my calendar stops syncing. I have to notice this, go to the accounts option, and manually trigger a long term sync. This is very very very annoying and I'm going to find a new program as soon as I have the time. Note this isn't fastmail's fault, but it does significantly inhibit use of their service.

The email composition box on mobile firefox on fastmail is a little funky too, but that's on me. I wouldn't be surprised if I'm essentially the only person using mobile firefox/android/fastmail's web client. This was pretty much the outcome of my effort to de-google myself.

That said, I'm really happy with fastmail and I think I'm prepaid for another two years.

yeah, that one is hard to live down. It's happened (as far as we can tell) twice in the entire history of the company, amongst hundreds of "I've lost my password" requests per week. Lost password was seriously in the top three most common support requests every week right up until we built the automatic recovery system:

https://blog.fastmail.com/2016/07/21/multiple-ways-in-keepin...

and we responded fairly directly to that Hacker News thread the next day with this:

https://blog.fastmail.com/2017/12/06/security-account-recove...

Obviously it's hugely embarassing to the company that it happened at all, and awful for the victim. I think it's perfectly reasonable for you to bring it up, and it is a consideration for anybody choosing us to do their research and decide if the steps we've taken to mitigate it happening again are sufficient.

Hello,

I'd recommend you to change your recommendation to DavDroid. It's free and seems to be much better than the one you are recommending.

Clarification: It's free to side load, but not to install from the Google Play Store.

Huh, you are right. I was remembering wrong! Thanks for correcting. Now I remember why I installed F-Droid.

> Eg in order to access calendars hosted on fastmail, you will have to use a third party caldav program

If using an app bothers you, stop using Android, because CalDAV is the standard for synchronizing calendars. iOS supports CalDAV natively.

That Android doesn't support it natively is yet another example of Google infecting the market with proprietary stuff.

You can expect the iOS implementation to be buggy and not fixable without an OS update. Meanwhile, there are multiple open source CalDav implementations for Android that update automatically.

The most probable reason it isn't installed by default is that CalDav is a failed standard, which most people don't use and don't want wasting space on their devices. ActiveSync and Google Calendar won, which is why even iOS paid the Microsoft tax to support ActiveSync long before it supported CalDav.

I used CalDAV on both iOS and MacOS for the last 2 years and worked just fine. Never had any problems. Feel free to correct me if I'm wrong.

It's true that back in 2015 FastMail was not doing invitations and RSVPs through CalDAV, but they fixed that since then.

> most probable reason it isn't installed by default is that CalDav is a failed standard

That is extreme bullshit, the same kind of bullshit that Google used to kill Google Talk and its XMPP interop, while pushing for their shitty and completely proprietary Hangouts.

People used Google Talk back in the day due to its simplicity and interoperability. Who is using Hangouts now? I actually hope it dies, because we can then put such bullshit arguments to rest.

CalDAV can only become a failed standard because unpaid fanboys and shills keep normalizing this behavior.

But until then I'll keep using CalDAV and I'll be happy about not participating in this charade ;-)

CalDAV has some issues - we're working on making it easier to work with at https://devguide.calconnect.org/

(when I say "we" - I haven't actually attended a CalConnect for a year, due to spending half my life traveling as it is - but FastMail has sent someone to every event for the past few years, and Ken has been going for ages before that)

And JMAP calendar support will be really nice:

http://jmap.io/spec-calendars.html

With the JSON format on the standards track now:

https://tools.ietf.org/html/draft-ietf-calext-jscalendar-00

> [...] iOS [...]

> [...] Google infecting the market with proprietary stuff.

You know that Apple's iOS is proprietary while Google's AOSP is open-source? As others have pointed out: AOSP + F-Droid + DAVdroid is the way to go.

Irrelevant in this context. Open Standards matter more than Open Source.

The former is designed for interoperability. The later is designed for forking.

The difference is subtle, but you can't fork your way out of Google's control of the market, unless you have Google-like resources. Big companies have tried and failed. Chrome is now the new IExplorer and its Open Source nature does not matter, quite the contrary, the danger is now less visible than it was with IExplorer, because compared to Microsoft they can use OSS for marketing and they aren't dropping the ball on its development.

Open Standards:

OGG: https://caniuse.com/#search=ogg WebM (VP8, VP9): https://caniuse.com/#search=vp9

Guess who's pushing the proprietary standard H.265: https://caniuse.com/#search=h.265

Another Open Standard: USB Type C. Guess who's pushing their own proprietary standard.

It is true though, that Chrome is starting to control the browser market which isn't a good thing. Mozilla is the solution here, not Apple. The new "Internet Explorer" is Safari: https://dev.to/nektro/safari-is-the-new-internet-explorer-1d...

Furthermore: You can change the browser (engine) on Android. You can't on iOS.

For me companies are not sports teams.

I can criticize or applaud a company for one choice or product independent of everything else. Actually if you were to look at my comments history, I've always been more critical of Apple.

Yes, you can change the browser on Android. In this context I don't care.

In my eyes Google has become an enemy of open standards.

Why not use 2FA with Fastmail? https://www.fastmail.com/help/account/2fa.html

_And_ they support Yubikey apparently.

And U2F keys (including Yubikey U2F), which I have used since they introduced it.

I pay fastmail for a side business account but I've been thinking about buying a Google Domains "account" for personal use just so I can use a custom domain for free on Gmail. Identity theft is the sole reason I don't trust anyone else and Google owns my soul for that. In a matter of hours, just like your link shows, a hacker could reset the password for everything I have. With the data he acquired it could also be possible to circumvent TFA.

Unfortunately even with me owning everything after the "@" I'm still locked to Google (I don't mind losing data) and they could freeze my domain if I do something wrong on Gmail. Could as in theoretically. Am I being over paranoid? Did this ever happened to anyone? Will I at least be able to reach a human on Google domains? Because I sure as hell won't be able to using a free Gmail account.

I'd recommend you to change to DavDroid. It's free and also on F-Droid.

I won't be managing calendars. Sadly, your choices for that seem to be either Gmail (which I'll continue using for my calendar) or Outlook (and the Outlook calendar). I'd pay good money for a working third party calendar/contacts solution that worked well on my phone, tablet, and Windows. Google doesn't fit the bill there, either, unless you like web-only.

As for securing Gmail with yubikey... how do you gain access via a standard email client like Thunderbird in that case? Anything that can't do that is a non-starter for me.

Do Gmail's app passwords not work with yubikey? I know that with totp 2fa enabled, I can generate passwords that bypass the 2fa codes. There also might be some way of using a 2fa code in the password field as well (PayPal used to do this, you just appended your 2fa code to your password).

Nextcloud or owncloud have calendars/contacts sync iirc, but I'm not sure how well it works.

I meant I won't manage calendars with my own domains. I'll be using a personal Gmail account to manage my calendars and contacts. But no critical emails will pass through Gmail and no financial or similar accounts will be tied to it.

I've also noticed the thing on mobile Firefox. It's not unusable, but there is something weird going on.

You shouldn't touch it for more serious reasons. I can confirm with absolute certainty that Gmail occasionally silently drops mail you send.

This does not seem to be directly related to Google's anti-spam system, neither sender nor recipient are marked as spam originators in those cases, and the mail will not bounce back. It simply disappears.

The FastMail signup page hits both "google.com" and "google-analytics.com". Not quite what someone looking to escape the Google embrace would hope for... Bron?

If you read closely, you'll notice that Fastmail is not entirely dismissing AMP either

If you read closely, you will notice that due to the enormous amount of power that Gmail has, they cannot refuse to serve emails with AMP content in the end.

Yeah - our duty is to serve the needs of our customers while making wise and pragmatic security decisions to keep them safe. If large amounts of email that people want to see is delivered via AMP pages, we'll make them viewable and usable somehow - hopefully in a way that makes it clear that they are mutable, and maybe even informs users if they've changed since last view.

> "...hopefully in a way that makes it clear that they are mutable, and maybe even informs users if they've changed since last view."

That would be amazing, and as a happy Fastmail customer I'd love to see it implemented. I am in full agreement with your blog post, and Google's AMP-email plan only further cements my position to excise Google from my life as much as possible. As much as I love seeing new and emerging technologies, there are times when one must say "that's too far".

Well, they could. AMP content is basically for email marketing and that's about it. Showing updated marketing brochures, deals, or ads within actual email content. It's nothing that the vast majority of users actually want or need. But marketers and spammers really really want it.

When I saw the AMP for email announcement I was not excited, but I did not get the online dread until I read this post.

The immutability of my email has saved me so many times. I also have this feeling (which may be unfounded) that emails are "proof" of something when I get into a dispute. If my email can change or rot underneath me, I will have to change the entire way I operate online.

I like AMP websites (at a basic level they're fast and that's all I care about) but I have no interest in AMP email. I hope I can opt-out of it.

From the Google announcement[1]:

> With AMP for Email, you’ll be able to quickly take actions like submit an RSVP to an event, schedule an appointment, or fill out a questionnaire right from the email message.

Form the company that prides itself on doing advanced natural language processing and machine learning. How about I just reply to the email? You know, via text.

Do some simple sentiment/content analysis and leave the rest to the senders integration between email client, calendar, crm whatever...

We tried "send people code". It was called office macro virus (viri). Running the code as js doesn't really improve things as long as all your important data lives in the same js namespace...

[1] https://www.blog.google/products/g-suite/bringing-power-amp-...

Gmail has a reasonably nice small inner-core functionality with keyboard accellerators which is javascript-portable to my life. I won't trust a cafe computer to run gmail to login, but I can trust my changing personal device to let me run gmail in some consistent manner through keyboarded commands I like.

And the spambot is good.

But adding rich features? gaaaaah. I want to go back to MH. I want to go back to my shell. I'm so tempted to walk into a dark corner, rather than have the HTML actively engage with me.

because many things, but perhaps I'm kidding myself? I bet I didn't realize how many tracking events exist through my email reading patterns, that google know, and can monetize.

this AMP thing is just a more overt moment. I'm a frog, and I've been boiled slowly.

> I'm a frog, and I've been boiled slowly.

That is a myth: https://en.wikipedia.org/wiki/Boiling_frog

These days it's more of a metaphor than a myth.

Also I am not actually a frog

AMP for gmail will be the straw that moves me completely off of google's platform.

For me it was when I had location services disabled on my phone and Android _still_ popped up a notification about the commute time between my home and work, as I was walking out the door.

At the risk of venturing off the topic of the main thread... Could that behaviour possibly be explained by timing rather than location? My Android gives me commute data around 7:30AM, regardless of where I am or whether I'm moving. Perhaps they simply guessed you'd be at home.

“Google has confirmed it has been able to track the location of Android users via the addresses of local mobile phone masts, even when location services were turned off and the sim cards removed to protect privacy.”[1]

Not saying that’s what happened here, but with Google these days I’ll assume evil[2] instead of giving the benefit of the doubt.

[1]: https://www.theguardian.com/technology/2017/nov/22/google-tr...

[2]: http://doonesbury.washingtonpost.com/strip/archive/2014/06/0...

Not just timing... but you're connected to "CompanyWiFi" and it's the end of the business day when you usually disconnect your charging cable/leave. There are many signals they could use to show that

I mentioned this the other day when a "Google Talk" discussion [1] was featured on HN. The reason I love Google Talk is the fact that conversations are saved in my inbox, and I can export the history to a local drive and encrypt the files. Pictures can go 404, but text, never. Email should be simple, but I know in 20 years, our Internet technology will end up like futuristic anime world technology. A simple, non-interactive, non-multimedia e-mail will last like a paper.

[1]: https://news.ycombinator.com/item?id=16349897

E-mail and IRC. Relevant XKCD: https://xkcd.com/1782/

Finally interested in getting off gmail. Could someone summarize the pros/cons of fastmail vs. protonmail or any other major email provider?

I can't compare services too well but I'll toss Migadu into the hat.

https://www.migadu.com/en/index.html

It's basically just an IMAP server. They have webmail but otherwise it's on you to provide a client.

So far it's been great, I switched from gmail and I am not looking back. They give really nice clear instructions on setting up your DNS properly and the pricing isn't too bad.

My main motivation was to get onto a service that lets me have my own domain. Once you're off gmail you are then free to choose and switch between whatever you like.

You might find this useful in your research: https://thatoneprivacysite.net/email-section/

I'm disappointed at this. If everybody ignored this AMP business, it wouldn't get mainstream attention.

I don't like the idea that some day use need to have a full blown web browser to check your mail.

This is pretty fun in an F500 org where email retention is 2 months or less.

Many of you have the luxury of several years of searchable email. Not all of us do. And MS exchange search functionality isn't anywhere near what Gmail's is.

I do want to use Fastmail, but their ToS are no better than Gmail i.e, that they can terminate your account any time for any reason whatsoever. Source : https://www.fastmail.com/about/tos.html This is the biggest reason I am hesitant to try fastmail.

But they probably wouldn't.

That's the whole advantage of building up a business reputation over years (part of which is blog posts like these; another part of which is just not doing shit like that.)

As a potential customer, I knew that Fastmail didn't have a reputation for abusing customers or capricious/erroneous/fucked-up account termination. That's why I chose their service, and today I'm a mostly-satisfied customer.

I didn't and wouldn't choose Google for this kind of service because I don't have that level of trust in them (because, as we all know here, they not only can but also do engage in fucked-up account terminations all the time).

Even if the Fastmail terms of service said "we will not ever terminate your account unless you are convicted of felony child abuse" they could always terminate your account by going out of business.

So I get your concern, but that's really always a concern. You have to judge that risk, and the primary way to do that is by checking out a company's reputation.

I understand your point, but prior to the recent update their termination criteria were really broad, basically on whatsoever reason your account could be terminated. Now they have modified their ToS and the termination criteria now seem reasonable.

Yes but for some people the word "probably" is not going to work.

They need to run their own stack with associated backups.

Hmm, it doesn't say they can terminate you for any reason at all, but rather only "if you fail to comply with these Terms, or where required to by law," in addition to "non-payment, which is defined as failure to make a renewal after your paid subscription period expires."

Edit: This is apparently a fairly recent change, they wrote a blog post about it: https://blog.fastmail.com/2017/09/11/tos-update/

Thanks for the link. Now their termination criteria seem reasonable enough and I have opened an account. The interface seems really nice.

So, you're basically saying that you don't trust anyone's terms of service enough to use their email. You rolling your own, then?

If so, more power to you. But let's be real, that's a damn lot of time that takes to do right. And if you're not doing it right, then why do it yourself.

I don't love google, but google does a better job with email than I'm willing to do for myself.

Fastmail does an even better job, in my opinion, which is why I pay them actual money to do that job. Could I manage all this myself? Sure. I guess. But I want to fuck around with other things.

You've got to be in a weird situation where Fastmail's TOS is more frightening to you than Google or Apple or Micrososft's.

I'm not sure why you're being downvoted (language maybe? But we're all adults here) but you're exactly right. Fastmail is a company that provides a service for a fee, it would be insane if they didn't have a TOS enumerating their rights regarding their customer relationship. If they didn't have the right to terminate service, the customer could do whatever they wanted (use the service to send out spam or engage in illegal activity) with no risk of losing service.

If GP wants an email service that will let them sidestep the law, as you said, they can roll their own. I can't think of any other reason someone would be turned away by a sensible TOS.

I am saying the exact opposite. Their ToS were so broad prior to the recent update, that if you trusted their ToS, using their service was difficult to justify. Now they have switched to more reasonable ToS and I am giving fastmail a try. No amount of trust can justify overly broad power of termination. If they're never going to exercise that power, why to have that in the ToS. Considering how important a part of our digital lives email is, it makes sense to expect your account does get terminated only in rare circumstances,(when required by law). I am glad fastmail too realized this and updates their ToS.

They did this to me. I signed up for a fastmail.fm account around 2002-2003. They presented their services at the time as a 'one time' fee - something like 20$ if I remember correctly.

Anyway around 7-8 years later they announced that any customer that was using their services from the one time fee would be kicked off. They gave a warning of a few months but after that I lost all the email I had on that account as well as access to the email account.

I don't hold a grudge or anything and feel I got my money's worth, but I just thought I'd throw this out there as information.

Are ToS enforceable for individual and small-business customers, in the US? What could we do, hire a lawyer and sue the provider? File a complaint with the, er ... new management ... of the FTC?

Better to look first that the offer is a win-win business proposition from the get-go, with the provider likely to continue making enough profit to pay their bills. That way they have reason to continue providing quality service. There are a thousand ways to weasel out of a contract.

At least with FastMail you'd have a phone number that will get you to a human to ask why.

You have a phone number with Google Apps and support PIN in admin console, has anyone had any success of talking with someone that isn't a human version of a Twilio phone to email transcriber? That can actually get shit escalated whilst your on the phone or at least shortly after. The presence of a phone number means very little if they don't answer or one of those annoying press 1.. for then press 2.. blah blah

A client was on Zoho business with paid support. Their phone number went to voicemail every single time, they called back four days later, great fun in an emergency. Stay away from them on the subject of email.

When I enabled Enterprise trial on Google apps to change the domain on my legacy free account, they called me to see if there was anything they could help me with. There was no canned responses at the time, they actually answered the couple of off-topic questions I had at the time, and were quite friendly. That may have changed since, or it may be an Enterprise-only or new-customer thing, though, and I've never actually called them up myself.

And your email account won't take down all sorts of other stuff with it.

When you pay for something, you are more important than when you use a free service.

Off course, but their previous overly broad termination criteria couldn't be justified by me. Now that they have updated their ToS to more reasonable terms, I am trying their service.

It's bad because people can manipulate email. It is not absolute. An overzealous email admin/exchange admin can work horrors.

But maybe that's just me. I've been an Exchange admin.

For sure - anybody who can modify your mailstore can change emails - that's not really under debate. The same way anybody who has access to your hard drive can change your files.

The issue at hand here is whether the original sender can modify the message after you've received it.

I guess they can by brokering a deal with the bad actor in charge of your mail server. Unlikely but email is still bound to social manipulation.

We're in the "you're screwed regardless" territory here - like having an ISP who intercepts TLS connections and substitutes content as you download it. There's no real way to work around that, though you might be able to detect it if there are unforgeable signatures on some of the content (e.g. DKIM signatures from third parties on incoming emails) - though the intermediate can strip those too, so all you see is "unsigned" rather than "modified".

> if there are unforgeable signatures on some of the content (e.g. DKIM signatures from third parties on incoming emails)

FWIW, in many cases content can be changed even if signed with DKIM without breaking the signature.

http://noxxi.de/research/breaking-dkim-on-purpose-and-by-cha...

I think email clients should be rethinking how they communicate to users whether or not an email is signed, e.g. if the headers haven't been oversigned and/or the full body hasn't been signed then it may be better to just show the message as having been not signed at all.

Part of the reason I download all my email to my PC.

But then the DKIM will be broken, at least if the sender’s client properly signed it.

This is the first convincing argument I've read against AMP email.

On the other hand, if someone sends you a link to a web page, sure the link didn't change, but that's not very useful, since anything can happen to the web page that the link points to.

So it might just be about not confusing the user about what's immutable? Which is itself pretty important.

It's the first convincing argument i've read against AMP email, assuming it's a valid argument. It doesn't look like amp4email is any less immutable than standard email is - it fetches some resources from external servers, but mandates that those resources must be static and cacheable. Gmail's current behaviour is to download and store all images in emails when they are first opened, which makes the images in emails as immutable as fastmail wants them to be, and i don't see why they would treat any other resources delivered in amp emails differently to images. To me, this seems perfectly reasonable - the responsibility to store email contents in the state they were first recieved should be on the recipient's client, not the sender's server.

i love this blog post, because it's great to write down in clear terms why email being a read-only log is so important. but it looks like in the case of amp it might be a bit of a straw man.

That is absolutely a good point. I should have shown my working a bit more.

static is boring, because every email can still have a custom endpoint.

proxyable is more interesting.

You say "cacheable" - I don't see that in the AMP project notes:

https://github.com/ampproject/amphtml/issues/13457

@ras9929 yes amp-list allows you to generate dynamic content populated from a json endpoint. The demo shown today did exactly what you are suggesting. See https://www.youtube.com/watch?v=p8Eo4gAoDBA&feature=youtu.be

The only reason to host images remotely rather than including them as cid: links inside a multipart/related is size and encoding overhead. Likewise, a new dynamic multimedia format could be entirely self-contained within the email if you wanted to design it that way.

Instead what we have is something which is very tightly coupled to short-lived online services. It's a really poor archival format, but it has just enough sweet bits that people will want to use it for things that it shouldn't be used for. It's really short-term design.

Sure - and as I said in the blog post - this is already an issue with embedded images - which can be made to look pretty good and, if remote, can be changed later. Spam scanners penalise messages that are just a remote image for good reason.

Then you should use Apple Mail for macOS which has the option of including a PDF of the webpage rather than the obviously fragile URL.

Hey, Thunderbird team, this is a feature I'd want.

Thunderbird team: Generate a request to the URL, and include the attachment as a WARC file, not a PDF. The client or any other system can then render that content however they desire at a later date.

I read this

  Of course, we’re a hosted “cloud” service. If we turned bad, we could start silently changing your email. The best defence against any cloud service doing that is keeping your own copies, or at least digests of them.

Does this remind anyone else of that old Gmail Paper April Fool's prank? Last bastion of immutability. http://content.time.com/time/specials/packages/article/0,288...

Wait why do they have a legit link to it still? https://www.gmail.com/mail/help/paper/

> "It's paper, plain and easy. I sometimes find myself wondering: what will Google think of next? Cardboard?"

Keeps you wondering where they get their product names...

https://web.archive.org/web/20141217113440/https://www.gmail...

I've begun to see immutability as a common theme in some of the most esteemed tech in production. Email, git, cryptocurrency, and stream processing (although I admit I don't know a lot about that one) just to name a few big ones.

For me, email is just a repository of order and shipping confirmations. I can't even remember the last time I sent an email, or I even read one written by a human.

Here's a free B2C startup idea for you aspiring founders: a personal email (local?) archiver and search engine. Pull all my logs from my 15 different addresses I've had over the years, and give me super-fast realtime search on all of it. I wouldn't hesitate to pay 10 bucks a month for that. This idea has a super-useful B2B angle as well (think of the explosion of MailChimp clones).

If you don't want to put your data in another silo, this is what mu [1] and notmuch [2] provide. I have been using mu/mu4e for a while and it is absolutely great for quickly finding e-mail, creating virtual search-based mailboxes, etc. Combined with isync and Fastmail's standard-conforming IMAP support, you have a really nice e-mail setup.

Of course, it's not for the general public, but this is Hackernews ;)

[1] https://www.djcbsoftware.nl/code/mu/

[2] https://notmuchmail.org

https://github.com/salyh/elasticsearch-imap

getmail + grep

I love FastMail and this is just one of the several reasons I recently updated to a 2 year plan.

I hope you can implement some feature to download the amp-content or similar so it works like normal email. I do not like amp at all but I understand if you have the need to do something to support it, but as other have written please leave it off by default!

Email is quickly becoming the equivalent of linked in notifications. When you have 100 unread emails you might be flooded with something important. When you have 20-100 thousand unread emails: Email is broken

It's the electronic memory of nobody cares. I will potentially spend 5-30 minutes a day on email... Most days it is zero

You don't need to read everything for it to be useful. I get email reminders of things I need to do - I don't need to read past the subject line (same with shipping notifications), and purchase receipts are useful to keep in case there is a problem (you have a searchable record of when/where you bought it) but don't need to be actively read.

There's a high percentage of emails I get that I don't get any extra value from actually reading them, but I would lose value by not getting them at all.

I suppose this depends on how you use it. The only mass notifications I get are from bitbucket and that is only because it does not have any other sort of notification system

Don't accuse a system to be broken if you don't use the system properly.

Great post!

> The email in your mailbox is your copy of what was said, and nobody else can change it or make it go away. The fact that the content of an email can’t be edited is one of the best things about POP3 and IMAP email standards.

I rely on this feature of email all the time as I'm sure most people do. We cannot let this change.

This makes a convincing argument for the general adoption of ipfs as a the backbone of the internet.

As I understand it, nothing can be truly deleted, you only need to know what the hash of the object was and chances are it will still be accessible in cache for quite some time.

So, literally illegal in Europe, where you have the legal right to be forgotten from the internet? There is a lot to be said for being able to delete data from an internet-connected computer and trust that it is, in fact, deleted. Email definitely falls in that category, but while deletion for email has a fairly obvious value, remote mutability of emails is extremely questionable at best.

IANAL but I don't believe ipfs in of itself runs afoul of "right to be forgotten". Skimming Wikipedia, "the right to be forgotten" only requires search engines to not index things which are "deleted", or more realistically, things which have been unlisted.

Because even in the infrastructure we have today, objects aren't truly "deleted" for quite some time, at least not where CDNs and Google and Facebook and others are involved.

Perhaps a better place to start the discussion about the legality of ipfs would be to ask if bittorrent is illegal in Europe.

After all, if even one seeder is online somewhere in the world, a torrent is accessible and cannot be deleted. Does bittorrent have the potential infringe on someone's right to be forgotten?

ipfs operates in a similar way (peers and seeds).

As always Bron & teams - so happy with your take on this and proud to be a Fastmail user and advocate.

-Sam.

This is why I hate docsend pitches. I can’t go back a year or two later and look at things - someone will ask me if I know a founder and I search my inbox and find them, but the pitch is gone and I can’t rememeber what they did or what we talked about.

Perhaps not to the point, but I find more interesting pieces that I want to remember occur in Hangouts, Slack or some other more expeditious medium other than email.

I suspect that for some, email is losing priority.

Google just wants to take control of publishers. And then dictate to them what they can do or not, when a publisher page is displayed in an email. No, to AMP for email

> We strongly believe that our customers stay with us because we’re the best, not because it’s hard to leave

That's why I stay with them.

I love seeing posts like these where a company demonstrates what their core values really are, not just shallow slogans. I'm a happy Fastmail customer and just renewed for 5 more years.

Off-topic -: Do you plan to ever open source your Android app?

an email service would be the only instance where I would consider disabling my ad blocker if ads are not targeted... could FastMail consider?

A bit unrelated, but since, Bron, you are obviously reading this: I love your blog, the only thing that drives me crazy: I can’t see the scroll bar in your blog posts on my mobile. I guess it’s because it’s rendered in white. Scroll bars, however, are great to have an indication how much of a page I’ve read already, like a download bar. Not having it drives me nuts :-)

I have consulted with the guy that wrote the HTML and CSS in the first place and we’ve determined why this happens: the header and footer are both dark, so to make the overscroll background colour (when you scroll past the end of the document) dark as well, `html { background: #323436; color: #fff; }` is applied; but apparently this has the negative side-effect of making it choose to use a light scrollbar which is invisible on the actual content background of white. In short, an iOS-specific hack causes another iOS-specific problem!

We’ll think about it some more.

Oh wow. Thanks for looking into it. Sounds nasty... good luck

Yeah, our blog is currently a pain to work with in a few ways. It's generated straight out of our source repository from Markdown files, and you have to do the full pull request, merge, deploy to get posts out.

We're looking at moving the blog to another platform, and usability review will be part of that!

I recently wrote a blog engine that's pretty lightweight. Sort of tries to hit a middle-ground between a static blog and a wordpress type of thing. It also . . . doesn't work perfectly. I fucked something up with drafts, and I need to get back to it. But if you are interested, it's not too bad. Insanely fast.

http://actuallysprained.net/

Source code is here: https://bitbucket.org/tronflux/pyrant

I'll pass the link on to the team looking at it. I think they already have something in mind though. Ta.

picocms

What browser are you using? I can’t reproduce this on Firefox for Android (scrollbar rendered in grey, as is usual) and can’t easily imagine what could be causing it.

Safari

>(even more specifically, an email with remote images can totally change after being content scanned).

Can anyone speak to the prevalence of this abuse strategy? Are our anti-spam engines able to handle this?

Then why isn't Fastmail adding some kind of end-to-end encryption at least for its own users? Shouldn't our memories be private (unless we choose otherwise)?

https://blog.fastmail.com/2016/12/10/why-we-dont-offer-pgp/

Thanks! The benefits of having blogged all this already :)

Gmail inexplicably deleted all my email prior to sept of 2009.... and later I needed the emails I had in the account.

So yes - email is and should be your digital mem, but the system sucks and the companies suck that promise you free "digital memories" -- so I am still on the fence in general regarding all tech firms that provide a free service - but what should one plan to pay for this:

---

I was born in 2028. I was immediately augmented from what I was organically contrived to be/become; a Human.

Human.

What did that mean exactly? What is the definition of a Human? What the FUCK is this bag of potential intelligence? This bag of potential revenue? This bag of potential fealty? This.. bag... of... ...potential???

Out of the gate the system labeled, confined, contrived, pre-determined and then finally programmed me as to what, no, WHO, I was....

I had to then begin to PAY to be "HUMAN" -- I had to pay for maintenance of my body, pay to feed it, pay to educate it, pay to protect it, pay to get it loved, pay for everything that I either required or desired... -- this is what the 'definition' of being human has become.

If you are born and cant be intelligent enough, beautiful enough, lucky enough, rich enough or evil enough... You are not allowed to be human. Survival of the fittest at its best. And the only ones who would agree with that, are those that can state that they are better than masses who cant compete....

This is the new 'Human'

Who is greater than what.

When youre a "what" - a plumber, a coder, a low life, a socialite... yeah... there are lots of layers in WHAT....

But there is really only one "who". WHO is that WHAT? is the basics....

Who is that master plumber?

Who is that elite socialite?

Who is that low-life?

---

Then the system judges "how much"

"How much has that low life cost society"

"how much does that plumber give to society?"

"How much is that socialite worth?"

"How much does that engineer contribute to my life's well being?"

"How much do these jerks make?"

---

So, as we discover who and what we are, we need to look at how we became that [thing].

How? Parents predilections, socioeconomic status, location born, innate abilities, genetic modifications, external modifications....

Human is a basic condition that is manipulable and shall be exploited through whatever given tools are available to those who are in a position to exploit.

Now, where is my blood-boy.

/fiction-rant

Email is not immutable though? It's pretty easy to just copy an email out of your favorite IMAP client, modify it, and drag it back. Do they not know this?

I think the point is that it's immutable to the user. Nobody can go in my mailbox and change the content of emails that are there. You can't unsend an email (except for weird hacks like delaying sending the email in the first place). The use of the term immutable here is not intended to suggest your inbox cannot be modified in any way by yourself.

A good example of how Gmail has futzed with immutability with "dynamic" content before is how they embed Google+. It lets you +1 and comment straight from inside Gmail, which is pretty awesome! But... in the case of a notification for a deleted post or comment, the dynamic overlay Gmail uses will try and obscure the content. You end up having to go to a mobile or IMAP client to see what was actually contained in the email notification of the deleted G+ item.

> The use of the term immutable here is not intended to suggest your inbox cannot be modified in any way by yourself.

Okay, but then, is this any different from cloud storage? Would you also say Google Drive is immutable for the same reason? Or for that matter, wouldn't the same go for files on your computer?

Yes - assuming you trust Google not to fiddle it. I would expect that a document I stored in Google Drive wouldn't update itself a week later.

OK, so by "immutable" you really do mean "static" then? Static stuff can change, but stays unchanged until you actually change it. Dynamic stuff can change even without input from you. Mutable stuff is possible to change. Immutable stuff is impossible to change. etc.

The bigger issue though is I'm trying to square what you're saying here with your blog post:

> I admit it annoyed me when I first ran into it – why can’t you just fix up a message in place

If this was a poor wording, maybe go back and rephrase? Because I it seems pretty undeniable that after reading this sentence the reader gets the impression that you claim it's not possible to go back and fix up a email in your own inbox. Which wouldn't really matter, except that people who aren't aware otherwise will actually believe you and spread misinformation on this. Last thing I want is someone reading your blog post and falling for a scam because they read from a presumably reputable source (you) that emails can't be edited post-facto.

Once you send an email to someone, you can't change it. It's that simple.

It has absolutely nothing to do with what you can do to your own inbox. The entire point is that you should be able to rely on the fact that what you see in the emails you receive from a sender cannot be modified by that sender.

If someone sends you threats over email, you just archive them as evidence. Now with amp, they can send you threats that only show a threat the first time and then load inane text the rest of the time.

I'm sure someone thought this was a good idea but I can't imagine they used emails very much themselves because this is idiotic. Email isn't a web browser.

There are tons of games you can play with email. If it isn't signed with PGP or S/MIME or DKIM someone on either side can make it look like something completely different than the original.

A bad actor can claim their edited copy of your email is death threats.

Emails are immutable, mailboxes are mutable - but only by deleting and writing a new email. Sure it can be similar to the previous email because copy and paste exists - you're not hand scribing it. But the fact remains that for the mailstore, this is a brand new message minted out of whole cloth. You can't edit in place.

And in terms of how our own servers work - there is a backup of the old version, because it was a separate message in its own right that was deleted by the action of making a new message and deleting the old one.

The problem with this isn’t what Google is doing, but the fact that they are calling it email.

Email is a document. It is an artifact that was sent, and making it anything other than that may be a useful thing, it isn’t email.

Nothing is actually impossible to change, so your strict definition of immutability doesn't mean anything.

Well, duh - if you can delete, edit, and upload a NEW email clearly you can change the state of your mailbox. That's a new email though, it's not the same email. Books are also not immutable - you can throw away a book and print a different book with the same cover.

So at that level, nothing is immutable if you have full write access to it.

The difference is, who has access to mutate the message? If you mutate it yourself, more power to you. It's your copy. If the SENDER can mutate it right there in your mailbox, that's a different story.

In what sense is it a "new" email? It has exactly the same headers and message body (except for whatever you choose to modify, obviously), including dates and sender and everything. It's like copying a file on top of another file and claiming the older one isn't modified, it's just a "new" file that you're copying. I mean, OK, but how is this a meaningful or useful statement? The result is pretty indistinguishable from having modified the bits of the original email in-place from the user's standpoint.

If you mean it can't be mutated by anyone other than the account owner, then that would be worth clarifying I think? But even then, the same is true of, say, my Google Drive. Nobody can modify my files who hasn't received my explicit permission. So are files on Google Drive "immutable" to you?

"modify it" - looks like a new email to me. It's going to have a different secure digest. You can argue semantics here - but the main difference is:

YOU can modify the messages in your Inbox.

THE SENDER can not. Unless they have write access to your mailbox and can copy things out in a client, edit them, and write them back.

Regarding the "the sender" thing -- see my update above; sorry I was busy editing my comment before you posted this.

Regarding the secure message digest: if that's your claim, maybe clarify that "[DKIM-]signed messages are tamper-proof"? Because not all email messages are signed. Also, I think you can still upload messages with broken signatures (not sure?) in most mailboxes, and the user won't necessarily know either (who verifies DKIM signatures manually?)... but I'd have to double-check this.

Yeah, probably true - I did mention our non-standard DIGEST.SHA1 (I'd like to change that algorithm at some point, though the risks are kind of overblown, particularly since we inject some randomness in the SESSIONID field that's part of the Received header added on every delivery)

That said, if you tried to claim that a message was from somebody and used a tampered version, then checking the DKIM signature is something I expect would be done as part of the forensic analysis, as would checking the mail server logs. At least on our servers, you'd be able to tell from the logs that the digest changed when the new copy was uploaded - assuming you claimed something about downloading it and moving it to a new folder with your client.

It's not mutable by the sender. If you edit your email history it will change. If you don't edit it then it won't.

It's not proof by itself, but might be if you can convincingly claim that you didn't edit your received email.

Also - if it has a DKIM signature on it (or ARC chain), then you can't modify your copy and still have the signature pass. And that signature was probably made with a private key that you don't control.

Reply on news.ycombinator.com