13 ms·

Thinking out loud about 2nd-gen email

• riffic 2y ago
  email is a good example of something that won't so easily be "2nd-gen'd" because everything it's built on is here to stay thanks to Lindy Law https://en.m.wikipedia.org/wiki/Lindy_effect https://en.m.wikipedia.org/wiki/Lindy_effect
  • striking 2y ago
    I found your link interesting and informative. I'm curious if you have any specific comments on this quote from the story: > From there, the email services which implement MX2 would publish a public date, on which all messages sent to them by the old MX record, will be automatically sent to Junk. If just Microsoft and Google alone agreed on such a date, that would be 40% of global email traffic. Do you think this change wouldn't be enough? If so, why not?
    • riffic 2y ago
      all I can say is IPv6 (and to qualify, IPv6 is great everyone should be using it).
    • smeehee 2y ago
      MX records don't send messages. Assuming that “sent to them via SMTP” is meant… well, moving all messages to ‘junk’ isn't a good idea: it needs to be restricted to messages sent on or after that time. But why not just respond with “554 No SMTP service here” on opening the connection?
  • nine_k 2y ago
    A solution that is 100% interoperable with the existing widely deployed solution but also offers substantial advantages can have good chances to coexist with the old solution for years if not decades, supplanting it only slowly. Examples of success: monochrome TV -> color TV, landline phones -> mobile phones, the Windows 3.x -> Windows 9x -> Windows NT/2k/XP transition. Email has a really well-working transport layer. The UX layer can see some innovation while staying compatible.
    • sneed_chucker 2y ago
      Yeah, backwards compatibility that you slowly frog boil people out of is definitely the most effective solution for something like this.
  • jasode 2y ago
    >email is a good example of something that won't so easily be "2nd-gen'd" because everything it's built on is here to stay The key argument is that email is already getting "2nd-gen'd" -- but it's happening in bite-sized and incoherent steps that don't fully work. Example of new 2024 DMARC/DKIM/SPF requirements from Google & Yahoo: https://www.google.com/search?q=yahoo+gmail+new+senders+dkim+spf+requirements https://www.google.com/search?q=yahoo+gmail+new+senders+dkim... The above situation is acting like a pseudo-2nd-gen email standard that's evolving in slow motion (without us officially calling it "gen v2.0"). Those email policy changes will be adopted because big cloud email providers like Gmail and Yahoo have a massive influence on the entire email landscape. Therefore, a new hypothetical "MX2" standard that was more coherent with better authentication, anti-spam, and anti-phishing features could be promoted by a consortium of Google/Microsoft/Yahoo/Apple. The smaller players like Fastmail, ProtonMail, Mailchimp, Sendgrid, etc and most everyone else would all have to follow the cloud email providers' lead because everybody wants to be able to send email to them.
    • deleted 2y ago
      [deleted]
  • chuckadams 2y ago
    Lindy’s closed six years ago.
    • riffic 2y ago
      it actually closed in 1969 (or 1957).
• sneak 2y ago
  > By simplifying the stack to the above, eliminating SPF, DKIM, and DMARC (and their respective configuration options), and standardizing on one record (MX2) for the future, running your own self-hosted email stack would become much easier. Additionally, the additional authenticity verifications would hopefully allow spam filters to be significantly less aggressive by authenticating against domains instead of IPs. This assumes that the reason antispam tools make it hard to host your own email is because of spam. That’s only part of it. The other part is that deliverability is a cartel, and two of the biggest players, Google and Facebook/Meta, wish to be the intermediary between you and your audience and sell you access to their eyeballs. Truly federated email allows you to communicate directly with your audience, bypassing apps and paid ads. This is a threat to their business models. Additionally, domains are cheap, and moving the trust decision to domain from IP doesn’t get you much. Unknown/fringe domains will still land you in spam by default, same as non-deliverability-cartel IPs do today.
  • hacker_homie 2y ago
    I was wondering about this as well, I think he is suggesting they report the spam to your domain registrar, who either does something about it or there whole cert chain gets blocked by default.
  • jacobsimon 2y ago
    Yeah don't see how domains would be that much better than IPs but it would be easier to understand. It's already quite common for email senders to use multiple domains when they're concerned about deliverability, and domain reputation is already a factor I believe. Re: deliverability, I do think incumbents are benefiting from the complexity of email, but I'm not sure I follow your argument about Meta.
    • sneak 2y ago
      Nobody would use Gmail if it didn’t deliver messages from Facebook, same as how nobody would use iPhones if you couldn’t install Instagram and WhatsApp on them. Google and Meta are in the selling-access-to-eyeballs business. They don’t need to explicitly collude to keep others out of your inbox, their interests happen to be aligned here automatically.
• eej71 2y ago
  Some good ideas in there I think. But I think unless you can shoe-horn them into the existing MX record and get piecemeal buy-in, the results will be quite similar to what we see with IPv6 vs. IPv4. No?
  • jwr 2y ago
    Why? The example of https coexisting with http was convincing.
  • notatoad 2y ago
    email has already been sufficiently captured by the big guys that if they chose to support this, there would be buy in. and without their support it's dead. if outlook and gmail announce that emails that aren't MX2 get ranked more harshly in their spam filter, everybody will adopt it. if they don't do that, nobody will.
  • jandrese 2y ago
    I don't see the problem with implementing it via the MX2 option. That makes backwards compatibility a lot easier than messing with the existing MX option. It also means if the proposal goes over like a lead balloon it at least won't have made the existing situation worse. Good luck convincing Microsoft to implement anything you're suggesting in Outlook though. Or for Google to add it to gmail.
  • quectophoton 2y ago
    Seeing how we got a brand-new and very shiny `HTTPS` RR type instead of using the existing `SRV`, I'd say the hope for improved email is not zero. Still very close to zero, but not zero.
• shortformblog 2y ago
  Some great thinking here, and the kind we need. For all the bellyaching about HTML and email, the real problem is that nobody has been bothered to build a standard that everyone agrees to. The gradual approach is a smart one, too. I think AMP for Email has some great ideas but bad branding. It could be a useful starting point for this discussion.
  • chrismorgan 2y ago
    Are you familiar with what AMP for Email is about? It’s dynamic content. That’s all. And that’s something that has no place in email. AMP for Email is dealing with a completely different problem from the one discussed in this article—one that no one asked to be fixed, and which few people even agree is a problem (and they’re all trying to sell you something).
    • shortformblog 2y ago
      Do you think I would have brought up AMP for Email if I didn’t know what it was about? Please, take a breath.
    • shortformblog 2y ago
      One additional point. This gatekeeping about what email should or should not be is just too much sometimes. It is the very reason why email has been in stasis for so long. Anyway, you understand why I brought it up, right? It is an attempt at a standard in email that already exists. When we are talking about improving email, highlighting existing work is useful. That means there is something tangible that can be used to improve the weaknesses in the current model. Additionally, he brought up HTML email in the post. AMP email is an attempt at standardizing HTML email. That is relevant to what he wrote.
      • chrismorgan 2y ago
        No, I don’t understand why you brought it up. It was Google trying to shove through something they’d invented, using their market power as leverage. You don’t make good standards like that. It was also not at all about standardising HTML email—it didn’t improve anything in that way, except insofar as the AMP part being chosen implies that the client has decent HTML support. AMP for Email is purely about dynamic content in emails. And the very way that each provider that supports AMP for Email has required whitelisting of each sender shows there’s something extremely rotten about the entire thing.
