[HN Gopher] Mnm - an open source project to replace email and SMTP
___________________________________________________________________
Mnm - an open source project to replace email and SMTP
Author : skinkestek
Score : 313 points
Date : 2021-01-16 19:48 UTC (1 days ago)
(HTM) web link (mnmnotmail.org)
(TXT) w3m dump (mnmnotmail.org)
| GekkePrutser wrote:
| Hmmmm...
|
| I think this is great and not great.
|
| Great because SMTP is completely broken. The lack of E2E
| encryption and sender authentication makes it completely useless
| these days. We're bogged down in workaround upon workaround to
| combat spamming/phishing and other abuse. Companies no longer
| rely on its security but instead just send an email to check
| their portals. We need something new.
|
| However the whole slideshows/surveys should be handled in the
| applications. We need a good protocol first.
| throwawaysea wrote:
| > The lack of E2E encryption and sender authentication makes it
| completely useless these days.
|
| Both SPF and DMARC provide sender authentication.
| GekkePrutser wrote:
| Well one issue with them is that they're totally optional.
| The protocol should have this built in. The way it is now is
| a kludge. Even mails from big companies still end up in my
| O365 junk box. I didn't check them in detail but something
| failed there. At the same time the spammers are actually
| pretty good at avoiding spam filters.
|
| Also, they don't really provide sender authentication. They
| provide sending domain->sending server verification. If you
| have a business that uses the same email provider, you will
| be able to fake sender auth if you can convince the server to
| send it. This is why it's a kludge.
|
| If we'd require emails to be signed by default this issue
| wouldn't be present.
|
| What I really miss these days is public protocol innovation.
| In the old days if a protocol stopped meeting the needs,
| people would go back to the drawing board and publish and
| agree a new RFC. These days we just tack on workarounds to
| old protocols without fixing the root issues, or we switch to
| closed alternatives (like what has happened to IM) which is
| even worse.
| dane-pgp wrote:
| > Well one issue with them is that they're totally
| optional.
|
| So is every proposed replacement for SMTP.
| GekkePrutser wrote:
| True, but at least it would have those things
| incorporated in it. So you don't have different versions
| with and without.
|
| I would imagine it would gather uptake pretty quickly.
| Just like other protocols which have advanced. Like SSH
| v2, nobody uses v1 anymore.
| zimpenfish wrote:
| I thought SPF was more "this email is allowed to come from
| these hosts" authentication which tells you nothing about the
| sender (to me, at least) other than "they used an approved
| host"?
| nobody9999 wrote:
| > > The lack of E2E encryption and sender authentication
| makes it completely useless these days.
|
| >Both SPF and DMARC provide sender authentication.
|
| And TLS encryption via _required_ encryption via
| STARTTLS[0][1] plus s /mime or gpg _can_ provide E2EE.
|
| Not sure if mnm/tmtp supports endpoint data encryption
| though.
|
| [0] https://en.wikipedia.org/wiki/Email_encryption
|
| [1] https://tools.ietf.org/html/rfc8314
| GekkePrutser wrote:
| The problem is that s/mime and gpg are too complex for end
| users. Especially the key management, the encryption itself
| is not the issue.
|
| s/mime is expensive in terms of certificates and difficult
| to set up. GPG's trust chain based on key signing parties
| has never taken off outside the crypto geek community
| (Don't get me wrong, I'm one too!)
|
| Perhaps a "let's encrypt" approach to s/mime could work
| though. I could see that happening. It would indeed solve a
| lot of issues.
| nobody9999 wrote:
| You make very good points.
|
| Corporate environments generally have an easier time with
| s/mime, and IIUC this app is focused on corporate
| environments.
|
| GPG is nice (I like a lot and have used it for a very
| long time), but it's certainly niche.
|
| That said, I included s/mime and gpg to illustrate that
| end to end encryption is not only possible, but that
| mature, functional tools are available in an
| SMTP+extensions environment.
|
| It would be interesting to know _how_ mnm /TMTP does
| encryption. I'd assume it uses TLS for transport. As for
| endpoint and server storage encryption (assuming it does
| that at all), you'd hope they'd use some sort of
| asymmetric key encryption, which raises the same issues
| as s/mime and gpg.
| upofadown wrote:
| >The lack of E2E encryption and sender authentication makes it
| completely useless these days.
|
| The elephant in the room here is that there is nothing wrong
| with, say, PGP. Any meaningful approach using public key
| crytography and crytopgraphic signatures to achieve
| confidentiality and authentication over SMTP ends up with the
| conclusion that you could of just used the OpenPGP protocol.
|
| I think the reason we like to think that there is some new
| method available that will finally make things work is the hope
| there is a purely technological solution available. After 30
| years of failing to come up with such a solution it is clear
| that there is no such solution possible in isolation.
| md_ wrote:
| PGP is incompatible with both forward secrecy and metadata
| secrecy.
|
| If you only want to keep your message body confidential (or
| authenticated), PGP is reasonable. But it provides a strictly
| lesser degree of secrecy than modern e2ee messaging
| applications.
|
| In fact, depending on your threat model, modern SMTP-TLS
| (which is not e2ee, but does provide some metadata
| confidentiality and forward secrecy) may in fact be an
| improvement over PGP.
| iggldiggl wrote:
| Another thing is that e2ee breaks a number of useful
| features of e-mail:
|
| - The ability to painlessly access your mail from a number
| of different clients, ranging from fully-featured desktop
| clients to smartphone apps to webmail.
|
| - Server-side filtering (both spam and in general)
|
| - Server-side searching (mandatory for webmail and
| depending on how big your mail archive is, still rather
| useful for smartphones, too)
| upofadown wrote:
| >Server-side searching
|
| Pretty sure that is what the unencrypted "Subject:" is
| for... :)
|
| There is now a way to encrypt the subject but it is
| turning out to be a controversial thing to do. Perhaps
| that is at least partially the reason.
| upofadown wrote:
| Forward secrecy isn't really an issue with email. There are
| few that would be willing to delete their emails after
| reading them. Keeping old messages around for all practical
| purposes negates the value of forward secrecy. Most people
| like to keep their old messages in an easily accessible
| form so forward secrecy is not very important for messaging
| in general.
|
| >...metadata secrecy...
|
| This is not a huge problem with a medium like email where
| you can be more or less anonymous. Contrast with things
| like instant messengers that insist on a phone number.
|
| >But it provides a strictly lesser degree of secrecy than
| modern e2ee messaging applications.
|
| Most of those applications take the form of instant
| messengers. Since such things by necessity have to leave
| the private key material exposed all the time they are
| generally less secure than something like encrypted email
| where that key material can be kept very locked down.
|
| >...modern SMTP-TLS (which is not e2ee, but does provide
| some metadata confidentiality and forward secrecy) may in
| fact be an improvement over PGP.
|
| True enough. SMTP-TLS does provide even more security to
| the encrypted email user. Most importantly, it prevents
| passive listeners from detecting that an email was
| encrypted and thus worthy of further interest.
|
| I can't help but point out that this sort of discussion is
| an excellent example of the state of denial that exists
| with respect to end to end encrypted messaging these days.
| Rather than addressing the broader overall issues we are
| quibbling about obscure technical details.
| GekkePrutser wrote:
| E2E with forward secrecy was not possible in the past
| because email was an offline thing. You can't do PFS
| without a live connection between the endpoints.
|
| However, these days this should be less of an issue in an
| ever connected world. Nobody uses UUCP or batched SMTP
| anymore :)
| md_ wrote:
| Which details? :)
|
| E2ee messaging is used by billions. Without talking
| details, it's hard to know what about the status quo we
| wish to improve.
| eeZah7Ux wrote:
| metadata are leaked by mnm, activitypub, xmpp, matrix & so
| on
| LockAndLol wrote:
| I honestly think we shouldn't be writing a new protocol to
| replace email but repurposing an existing, safe protocol like
| Signal's protocol and writing an app that looks like an email
| app.
|
| Not only would it liberate Signal from centralization and make it
| federated, it would provide all the benefits of the protocol and
| whatever benefits people believe email have. Signal staff is
| already working on getting rid on removing the phone number
| requirement.
|
| Another candidate could be the matrix protocol. I would really
| appreciate getting rid of email altogether. It's clunky and old.
| Aachen wrote:
| So what is the actual design? How is it different from SMTP or
| other comparable protocols or products? The page tells me it's
| meant to replace email, it binds together features like charts
| into this smtp replacement (don't quite get why one needs to have
| anything to do with the other), and then tells me where I can
| download it. The only link to a design spec goes to a Github repo
| with 1 issue namely "todo: design docs".
|
| What's here to see if not that? I'm not going to spend hours on
| installing, running and testing software when I don't even
| conceptually know how it works. It's like linking a download page
| for yet another instant messenger, saying it'll have certain high
| level features, but not how the design will be better than the
| existing messaging services. Why should I install that?
|
| I'd love to read about a concrete design that could fix (some of)
| email/smtp's problems and get invested in the idea and run a
| server of my own etc., in that order, but not spend hours
| investigating something with a 95% chance of not being better in
| the first place.
| networkimprov wrote:
| See link to "simple protocol" in first sentence of homepage,
| and link "Why TMTP?" after goals.
| networkimprov wrote:
| Author here. Sorry to be late to the party. AMA.
|
| Follow mnm! https://twitter.com/mnmnotmail
|
| To address some comments...
|
| The protocol[1] has two layers, altho that's not emphasized in
| the draft. The outer layer covers posting messages for
| recipients. The inner layer describes message contents, and isn't
| enforced by the server (see protocol #7 Post //datahead segment).
| You can do special-purpose apps with the outer layer without
| supporting the inner if you don't send messages to normal
| clients.
|
| EDIT: The protocol will see many more revisions (some already
| planned), and real-world use, before it's proposed to a standards
| body.
|
| This isn't a drop-in/swap-out replacement for email. It's a (far)
| better way of doing electronic correspondence. It will take some
| years to build the community and infrastructure necessary for
| TMTP to widely supplant SMTP. It's been suggested recently that I
| draft an architecture doc for TMTP[2], which will also discuss
| infrastructure.
|
| Part of that infrastructure involves "marketplace" sites which
| verify members' real-life identities and let people make contact
| with folks outside their normal circles (e.g. work, school,
| community, hobbies/interests). Most professional organizations
| would run marketplace sites for their members.
|
| I gather that the IETF has (repeatedly) stated that it is not
| interested in adjusting SMTP to solve "the spam problem". [3]
|
| Re end-to-end encryption, that can be considered for the inner
| layer protocol. I don't rule it out, but it's not a priority at
| present.
|
| If successful, "mnm" won't be the only implementation of TMTP.
| Maybe some other client will have a better name. (OTOH, Slack did
| well, and that's a pretty terrible name for a workplace tool ;-)
|
| EDIT2: SMTP and related protocols have no effective defense
| against phishing. A large fraction of phishing attempts originate
| at authenticated domains, like Gmail.
|
| ---
|
| [1] https://github.com/networkimprov/mnm/blob/master/Protocol.md
|
| [2] https://github.com/networkimprov/mnm/issues/5
|
| [3] https://www.rhyolite.com/anti-spam/you-might-be.html
| networkimprov wrote:
| @DANG could you push this group to the top of the comments, so
| ppl see answers to FAQs? Thanks!
| leshokunin wrote:
| Interesting idea! I think we could use Mailscript to bridge Mnm
| with email. Would you be interested?
| networkimprov wrote:
| What should I read about Mailscript?
| leshokunin wrote:
| You can see more at Mailscript.com. Check out
| docs.mailscript.com and api.mailscript.com to get started.
|
| Happy to chat any time. I'm Shokunin@mailscript.com
| anticensor wrote:
| Why TMTP and not MQTT? The latter is a general purpose
| messaging protocol too.
| petre wrote:
| Because one shouldn't subscribe to mail but rather get it?
| md_ wrote:
| IETF isn't disinterested in solving the spam problem. If that
| were true, why would they have published multiple RFCs to fight
| spam?
| nickik wrote:
| Matrix basically does everything you would possibly want from
| such a system and it does much more on top of it, like e2e
| encryption.
|
| Its based around the simple HTTP and JSON transports and its well
| standardized.
|
| What am I missing?
| Whiteshadow12 wrote:
| Dropbox history on HN gave us a lens on how comments here are not
| true reflections of what could happen, as well as give every
| would be project the best clock, "what if we are the next
| Dropbox". Super fascinating.
| jbverschoor wrote:
| Well, I instantly knew Dropbox would be a hit. At least for me
| juniperplant wrote:
| Kind of disappointed in not seeing end-to-end encryption being
| mentioned?
|
| I thought it was perceived as one of the fundamental flaws of
| email.
| networkimprov wrote:
| Addressed here:
| https://news.ycombinator.com/item?id=25804869#25807379
| Aachen wrote:
| No it's not. I found two dismissive lines somewhere towards
| the end of you link. That's not addressing it at length
| somewhere worth clicking towards.
|
| Saving others a click:
|
| > Re end-to-end encryption, that can be considered for the
| inner layer protocol. I don't rule it out, but it's not a
| priority at present.
| eeZah7Ux wrote:
| ...not to mention the leaking of metadata.
| based2 wrote:
| https://github.com/networkimprov/mnm/issues/5 create TMTP
| architecture doc
| inopinatus wrote:
| Those who have not read https://craphound.com/spamsolutions.txt
| are doomed to repeat it.
| 0xbadcafebee wrote:
| They lost me at "weird JSON header followed possibly by arbitrary
| 8 bit data". The rest of the protocol is kind of crazy too.
| FiveNinjas wrote:
| took me way too long to find out that the T in TMTP stood for
| Trusted.
|
| I was looking for protocol descriptions in how this could work.
| Author said people would be more impressed by code - but I think
| a protocol spec along with a reference implementation would be
| useful.
|
| So... what in this proposal isn't fulfilled by a private walled
| message platform such as Whatsapp, or Signal, or Facebook
| Messenger? Nothing here needs this to be 'email'.
|
| And if you're into adding trusted layers with revocation to
| email, well we have DKIM, client certs, encryption. You can do
| the 'trusted' enforceability at the application level over the
| untrusted SMTP network level.
|
| All in, probably DOA as an idea.
| networkimprov wrote:
| If widely adopted, most TMTP clients would have concurrent
| logins to many servers at different sites. Your traffic isn't
| routed via a middleman like Facebook which everyone needs to
| join, and which scans your content for advertising purposes.
|
| I've implemented both client and server, so there's the basis
| for a "reference implementation".
|
| More here:
| https://news.ycombinator.com/item?id=25804869#25807379
|
| (I'm the author.)
| als0 wrote:
| Just been thinking that it's bad to use 'trusted' in an
| acronym. Not only is it subjective but it will also not stand
| well over time. Just like how NG is avoided.
| nobody9999 wrote:
| >I was looking for protocol descriptions in how this could
| work. Author said people would be more impressed by code - but
| I think a protocol spec along with a reference implementation
| would be useful.
|
| I went and looked for a protocol spec as well. When I didn't
| see anything concrete on the site in the submission title, I
| poked around the comments a bit more and found a link to the
| Github issue[0] requesting detail with respect to the
| architecture of the TMTP protocol.
|
| I further poked around in the appropriate places[1] but found
| nothing remotely related.
|
| The protocol spec[2], while useful in defining the control
| mechanisms and message formats is vague or silent when it comes
| to a variety (too many to list completely here) of functional,
| operational and implementation issues.
|
| A comparison of TMTP's spec with SMTP[3] ("the protocol at the
| root of all these problems"[2] with messaging), is quite
| illuminating.
|
| While SMTP by itself lacks a variety of features, it provides a
| robust, interoperable architecture that's broadly supported and
| has been augmented repeatedly by other protocols (e.g., MIME,
| DMARC/DKIM, SMTP-AUTH, LDAP, etc.) to provide such features.
|
| It's not clear to me that mnm/TMTP has been fleshed out enough
| to provide a real alternative to SMTP+extensions. Rather, it
| appears to be another (there are many) client/server messaging
| application that's not interoperable.
|
| Should these issues be addressed, discussed and refined in the
| appropriate forums[4], It's possible that TMTP could turn out
| to be a viable replacement for SMTP.
|
| I applaud the authors' work and hope they have much success
| with their entry in the messaging app market.
|
| [0] https://github.com/networkimprov/mnm/issues/5
|
| [1] https://www.ietf.org
|
| [2] https://mnmnotmail.org/rationale.html
|
| [3] https://tools.ietf.org/rfc/rfc5321.txt
|
| [4] https://www.ietf.org/how/wgs/
|
| Edit: Fixed links.
| networkimprov wrote:
| The protocol draft:
| https://github.com/networkimprov/mnm/blob/master/Protocol.md
|
| And yes, TMTP will see a lot more revision, and real-world
| use, before it's proposed to any standards body.
|
| (I'm the author.)
| nobody9999 wrote:
| Thanks for the response.
|
| Yes. That was the document I was talking about, but I
| linked the wrong page.
|
| My apologies for any confusion.
| xwdv wrote:
| I wonder if people in 10 years from now will come back here to
| see the beginning of the project that replaced email.
| knorker wrote:
| Just like with Wave.
| reitanqild wrote:
| This one has the benefit of not being owned/backed by a
| company that must be one of the biggest quitters of all time
| ;-)
| gm wrote:
| The road of tech is littered with the bodies of email
| replacements.
|
| Some of them went on to thrive, but not as email replacements:
| Slack for one.
| greatgirl wrote:
| Most hard problems are not solved simply by creating a
| technically superior product, they are often unsolvable due to
| mundane factors like user adoption, distribution, financial
| issues, server issues, etc.
| GNU_James wrote:
| I'll stick to regular email till I'm dead. Thanks.
| networkimprov wrote:
| A killer phish will get you sooner than later :-)
| gm wrote:
| It looks great, but there's zero chance I'm going to replace my
| current SMTP with a new protocol no one (yet) uses. If there's a
| bug in all of this it's in laying out very clearly how to ease
| into this. Especially in a world of hosted email providers where
| everyone is using Exchange, Google Email, and even cPanel to host
| email for organizations, and none of them have a big incentive to
| support this.
|
| EDIT: On thinking about it, I'd think this would have more
| chances if they phrased it as an augmentation of email's
| capabilities rather than an email killer.
| networkimprov wrote:
| Yes, I need to write an architecture/roadmap doc.
|
| Also addressed here:
| https://news.ycombinator.com/item?id=25804869#25807379
| [deleted]
| samstave wrote:
| also, is SLS or E2EE an option?
|
| Why not a proxy through Signal as an option...?
| user3939382 wrote:
| The way to accomplish the change is to propose upgraded
| versions of SMTP, IMAP, et al that are backwards compatible
| with existing protocol versions. This way the infrastructure
| can update incrementally. If both clients in an email exchange
| and all the servers they're using in between support the new
| versions you get the features. iMessage manages this pretty
| well.
| throwawaysea wrote:
| This is already the case for encrypted transport of email and
| is how email has been evolving all this time.
| livre wrote:
| Another alternative is to support cross communication between
| email and this new protocol until it has enough users that
| supporting email stops being a priority. Then start offering
| new installations with email compatibility off by default
| until the majority of the users are on the new protocol, then
| keep email support only on lts releases and finally remove
| email completely. This way you avoid having to carry the
| baggage of email forever and having to support an old
| protocol full of backwards compatibility hacks. This is all
| in theory, in practice I doubt this will ever get close to
| replacing email.
| chrisandchris wrote:
| That works pretty well for IPv6, doesn't it (actually, it
| does not)?
|
| The problem with that approach is that as long as 0.01%
| still uses the old protocol, you can't get rid of it. And
| then you have a bag with the old and new protocol and maybe
| after 20 years you realize it's going to take another X
| years until you have at least some relevant adoption, as
| demonstrated with IPv6.
|
| If one is ever going to ,,replace" email it happens on top
| of the existing protocols and not as a replacement.
| livre wrote:
| You make a great point. A very popular protocol or
| standard is never fully replaced. Either it continues
| existing next to the new thing (IPv4/IPv6) or gets an
| update while still having to deal with backwards compat
| (HTML, CSS). Whatever the case is we'll still be dealing
| with email in 20-30 years from now.
| 0df8dkdf wrote:
| I would recommend checking out wildduck
| https://wildduck.email,
|
| It is backward compatible, smtp, imap, pop3 and support
| unicode email as well, and it is REST API callable. So you
| can receive and send email.
| ianai wrote:
| Na. We're talking about adding a protocol to a list of a
| handful which people use regularly. What you just said sounds
| like something I would have heard in the 90s about using
| email for legitimate purposes. Why do we need email when we
| have fax? (Granted fax still exists, but it's no email
| killer.)
|
| This sort of thing could be deployed by people in addition to
| the other services. For a while and perhaps a long while
| it'll be fringe. But if there's enough utility to it then it
| may just catch on.
| EricMausler wrote:
| If support for both is going to be part of the plan, I do
| not suggest planning to drop support for email. Commit to
| supporting both or dont
| mortenjorck wrote:
| There are two key requirements for anything that would
| actually supplant email:
|
| 1. Call the protocol "Email 2"
|
| 2. Build something that actually justifies the name
|
| I'm only half joking; the messaging _around_ the protocol is
| almost as important as the protocol itself. iMessage is a
| good example of how to expose something like "Email 2" to
| the end user: as a seamless upgrade, indicated by a subtle UI
| element, when a client happens to negotiate the upgraded
| protocol with the server.
|
| Enabling incremental upgrades to infrastructure is critical,
| but strict backward-compatibility isn't necessarily so. As
| long as the architecture of the new protocol makes falling
| back to IMAP/SMTP straightforward when an upgraded client or
| server isn't available, Email 2 doesn't have to be able to
| talk directly to legacy.
|
| There's certainly a chicken-and-egg problem in driving enough
| server adoption to get client vendors to add support while
| driving enough client adoption to get server operators on
| board, but there's probably a sweet spot between making a
| clean enough break with legacy tech that it's more
| straightforward to implement, while making it _conceptually_
| similar enough that it can still plug into the same patterns.
| otabdeveloper4 wrote:
| The target audience of this uses Microsoft Exchange, not "email
| and SMTP" anyways.
| onebot wrote:
| This was what Lotus Notes was to be. Maybe not open source, but a
| reach communications platform.
| throwawaysea wrote:
| Email is fine and has a place in the array of digital
| communication choices we have available. If you don't like email
| you can always use a private communication format instead and
| have your safe walled garden. But a federated, openly addressable
| protocol is important to retain. Email can also be made
| reasonably secure - with SPF, DMARC, more secure DNS, and other
| evolutionary changes. But I don't get the purpose of this project
| in trying to attack the foundational motivations for email to
| exist.
| iovrthoughtthis wrote:
| I'm not sure why everyone always tries to replace email with
| better messaging as if messaging was email's killer feature.
|
| The reason I first got an email address was to get a Runescape
| account. Email's killer feature on the modern internet is
| identity management. On most sites it's impossible to create an
| identity without one.
| networkimprov wrote:
| There's no inherent reason to have an identity separate from
| the one the site you're joining grants you.
|
| I'd guess that site is leveraging the effort which webmail
| providers spend to weed out bots and sock-puppets. And perhaps
| they use the address for adtech purposes. But I don't know for
| sure.
|
| I'd love to hear from such sites about how they use customer
| email. If it's not primarily for communication, it may not make
| sense to accommodate it in TMTP.
| doctorfoo wrote:
| For password reset?
| iovrthoughtthis wrote:
| > There's no inherent reason to have an identity separate
| from the one the site you're joining grants you.
|
| What do you mean?
|
| > I'd guess that site is leveraging the effort which webmail
| providers spend to weed out bots and sock-puppets. And
| perhaps they use the address for adtech purposes. But I don't
| know for sure.
|
| It's a lot like having a physical address which is used as a
| core part of meatspace identity management.
|
| > I'd love to hear from such sites about how they use
| customer email. If it's not primarily for communication, it
| may not make sense to accommodate it in TMTP.
|
| A shared unique identifier (value for user is that it is
| consistent across services).
|
| A means of authentication when primary auth (password) cant
| be used (company sends links etc).
|
| 1-1 channel of communication (notifications of activity or
| changes in a service).
|
| Obviously, it's just my opinion, but making a new messaging
| protocol won't fix email. My hunch is that is because email's
| primary purpose (to the end user) is not to provide a
| messaging channel but to provide an identity.
| m___ wrote:
| Is there anything here that ssh protocol and derivatives, sshfs,
| scp, sftp, and then VPNs cannot do,
|
| It seems an ill defined approach to protocol, mixing idiot proof
| user interfaces with the former. The license??? Looks and feels
| like another pair of sneekers. The functionality is all
| surrounding us, the innards (protocol), are many that can comply
| with the white-paper.
| anaganisk wrote:
| Yeah, please do come back with your comment, when a regular
| babushka can ssh into her server in AWS, and run all the hell
| you mentioned. I dont understand people who think every thing
| is designed with developers in mind. Not everyone is a GNU GPL
| C++ cruching desktop junkie.
| alisaus2 wrote:
| Top burny busty chicks only on this site! Follow the link, and
| you won't be sorry! - https://adultlove.life
| superkuh wrote:
| It's cool but what I really want, what I'd trade almost anything
| for, is an all-in-one smtp+dkim+imap mailserver binary written in
| a non-meme language.
| jagger27 wrote:
| Go isn't a meme language.
| tacon wrote:
| I have been running my own mail server since the 1980s, using
| Debian/exim4 for the last eight years. With the weird patches
| for greylisting, etc., I never wanted to update it. In the last
| week, I jumped to docker-mailserver[0]. O.M.G. That is too
| easy! Yes, there is picking one's way through the options at
| first, but those go in a tiny config file and survive updates.
| The heavy lifting is all in one container. I just use it as a
| mail gateway, into a local machine that has port 25 filtered,
| but I played a bit with the imap functions, too. You do have to
| have a box somewhere that can run containers, which for me is a
| KVM VPS.
|
| Gmail instantly was happy with my inbound emails. I got on a
| backscatter blacklist because I didn't immediately drop invalid
| email addresses at the gateway, but that will time out shortly.
| And just as I had settled in with the new server, I got to test
| the update function. This week the entire docker-mailserver
| project moved to a new repo name on Github, with a new release.
| A couple of the config files changed names, but nothing much in
| contents. A docker pull for the new image name, and my mail
| server was running the fresh release. Happy, happy, happy.
|
| [0] https://github.com/docker-mailserver/docker-mailserver
| gm wrote:
| Why would a market care about the language a product's written
| at? Maybe only programmers, and anal retentive ones at that.
| bee_rider wrote:
| I wouldn't want to depend on some open source project in an
| obscure language because it will likely get fewer
| contributors. But go isn't some obscure language.
| Proven wrote:
| You won't get to depend on it if it has few contributors.
| pozzen wrote:
| Like Maddy? https://foxcpp.dev/maddy/
| superkuh wrote:
| Yes. Exactly like Maddy except not in Go.
| hactually wrote:
| So non meme language and not Go?
|
| What languages are acceptable then? You may need to provide
| a definition to prevent confusion.
| superkuh wrote:
| I mean languages that have been in existence for more
| than a decade and aren't controlled by a single
| corporation.
| t0astbread wrote:
| Go has existed for 11 years. It's probably safe to say
| that it won't die off soon. As for the control part: What
| could Google do to Go that would affect you as a user of
| some software written in it?
| brian_herman wrote:
| I would rather use something like https://jmap.io/
| networkimprov wrote:
| JMAP is an extension of the email protocol stack; it's
| fundamentally different than TMTP.
|
| (I'm the author of mnm.)
| pmlnr wrote:
| Don't try to "replace" email, ever. Build, name it is a X, just
| not as "to replace email", because by doing that, it's DoA.
| ddingus wrote:
| This!
|
| People do not want email replaced. They may want a new thing
| enough to use it in huge numbers.
|
| And then that thing has to endure long enough, be open enough
| to see even a modest level of trust email has at this point.
| networkimprov wrote:
| Try to stop me :-)
|
| Also addressed here:
| https://news.ycombinator.com/item?id=25804869#25807379
|
| (I'm the author.)
| ajsnigrutin wrote:
| Yup!
|
| There are many, many protocols for exchanging messages, chats,
| files, etc. (basically, what e-mail does), they all come, get
| some traction, last for two years, then die (except maybe irc,
| but except for a few nerds, it's hard to get anyone on there
| anymore). Some get killed by google, some just get replaced by
| "the next new thing"... but e-mail still lives, and works, and
| does what is needed.
| almaember wrote:
| > except maybe irc, but except for a few nerds, it's hard to
| get anyone on there anymore
|
| Well IRC isn't really meant to be used for persistent
| communication anyway
| GekkePrutser wrote:
| It doesn't do what's needed. It provides a channel for spam,
| insecure delivery etc. It's too broken. We do really need a
| new email.
| ruslan wrote:
| We do not need new email. We need a way to authorize
| messages sent and also a way to enburden senders for the
| content they send. In pre-internet era UUCP was widely used
| to deliver messages, UUCP providers used to charged their
| customers for each message they sent which made spam
| broadcasting quite costly. What I see is a kind of
| distributed message transportation system that takes
| currency from sender and shares a fraction of it with
| recipient. I.e. sender always pays for sending their stuff,
| recipient gets paid for interruption. SMS messaging is very
| close to this.
| ddingus wrote:
| None of what you wrote speaks to not doing what is needed.
| franga2000 wrote:
| The fact that it has problems is entirely tangential to the
| fact that it does what's needed. What's needed is "I send a
| thing to a person and it soon-ish shows up on their end",
| with the bonus of knowing that someone would have to expend
| significant effort to intercept it. This has been true
| since the invention of writing and very few scenarios
| needed more. Anything on top of that (spam rejection,
| steong verification and encryption, etc.) is nice to have,
| but clearly not critical, because otherwise we still
| wouldn't all be relying on paper mail, email and sms for
| even the most critical of things.
|
| So yes, we really do need something better than email (and
| we have plenty of options), but it doesn't have to (nor
| will it any time soon) replace email.
| zapzupnz wrote:
| Yes, but the point is, don't sell it that way.
| oss2020 wrote:
| Real transport level security will be possible with MTA-STS
| (rfc8461). Use DNSSEC, enforce TLS, and verify server
| certificates. Also I haven't had much trouble with spam
| recently (spam filter works fine).
| wowxp wrote:
| The source code is totally unreadable.
| networkimprov wrote:
| Please clarify. I don't use _go fmt_ because mnm makes heavy
| use of the filesystem API, and the error-handling boilerplate
| for rarely-occurring, unrecoverable errors is painfully high.
|
| See also
| https://github.com/networkimprov/mnm/blob/master/codestyle.t...
| kyrra wrote:
| The (I believe) author of this posted it on the golang subreddit
| a few days ago. It looks like he's very open to contributions if
| you're willing to help.
|
| https://www.reddit.com/r/golang/comments/kxe5bi/mnm_an_open_...
|
| The one interesting link from his post, is a link to the spec
| itself.
| https://github.com/networkimprov/mnm/blob/master/Protocol.md
| networkimprov wrote:
| I welcome constructive feedback and contributions!
|
| I have a "Yes, and ..." attitude to input and community. (I
| know the pain of being part of an open source community that
| doesn't.)
|
| (Yes-and is a comedy/theatrical improv technique; always
| embrace what the previous speaker said, and build on that. Tho
| admittedly, you can't run an open source project in an entirely
| improvisational manner :)
| transistor-man wrote:
| Just curious, how do you pronounce this, as in how would I
| recommend this to some one verbally?
| networkimprov wrote:
| em-in-em, like the rapper :-)
| retpirato wrote:
| This looks a lot like instant messaging to me. Maybe glorified
| IM, but still IM.
| young_unixer wrote:
| I'm sorry, but with such an awkward name they won't convince many
| people.
| networkimprov wrote:
| mnm = mnm is not mail
|
| Also addressed here:
| https://news.ycombinator.com/item?id=25804869#25807379
| gm wrote:
| LOL, yeah, recursive project names stopped being interesting to
| me after "GNU's Not Unix"
| anaganisk wrote:
| May be thats we said about, rediff, google, duckduckgo,
| WhatsApp, tumblr, and others.
| umvi wrote:
| And this is for techies who are used to xkcd, xna, gnu, etc.
| Could you imagine _any_ average consumer-facing product with
| this name being successful? There 's no candy-coating the truth
| I'm afraid - people couldn't handle a name like this, it's too
| much of a mouthful...
| arm wrote:
| Just to make the reference completely obvious, parent is
| referring to the candy named _M &M's_:
|
| https://en.wikipedia.org/wiki/M%26M's
| ccleve wrote:
| Marshall Mathers, Eminem, had the same idea, but did it
| better.
| slyall wrote:
| This seems to mainly be disigned to work within an organisation.
| Like Microsoft Teams or Slack
|
| It doesn't seem to work for a "common" email use case of
| contacting random people at other organisations. How would I say
| contact a vendor and a sales guy reply to me?
|
| Can I publish my address on my website or business card and
| people contact me?
|
| Of course any-to-any connections with email (or the phone system)
| spend a lot of time working with the downside of "unwanted"
| messages/calls.
| IlliOnato wrote:
| I think the idea is to have it adopted in stages.
|
| First, to communicate within a single organization or project.
| Second, between organizations/groups who adopted it already.
| Third, when critical mass is reached, open it.
|
| The really cool feature seem to be that an unknown/unapproved
| party can only ask you to establish a contact, and cannot
| immediately send you any links, attachments, etc.
| networkimprov wrote:
| There would be "marketplace" sites to connect with people.
|
| More here:
| https://news.ycombinator.com/item?id=25804869#25807379
|
| (I'm the author.)
| netik wrote:
| I think my main problem with this is the intermixing of higher
| "application" level features like surveys and forms with lower
| level protocol features like "message transport."
|
| This seems like a bad idea and goes against years and years of
| open systems design.
| networkimprov wrote:
| There has to be a definition of acceptable message formats for
| standard clients. I suppose that could be a separate protocol,
| but for now, there's one protocol draft.
|
| Also addressed here:
| https://news.ycombinator.com/item?id=25804869#25807379
|
| (I'm the author.)
| AndrewSChapman wrote:
| Completely agree.
| grok22 wrote:
| Not sure why that is a problem given the problem domain -- all
| those high-level features is what will help people consider
| adopting this. But email can only improve if you fix the whole
| eco-system including the server side -- which then means also
| dealing with the protocol. The modification to the protocol
| will probably help with all those "high-level" features.
| ianai wrote:
| You have to have a killer feature for something to get
| adopted.
| GekkePrutser wrote:
| The killer feature of a new email protocol will be that
| it's not SMTP.
|
| It should have sender authentication. E2E encryption that's
| easy and works by default. Those would be more than enough
| killer features, SMTP is just too broken and all the
| workarounds we have in place like DKIM, SPF, Spam ratings
| etc etc don't make up for it. We still have spam, important
| mails still end up in our junk boxes, and nobody trusts it
| enough anymore to put important content in emails. The war
| has long been lost.
| EricMausler wrote:
| What are your thoughts on protonmail?
| mosselman wrote:
| As far as I know, and I could be wrong, ProtonMail wraps
| around pgp inbox encryption. Many providers have exactly
| this service already.
|
| The difference seems to be that ProtonMail don't allow
| you to use normal imap and your own client with pgp, but
| force you to use their client. This is probably a trade-
| off made to protect users against them selves in one way
| (disabling encryption for grandpa) and hiding the non
| tech-savvy from all the technical details.
|
| Again, many assumptions here.
|
| So, to me, mentioning proton here doesn't make sense as
| the underlying tech: smtp & pgp have existed and been
| industry standard for a long time. So there is not issue
| of adoption.
| thayne wrote:
| Not the parent, but protonmail is still just more hacking
| to work around a broken system. It is a valient effort,
| but to really fix email the whole thing needs to be
| replaced.
| GekkePrutser wrote:
| I'm with thayne above on this one.. Protonmail just
| offers secure storage on their system but they still see
| the external incoming emails unless they're PGP
| encrypted. They make that easy, but still. PGP didn't
| take off in 30 years, it's just too complex. Tools can
| help that but the weak point is its key management.
| AndrewSChapman wrote:
| Agree with everything you've said. Additionally,
| consistent rendering. If you've ever tried to send an
| email campaign and had to support all the old (and
| sometimes surprisingly new) Outlook clients and Lotus
| notes, you'll know just how painful that is.
|
| Email must be: * Secure and encrypted; * Have proven
| identity; * Have easy to fabricate and predictable
| rendering;
|
| I feel like the ability to have forms and charts is very
| nice, but adds a lot of complexity, especially from a
| security point of view. I'd be looking at this kind of
| "application level" functionally being a layer added
| optionally on top, not being in the core protocol.
| Geezus_42 wrote:
| I have a job because people put important stuff in
| email... lol
| ddingus wrote:
| "Nobody"
|
| "War"
|
| Few, outside small, likely familiar tech circles, use
| these terms when discussing email.
|
| Not being SMTP usually means being another messaging
| island or other, which has only strengthened email.
|
| Lists have huge value today, still!
|
| Now, there is one exception: Marketing
|
| The reason? Everyone else is busy getting work done.
|
| Whatever may transcend email needs that quality, or it
| will, in fact be, yet another messaging island.
| vinay_ys wrote:
| Exactly. There's no replacing email with something that's
| closed membership / invite-only etc. The whole point of
| e-mail is its your address where someone can initiate a
| contact, like phone number. You can choose to filter it
| etc. And you can choose to get attested emails which you
| can trust more etc. But fundamental nature is it is open
| for anyone to contact you. If you lose that, and build a
| custom new protocol, you are just building another closed
| wall messaging application.
| jbaber wrote:
| Gmail has done this. I often follow up e-mails from my
| personal domain with a copy from a gmail account since it
| gets guessed as spam randomly.
| xtf wrote:
| And that is what xmpp already offers
| 3131s wrote:
| It seems to be a favorite of criminals everywhere, which is a
| good measure of worth in this case.
|
| https://www.cyberscoop.com/jabber-xmpp-cybercrime-russia-
| enc...
|
| There was a major deep web counterfeiter about a decade ago
| that remained active on Jabber even as a federal fugitive,
| not sure what ended up happening to him.
| unethical_ban wrote:
| Open systems design has lost the messaging wars.
|
| Federated/decentralized, secure, non-real-time messaging is the
| problem space. If it can make some overwhelmingly common use
| cases of current e-mail that much easier, then so be it.
| teleforce wrote:
| Don't count your chickens just yet, the jury is still out on
| this one.
|
| If history has any say on this, communication solution based
| on proprietary technology will meet their death sooner rather
| than later. How many network protocols have been invented
| before and after TCP/IP? I know we are talking about
| messaging now, but messaging is just another overlay network
| over TCP/IP.
|
| I'd envision in the future that the open messaging systems
| will be more pervasive. It will be based on local-first
| software and probably based on the automerge capabilities.
| The automerge community is focusing on collaborative editing
| at the moment but could someone please work on automerge
| solution for messaging system? This can be an excellent new
| paradigm for open world of messaging. I am seriously tired of
| people asking me to install the proprietary software of
| WhatsApp, Line, Wechat, etc.
| vinay_ys wrote:
| Yes, it is unfortunate they chose to do that. I stopped reading
| when I saw that section.
| networkimprov wrote:
| It makes me smile to hear that someone expects to read a
| perfect document on a perfect product which they understand
| perfectly; even tho the product is a preview, the document is
| a draft, and they only read it once.
| vinay_ys wrote:
| There was nothing imperfect in what I read. It was
| perfectly clear what features this product considers in its
| scope. I just didn't agree that those feature went well
| together with the stated goal of replacing current email
| systems.
| petre wrote:
| The junk folder should be the default deliveey folder, not the
| inbox. Anything not moved from it for several months should be
| erased.
| tsimionescu wrote:
| So people should be expected to regularly go through their Junk
| folder to see if anything interesting has popped up?
|
| A junk folder is only useful if you essentially never have to
| open it.
| umvi wrote:
| Think of it like cellphones. If you aren't in the contact
| list you are blocked by default.
| beowulfey wrote:
| There was a time not that long ago when we didn't have
| caller ID and we actually answered ALL our phone calls
| tsimionescu wrote:
| That's not at all how my cellphone works. This has been
| thankfully the case recently when a hospital contacted me
| to notify that they had admitted my grandmother.
|
| It's not safe to block calls from unknown numbers if you
| have people that may depend on you.
|
| Email is much less likely to be critical, but there are
| still occasions when you may be contacted with important
| information by addresses you didn't think to white list.
| FiveNinjas wrote:
| you mean like Skype. There's nothing specially 'email'
| about this other than it is a bad mix up of a P2P
| communication app and a supposedly 'trusted' version of
| SMTP.
| hyakosm wrote:
| It's the difference between a social network decicated to
| exchange in a bubble and a truly universal communication
| service like post, phone system or email where anyone can
| reach anyone without subscribe to same/any service, without
| being "friend" or trusted.
| userbinator wrote:
| I'm particularly wary of mail filtering that seems to always
| put mail from a sender that hasn't been seen before into
| junk... which certainly puts a bit of a chilling effect on
| communcation.
| [deleted]
| megous wrote:
| On the contrary, Junk folder is only useful if you go there
| regularly and check that non-junk mail didn't get there.
| Especially for services that have too much false positives,
| like gmail.
|
| Otherwise you can just drop the mail you'd put there
| immediately on reception and not even store it.
| xaduha wrote:
| Any particular reason XMPP can't extended to support email-like
| usage? It's not like email is that special, apart from inertia
| and the fact that it's not going anywhere because of it.
| josephg wrote:
| XMPP can be extended to support anything. We could do http over
| xmpp if we wanted, but that doesn't make it a good idea.
| mst wrote:
| There's also an RFC for SOAP transport over SMTP.
|
| Occasionally I threaten to implement it in order to upset
| somebody.
| josephg wrote:
| :( I'm upset already.
| flemhans wrote:
| Would popular rapper Eminem claim trademark infringement?
| reaperducer wrote:
| Not any more than candy maker M&M Mars would.
| md_ wrote:
| As someone fairly well-versed in the email ecosystem, I don't
| understand this proposal, like, at all.
|
| - Is it even federated? It seems like not--it seems like it's
| proposing a protocol for organizations to use to run their own
| messaging service in-house? - If it's not, this
| doesn't really get at either the _interesting_ parts of email--
| the universal federation--or what makes it _hard_. (The reason
| email has spam, authentication, and confidentiality problems
| really boils down to the difficulty in securely establishing
| authoritative identities; this is why protocols like DANE, DMARC,
| DKIM, SPF, and MTA-STS are tacked on top.) - If it is,
| the documentation is woefully underemphasizing this point. :)
|
| - The proposal (as others have noted) seems to mix application
| features with message delivery. This doesn't seem useful.
|
| - Instead of using encryption, the proposal says that "To prevent
| theft of correspondence (in the event of a compromised account or
| server) the messaging service must store only messages that have
| not yet been delivered". This is...a really problematic design
| choice.
|
| - The proposal suggests a bunch of reasonable _application_
| features which many email providers (at the MTA or MUA level)
| _do_ already support (like "blocking anyone", "selecting [who]
| can correspond with you", etc). Email is fully compatible with
| these features! - Conversely, the proposal
| suggests some features which are not obviously satisfied by the
| proposal itself, like "always know from which site a message
| originated." Again, where is identity even discussed?
|
| To be blunt, this proposal doesn't seem like it was written with
| an eye to what's actually challenging about email. The fact that
| SMTP is not JSON is really not a significant problem; the focus
| of this proposal is just in the wrong place.
|
| To make this more constructive, I would suggest reading the IETF
| SMTP WG archives to understand the kinds of problems implementors
| and spec-authors face.
|
| I'm frankly pessimistic about the prospect for a wholesale (non-
| incremental) replacement of SMTP, but even as a design exercise,
| starting with what real implementors struggle with makes sense.
| networkimprov wrote:
| TMTP is not federated because federation is a security hole,
| except in certain circumstances. There are other ways to
| connect with people outside your current circles. See my other
| comments herein.
|
| I've been asked to create a doc describing the architecture and
| infrastructure of TMTP. That should clear up the Q's you and
| others have raised.
|
| (I am the author.)
| md_ wrote:
| So is this better viewed as a replacement for enterprise
| messaging?
| StreamBright wrote:
| Point 1 is great, point 2 is disastrous. Yes, we need a new email
| protocol, it has to be simple, cryptographically sound, it must
| weed out the concept of spam (there are great ideas on this
| subject, like the cost-based anti-spam systems[1]. We do not need
| more attack vectors like a JS based chart library. You can render
| charts as static images without running any code on the reader
| side. Some days, I wish there was a LaTex based email that did
| these.
|
| https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems
| networkimprov wrote:
| The new user experience aspects are largely constructed with
| markdown extensions.
|
| There's nothing insecure about including JSON data for a
| chart/graph. It wouldn't support arbitrary JS (for heaven's
| sake :)
|
| More here:
| https://news.ycombinator.com/item?id=25804869#25807379
|
| (I'm the author :)
| 0df8dkdf wrote:
| * SMTP, the protocol at the root of these problems, originated at
| a time when the links between Internet sites were slow and
| intermittent*
|
| I think the author missed the whole point. Not everyone has
| access to fast internet or internet at all. SMTP was designed
| with that in mind, and it also works better than other real time
| messenger in that sense. Async federated communication.
| networkimprov wrote:
| I'm referring to a time when the _Internet backbone_ was slow
| and intermittent. You 're describing the last-mile situation.
|
| JMAP offers a solution for intermittently connected devices
| (phones) which expect notifications and messages from Internet
| services.
|
| I expect TMTP will do the same; it's far from final. (I'm the
| author.)
| alisausa wrote:
| Hello
| TedDoesntTalk wrote:
| How can this reach critical mass when people are already using
| email for a similar purpose?
| IlliOnato wrote:
| If I understand them correctly, they have in mind the
| following:
|
| Stage 1. Organizations would use it to create _internal_
| messaging systems, for employees/members only. At that stage it
| does not replace e-mail, and both systems are used alongside
| it. If it is mandated to be used for internal communication,
| this solves the problem of getting "Open this immediately!!!"
| e-mail claiming to come from your boss, but being in fact from
| scammers. It also solves the problem of e-mail from your
| colleagues getting into spam folder.
|
| Stage 2. If your clients, suppliers, etc. start to use mnm, you
| can add them to your mnm network, and stop using e-mail in
| communication with them. When you reach this stage, you can
| severely reduce using of e-mail for your organization, at this
| point perhaps the only people who need e-mail are marketing,
| support, and perhaps developers (but the latter only for
| maillists).
|
| 3. mnm gets a critical mass, where it makes sense for
| organizations and projects start to offer mnm as an option to
| contact them, and later to require them. At this point "general
| public" starts to use mnm.
|
| 4. When it reaches critical mass among general population,
| e-mail can start to be phases out.
|
| Don't know how realistic is this, and some design decisions of
| the mnm team seem counter-productive, but to me it does not
| sound completely crazy.
| dingaling wrote:
| But all that complexity of migration, when similar results
| can be achieved today using SMTP trust-lists and separate
| accounts.
|
| In your roadmap example, steps 1 and 2 can be done right now
| by maintaining trusted network lists for SMTP, so that
| employees can't be spammed by unapproved senders. And it can
| enforce TLS between those trusted networks for privacy.
|
| Meanwhile the customer-service people can have both guarded
| @internal.bigcorp.com and open @bigcorp.com accounts, the
| latter for public communication.
|
| That's a pattern that's already in use and works on existing
| infrastructure. Any new protocol will have to offer
| overwhelming benefits.
| networkimprov wrote:
| Excellent roadmap! \o/
|
| More here:
| https://news.ycombinator.com/item?id=25804869#25807379
|
| (I'm the author.)
| networkimprov wrote:
| Email is in deep trouble, due to the cybercrime crisis, in
| which SMTP plays a leading role, enabling phishing.
|
| The only effective solution is to _#banSMTP_ - i.e. block it on
| public networks.
| mdpttt wrote:
| This was the first thing that came to my mind as well, but on
| the other hand this seems to solve some real issues. Is there
| some space for solving this issue by evolving/improving SMTP?
| jbverschoor wrote:
| IETF / RFCs
|
| I don't understand why you need to completely (and naively)
| need to recreate something like SMTP.
|
| This project tries to do too many things, even forms and
| charts. There's no separation between layers.
| gm wrote:
| True, when I read the description, it looked to me like a
| bundle of smtp, email rules config utility, spam filter,
| and email client, all in one package you cannot
| reconfigure.
| dsr_ wrote:
| You can solve a bunch of SMTP problems by organizing people.
|
| Let's call it the Secure Mail Cooperative. In order to join
| the SMC, you need to:
|
| - have an acceptable usage policy that means you will not
| allow any of your users to send spam (defined as...). Your
| first violation gets a warning. Your second violation gets
| you suspended from the SMC for a month. Third violation in a
| year disqualifies your organization from ever rejoining.
| Reset the count a year after a second violation.
|
| - register the fingerprint of your SSL certs with the SMC,
| which will publish it in a DNS accept-list.
|
| - add an SMC header to your SMC-bound email that indicates
| the address of your SMC postmaster, who is one or more people
| who can enforce the AUP on your side. The SMC postmaster
| address should never accept non-SMC email.
|
| - agree that the SMC postmaster will be tested every so often
| and a lack of a response within 168 hours will be considered
| a violation, same as spam.
|
| That's all off the top of my head, but it could reasonably
| work... for individuals and small to medium organizations. It
| requires too much attention for a Google or Microsoft to
| afford.
| TedDoesntTalk wrote:
| i wouldn't have my organization join this cooperative. Why?
| Because accounts get compromised and spam gets sent. It
| just does, even with 2FA and NFC dongles and public/private
| keys.
|
| In your cooperative, if two or more of the thousands of
| accounts in my org are compromised, the entire org loses
| email?
|
| Not gonna happen, even if you tweak the rules to be more
| lenient.
|
| Realistically we will always have spam. It can be reduced
| but, just like snail mail and all other forms of push
| communication, you will always get spam. Get over it.
| ruslan wrote:
| This is called responsibility. Lack of respobsibility
| brought us to the point where noone cares about security
| seriously. Yes, we talk much about it, but in reality we
| don't give a damn about it because possible damage is
| usually inappreciable.
| ruslan wrote:
| Fidonet operated exactly the way you describe. I recall in
| 90th I used to run quite a large Fidonet node. I was
| responsible for my points' (users) behaviour - when someone
| violated rules by misbehaving in an echo conference it
| effected me as a boss node in first place, I had to execute
| the ban and brainwash negligent user. What's more, I had to
| introduce new and old users to fidonet policy and its
| updates regularily to make sure they understand the rules.
| This all worked pretty well and was widely accepted.
| Fidonet was incredibly popular in 90th.
|
| I think we may create a similar network basing on same old
| ESMTP, what we need is just to agree on rules and their
| enforcement. Also we need to secure inter-node
| communications.
| LoSboccacc wrote:
| I don't get it, I can have all of this on email right now, and
| still be compatible with the rest of the world
|
| > choose the organizations/sites that relay your correspondence
|
| SPF/DKIM
|
| > select which members of a site can correspond with you
|
| whitelists have been a thing in a while
|
| > always know from which site a message originated
|
| SPF
|
| > can block anyone with whom you've made contact
|
| blacklists have been a thing in a while
|
| > may leave a site and never see traffic from it again
|
| domain filter are a thing too. preemptive 'but you still receive
| emails' - no you can send a 550 early on and interrupt the
| transfer as soon as you get the envelope sender domain
|
| > 2 To offer capabilities missing in traditional email, including
|
| that's all client side stuff and you can do all of it as of today
| on top of email. first part of the protocol is to know which user
| sent you markdown before, so you can send markdown to them. for
| user that you don't know if they have a markdown clent, your own
| client send a multipart with markdown and the local markdown
| representation as html, so you have a two-in-one
| discovery/fallback mechanism
|
| while the first one might be beneficial as you give more control
| from the sysad and into the user hand for point 1.5, the second
| part is a problem we already had and we already solved with the
| transition from text email to html email and it was never a
| protocol issue to begin with, so I don't understand why it has
| been rolled in here for more effort and little effective gains.
| networkimprov wrote:
| You _can_ (sort of, with a great deal of effort) but _you don
| 't_.
|
| And there is no effective way to prevent phishing in SMTP/etc
| if the server accepts connections from the public Internet.
|
| If you didn't, I suggest reading the protocol draft and "Why
| TMTP?"
| LoSboccacc wrote:
| you can check that the envelop and message sender header
| match at the mx level and let spf handle the rest
| networkimprov wrote:
| There is no authentication of the John Doe part of
| John Doe <not.john.doe@example.com>
| LoSboccacc wrote:
| DMARC
| silasdb wrote:
| There are many pessimistic comments here. I'd like to go to the
| opposite direction.
|
| First, I think the intention is very good. There are some
| problems with email that I don't know if they are possible to
| fix. Yes, JMAP [1] try to fix some of these problems for clients,
| but other flaws cannot be fixed without breaking backwards
| compatibility. Even unsuccesful, audacious experiments like that
| bring about discussions about what are the limits of current
| technology, what alternatives we have and what alternatives we
| can build.
|
| Anyway, the best solution for _asynchronous_ communication is
| still email. An incompatible solution would have to provide a
| compatibility layer for that. People refer Matrix here but I 've
| always thought that, although many teams have adopted Matrix as a
| solution for general communication, it is a chat platform and not
| a replacement for asynchronous communication.
|
| I just glanced over the site so I may sound repetitive: as a
| suggestion, I'd recommend adding some screenshots of client
| applications, diagrams explaning how mnm works, an explanation
| about federation and something that highlights differences to
| email.
|
| [1] https://jmap.io
| alisausa wrote:
| Top burny busty chicks only on this site! Follow the link, and
| you won't be sorry! - https://adultlove.life
| tormeh wrote:
| Email sucks. It doesn't need replacement with something else that
| does the same but encrypted. The whole skeuomorphic concept of
| electronic mail is just not great and needs to go away. What we
| need is federated chat, like Matrix maybe.
|
| Apropos: Is anyone aware of an email client that groups mail by
| sender, like a chat client? That would make email far more usable
| for me, as addresses that send a lot of mail and addresses that
| send little mail would get the same amount of screenspace.
| Currently my company email is drowning in automated internal
| semi-spam.
| beagle3 wrote:
| Thunderbird and Outlook both group by sender, and have for more
| than 20 years.
| BubuIIC wrote:
| I think delta chat does exactly this: https://delta.chat/
| (email as chat)
| tormeh wrote:
| Thanks! This looks great!
| RcrdBrt wrote:
| Deltachat maybe? Check it out. You might like it, it's a
| federated chat (since mail is) and built on top of the email
| tech stack
|
| https://delta.chat
| tormeh wrote:
| Thanks! This looks great!
| na85 wrote:
| >Email sucks
|
| Email is great. I can choose between umpteen providers or run
| my own mail server, it's a standard protocol with many
| different clients to suit one's needs, I can't get banned by a
| faceless FAANG corporation for no reason and with no recourse,
| I'm not locked into some walled garden and dependent on the
| benevolence of corporate overlords and I don't need to worry
| about some intern at Google suffering from NIH syndrome
| deciding to make completely unneeded "improvements" that
| negatively impact my UX.
|
| Email is old but that doesn't mean it sucks.
|
| Internal "semi-spam" is a social problem and needs a social
| solution. Changing protocols won't change the spam problem at
| your company.
| zimpenfish wrote:
| > I can't get banned by a faceless FAANG corporation for no
| reason
|
| They can make your life difficult though with their seemingly
| random decisions about what constitutes spam even when you
| jump through all the SPF/DKIM/DMARC/etc hoops.
| na85 wrote:
| What I mean is they can't lock me out of my emails and
| contacts without recourse because (unless I use gmail or
| similar) my contacts are stored on my local device, and
| potentially so is my mail.
| tormeh wrote:
| All the benefits you're listing are benefits that any
| federated protocol, for example Matrix, has. Completely
| orthogonal to email itself.
| na85 wrote:
| And the problems you listed with email aren't actually
| problems with the technology so much as problems with the
| way people at your company (and others) misuse the
| technology. They're completely orthogonal to email itself.
| mac01021 wrote:
| I'm not sure that's true. Email has a somewhat archaic
| data model that has suboptimal support for things like
| threading.
| rakoo wrote:
| What exactly does it need to do better threading ? Today
| a client can write anything they want in the References:
| and In-Reply-To: headers, and the server doesn't verify
| that it's valid. Would that be enough for you ?
| tormeh wrote:
| I only mentioned one problem with the clients, and an
| abstract complaint about doing one electronic
| communication but pretending it's physical.
|
| Some problems with email, from a user perspective:
|
| - The latency is too high for truly real-time
| communication
|
| - There is no cryptographic verification of the sender's
| identity (this problem is also shared with telephony).
| This has lead to really harsh anti-spam measures that
| make it hard to self-host. Sender verification + client-
| side sender whitelists would solve spam for good. It also
| means grouping by sender gives a very false sense of
| security regarding identity continuity between messages
|
| - There is no good support for groups or threads. Subject
| lines of type "Re: Re: Aw: Re: Sv: new proposal" is not
| an acceptable solution, as they look ugly and clients
| often disagree on how to parse and write them, leading to
| breakage of the thread
|
| - Clients do not group by sender, group or thread, partly
| because these concepts do not actually exist in email
| (see above) and partly for social reasons
|
| - Partly for historical reasons (it's just mail on a
| computer!) and partly for technical reasons (there is no
| sender, etc.) email is presented as huge letter-like
| affairs, leading to a felt need for all sorts of
| formalisms for every single message even if the messages
| are two minutes apart. Also email signatures (with
| logos?!) being attached to every message are just so
| wasteful both in terms of storage and in terms of screen
| space
| na85 wrote:
| > The latency is too high for truly real-time
| communication
|
| If you want real-time communication you really ought to
| be using VOIP.
|
| > There is no cryptographic verification of the sender's
| identity (this problem is also shared with telephony).
| This has lead to really harsh anti-spam measures that
| make it hard to self-host. Sender verification + client-
| side sender whitelists would solve spam for good. It also
| means grouping by sender gives a very false sense of
| security regarding identity continuity between messages
|
| I agree that the crypto situation in email needs
| addressed. I don't think that the answer to this problem
| is "throw it away and start competing standard #1982374"
| though.
|
| > There is no good support for groups or threads.
|
| Mailing lists are groups. Threading actually works quite
| well with subject-line threading. Mailing lists have been
| doing this successfully for decades.
|
| >Clients do not group by sender, group or thread,
|
| Some do. Gmail does, for example.
|
| >Partly for historical reasons (it's just mail on a
| computer!) and partly for technical reasons (there is no
| sender, etc.) email is presented as huge letter-like
| affairs, leading to a felt need for all sorts of
| formalisms for every single message even if the messages
| are two minutes apart. Also email signatures (with
| logos?!) being attached to every message are just so
| wasteful both in terms of storage and in terms of screen
| space
|
| The formalisms thing isn't actually true, and all of
| these are social problems, not technical ones.
|
| It's okay to just admit you don't like email, even if
| it's for purely subjective reasons.
| dieortin wrote:
| Some of this problems are (in my opinion) actually
| advantages.
|
| E-mail's latency makes it so people write longer, thought
| out messages, instead of spamming very short messages.
| This makes for a different kind of communication, which
| is better for many things.
|
| It also removes the expectation to respond really soon,
| and the sender doesn't know if you've read the message.
| de6u99er wrote:
| Does anyone remember Google Wave (now Apache wave)?
|
| I loved the concept.
___________________________________________________________________
(page generated 2021-01-17 23:02 UTC)