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.
“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.
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.
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.
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  - 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'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 , where it emphasizes minimizing the data collected from the customer.
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.
But to you point, my primary motivation in this instance was dramatic effect. Additionally, I'm hoping it will catch on.
The lock-in provided by not using a custom domain is very convenient.
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)
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: 
> "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."
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.
Just as a rhetorical question: do they decline local parts in the form of firstname.lastname? Thought so.
Sounds like a BS marketing answer.
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.
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, 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.
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: email@example.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, firstname.lastname@example.org was reserved, but you can email me at email@example.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 firstname.lastname@example.org, 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...
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.
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
Why would they? Surely AMP for Gmail is a sweet revenue opportunity for Google, who are answerable to shareholders?
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.
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.
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.
> What is the vast majority of “live” content on the web, stuff that needs to call home and update itself? Not articles like this one, or videos or songs — those are just resources you request. Not chats or emails. Cloud-based productivity tools like shared documents, sure, granted. But the rest — and we’re talking like 99.9 percent here — is ads.
Truer words have never been spoken. Shame on you Google.
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.
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.
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.
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?
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.
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?
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.
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 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).
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 ) and write longer lines in the MIME message. (Not sure what they do after 998, which the spec says they MUST not exceed .)
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.
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
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.
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?
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"
"So, you can take all of my technical comments with a grain of salt in the
sense of all that ambition (or whining or paranoia. :-) I acknowledge these
suggestions are pretty ambitious, as above, and such ambitions would ask
that the Diaspora team learn a lot about emerging ideas and do some really
difficult things involving some bleeding-edge semantic stuff beyond the new
(and good) stuff it is already doing -- and that it is possible such
ambitious and risky efforts might fail for all sorts of reasons. Still, I
contacted the Chandler/OSAF project about the Pointrel system semantic
approach and they went another more mainstream way and failed anyway (well,
it's still ongoing, but it lost its way and most of its funding somewhere
along the line). But, I learn more each time, so maybe the above might seem
more coherent and approachable than what I sent the Chandler/OSAF people
years ago, and that in private, not in public where at least others could
learn from it. :-)
It's quite reasonable for anyone to say that, for now, a Semantic Web is not
what Diaspora is about, as no one can do everything. But somehow, I feel,
the really big future for something like Diaspora is going to be integrating
semantic web concepts. So, at the very least, if Diaspora was built in such
a way as to support future modules in that semantic direction, it might be
an even more successful thing that totally and rapidly eclipses Facebook and
many other technology platforms as well."
I wish I had more time to pursue these ideas in an open way other than as a hobby taking too much time away from family -- and involving unhealthily spending way too much time on the computer overall on top of regular 9-5 work time. I'm obviously personally invested in these ideas and enjoy programming in this area. But it's also a tough moral choice about spare time given the need for such systems to have a happier singularity factored against the very real costs to any individual/group and a very low probability of success for each specific effort. But collectively, if enough people try (alone or in small groups) in their own ways, likely somebody will succeed -- and then a larger group can build on that success in a stigmergic way. https://en.wikipedia.org/wiki/Stigmergy
Still, while such an effort to create an alternative may indeed be a trap of wasted effort for no results, what we have now with global use of (anti-)social media -- media designed to addict people and provide 24X7 surveillance and control of information flow via a few centralized services -- is a trap we're already collectively in.
Unfortunately, some people who I might otherwise think should know better -- like Paul Jones, UNC professor in the School of Journalism and Mass Communication and the School of Information and Library Science and of ibiblio fame -- seem to promote the centralized social media technology of this trap. They have given up on email due to spam, information overload, and other issues like asynchronicity -- and replaced email by collection of mostly commercial web services rather than try to make something better inspired by email's good aspects including local archiving and local search. See: "UNC professor Paul Jones went from pioneering to protesting email"
While centralized services do have some benefits over current email (including editing and moderating), it is not like the centralized services don't have their own new problems -- whether various forms of spam including low-quality duplicate content driven by monetization, having less time for reflection in a torrent messages with immediate response expected in some services, or even new problems where "unfriending" someone is a lot more complicated and stressful than not including someone on an email CC list.
I've posted a few comments over the years on Paul Jones' #noemail blog ( http://www.ibiblio.org/pjones/blog/category/noemail/ ) agreeing with him about email's problems -- while also pointing out obvious new problems with trusting all your communications to a few centralized services and suggesting working towards better alternatives. But those posts seem to have disappeared in what may have been a purge of most comments from that blog. That is an example of one of the perils of entrusting your messages to someone else for publication and archiving -- and a reason to consider a federated architecture as an alternative.
Still hoping he might someday promote a solution that keeps email's many benefits (including as a personal "electronic memory") while addressing the valid concerns he raises about email.
Anyway, stuff I like to think about and discuss and implement. Even though I may be reaching the point where, like many others before me, "The point of being done is not to finish but to get other things done." See: http://www.manifestoproject.it/bre-pettis-and-kio-stark/
And one might then hope for continued co-evolutionary bootstrapping improvement of concepts, artifacts, services, culture, and practices like Doug Engelbart talked about. And we can see that now, like in using the web right here and now on HN to discuss something better.
So, I can totally get where JMAP-as-it-is becoming a big success would move things forward, and we could then use JMAP to discuss the next generation of changes. So, I'm raising the issue of a broader aspiration -- while accepting it might not be best for JMAP right now.
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):
"I‘ve traditionally been in the IA camp my whole career; I’ve spent the last year going deep into the AI camp. Traditionally these have been opposite worlds but I’m wondering if there might be some powerful, interesting ways to combine them together. One is humanistic and and design focused, the other tends to be more analytical; the space between them is where I’m interested in exploring in the future."
Back around 1988 I applied to be in the NeXT developer program with a concept for an application (embarrassingly called "Orgi" back then, but I was young and reckless/foolish) where the idea was that any data item could hook up with any other data item (using triples). That application never got acted on until I met Steve Jobs when he gave a talk at Princeton and asked him personally about the developer program. And such ideas came out of my earlier interest in triplestores --
ideas that contributed to the roots of WordNet by my undergraduate advisor at Princeton, George A. Miller started just as I was graduating.
In any case, as I said, "I've been beating my head against that wall for years with very limited progress (as have others)". :-)
Jamie was obviously smart enough to connect with such ideas and move on to a happier life selling beer, pizza, and conversational ambiance. Obviously a much smarter guy than I am. :-) And I did not realize his early interest before, so thanks. I knew of another person who became much happier leaving contentious academia after his PhD and being a professor to run a hardware store. See also Matthew B. Crawford's "The Case for Working with Your Hands" written by someone with a PhD who left the non-profit public policy sector to do motorcycle repair: http://www.nytimes.com/2009/05/24/magazine/24labor-t.html
That said, maybe if Jamie had run Mozilla we would not have seen such a tragic waste of billions of non-profit dollars mostly pissed away -- including by mostly abandoning Thunderbird? Or, maybe his voice would have just been ignored? Hard to day. Innovation is such a complex thing. Some ideas I've collected for supporting innovation at such places: https://github.com/pdfernhout/High-Performance-Organizations...
Doug Engelbart and many people he inspired are others near the root of this "intertwingled" data ideas (including "Open HyperScope" as a successor to "Augment" http://hyperscope.org/ ). Ted Nelson and people he inspired with Xanadu. Alan Kay and Dan Ingalls with Smalltalk and its implications as a thinking tool (Dan ran a family hotel for years afterwards). Ward Cunningham with the Wiki server idea and now the Smallest Federated Wiki idea. Mitch Kapor and the Chandler Project. The recent Dat Project by Max Ogden and others also connects with all this somewhat. There is this great book called "Design and Memory" from 1980 by Peter Huyck and Nellie Kremenak exploring such ideas. And of course "As We may Think" by Vannevar Bush. But the roots go further back though annotated scrolls (and the Talmud) and millennia of libraries -- and even back to the first "Standing Bear" cave paintings (see the book, "The Walking People").
This issue of (re)creating a decentralized alternative based around an email-ish feeling of interlinked locally-searchable information is increasingly important because it potentially is a way to move beyond negative aspects of centralized (anti-)social media.
But, hey, my wife and I have more than 5000 books in our house, so all this might just be my hoarding tendencies trying to justify themselves? :-)
Well, off to an unrelated job. And it is unrelated precisely because most of the big paying players in this space (e.g. Google and Facebook) want to get between people and their data -- and typical startups make deals with investors which limit their ability to do FOSS. Still, I can hope there will eventually be, say, an "Automattic" of this "intertwingling" equivalent of WordPress. I actually had hoped Automattic might itself become such a company, but they sadly seem to now see themselves just as a Wix/Squarespace competitor (e.g. adopting Slack for internal communications -- and not even Mattermost or Matrix.org if they want to let someone else own that space and cooperate with another FOSS system).
At least it is nice to think about these things in my spare time -- although sadly at the cost of other experiences. Maybe it is all just a mistake to use my non-job time like that, like Piotr Solnica suggests: https://twitter.com/_solnic_/status/953578620617920513
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:
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
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.
Notice that this is from HP, not some small shop. Nowadays people expect you to be able to parse HTML emails and don't bother to have it work in plain text (I'd actually prefer if they got rid of the text/plain in this situation, this way mutt would know to display the HTML instead).
If AMP becomes popular enough and gets integrated by the big players I have no doubt that we'll see the same thing. Then it means you won't be able to process email in any significant way without a full blown Web engine (probably including JS).
First they ported everything to the web, now they're porting the web to everything else. I don't want the web. The web is bloated crap. Stop it. Please. Stop it.
Maybe an AMP filter could check the plain text content against AMP and HTML content and bounce the email with a custom message if there is no plain text or standard-HTML way to read the content.
Eventually a sufficiently capable filter will be likely to figure out that the thing these emails have in common is a poor text/plain part and adjust its weighting appropriately, but I’d expect it to take somewhere between “quite some time” and “a long time” to figure that out; in the mean time, it’ll mostly just serve to confuse the poor filter.
(How customised spam filters work, in a nutshell: take your various signals—e.g. has HTML, has remote images, has no text, is sent from a known-spammy IP address, mentions large sums of money—and figure out which factors occur more often in spam than ham, and increase the importance assigned to them; if the email reaches a chosen threshold, it’s showing sufficient characteristics of a spam message to be considered probably spam.)
SpamAssassin is probably the most widely-used spam filtering platform; I’m not certain that its standard rules are capable of deciding to filter on this sort of thing directly. I believe it has something around detecting overly short or non-representative text/plain parts, which is probably the primary signal this would coalesce around.
If I click on an AMP link (usually only via HN), and I get a blank page without any loading indicator, it's usually because someone posted an AMP link.
Is there any proof that it'll be able to run arbitrary JS? Or that it'll be mutable? Or that there will be no way to turn it off?
Furthermore, at the bottom, they specify:
> All fetchable attributes like src and href must be static
> All network requests must be proxy-able to ensure that user anonymity is preserved
This implies that anonymity is big focus (so your information will not be leaked), and that things will be fairly static.
Almost all the "speculation" happening goes contrary to that, leading me to believe that no one has actually taken the time to read up, and are just blindly expressing their existing preconceptions and hatred about AMP.
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)
Personally I run my self coded all in one mail server(SMTP & web & IMAP) binary and only use the text parts, or convert them to text.
Any marketing email gets blacklisted(sender or domain) and don’t have to worry about them anymore.
Last time I was on Gmail I remember that no matter how many times I would report something as spam(and unsubscribe) it would somehow still land in my inbox next time.
In a forum of tech enthusiasts we might be able to get away with emails exported from groff but we can't throw out all the useful features users like along with it.
IMO the problem with choosing HTML is that then it becomes tempting to embed a complete HTML rendering engine and try blacklisting elements or restricting it. This opens up a door for vulnerabilities. If e-mail used some format which only does formatting then it would be easier to avoid security problems.
For emails, headings, quotes, code blocks, hyperlinks, images and bold/italic/strikethrough is surely enough. Perhaps tables.
Unfortunately, that ship has sailed.
And it would require zero hacks like this AMP thing and would also be 100% retro compatible if a markup language with sensible plain text legibility were chosen.
Obviously very few clients will be able to read it, or even acknowledge that it exists but it's something. Maybe someone on the other end will appreciate it.
I've thought about trying to put a jmap face on the postgres schema of dbmail.org - but so far it's just an idea. And the next idea is that if jmap is so great, why no go straight for "graphql mail" on top of a postgres schema with solid lmtp/smtp support...
Google is one of the most destructive forces on the web for at least the past 10 years or so, they have extinguished Usenet and even try to replace http with their own proprietary technology. I have a feeling that their embrace & extinguish strategy will also work this time. Then again, I can't be the only one who marks all those newsletters and company info mails as spam and aggressively filters them out. No Facebook, Google, Apple, or other web site "news" reaches my eyes unless I want to.
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.
That's the reason FastMail is small company. It's our collective responsibility to support the company as best as we could. Of course, not many people would have the mindspace to think about data ownership.
One of the examples I can give is, I can easily pull up a polaroid from the 70s from the attic. I'm not sure we can do that 30 years from now in the digital space, unless we make a conscious effort.
I've built a small email backup app for the Mac a few years ago. I try to make the product as open as possible with open standards. I work with IMAP a lot. I love how they are spearing heading the movement (JMAP) to finally update a 20 year old protocol.
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.
Of course, I could connect native mail.app, but that makes your ui on desktop and mobile too different...
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.
and we responded fairly directly to that Hacker News thread the next day with this:
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.
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:
With the JSON format on the standards track now:
> [...] 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.
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.
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.
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.
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.
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".
The immutability of my email has saved me so many times. I also have this feeling (which may be unfounded) that emails are "proof" of something when I get into a dispute. If my email can change or rot underneath me, I will have to change the entire way I operate online.
I like AMP websites (at a basic level they're fast and that's all I care about) but I have no interest in AMP email. I hope I can opt-out of it.
> With AMP for Email, you’ll be able to quickly take actions like submit an RSVP to an event, schedule an appointment, or fill out a questionnaire right from the email message.
Form the company that prides itself on doing advanced natural language processing and machine learning. How about I just reply to the email? You know, via text.
Do some simple sentiment/content analysis and leave the rest to the senders integration between email client, calendar, crm whatever...
We tried "send people code". It was called office macro virus (viri). Running the code as js doesn't really improve things as long as all your important data lives in the same js namespace...
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
Not saying that’s what happened here, but with Google these days I’ll assume evil instead of giving the benefit of the doubt.
I don't like the idea that some day use need to have a full blown web browser to check your mail.
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.
Many of you have the luxury of several years of searchable email. Not all of us do. And MS exchange search functionality isn't anywhere near what Gmail's is.
That's the whole advantage of building up a business reputation over years (part of which is blog posts like these; another part of which is just not doing shit like that.)
As a potential customer, I knew that Fastmail didn't have a reputation for abusing customers or capricious/erroneous/fucked-up account termination. That's why I chose their service, and today I'm a mostly-satisfied customer.
I didn't and wouldn't choose Google for this kind of service because I don't have that level of trust in them (because, as we all know here, they not only can but also do engage in fucked-up account terminations all the time).
Even if the Fastmail terms of service said "we will not ever terminate your account unless you are convicted of felony child abuse" they could always terminate your account by going out of business.
So I get your concern, but that's really always a concern. You have to judge that risk, and the primary way to do that is by checking out a company's reputation.
They need to run their own stack with associated backups.
This is apparently a fairly recent change, they wrote a blog post about it: https://blog.fastmail.com/2017/09/11/tos-update/
If so, more power to you. But let's be real, that's a damn lot of time that takes to do right. And if you're not doing it right, then why do it yourself.
I don't love google, but google does a better job with email than I'm willing to do for myself.
Fastmail does an even better job, in my opinion, which is why I pay them actual money to do that job. Could I manage all this myself? Sure. I guess. But I want to fuck around with other things.
You've got to be in a weird situation where Fastmail's TOS is more frightening to you than Google or Apple or Micrososft's.
If GP wants an email service that will let them sidestep the law, as you said, they can roll their own. I can't think of any other reason someone would be turned away by a sensible TOS.
Anyway around 7-8 years later they announced that any customer that was using their services from the one time fee would be kicked off. They gave a warning of a few months but after that I lost all the email I had on that account as well as access to the email account.
I don't hold a grudge or anything and feel I got my money's worth, but I just thought I'd throw this out there as information.
Better to look first that the offer is a win-win business proposition from the get-go, with the provider likely to continue making enough profit to pay their bills. That way they have reason to continue providing quality service. There are a thousand ways to weasel out of a contract.
A client was on Zoho business with paid support. Their phone number went to voicemail every single time, they called back four days later, great fun in an emergency. Stay away from them on the subject of email.
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.
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.
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:
@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.
Of course, we’re a hosted “cloud” service. If we turned bad, we could start silently changing your email. The best defence against any cloud service doing that is keeping your own copies, or at least digests of them.
Wait why do they have a legit link to it still?
Keeps you wondering where they get their product names...
Of course, it's not for the general public, but this is Hackernews ;)
I hope you can implement some feature to download the amp-content or similar so it works like normal email. I do not like amp at all but I understand if you have the need to do something to support it, but as other have written please leave it off by default!
> The email in your mailbox is your copy of what was said, and nobody else can change it or make it go away. The fact that the content of an email can’t be edited is one of the best things about POP3 and IMAP email standards.
I rely on this feature of email all the time as I'm sure most people do. We cannot let this change.
It's the electronic memory of nobody cares. I will potentially spend 5-30 minutes a day on email... Most days it is zero
There's a high percentage of emails I get that I don't get any extra value from actually reading them, but I would lose value by not getting them at all.
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).
Can anyone speak to the prevalence of this abuse strategy? Are our anti-spam engines able to handle this?
I suspect that for some, email is losing priority.