• dsr_ 2y ago
  How do mailing lists work? What's the difference between a VM set up by a real person to handle their email and a VM set up by a spammer to spam you?
  • throw0101d 2y ago
    > How do mailing lists work? If they keep the original From: header they would not work, as the sending (mailing list) server would look like a forger, so the ML software would have to do a rewrite that header. If you wish to keep original From: headers, then ARC would have to be incorporated into this proposal: * https://en.wikipedia.org/wiki/Authenticated_Received_Chain https://en.wikipedia.org/wiki/Authenticated_Received_Chain
• jcranmer 2y ago
  > A standardized HTML specification for email; complete with a test suite for conformance. Or, maybe we just declare a version of the HTML5 spec to be officially binding and that’s the end of it. keels over in laughter Oh, there's been quite a few attempts at at standardizing HTML rules for email. I was even in one of them, which petered out very quickly. Functionally speaking, the problem is you have three groups of people with HTML email (well, four groups, if you include the people who wish it died off). You have the marketing folks, who want HTML email to work essentially exactly like regular webpages so they can do all their normal design stuff and get it to work. You have the MUA implementers (particularly webmail), who need to aggressively sandbox and sanitize the HTML because to do otherwise is to risk security leaks. And you have Microsoft, who needs to keep visual compatibility with Word HTML because their userbase would flip out if they broke stuff. These groups want different stuff from HTML, and they're not going to do a good job of reconciling their viewpoints with one another.
  • deleted 2y ago
    [deleted]
  • hacker_homie 2y ago
    1. Yeah the marketing folks would hate this but we need to use a subset of HTML. 2. Ok so these are the people who are going to want to help us and they run the largest email servers at the moment 3. I think MS products already have web views in them (either edge or old edge), if we had a change over like MX 2 maybe that would be an acceptable trade off to break the old.
    • tichiian 2y ago
      We don't need a subset of HTML. Actually, we need Markdown emails. You can format stuff that needs structure, but not abusively so (no blinking marquee banners in eyesore colors), it is sufficiently compatible to plaintext that you don't even need the text alternative mime object. It is also more compact than HTML. And before somebody says "won't fly", all those fancy new "will replace email someday" messengers use markdown or some parts of it's formatting.
• hacker_homie 2y ago
  Yeah, two thoughts - no script tags in HTML5 it's mark up not JS. - no separate body for rich html and plain text, This will just result in "Please enable HTML rendering to view this message" - maybe we need to define a subset of HTML (no external resources, css etc..)
  • jandrese 2y ago
    I'd also restrict the allowed CSS to the tiny portion of the spec that styles the text and maybe some basic layout. Definitely no scripting allowed.
    • smeehee 2y ago
      And require that if any colours are set, both foreground and background are set. (I've seen too much breakage with assumptions about one or the other.)
  • prima-facie 2y ago
    I still hope to see text/markdown as an officially supported content type by email clients.
    • Avamander 2y ago
      I guess it could be added to something like Thunderbird. Would be really nice.
    • immibis 2y ago
      Not useful proposal. Markdown is both limited and ambiguous. It's okay for writing by hand more naturally than HTML, but the sender should parse it and then explicitly indicate which characters are bold, which ones are underlined, etc, and you're back at a subset of HTML.
• citizenpaul 2y ago
  The main issue is whatever replaces email MUST be intentionally asynchronous. There are a 1000 email replacements. The problem is they try to be better. No one wants email to work better than it does from a performance or function perspective. Email is literally the last tech bastion keeping us from 24x7x365 work days as matter of default procedure. Everyone knows this deep down and thats why they refuse to learn or adopt the better systems that already exist.
  • gjsman-1000 2y ago
    I think it's important to recognize the article does not suggest any obvious user-facing changes to how email operates; only technical ones that would hopefully fix the many pain points there.
    • citizenpaul 2y ago
      All the behind the scenes failures are also a feature. Diffusion of responsibility, plausibly deniability. No one needs "mgmt" to be able to nail their coffin easier than they already can. 99% of the world doesn't work in HN land of high pay for high expectations. Most places are trying to force people to work 100hrs a week for as close to min wage as possible. Unless countries start enacting actual labor laws with teeth I stand by my statement that no one really wants or needs email to work better, there already are alternatives.
  • TylerE 2y ago
    > No one wants email to work better than it does from a performance or function perspective. Hard disagree. Email sucks in just about every way.
    • citizenpaul 2y ago
      It sucks and that is a killer feature. Get a few years on you and the Grind-set will fade as you realize you don't want the only thing in life to be work. You will be glad email still exists.
    • 2y ago
• graiz 2y ago
  Would be great if Google/Apple/Microsoft could lead some of these Internet upgrade initiatives. I think we have more cross corporate collaboration on Emoji selection.
  • immibis 2y ago
    They did. Google's one is called Gmail, and Microsoft's one is called Outlook 365. They each want you to use their product and offer you improved service if you only use their product and talk to other people who are using their product. But Apple got the best lock-in with iMessage.
• bradleybuda 2y ago
  The best thing you could do to accelerate the rollout of MX2 (or any email replacement) is to have Congress bless it as a secure channel for Private Health Information
  • SushiHippie 2y ago
    Especially in Germany where it is either via letter or Telefax.
• ROFISH 2y ago
  [flagged]
  • ipsento606 2y ago
    Tying sender reputation to domains is not "defenseless against brute force attacks" because domains cost money
    • chrismorgan 2y ago
      I just looked through my Spam folder. I have 48 messages in the month to date. 18 of them are from at least ten domain names matching /^(marketexec|marketexecmail|market-exec)?\d{1,2}\.co\.uk$/. Domains cost money, but not that much, and people do do things like this. (There’s also the problem of senders aggregating messages from untrusted parties, so that reputation is always a tricky balance. For example, I have four spam messages from gmail.com this month. When I’m not getting bursts like this marketexecmail stuff that started two weeks ago and will probably stop within another couple of weeks, I find that at least a quarter of my spam messages come from gmail.com, outlook.com or hotmail.com; in January, it’s 12⁄46, and at least four more are from other general-public domain names that I recognise.)
  • thecosas 2y ago
    Keeping this as reference for later trolling with fellow email-standards nerds :-)
    • chrismorgan 2y ago
      Honestly, I wouldn’t consider this trolling. It’s a low-effort dismissal here (probably why it’s been flagged to death), but it’s still insightful and accurate. The first time it came up, certainly over twenty years ago and I’m not sure how much more (but you can find the form from at least that far back), it was honest weariness with claims of having solved spam. If you’re not familiar with these things, the keyword is FUSSP (Final Ultimate Solution to the Spam Problem).
    • Avamander 2y ago
