[HN Gopher] Thinking out loud about 2nd-gen email
___________________________________________________________________
Thinking out loud about 2nd-gen email
Author : gjsman-1000
Score : 185 points
Date : 2024-05-17 18:16 UTC (4 hours ago)
(HTM) web link (gabrielsieben.tech)
(TXT) w3m dump (gabrielsieben.tech)
| riffic wrote:
| 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
| striking wrote:
| 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 wrote:
| all I can say is IPv6 (and to qualify, IPv6 is great everyone
| should be using it).
| smeehee wrote:
| 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 wrote:
| 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 wrote:
| Yeah, backwards compatibility that you slowly frog boil
| people out of is definitely the most effective solution for
| something like this.
| jasode wrote:
| _> 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...
|
| 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.
| chuckadams wrote:
| Lindy's closed six years ago.
| sneak wrote:
| > _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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Why? The example of https coexisting with http was convincing.
| notatoad wrote:
| 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 wrote:
| 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.
| shortformblog wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dsr_ wrote:
| 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 wrote:
| > _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
| jcranmer wrote:
| > 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.
| hacker_homie wrote:
| 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 wrote:
| 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.
| chrismorgan wrote:
| You know what? We _had_ that. Markdown was modelled after
| it.
|
| I would also state that Markdown itself is completely
| unsuitable for the purpose. You'd need to design something
| new which _might_ look very similar to Markdown, but which
| would have basically no shared behaviour with even
| CommonMark as regards parsing, since you don't want HTML to
| be a thing. Markdown itself is _seriously_ compromised by
| its HTML basis.
|
| I can't actually think of a single comparatively-mainstream
| messenger that uses even a variant of Markdown; rather,
| they use their own lightweight markup languages
| <https://en.wikipedia.org/wiki/Lightweight_markup_language>
| that are very clearly incompatible with Markdown. (It's
| also _often_ a frontend editing feature that gets turned
| into something like HTML after that.)
| jcranmer wrote:
| text/enriched has been around for decades, and supports
| basic font styling (bold/italic/underline, color, font
| face, font size) and that's basically it.
|
| Actually, text/markdown exists as well. However, the
| definition of markdown syntax is, um, less than precise:
| https://daringfireball.net/projects/markdown/syntax (the
| text/markdown RFC literally has a parameter to indicate
| which flavor you meant by markdown!). And it incorporates
| HTML too, FWIW--legal HTML fragments are legal markdown as
| well. Honestly, markdown's million variants makes the HTML
| support landscape look uniform.
| chrismorgan wrote:
| Microsoft has done more damage to HTML email than everyone else
| put together. They've single-handedly held it back by at least
| ten years (maybe fifteen), and created tens or hundreds of
| thousands of jobs.
|
| In Outlook 97, they used the MSO renderer (Microsoft Word) for
| editing and presentation. It has an incomplete and buggy
| implementation of HTML 3.2.
|
| In Outlook 2000-2003, they did the obvious sensible thing:
| ditch that, and use MSHTML (Internet Explorer).
|
| In Outlook 2007, they switched _back_ to MSO, for reasons that
| never made a skerrick of sense to me (their explanation was
| vague nonsense that included the word "security", but the
| articles that discussed it vanished from the web long ago so I
| can't point you to any). I believe they still use the MSO
| renderer to this day. Windows Mail still embedded MSO. I
| _think_ that the new Outlook client they released last yearish?
| was _still_ using MSO, though I've heard claims to the contrary
| as well.
|
| The MSO component has had, I think, approximately _two_ changes
| in the last 28 years, one of which was supporting high DPI (...
| which it does imperfectly) and the other I forget.
|
| Since one of the major email clients is _still_ using a dodgy
| implementation of 1997 web standards, what incentive have other
| providers had for supporting newer stuff?
|
| We're _slowly_ getting places, but when you contrast it with
| the web's pace, in both backend and frontend (e.g. HTTPS
| deployment, and new CSS /HTML/JS features)--well, it's very
| obviously a _completely_ different environment.
| chuckadams wrote:
| They were embedding IE -- I imagine their security concerns
| were well-founded. But even gmail has crappy html support,
| and that runs in a friggin' browser!
| chrismorgan wrote:
| MSO probably had security problems _at least_ as large.
|
| And if there were security issues, they needed to fix them
| for IE's sake already!
|
| I don't remember the _details_ of what they wrote, and
| wasn't able to find it even five years ago, but I do
| remember that the reasons claimed just made _no_ sense.
| smeehee wrote:
| Fifth group here: HTML mail should never have been implemented.
| Better, never thought of in the first place.
| hacker_homie wrote:
| 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 wrote:
| 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 wrote:
| 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.)
| wooptoo wrote:
| I still hope to see text/markdown as an officially supported
| content type by email clients.
| Avamander wrote:
| I guess it could be added to something like Thunderbird.
| Would be really nice.
| citizenpaul wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| nradov wrote:
| What about it sucks? Seems fine to me as long as it's used as
| intended and not for other purposes.
| citizenpaul wrote:
| I don't personally think it sucks. There are bike-shed
| levels of improvements that probably any person on HN could
| dream up to make it more effective and work more reliably.
| TylerE wrote:
| Well, for a start, there is no way of knowing if a message
| I sent actually get delivered.
|
| Messages sometimes take minutes or even go up a to come
| through for no apparent reason what so ever.
|
| Massive spam issues. Headers are trivially forged
|
| People can sign up other peoples addresses to mailing
| lists, and if that 3rd party is a company, good luck not
| getting re-subscribed to random stuff for the rest of
| eternity.
| EvanAnderson wrote:
| > Well, for a start, there is no way of knowing if a
| message I sent actually get delivered.
|
| That's a feature. I don't want senders to know if their
| message was received without my explicit acknowledgement.
| dzhiurgis wrote:
| The only purpose it has for me for last decade is bills,
| invoices and all sort of similar transactional spam crap.
| TylerE wrote:
| Precisely. All actual communication (family, friends,
| etc) has moved to text, facebook messenger, etc, in large
| part because of how crappy email is/has gotten.
| nvy wrote:
| Only for spammers trying to get their marketing into my
| inbox.
|
| For personal use cases email is great.
| lxgr wrote:
| Email sucks, sure. But it sucks less than any of these
| alternatives:
|
| - Corporate support chats (no way to export/capture a
| papertrail as a customer, usually horribly brittle)
|
| - Proprietary/company-specific messaging solutions in my
| account on various sites (no notification channel for
| responses, often no papertrail for me either)
|
| - Contact forms (unidirectional, not standardized, no
| papertrail for me as a sender)
|
| - Push notifications (single-device only, no reasonable inbox
| management, headline-only)
|
| - SMS (just no on so many levels, most importantly that I
| don't want everything to be tied to my phone/phone plan and
| that I can't own my phone number in the same way that I can
| own a TLD)
|
| The EU (or Germany, I still haven't found out) mandates
| companies to have a support email address, and it's just so
| much more pleasant than the US pattern of providing only
| phone support, a horrible support chat experience, or a
| mailing address.
| karaterobot wrote:
| The person you're responding to is saying that email sucking
| is a feature _for the user_ , preventing them from being
| always at work. That making email like Slack would make it
| less appealing, and that's why nobody wants to replace it
| with something quote unquote better.
| byteknight wrote:
| While I understand the unspoken rules and norms of text
| messages, and chat messages are significantly different from
| email there is nothing prohibiting one from treating chat
| messages as asynchronous. You can train recipients the same you
| train a dog.
| graiz wrote:
| 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.
| chuckadams wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Email is not federated
|
| It is decentralized
| TylerE wrote:
| 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 wrote:
| "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?
| nephanth wrote:
| In whuch sense? Like my backend and my db communicate
| together, but they're both run by me, so arguably they
| don't correspond to that sentence
| kevindamm wrote:
| I think it's important to distinguish between application
| layer and lower layers of the stack here. For the lower
| layers (firmware updates for protocol changes
| notwithstanding) it is basically all federated, as you
| say. But at the application layer there are protocols
| that you can participate in just by knowing the protocol,
| and others which require knowing a secret or getting
| included in trusted peers or otherwise filtered to
| effectively make them proprietary and not federated.
| TylerE wrote:
| No?
|
| For a start, it wouldn't include virtually every online
| game, or any protocol that enforces user sign in, like
| Discord or MS Teams.
| wnevets wrote:
| HTTP is a protocol that allow servers to communicate with
| each other, regardless of who is running those servers.
| TylerE wrote:
| No. HTTP is Client/Server, not Server/Server.
| groestl wrote:
| My servers beg to differ.
| chuckadams wrote:
| Federation implies delegation from a central authority,
| which makes Mastodon and ActivityPub more "confederated"
| than anything. Inasmuch that MX records stem from the
| root servers, email is federated that way, but otherwise
| it's decentralized, with every MTA being its own
| authority. The line is fuzzy.
| azinman2 wrote:
| That's where its power comes in. We already have centralized
| communication systems.
| littlestymaar wrote:
| The problem isn't the federated nature, it's the combination
| of:
|
| - loose standardization, and lack of proper versioning
|
| - Postel's law, which is a recioe for disaster
|
| Takeaway if you want to design a federated protocol use a
| "the server chose violence" approach and reject any messages
| that is not perfectly compliant with the expected input for
| the given version (which must be part of the protocol
| itself).
| lxgr wrote:
| Basically every issue with purported email alternatives that
| various parties are trying to shove onto me (usually
| companies I need to communicate with for work or customer
| support purposes) is a direct result of them being non-
| federated, or that purported solution being SMS.
| Aloisius wrote:
| Content-Type isn't really an ambiguous case. It's invalid MIME
| - there can only be one Content-Type header in each part (RFC
| 2045 sec 3).
|
| The problem is, neither clients nor servers want to enforce it
| because users will complain.
| thecosas wrote:
| 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 wrote:
| 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 wrote:
| 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 :-)
| simmons wrote:
| 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 wrote:
| 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/
| gmuslera wrote:
| 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.
| jollyjerry wrote:
| 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.
| rcarmo wrote:
| 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 wrote:
| 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.
| rsync wrote:
| 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 wrote:
| You're describing new solutions like Stalwart and Maddy.
| Which try to automate away a significant portion of these
| issues and maintainability concerns.
| bradleybuda wrote:
| 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 wrote:
| Especially in Germany where it is either via letter or Telefax.
| hoyd wrote:
| What about Wave?
| AlienRobot wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| feature requests:
|
| - make unsubscribes work - make phishing harder
| azinman2 wrote:
| 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 wrote:
| 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?
| pembrook wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| nicklecompte wrote:
| > And neither of these companies have any interest in
| innovating
|
| I don't think this is true, or at least I think they have a
| strong interest in standardizing. Enterprise and personal users
| are routinely frustrated with Outlook and Gmail for dumb UI
| problems which are largely due to a lack of standardization.
| The only solution requires collective action. In addition, a
| well-written technical specification outsources a lot of
| difficult or highly specific questions to a committee of
| experts (kind of like how the C specification is an excellent
| technical manual, or K&R was a good de facto specification).
|
| Gmail and Outlook both have market lock-in on personal /
| business email because of how their email clients integrate
| with other personal / business software. (Gmail is also given a
| hand by rational consumer apathy; Gmail is fine and free,
| changing email addresses is a pain.) I don't think either
| company would gain or lose any competitive advantage by
| standardizing things around email itself. But it would probably
| reduce a lot of technical management headaches.
| upofadown wrote:
| >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 wrote:
| Not just a fingerprint: A TOFU, upgradeable key exchange
| mechanism. That would be great for (some types of) email!
| Animats wrote:
| 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-
| wo...
| aeblyve wrote:
| What if email was more stringently regulated by world
| governments? One can't code their way out of every situation.
| pyrolistical wrote:
| Unironically require gov id to send email?
| whoopdedo wrote:
| 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 wrote:
| This is just a convoluted way to arrive at the core problem:
| how does the recipient machine decide to accept a message
| delivery?
| giantrobot wrote:
| > 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
| nickdothutton wrote:
| 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 wrote:
| 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 wrote:
| It seems like great suggestions.
| matricaria wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > - 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 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.
| ivan_gammel wrote:
| > I think this will inevitably lead to people accidentally
| mailing each other information they never intended to
| forward.
|
| Why? A conforming client will just render the signature below
| the message as well as the other information (e.g. legal
| one).
|
| > I can't say I see the need for this
|
| Have you seen corporate email signatures in Germany? It's
| basically the demonstration of the lack of sense and lack of
| taste of some exec, often being more than a half of the
| message. People do need to be constrained here and relieved
| from signature design duty.
|
| > In a new protocol, the remote side will probably just
| ignore the unsubscribe request.
|
| Unless the standard will require digitally signed receipt in
| absence of which reputation of sender will suffer.
|
| > This would prevent any company doing marketing from using
| this standard.
|
| Not really. They will have more constraints for the design,
| but embedding vector graphics should be possible, just with
| some restrictions. There exist brilliant marketing emails
| with minimal formatting.
| EvanAnderson wrote:
| > 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 wrote:
| "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.
| pyrolistical wrote:
| 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 wrote:
| > 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).
| colordrops wrote:
| 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 wrote:
| 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 wrote:
| https://xkcd.com/2347/
| lxgr wrote:
| 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 wrote:
| > 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.
| kilburn wrote:
| Also, they would school them on actual-world problems in the
| process:
|
| - You can't wait until you receive the entire body to be able
| to compute a signature to then validate the sender as your
| first line of defense. It is just too expensive and opens you
| to DDOS attacks. People use IP reputation as a first line of
| defense because it is cheap, not because it is good.
|
| - You cannot enforce people's behavior through RFCs. I can
| assure you that random guy next desk will not care about your
| "this is a top-posting-thread" header and bottom post there.
| Even if she has to manually copy/paste things around.
|
| - Likewise, auto-generated plain-text versions of HTML (or
| other rich-text formats) are no better than what screen readers
| can achieve. Most poeple won't bother writing that alternate
| version, meaning the obligatory alt text is now less useful
| than when it was optional and only people who cared inculded
| it.
|
| - Your largest client may not update their e-mail
| infrastructure to comply with the latest standards. If that
| happens, you don't tell them to update or otherwise you won't
| be answering them because their e-mails go to spam. You do
| whatever is necessary to ensure that their e-mails _don 't_ go
| to spam. Business always comes first.
| gjsman-1000 wrote:
| Hypothetically, while I'm no expert:
|
| 1. Could a future protocol require an immediate initial
| message (a "hello") stating exactly how much content will be
| sent, and until the "hello" is sent, it's limited to, say,
| 128KB before the connection is immediately terminated? (And
| of course, if the content exceeds the declaration,
| termination and immediate IP temporary ban, safe to do as
| this is an obvious violation of a new spec?)
|
| 2. The goal is to make it easier for the email client which
| by itself will encourage good behavior. There's also no
| requirement for the messages to all be in one massive blob.
|
| 3. The goal is that it would be automatically created by the
| client. For personal emails, this is easy. For enhanced HTML
| emails, that is where the requirement comes in. Email
| providers can come up with their own ways of enforcement from
| there (I.e. "if it's only one sentence, you obviously didn't
| do it"), though I get your point and that would become messy
| unofficial spec again.
|
| 4. Could a future emails system have versioning, allowing the
| server to clearly communicate ("Hello, I implement MX2
| v3.1.")? In addition, a business can obviously make their own
| settings that original email alerts do not go to Junk in
| their business mailboxes - but they do know they'd better get
| on it or their messages to clients might go to Junk.
| kilburn wrote:
| 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 wrote:
| 2nd-gen email exists in the form of xmpp. Reuse HTML constructs
| if you dare (https://xmpp.org/extensions/xep-0071.html) or use
| simpler, safer markup
| (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) It's all there for
| you to take and improve on without rewriting everything from
| scratch.
| ralferoo wrote:
| 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 wrote:
| 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 wrote:
| Why not standardize on using HTTP3 using POST requests with
| JSON payload instead?
| gjsman-1000 wrote:
| Heck, after writing this article, I'm wondering why email
| can't be a standardized JSON-driven API implemented on a web
| server..:
| sangupta wrote:
| Just left this comment on your site. Would be much simpler
| to maintain, switch-to, and motivate for migration.
___________________________________________________________________
(page generated 2024-05-17 23:00 UTC)