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.
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.
> 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.
"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...
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
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.
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?
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'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.
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...
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).
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
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.
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).
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.
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 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?
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?
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.
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.
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?
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.
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.
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.
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 :-)
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.
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.
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!
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?
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)
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.
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.
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.
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.
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.
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.
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].
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.
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.
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
The whole point of turning off 'location' is I want it to not track my location. I disabled it on purpose. If I only wanted to turn off GPS, I would do that. I turned off location.
If they're not actually going to turn off 'location' then don't call it location. Call it GPS, and be honest about it.
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'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.
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.
“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.
> 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.
> 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)
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.
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.
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."
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).
> 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?)
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.)
> 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?
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.
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.
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
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...
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.
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
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.
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.
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.
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.
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".
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.
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.
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.
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?
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.
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 :)
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.
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 se...
> 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 d...
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]
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.
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.
>> 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.
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.
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.
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 ;)
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.
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.
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:
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.
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.
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 ;-)
(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)
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.
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.
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".
Fastmail user since forever, I've waited until I hope I'm not upsetting general discussion, risking this plea in case of potential remedy.
I managed to convert my free for life account to a paid account when I was hoping to merge a paid admin account with my free one. AFAIK My original email account wasn't subject to required login activity but the merged account was. What I had wanted to do at the time, was to be using my lifetime account for primary receipt of multiple domain administrator user email accounts, as I had relied heavily on fastmail for the effective archive.
In short, I was separated from my twelve years plus old email account, by a change in my account that I had no ability to undo, events overtaking my life very soon after the merge.
Lifetime accounts such as I had can be a lifeline.
Continued use of my archive enabled me to save several domains otherwise I would have lost due to the interrupted existence I had. I was able to mostly wind down my business semi gracefully, as a result.
Can Fastmail once again offer lifetime accounts, without any minimum requirements of use intervals?
I am not begging for a reinstatement here but asking if there is a fair price I can pay for this once off, and exhorting the creation of a account type that gives incredible peace of mind to serious users.
Consider my elderly mother, whose health declined in days rendering her helpless, but it took a year and two months to obtain the necessary court authority over her affairs.
A court will not make any order giving access to email accounts in a hurry. The account will be treated as being a real part of the person's identity. At least in the UK.
Recent email standards that prevent sending spoof return envelope addresses reinforce the same effect of having the equivalent of identity.
Arguably anyone who used any consistent signature in body in text, was identifying the same origination with their identity.
Only a week ago in the high court, my McKenzie Friend (now non practising retired barrister I've known from his uni jazz band days) held at offer of test, ie implicitly asked the judge if the court accepted his email printouts and the auto reply as a legitimate correspondence with the other entity, and the vestigial gestures of approval said to me the court was absolutely not separating the autoresponder from the defendant.
Service upon a known or advertised email address is definitely now service in the UK, save for where the nature of a order, such as a Penal notice requires personal service or personal attestation of the correct procedure attempted.
THIS EXCLUDES so many accounts in the event of a range of life events, from incapacity due to illness or - this sank a great friend on his second time bootstrap (he made it on the third) the breakdown of a co-founder, the real possibility in England for a statutory period of declared incapacity far exceeding the eventual needs (insurance coverage, spousal and corporate, often tips this decision from one to six months), indictment or visa irregularities.
The last two seem ominous but I'll be quick: the Family Division of the high court handles all manner of cases from the deterrent of stalkers to divorce. This court is provided for by no kind of legal aid. None. Zero. And the law is fiendish and the talent scarce. And the case load so high that combined with lay appellants, the temper of judges despairing of any positive result, can be brutal to unprepared litigants. To this firmament we can add a body of criminal penalties for breach of sanctions, that the judiciary at large appears to think unbalanced. Because if you're not able to comply with the court's ruling, the court forever under pressure of time and resources, the combination of both zero public funding and criminal penalty can be extreme. Far too often, spouses are prohibited from entering large geographic areas impossible to avoid, even including workplaces. This is a easy arrest for a young officer with almost guaranteed guilty plea, but a guilty...
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.
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?
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...
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.
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.
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.
291 comments
[ 3.4 ms ] story [ 266 ms ] threadIn 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.
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.
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.
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.
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.
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.
You could always just 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
It might be possible to match on non-empty text/plain?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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...
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).
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
I wish more people published data about it.
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
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.
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.
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?
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 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.
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 proof by itself, but might be if you can convincingly claim that you didn't edit your received email.
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.
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?
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.
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.
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.
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.
A bad actor can claim their edited copy of your email is death threats.
We're looking at moving the blog to another platform, and usability review will be part of that!
http://actuallysprained.net/
Source code is here: https://bitbucket.org/tronflux/pyrant
We’ll think about it some more.
Off-topic -: Do you plan to ever open source your Android app?
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
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.
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.
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.
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
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...
If they're not actually going to turn off 'location' then don't call it location. Call it GPS, and be honest about it.
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.
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.
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.
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.
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.
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.
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.
OTOH, I like that Posteo is not a corporation, but actually run by a natural person with full personal liability.
_____
> 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
How is storing the domain part of the mail address so very different from storing the local part?
> 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.
They don't want to be put in the position where they know what natural person a certain email belongs to.
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)
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.
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
Just as a rhetorical question: do they decline local parts in the form of firstname.lastname? Thought so.
Sounds like a BS marketing answer.
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.
The lock-in provided by not using a custom domain is very convenient.
WPUASTSWSWYOGTUO
But to you point, my primary motivation in this instance was dramatic effect. Additionally, I'm hoping it will catch on.
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."
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
Why would they? Surely AMP for Gmail is a sweet revenue opportunity for Google, who are answerable to shareholders?
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.
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.
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.
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
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.
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.
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.
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...
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
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
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
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.
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.
Side thought: If we really need brilliant people to run e-mail, God, we really need to rethink the e-mail stack.
Because everyone should have e-mails, and e-mails shouldn't be so difficult we need a team of security researchers with Ph.D's to setup a server.
What a strange world we live in.
But maybe that's just me. I've been an Exchange admin.
The issue at hand here is whether the original sender can modify the message after you've received it.
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.
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.
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.
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.
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).
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 :\",
Hence "memory" - because that's how people use it :)
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?!).
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!
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?
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.
As related market research, Kolab uses IMAP as a general-purpose data store: https://github.com/pdfernhout/Twirlip2/blob/master/design/ma...
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/
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 se...
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.
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 d...
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
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.
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.
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.
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.
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.
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://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.
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.
Nextcloud or owncloud have calendars/contacts sync iirc, but I'm not sure how well it works.
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.
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.
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.
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.
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.
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 ;-)
(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
> [...] 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.
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.
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.
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.
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".
I managed to convert my free for life account to a paid account when I was hoping to merge a paid admin account with my free one. AFAIK My original email account wasn't subject to required login activity but the merged account was. What I had wanted to do at the time, was to be using my lifetime account for primary receipt of multiple domain administrator user email accounts, as I had relied heavily on fastmail for the effective archive.
In short, I was separated from my twelve years plus old email account, by a change in my account that I had no ability to undo, events overtaking my life very soon after the merge.
Lifetime accounts such as I had can be a lifeline.
Continued use of my archive enabled me to save several domains otherwise I would have lost due to the interrupted existence I had. I was able to mostly wind down my business semi gracefully, as a result.
Can Fastmail once again offer lifetime accounts, without any minimum requirements of use intervals?
I am not begging for a reinstatement here but asking if there is a fair price I can pay for this once off, and exhorting the creation of a account type that gives incredible peace of mind to serious users.
Consider my elderly mother, whose health declined in days rendering her helpless, but it took a year and two months to obtain the necessary court authority over her affairs.
A court will not make any order giving access to email accounts in a hurry. The account will be treated as being a real part of the person's identity. At least in the UK.
Recent email standards that prevent sending spoof return envelope addresses reinforce the same effect of having the equivalent of identity.
Arguably anyone who used any consistent signature in body in text, was identifying the same origination with their identity.
Only a week ago in the high court, my McKenzie Friend (now non practising retired barrister I've known from his uni jazz band days) held at offer of test, ie implicitly asked the judge if the court accepted his email printouts and the auto reply as a legitimate correspondence with the other entity, and the vestigial gestures of approval said to me the court was absolutely not separating the autoresponder from the defendant.
Service upon a known or advertised email address is definitely now service in the UK, save for where the nature of a order, such as a Penal notice requires personal service or personal attestation of the correct procedure attempted.
THIS EXCLUDES so many accounts in the event of a range of life events, from incapacity due to illness or - this sank a great friend on his second time bootstrap (he made it on the third) the breakdown of a co-founder, the real possibility in England for a statutory period of declared incapacity far exceeding the eventual needs (insurance coverage, spousal and corporate, often tips this decision from one to six months), indictment or visa irregularities.
The last two seem ominous but I'll be quick: the Family Division of the high court handles all manner of cases from the deterrent of stalkers to divorce. This court is provided for by no kind of legal aid. None. Zero. And the law is fiendish and the talent scarce. And the case load so high that combined with lay appellants, the temper of judges despairing of any positive result, can be brutal to unprepared litigants. To this firmament we can add a body of criminal penalties for breach of sanctions, that the judiciary at large appears to think unbalanced. Because if you're not able to comply with the court's ruling, the court forever under pressure of time and resources, the combination of both zero public funding and criminal penalty can be extreme. Far too often, spouses are prohibited from entering large geographic areas impossible to avoid, even including workplaces. This is a easy arrest for a young officer with almost guaranteed guilty plea, but a guilty...
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.
-Sam.
Of course, I could connect native mail.app, but that makes your ui on desktop and mobile too different...
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.
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.
That is a myth: https://en.wikipedia.org/wiki/Boiling_frog
I suspect that for some, email is losing priority.