• chuckadams 2y ago
  Proposes to replace SPF, DKIM, and DMARC with a brand new signature scheme that Trust Me, Will Work This Time. And because this scheme is of course innately perfect, hardwires a reject policy. Mixes up MUA and MTA technologies as if they were even the same ecosystem. Yeah, email needs replacing, but it needs actually serious proposals.
• lxgr 2y ago
  Yes, please. Every day we don’t fix email is another day organizations will continue shifting to phone numbers as identifiers, which is 10 times worse.
• perlgeek 2y ago
  There's a whole world of email mess that the article didn't even touch on: ambiguity, for example by repeating headers with conflicting values. For example, you could have, in an email: Content-Type: text/plain Content-Type: text/html now, maybe a virus scanner will think that the email is plain text, but the recipient's email reader parses it as HTML. Same potential confusion with Content-Transfer-Encoding. And then there's the matter that headers are supposed to be ASCII-only, but what happens when you send header values with 8 bits set? And then there is how email threads work. Most of the world uses "In-Reply-To" and "References"-headers, but Exchange, in its infinite wisdom, decides to ignore them and has its own proprietary headers. Basically every aspect of email has very annoying problems, and every attempt at a version 2 needs to either ignore some of them (annoying those particularly invested into this problem), or reinvent the whole wheel, running in Second System Syndrome worries. It's not easy...
  • TylerE 2y ago
    Oh, it's very easy, really, but getting people to accept what it will take won't be. Don't make a federated protocol. Basically every issue with email can be traced to it being federated.
    • r3trohack3r 2y ago
      Email is not federated It is decentralized
      • TylerE 2y ago
        Email is absolutely federated. "A federated protocol is a protocol (defined next) that makes it possible for servers to communicate with each other, regardless of who is running those servers." Federated is not a synonym for Mastodon instance.
        • wnevets 2y ago
          "possible for servers to communicate with each other, regardless of who is running those servers." Wouldn't that definition include almost everything on the internet?
• thecosas 2y ago
  Trying to wrap my head around how bulk email providers (Salesforce, etc) would operate in this? I guess you could give them a subdomain of your main domain and have a separate MX2 record. This might help silo off newsletter, transactional, and actual person to person messages like many already do in the current environment.
  • gjsman-1000 2y ago
    It's a little confusing, but my idea is that there would be multiple MX2 records for every authorized sender's key. One of those MX2 records would have a marker on it for incoming mail.
    • thecosas 2y ago
      Ah, gotcha. Feel like I've got the existing MX stuck in my mental model. Honestly with all of the existing DNS record based "authentication" with SPF, DKIM, DMARC its already a mess for bulk senders too lol. Thanks for putting these thoughts together :-)
• jollyjerry 2y ago
  Email is one of the services I would like to self host for small projects, ran into issues immediately for spam. I like the idea of using public keys tied to a domain, but feel the email service providers have little incentive to adopt this because the complexity adds value to their service.
• simmons 2y ago
  Thanks to the OP for writing this up. I'd love to see mail be rebooted. A few thoughts: 1. I don't know if HTTPS is the best analogy, since it took 20 years for it to really become widely used (vs. non-secure HTTP). I think a better analogy might be the transition from HTTP/1.1 to HTTP/2 (or HTTP/3?). 2. I don't think we can rely on large providers (e.g. GMail) to quickly adopt a new system and even issue switchover ultimatums. A simpler mail system may not be in their best interest. Aiming for slower, organic growth could be more realistic. Even if a next-generation mail system never becomes dominant, it could still provide value. (Maybe Mastodon/ActivityPub is the analogy here?) 3. In any sort of reboot, I think a modern encryption system (something like Signal protocol?) would be a must. 4. Can we have a system where senders need to hold tokens to authorize them to send a message to a recipient? The whole "anyone on earth should be able to send you an unsolicited message" idea is ultimately the source of the spam problem. Messaging systems that rely on bidirectional agreement have much less of a spam problem. (Obviously this raises a slew of other technical and UX questions...) I know that making too many changes is a risk. But I think that there is also a risk in making too few changes. (If the value proposition isn't sufficiently bold, this may hurt adoption.)
  • belthesar 2y ago
    To your thoughts: > 1. I don't know if HTTPS is the best analogy... IMO, the lynchpin to HTTPS accessibility was that we made cutting certificates easy, and most importantly, free. By eschewing the baseline requirement for cutting a certificate to being able to validate that the site on the domain is trusted by virtue of a relationship between the hostname and the certificate requester, and providing an API to automate the renewal process, opting into HTTPS went from "administrative burden that needed a sysadmin to manage" to "service any hosting provider could leverage". LetsEncrypt and the ACME protocol, and Cloudflare before them, did much to radically change the landscape for making HTTPS accessible to everyone. [1] That makes the analogy pretty apt to me, IMO. 2. You make a very valid point here. By virtue of letting SMTP languish so long, bandaiding it as we went, instead of opting for a major refactor of how email works, we made an environment that was rife for consolidation. As a result, it makes sense that we might have to boil the frog to make a change. 3. I'd love to see it, but I'd be interested in learning how key exchange/trust works. I'd be interested to see how you'd envision enabling new senders to send you mail. 4. This feeds back into my comments on 3. With established contacts, this is great, but in a world where, say, you were giving a talk, and wanted to offer folks that listened to your talk a way to contact you afterwards, how would you distribute the token? If someone abuses the permissions, how do you invalidate it? I can't foresee this being an all-or-nothing system, and don't really see a system where creating some sort of one-way or two-way trust between individual senders and recipients is at all feasible. [1] Let's Encrypt stats: https://letsencrypt.org/stats/ https://letsencrypt.org/stats/
• gmuslera 2y ago
  Something clicked when he was saying that SendGrid and Mailchimp are clean, and it remained till the end. Email born as internet, something decentralized. But it is getting harder and more complex to have your own mail server, because you have to comply with a lot of requirements of major mail providers. For big scale servers, and commercial mass sending companies ("legal spam") they can afford to comply with all those requirements. And about ("not legal") spam and malware senders, or they don't care if they reach a limited set of target, or the reward is high enough to try to trick the system. So the smaller mail servers, without so many users, or without so knowledgeable maintainers, if any, are getting expelled from the game by both bad and big players, some just move their email administration to some of the big providers (and privacy and territorial requirements may be a problem here). What the article proposes is another change to push things in the same direction. And, for good and bad, some of the present use cases may be harmed by this proposal too, like devices and other simple notification services, or mailing lists.
  • immibis 2y ago
    It's the same on social media and the Internet at large, until the Elmo's tantrum accidentally popularized Mastodon. Sure, you don't have to do anything to be visible in a web browser (except you do, since you need a domain name and a Let's Encrypt certificate) but you have to obey Google's rules to be searchable at all, for example, and everyone's just browsing the same big websites all the time except when they click on an outlink, so you have to go to those websites and post outlinks to yours if you want any traffic, which is likely to get you banned for self-promotion even if it was something people actually wanted to read. Basically everything's centralized now because bad money drives out good, and I don't have any ideas to fix it. It may be fixing itself to some extent as some CEOs keep banning their anchor users in strange tantrums.
• rcarmo 2y ago
  This is an interesting thought experiment, but I really want e-mail to stay mostly as it is today, except with a nicer way for me to make sure SPF/DKIM/etc. are enabled sanely for small domains.
  • Avamander 2y ago
    I think the ecosystem is definitely moving in that direction. I also think a lot of the ambiguities could be fixed with new RFCs gradually.
    • jcgl 2y ago
      What do you think needs changing in the standards, rather than simplified implementations? That is, implementations that are suitable for small- and medium-scale turnkey deployments.
  • rsync 2y ago
    That is a very good suggestion and it is my highest priority as well, in terms of "thinking about improvements to email". I do understand the attraction of highly specialized, modular and pluggable tools - so I know why OpenSMTPd does not have a built-in nameserver, spam filter or DKIM service. The architects are thinking about correctness and scalability and modularity, etc. But Oh My God it would be so much simpler - and comprehensible - if there was just one package with just one config file. If the only purpose of a particular nameserver is authentication tasks for a mailserver, we should consider moving the nameserver into the mailserver. The same goes double for dkimproxy.
    • Avamander 2y ago
      You're describing new solutions like Stalwart and Maddy. Which try to automate away a significant portion of these issues and maintainability concerns.
• hoyd 2y ago
  What about Wave?
• AlienRobot 2y ago
  >A standardized HTML specification for email There is no reason why this couldn't exist in the current e-mail technology. In fact, as someone who has written HTML, I'd rather not have HTML anywhere if possible! It's a terrible, nonsensical technology. A simple XML format for display text/images would be much easier to deal with, and also easy to transpile to a HTML/CSS subset. I'd like to hope that e-mail will last longer than HTML! I think the biggest problem with e-mail is that the lack of inter-provider communication protocols, something that distributed social media (the fediverse) has. For example, there is no way for a provider to know whether or not an e-mail sent was opened, so EVERYONE uses tracking pixels! Like, just put this into a protocol already! The problems you're talking about with HTML support are simply because there is no way for a provider to announce what HTML it supports, partly because this depends on the client that opens the e-mail, not the server that stores the e-mail. But even then, seriously, this should really just be a setting per account and if you use Thunderbird it announces to everyone "hey this dude uses Thunderbird, so don't use fancy HTML!" and if you switched to something else you would just start getting different e-mails. You can see why this wouldn't work with HTML, since HTML is a terrible language that has no actual support for being displayed in a zillion different clients despite what it claims.
  • ndriscoll 2y ago
    Return receipts are already a thing aren't they? But most people don't actually want to be tracked, so the correct thing to do there is not allow any external resources to be loaded from an email, and to make user tracking illegal/codify that stalking millions of people doesn't make it okay; it makes it millions of counts of stalking and harassment. HTML already gracefully degrades. If you don't support a feature, you just ignore it and continue. It works just fine unless you're shooting for exactly matching some figma design on all clients, which is exactly what HTML is not supposed to do.
• russellbeattie 2y ago
  Interesting idea, but two general criticisms: 1) No one changes established tech (software/hardware/services) unless the "new new thing" is 10x better/radically different than the old. 2) "Bullshit talks, code walks." Here's how something like this becomes an actual standard: Someone codes up a prototype, and gets others to use it. Enthusiasts join in and improve it. Five to 10 years or more passes and if the new standard is actually worthwhile, it will have grown to the point established organizations finally pay attention and - if it's in their best interests - will adopt it. Take git as a prime example. Launched in 2005, it was still at only 42% adoption by 2014 (according to Stack Overflow yearly survey). A decade after that, however and it's at more than 95%. It took nearly two decades for one of the most quickly adopted technologies in the 21st century to become ubiquitous. So get on it and we'll see you in 2044.
• Savageman 2y ago
  The past/quoted reply should be a separate part too. The main part should only contain the new content. Potentially even the signature should be its own part.
• phlogisticfugu 2y ago
  feature requests: - make unsubscribes work - make phishing harder
• azinman2 2y ago
  If we’re really going to mx2 there are so many things that could be done to improve things, but at minimum at the protocol level, it’d be great if there was a two way street to let ppl know you’re treating or reporting them as junk. This not only is great signal for advertisers to stop spamming me, but also let gmail know some account they have is sending out phishing emails (domain reputation is meaningless here).
  • dflock 2y ago
    Isn't that just a perfect way to train spammers, though? Keep sending to the server, get instant feedback, iterate until the spam gets delivered?
    • DoctorOetker 2y ago
      the spam filter algorithm can be provided with information on the number of attempts, and the explicit user intervention of marking something as spam, so what if the spammer learns they exhausted their attempts or user tolerance?
• pembrook 2y ago
  I would love to see some sane, email 2.0 standards like the author talks about. But, email is only decentralized in theory. In reality, email was fully captured a decade ago by a monopoly of 2 particular inbox providers. In consumer, Google has a defacto monopoly and runs the show. In B2B, Microsoft has a defacto monopoly and runs the show. Nothing can change without Google or Microsoft making the move first. And neither of these companies have any interest in changing/improving anything, given they already have a monopoly in their respective corner of the market. What we need first, is to lower switching costs to open up the market again. This could mean making DNS less of a nightmare so domain-based email becomes easy again. This could mean a government mandate that your email address (like a phone number) must be allowed easy transfer to other providers (Since Google owns the Gmail.com domain, they own your "phone number" in a sense). Etc. Etc. Imagine if Google and Microsoft owned your physical mailbox...and they decided what type of letters you could receive from who...and they sold ad-space in it. That's essentially what we've done with our digital mailboxes.
  • anon291 2y ago
    > What we need first, is a government mandate that your email address (like a phone number) must be allowed easy transfer to other providers. As long as Google owns the Gmail.com domain, they will be able to hold the entire network hostage. A mandate is perhaps heavy handed, but a statement that the government will no longer communicate via e-mail and only via protocol X would be appropriate. As for the email transfer... that would certainly have to be a new protocol. There is no mechanism to do anything of the sort today. the @... part literally means @ that server.
  • ivan_gammel 2y ago
    Enterprise and regulated communications can break any monopoly if the money/legislators agree that an alternative is better. Let’s say, EU issues a directive that certain types of communications must adhere some requirements which email v1 cannot implement. It will automatically create the market for email v2 and v1-to-v2 gateways. Or Salesforce and Meta agree on a new protocol for CRM comms, that brings more trust to email v2 campaigns, because SF can certify senders and Meta recipients.
  • 2y ago
• deleted 2y ago
  [deleted]
• upofadown 2y ago
  >Clients which implement MX2 can, optionally, have an updated encryption scheme to replace OpenPGP. That's entirely vague... >Something like Apple’s Contact Key Verification. So a key fingerprint? >Hopefully there would be forward secrecy this time. I for one would not want to delete all my email on receipt. Otherwise there is no point, the attacker gets the stored email when they get the private key if the email is still available to the user. Normally people keep their email indefinitely. I hope this is not a proposal to store email insecurely. Having said that, I have sometimes thought that it might be cool and maybe even useful to have a "Mission Impossible" style email type that would entirely delete itself after reading. I think this part of the proposal needs much work. A good first step would be to study the details of current encrypted email technical culture.
  • lxgr 2y ago
    Not just a fingerprint: A TOFU, upgradeable key exchange mechanism. That would be great for (some types of) email!
    • upofadown 2y ago
      How would it be different than a key fingerprint in practice? You don't have to check the fingerprint initially (TOFU).
• Animats 2y ago
  The usual checklist for anti-spam ideas applies.[1] Some minor fixes to implementations might help, though. - Mail forwarders and the SMTP server side of receiving servers should, when possible, forward immediately, making a connection to the next node while holding the incoming SMTP connection open. Pass back errors immediately as SMTP errors if at all possible. Phone to phone emails should be as fast as SMS. - Same for spam filtering. Reject at the SMTP level for invalid sender identification. Gradually tighten up on invalid sender identification. In general, reject and pass back errors to the sender rather than sending to a "junk" folder. This is useful for making the big services clean up their act. If Google's gmail sender gets a hard reject at the SMTP level for a lot of mails from a sender, they will probably do something to the sender. [1] https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wont-work-checklist/ https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wo...
  • newscracker 2y ago
    > Same for spam filtering. Reject at the SMTP level for invalid sender identification. This is what Posteo (posteo.de) does by default* instead of accepting emails and putting them in a Spam folder. [1] It checks for a few different things and rejects the mail if the spam criteria are met. In my limited experience, many mail server admins of large organizations don’t even look at these email rejections to take any action. The result is that the mails keep getting rejected and the receiver doesn’t even know the context or content (by design). * Posteo now has the option of accepting mail and putting it in the Spam folder too, if one desires this mode of operation. [1]: https://posteo.de/en/help/how-does-the-posteo-spam-filter-work https://posteo.de/en/help/how-does-the-posteo-spam-filter-wo...
    • Animats 2y ago
      Nice. That, plus the first item I mentioned, real-time forwarding, would mean that fails would show up immediately in your sending program, rather than a possible bounce message from a forwarder. Anything that can reject mail should work that way. The recipient's final IMAP server, which may have spam filtering, should also pass back rejections as SMTP statuses. So, if you get the "send completed" from your sending SMTP client, that should mean it's in the recipient's mailbox waiting to be read. This would improve the user experience for person-to-person email. This is completely backwards compatible, so it's quite do-able as an enhancement. Most email forwarders today are old and from the store-and-forward era, and from systems where opening large numbers of TCP connections was a problem. There's a sub-status for rejected spam: 550 5.7.1 Delivery not authorized, message refused That subcode list hasn't been changed since 2003. A few new codes would be useful. I'd suggest: 550 5.7.8 Message refused - spam 550 5.7.9 Message refused - not compliant with laws in recipient's region. (CAN-SPAM, etc.) 550 5.7.10 Message refused - phishing attempt / hostile code 550 5.7.11 Message refused - previous messages from same sender also refused Let the spam filters talk back that way to the delivery services. It would be useful if mail delivery services noted such statuses and gave the sender a spam strike. They don't have to pay attention to that info, but the better ones would.
• aeblyve 2y ago
  What if email was more stringently regulated by world governments? One can't code their way out of every situation.
  • pyrolistical 2y ago
    Unironically require gov id to send email?
• whoopdedo 2y ago
  Not addressed by the article is SMTP. Is there still a need for store-and-forward in the modern internet? I think that a lot of the current headaches with mail management are because receivers bear the cost. It made sense at a time when availability wasn't guaranteed. But server uptime now is much higher than it was in 1982. And although the original plan for email was that any machine could send a message to any other machine, it has since evolved into endpoints only ever connecting to a designated server. Rather than that server having to push all mail content around, it could hold the messages and post notifications to the destination, then release only after delivery has been accepted.
  • warkdarrior 2y ago
    This is just a convoluted way to arrive at the core problem: how does the recipient machine decide to accept a message delivery?
  • giantrobot 2y ago
    > It made sense at a time when availability wasn't guaranteed. It still isn't guaranteed. There's any number of reasons two MTAs can't talk to one another. Then there's more reasons an MTA can't talk to an MDA. > Rather than that server having to push all mail content around, it could hold the messages and post notifications to the destination, then release only after delivery has been accepted. IIRC this was one of the ideas behind Internet Mail 2000[0]. The open questions on that page are actually pretty good arguments against such a system. Not that e-mail is perfect but an open message sending system has a lot of important details to get right to work properly. [0] http://cr.yp.to/im2000.html http://cr.yp.to/im2000.html
• nickdothutton 2y ago
  As someone old enough to remember early 90s email, before wave after wave of noise and the myriad “solutions”, I find it hard to accept that we can’t do better and somehow discover email 2.0. Especially now there are so many other commonly used services/protocols for things that are “not email”. I can’t help but think that somehow recipient identify and preferences could form a part of it.
• phkahler 2y ago
  My main requirement is verification of the sender. One way to do that could be to send only a link to the message and have the receiver request the data from senders server. Then receiver could cut it off if the file is too big. (Maybe notify end user of the undelivered mail and they could retry if they're OK with it). Not sure how long a pending message should stay on the senders server. Another idea is to have the payload be a zip file. The end user could then have apps to process different content types. Only the "email" type would get processed by a traditional email client. Attachments would just go in a folder under the email message. Just thinking out loud. An authenticated asynchronous method of sending "stuff" including "email" messages.
  • lugu 2y ago
    It seems like great suggestions.
  • immibis 2y ago
    It's all internet-centric. You can't download from the sender if the sender is an onion service and you're getting the email through an onion-to-clearnet relay, even if the sender address is correct. And MIME is already like a zip file but different.
• matricaria 2y ago
  Why don’t we replace email with something like XMPP or Matrix? I think they solved most of those problems already and are easily self hosted.
  • Arathorn 2y ago
    Mail over Matrix would be amazing; you'd get PFS e2ee; reactions; edits; redactions etc for free... and be able to segue between longform and shortform chat and VoIP and calendaring etc. If the core team wasn't stuck focusing on the core project, I'd build this like a shot.
• ivan_gammel 2y ago
  A few things I would like in it personally: - different, more strict message structure and format replacing headers and parts (maybe some less verbose equivalent of XML) - signature as a separate part of the message that is never quoted (and more standard way to identify and attribute quotations in the text) - legal information as a separate part of the message (imprint, privacy policy, confidentiality and copyright notices etc) - privacy controls as part of the message (unsubscribe, GDPR disclosure/removal etc) - replace HTML with Unicode-based formatting that is equivalent of Markdown subset and is email-specific, to avoid any attempts to reuse renderers built for other purposes
  • jeroenhd 2y ago
    > - different, more strict message structure and format replacing headers and parts (maybe some less verbose equivalent of XML) Hard agree on that. Differences in header implementation is such a wide-spread problem with any kind of message forwarding program design, whether it's reverse HTTP proxies or chains of email middleware. > - signature as a separate part of the message that is never quoted (and more standard way to identify and attribute quotations in the text) I think this will inevitably lead to people accidentally mailing each other information they never intended to forward. I do agree that quotes and replies need better standardisation, but I don't think this is the solution. > - legal information as a separate part of the message (imprint, privacy policy, confidentiality and copyright notices etc) I can't say I see the need for this. Just a few links at the bottom are enough. > - privacy controls as part of the message (unsubscribe, GDPR disclosure/removal etc) There's already a standard unsubscribe header (https://www.ietf.org/rfc/rfc2369.txt https://www.ietf.org/rfc/rfc2369.txt has List-Unsubscribe, for instance). In my experience, it's only used by companies that have visible and simple opt-out links. In a new protocol, the remote side will probably just ignore the unsubscribe request. > - replace HTML with Unicode-based formatting that is equivalent of Markdown subset and is email-specific, to avoid any attempts to reuse renderers built for other purposes This would prevent any company doing marketing from using this standard. That also means sign-ups won't be supported, which will work against any adoption. People who want this can use text/plain in email already. You can even read most HTML email by telling your email client to view text/plain instead of text/html.
• EvanAnderson 2y ago
  > Send a real spam email? Block that domain when there’s complaints. What happens when the spam comes from gmail.com, outlook.com, or any of the other big cartel domains? Their domains can't be blocked without loss of functionality.
• talkingtab 2y ago
  "Self-hosted email is not very popular in part because of the complexity of the current email system, so between Microsoft, Google, Amazon, Zoho, GoDaddy, Gandhi, Wix, Squarespace, MailChimp, SparkPost, and SendGrid – you have most of the email market covered for the US; anyone not in the above list would quickly fold." In my opinion the last thing the world needs is a system that is so complex that only a few people can implement it. I would go farther and take the position that any email system that cannot be self-hosted is not worth the effort. I am much more interested in a conglomeration of selfhosters.
  • throwaway2037 2y ago
    This completely ignores the issue of trust, which explains why the market is so concentrated. In the current system, there are no financial penalties to spamming, like landline spam in Germany.
• pyrolistical 2y ago
  The only major problem with email is spam. Everything else are minor annoyances. I don’t see how MX2 will reduce spam. Banning domain isn’t going to work when they are cheap to obtain.
• Rudism 2y ago
  > If an email has a rich, HTML view; it should be required to come with a text-only, non-HTML copy of the body as well; for accessibility, compatibility, and privacy reasons. I can't imagine this working. The plain text section would probably something like "Upgrade your email client to view this message" 90% of the time and be completely pointless. Maybe it's an unpopular opinion but if I were rebooting email I'd forego HTML entirely and either say it's strictly plain-text, or use some Markdown-like formatting spec that looks fine even when viewed as plain text (email clients could provide WYSIWYG editors for less technically-inclined email authors). The evils of HTML in email (phishing, impersonating companies, and other scams) far outweigh the benefits (none, as far as I'm concerned).
  • chrisjj 2y ago
    > I'd forego HTML entirely and either say it's strictly plain-text Inferior to typical print media text richness would rightly get rejected by most users. > or use some Markdown-like formatting spec that looks fine even when viewed as plain text No rich format can "look fine" when reduced to plain text. Reason being that the reduction loses information that the sender relies upon the receiver seeing. > The evils of HTML in email (phishing, impersonating companies, Neither of those evils are specific to HTML.
  • swiftcoder 2y ago
    And exactly zero of the people who send marketing emails are going to adopt your plain text email replacement. In the year 2024 we ought to be able to format text and add images to our communications. For the folks who really want to RETVRN to the days of plain text, command line mail clients are still a thing.
    • withinboredom 2y ago
      My old marketing department would beg to differ. Plain text is easy, graphics and layout is hard. Further, all our emails were written in plain text first, then styled once we were 100% on the copy (so they could be sent off for translations in 20-odd languages).
    • 2y ago
• colordrops 2y ago
  This all sounds like a great proposal to fix some major problems with email, but it doesn't address the biggest issue. The reason these issues haven't been fixed is vendor lock-in. Making it "insanely difficult" to self-host is a feature, not a bug. Try migrating off of google or whatever your email provider is. You will find that you have 300 accounts that use email as your core identity provider. Getting locked out of your account is on par with having your house burned down. Email is a huge moat that these big companies are not going to let go of easily.
• ttul 2y ago
  I run one of the largest email sending services on the internet. I have been living the “mess” of internet email for over 20 years. Here’s the thing: despite the internet’s email system being complex and confusing and riddled with problems, it is universally adopted and interoperable. No other open communication tool can boast of email’s massive interoperability. Any new system will face the impossible burden of winning hearts and minds while the old system continues to chug along with billions of annual R&D spending and dozens of conferences full of smart people working on solving problems. Even if “MX2” can peacefully coexist in the DNS, why would anyone spend the millions of dollars in engineering effort to move while their teams are busy building the latest layer that’s been invented to patch over the current system? By all means if you want to propose a new email system, show up at IETF or M3AAWG and make a bold proposal. Someone will buy you a beer while they explain why you are much better off getting into the mud pit with the rest of us and working on the next pragmatic fix to keep things rolling along.
  • gjsman-1000 2y ago
    https://xkcd.com/2347/ https://xkcd.com/2347/
  • lxgr 2y ago
    I think it all depends on the right pitch: As a replacement for current email only, you're probably right in that nobody would care enough to do the significant investments necessary in a reasonable timeframe, similarly to IPv6 (and the pain there is arguably even greater than for email). As an alternative to something with the semantics of what companies currently use SMS for (i.e. having ostensibly higher reliability and security), I think you'd see a lot of interest.
  • deskr 2y ago
    > universally adopted and interoperable No. Big email server all over the place might drop your emails for whatever reason is and they won't tell you.
    • 1vuio0pswjnm7 2y ago
      Question is whether a new or updated protocol could force users such as "email providers" to change their behaviour. Here is something to downvote, a series of questions: What if email were "pickup only" _from the sender_. Not from some intermediary recipient, e.g., an "email provider". What if the the recipient had to identify acceptable senders before they could "send" mail to the recipient. Arguably this already happens every time an email recpient gives out their email address to some email sender. What if the sender did not "send" mail but instead uploaded it to host run by the sender and accessible by the recipient. Then the recipient retrieves the mail from the sender. In the past, one large email provider had an RSS feed for a user's inbox. What if the RSS feed is not provided by some third party "email provider" but by _senders_. What if the feed indicates whether there is new mail waiting to be retrieved by the recipient. Arguably, something like this already happens, albeit using third party intermediaries, for example as millions of people use non-public webpages on third party websites to communicate with each other, instead of using email. Recipients check these pages for comments or messages from "senders". A simpler idea that requires no changes to any email protocol, which I have tested successfully on home network, is for sender and recipient to be on a peer-to-peer overlay and run their own SMTP servers, like the original internet. The sender SMTP server communicates directly with the receiver's SMTP server, not a third party SMTP server run by an "email provider". Obviously, sender and receiver should not invite anyone onto this network who they do not know and from which they do not want to receive email. The fundamental problem with email is that personal, non-commercial email is mixed with commercial email, mail that is selling something. That's beneficial to marketers, but not email users. Any change to email that threatens to exclude the unsolicited, commercial email will be opposed fervently.
• kilburn 2y ago
  I couldn't resist.... Your post advocates a (x) technical ( ) legislative ( ) market-based ( ) vigilante approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.) ( ) Spammers can easily use it to harvest email addresses (x) Mailing lists and other legitimate email uses would be affected ( ) No one will be able to find the guy or collect the money (x) It is defenseless against brute force attacks ( ) It will stop spam for two weeks and then we'll be stuck with it ( ) Users of email will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it ( ) Requires too much cooperation from spammers ( ) Requires immediate total cooperation from everybody at once (x) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business Specifically, your plan fails to account for ( ) Laws expressly prohibiting it ( ) Lack of centrally controlling authority for email ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses ( ) Asshats ( ) Jurisdictional problems ( ) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money (x) Huge existing software investment in SMTP (x) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email (x) Armies of worm riddled broadband-connected Windows boxes ( ) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers ( ) Dishonesty on the part of spammers themselves (x) Bandwidth costs that are unaffected by client filtering (x) Outlook and the following philosophical objections may also apply: ( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable ( ) SMTP headers should not be the subject of legislation ( ) Blacklists suck ( ) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud ( ) Countermeasures should not involve sabotage of public networks (x) Countermeasures must work if phased in gradually ( ) Sending email should be free ( ) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses ( ) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough Furthermore, this is what I think about you: (x) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it. ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!
• rakoo 2y ago
  2nd-gen email exists in the form of xmpp. Reuse HTML constructs if you dare (https://xmpp.org/extensions/xep-0071.html https://xmpp.org/extensions/xep-0071.html) or use simpler, safer markup (https://xmpp.org/extensions/xep-0393.html https://xmpp.org/extensions/xep-0393.html). Sign and encrypt with omemo with the assurance it hasn't been mangled with. Use the SRV records registered for it. Define multiple alternative content types if you want (https://xmpp.org/extensions/xep-0481.html https://xmpp.org/extensions/xep-0481.html) It's all there for you to take and improve on without rewriting everything from scratch.
  • immibis 2y ago
    One thing I recently realized is how many protocols are basically the same but ended up in different fields of application by accident. SMTP can transfer arbitrary blocks of text data from a@b to x@y. Usenet can broadcast arbitrary blocks of text data with just a few mandatory headers, so why don't we use NNTP for blogging? You can put mails in your own outbox via IMAP, where the mail server can pick them up and send them. Why don't browsers load HTML via FTP? ActivityPub is basically SMTP if it was JSON (it's so much SMTP that it has a field for 'envelope sender' which was previously thought to be a specific quirk of SMTP), so why don't we use it for email? Or why don't we use SMTP for chatting? Actually, wait, Delta Chat literally does that. Or why don't we use XMPP for email? Or, I don't know, Apache Kafka or Redis. A Kafka server allows you to publish arbitrary messages and stores them until they're retrieved, which is also what a mail server or a chat server does. The only real difference is how authorization works. If you run IRC over Kafka, or IRC over NNTP, you won't lose messages when you disconnect - sounds pretty sensible. Actually what is the difference between NNTP and Apache Kafka, anyway? You get the idea...
    • rakoo 2y ago
      Totanly agreed. We as a profession do not learn what existed before, only what the latest are doing and it's tiring. We value creating instead of reusing and maintaining, as seen in the extreme in the evaluation process at Google. We have Show HN for brand new stuff and not Remember HN for past, proven technologies put back to use. As said eloquently by Lu (https://www.todepond.com/ https://www.todepond.com/): NO MORE IDEAS WE HAVE ENOUGH NO MORE TOOLS WE HAVE ENOUGH
• ralferoo 2y ago
  Some good ideas, but also stops short on a few things. * It talks about signing the message to prove the sender, but why stop there? We might as well extend it by having recipient public keys available via DNS records directly (or DNS specifying how to fetch them using some other protocol) and encrypting the contents of the e-mail as well. This alone could be the killer-app reason to adopt this thing. * As the recipient of spam, I don't really care so much whether the sender owns the domain or not, because it's relatively cheap and easy for them to buy a domain and set up DKIM/DMARC if they had to. What I really care about is only receiving e-mail that I have opted into receiving. Whilst there will always be a need for some people to have public mailboxes that anyone can send to, for the most people it'd be better to have something where you can only send a mail to them if you have a token that grants you that right. My mail client should be able to fetch the potential sender's public key and sign a token that says this key can send mail to me until this date. Maybe every time you reply to someone, you send out a new token with a longer window. Maybe you need your mail client to prompt you to re-issue tokens to people you've previously been in contact with. But the ability to choose to end the conversation further would be great. * Maybe for people who don't have a valid token to send to someone, there can be a way of requesting a token, maybe the sender's name, public key/address, a short sentence for justifciation and if the recipient agrees, then the sender can send the rest of the mail. * Mailing lists would get a bit more messy, as they'd have to re-sign and maybe re-encrypt every message. Maybe that's not a bad thing though, as with re-encrypted contents it'd be harder to correlate the same message sent to different people as the same, thus tying them to the same list. * As some other senders have said, I'm not sure full HTML is the answer. Markdown is better, because it would enable a client to unambiguously cut, quote and cite parts of the original. But people want all sorts of fancy formatting at times, so maybe we need a better markdown and/or restricted set of features. Most people also, don't really need all those colours etc, they just want something that's visually different to the rest of the conversation so you can tell who said what in a very jumbled thread. Maybe the markup should be required to identify which bits of copied content came from where. That said, getting critical mass of adoption is going to be hard, and there's not really any money to make from implementing it, only expense. The article correctly points out that something will only happen if it gets critical buy-in from all the big names, but of them probably only want to do it if they can get up controlling something and being the gatekeepers of the rest of the internet.
• MiscIdeaMaker99 2y ago
  I like what the author is saying, but I want everyone to keep in mind that how we send email is mutually exclusive from how we read/create email. You can solve issues related to one while not dealing at all with the other. For example, something I'd love to see is SMTP2. What can we do to improve SMTP and make it faster? Can we require TLS? Can we standardize and lockdown sender authentication? We wouldn't necessarily need to have a separate DNS records because it could be handled in a fashion similar to HTTP and HTTP2 and use the same ports. This new protocol could be tied to a new standardized email format, if that's what people wanted to do.
  • sangupta 2y ago
    Why not standardize on using HTTP3 using POST requests with JSON payload instead?
    • gjsman-1000 2y ago
      Heck, after writing this article, I’m wondering why email can’t be a standardized JSON-driven API implemented on a web server..:
      • sangupta 2y ago
        Just left this comment on your site. Would be much simpler to maintain, switch-to, and motivate for migration.
      • immibis 2y ago
        It could, but why change what isn't broken? Email messages are quite agnostic to how you deliver them, though. IIRC Google and Microsoft use a proprietary protocol with each other. Outlook uses a proprietary protocol with Exchange. Email used to be transferred through a non-internet packet-switched point-to-point network of intermittently connected dial-up links. The fact that the email messages are agnostic to how they're transmitted is actually very cool, because it enables switching to future technologies without any changes to the user agents, and vice versa. You put a file in your outbox and it magically appears in someone else's inbox later. Originally mail readers had to be executed on the mail server and read directly from your inbox directory, then we created new last-mile protocols so the reader could run on a separate computer (which in my understanding is basically identical to a Fidonet "point"). You can easily imagine a mail server connected to an onion router, or to Yggdrasil or some other meshnet, or even to whatever remnant of the original UUCP net someone is still running for fun. The current design enables this sort of thing.
• treflop 2y ago
  The problem with email isn't due to a technical problem with email. It's because: (1) there exists a messaging system where you can message anyone else in the world without prior contact and (2) it is an open standard anyone can implement. So even if you made Email2, it would have the same problems. People will violate any spec you write and Email2 will not fix that. Encryption isn't a thing because no one cares about it and Email2 will not make people care. The most complex part about email is email authentication (SPF, DKIM, DMARC) and trust but Email2 will still ultimately be have to be based on "how long you've been around" because email is not intrinsically linked to a real identity that has been licensed.
• hi-v-rocknroll 2y ago
  Much of this has been thought about and done already. - Multipart MIME has existed for 30+ years. https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html - HTML and CSS spec for email: https://www.caniemail.com https://www.caniemail.com - Redoing the world is a non-starter, it avoids compatibility and avoids solving problems that exist now and instead recreates the same problem all over again.
• tiffanyh 2y ago
  Isn’t WhatsApp/Slack/iMessage/etc the “2nd-gen email”.
• Floobergeist 2y ago
  [dead]
• dailykoder 2y ago
  >Some IP addresses are “cleaner” than other addresses All IP addresses are equal, but some addresses are more equal than others. - George Orwell
• quibuss 2y ago
  One of the security issues is the open headers. Would be nice to have a mail solution that handles headers like gossip.
• pif 2y ago
  > If an ancient, 20 year old email client, tries to send a message – it finds the MX record and sends the message just like normal. Maintaining back-compatibility: good! > From there, the email services which implement MX2 would publish a public date, on which all messages sent to them by the old MX record, will be automatically sent to Junk. And the idiocy kicks in two sentences later: IPv4/IPv6 anyone?
• pif 2y ago
  The biggest problem with this idea is that its major point is to make self-hosting mail servers a reality again: you will never move the masses for the wet dreams of a few of us nerds!
• lambdaone 2y ago
  I think the best analogy here might be WHATWG and HTML5. Instead of creating an entire new and expanded 'second system' (as the W3C was trying to do with XHTML), the existing major players in that field created something that was a much more strictly defined standard that was carefully to be forwards and backwards compatible with the existing mess, with well-defined behaviour for non-conformant content, and then started building on that new standard. The big players in email are now in the same situation as the big browser vendors. If they defined a strict subset of the existing body of de-facto email standards, critically with well-defined behaviour for non-conformant content, and then blessed that as email 2.0, they would then have something well-defined and workable to build on. This might include mandating a restricted subset of HTML5 for HTML content, a canonical transformation of that content to plain text for interoperability, mandating plain-text email as acceptable (perhaps with a canonical transformation to HTML) the use of SPF, DKIM etc with specified defaults, SMTP with specified features enabled, etc, etc. Then what is effetively a well-defined profile of traditional email becomes the new (forwards and largely backwards) well-defined email system, and we can all move forward from there. But to do that, there would need to be the will to create an email equivalent of WHATWG.
• wigster 2y ago
  maybe we need one penny email. just stop the spam would be a delight
• empath75 2y ago
  I don’t know that email is worth saving. I barely look at my inbox. It’s 90% spam and ads and the only functional use I get out of it is password resets and MFA. Just let it gradually die of neglect like newsgroups. It’s was built around the idea of lifting a communications paradigm from the physical world in exactly the same way that newsgroups were a riff on a message board. There’s all kinds of newer ways of organizing communication on line. We don’t have to try and recreate the experience of writing a letter on the internet any more.
  • throwaway2037 2y ago
    I use Gmail which accurately blocks 99% of spam for me. Have you tried it?
• markhahn 2y ago
  html, really? most email users I know don't give the first shit about html. email isn't fundamentally for marketing, and it's not a publishing format, so why any html at all? suppose the only markup available is \n...
• tamimio 2y ago
  > Last, but not least, there’s the inane juggling of IP reputation. Add domains TLD as well, some domains tld are rated less than others when it comes to spam filters.
• ChrisMarshallNY 2y ago
  One thing that jumped out at me: > countless surprise instances of legitimate emails going to Junk I think the definition of "legitimate" is in the eye of the beholder. Some folks believe that their "p3n15 extension" email is legit. Hard-core spam has wrecked the internet. There's a lot of money in it, so these moneyed people will find a way to bypass anything, because services will spring up, that will sell that. I have an email address that receives mail on 3 domains. Only one of them is "legit," so any email that comes in on the other two, is automatically spam-canned. Apple won't let me turn off the other two domains (me.com and icloud.com), so I have to set a rule in my client to can them. They get hundreds of spams (many are scams), each day. These are just the ones that passed the "low-hanging fruit" filters the email server does, so I assume that I actually get thousands each day. I was just talking to someone today, who got his PayPal account pwn3d; probably by following the directions in a well-crafted phishing email. These things work, so no one will stop doing it; especially since the cost is so low, and the ROI is pretty good. The only thing that is likely to stop the spam tsunami, is a cost to send. No one wants to do that.
  • juped 2y ago
    it's in the eye of the recipient and happens all the time for nonsensical reasons
    • ChrisMarshallNY 2y ago
      I agree, but people with money, like to argue otherwise. For some reason, folks like listening to people shuffling a handful of benjamins, more than the poor schlubs getting the spam.
• matheusmoreira 2y ago
  At this point I just want self-hosting to be possible. I can set up all the SPF, DKIM and DMARC nonsense and still be unable to deliver email. Those things don't actually matter, what matters is whether I'm part of the super special trusted IP club. It's 2024 and this supposedly federated system still doesn't allow me to self-host.
• johnklos 2y ago
  "anyone not in the above list would quickly fold" So... intentional and deliberate centralization of email? No, thank you. We already have plenty of proof that corporations cannot and will not do what's best for humankind, and would prefer to do specifically what's not best in order to leverage pain and strife to bolster themselves and/or to punish competitors. Interesting how later this is mentioned: "running your own self-hosted email stack would become much easier" So... the list is supposed to be of people and organizations that don't adopt MX2, and not a list of organizations that aren't "Microsoft, Google, Amazon, Zoho, GoDaddy, Gandhi, Wix, Squarespace, MailChimp, SparkPost, and SendGrid"? Specificity and clarity are good things. BTW - self-hosting email is not "insanely difficult". It's just difficult to get outgoing IPs that have a decent reputation. But it really doesn't even matter - anyone can self-host easily, and simply smarthost through a reputable provider. This makes self-hosting really not that hard at all.
• novok 2y ago
  While we are at it, making email that implements MX2 HIPPA, bank, etc compliant by default so medical/bank services can send you medical notifications and communications directly to your email instead of telling you to login to your account to see a message about your next doctors appointment or test result.