networkimprov

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?"

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.

@DANG could you push this group to the top of the comments, so ppl see answers to FAQs? Thanks!

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.)

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...

JMAP is an extension of the email protocol stack; it's fundamentally different than TMTP.

(I'm the author of mnm.)

A killer phish will get you sooner than later :-)

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.

What should I read about Mailscript?

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 :)

There would be "marketplace" sites to connect with people.

More here: https://news.ycombinator.com/item?id=25804869#25807379

(I'm the author.)

mnm = mnm is not mail

Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379

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.)

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.)

Addressed here: https://news.ycombinator.com/item?id=25804869#25807379

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 :)

Yes, I need to write an architecture/roadmap doc.

Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379

Try to stop me :-)

Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379

(I'm the author.)

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.)

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

Excellent roadmap! \o/

More here: https://news.ycombinator.com/item?id=25804869#25807379

(I'm the author.)

em-in-em, like the rapper :-)

This. And the effectiveness of targeted phishing is why we must replace SMTP-based email, and eventually block SMTP on public networks. It isn't suited to the 21st Century Internet.

Hence, the mnm project[1] (open source client & server) and TMTP[2][3].

[1] https://mnmnotmail.org

[2] https://github.com/networkimprov/mnm/blob/master/Protocol.md

[3] https://mnmnotmail.org/rationale.html

Building a legitimate email replacement, "mnm":

https://mnmnotmail.org

https://twitter.com/mnmnotmail

Not production-ready, but well past half-baked. I began publicizing it this month.

Legitimate, i.e. n-identity, decentralized, store-and-forward, simple protocol, open source. Contributors welcome!

#banSMTP

There are two ways to communicate with ppl outside your org without federation (this is covered on the website):

1) Set up a second TMTP service where customers and/or suppliers can create accounts, along with employees who need to interact with them.

2) Have some employees join a third-party service which is open to all involved in your field. There is a risk of phishing in this case, but:

. a) anyone you haven't previously contacted is limited to short, plain-text communications to you (see Ping in protocol), and

. b) such third-party services would typically charge a fee to members and impose a small cost per-ping, and

. c) you know that you're dealing with unknown entities with possibly malicious intent.

TMTP clients support active logins to accounts on any number of TMTP servers, just as browsers support multiple active connections to websites.

I've only just begun publicizing it, after getting the client & server implementations to a point where folks can evaluate them.

Protocol: https://github.com/networkimprov/mnm/blob/master/Protocol.md

Why TMTP? https://mnmnotmail.org/rationale.html

Follow: https://twitter.com/mnmnotmail

TL;DR: Thousands of brilliant minds have tried to fix email for decades, and realized it can't be done!

Ahem, I'm trying to bury email, not save it -- not unlike Slack :-)

I agree with both of you, and TMTP supports adding people to a thread after it starts (see PostNotify).

By "replace SMTP" I mean the whole email protocol stack, not only SMTP. I'm not proposing to replace it for all situations overnight; of course SMTP etc will be used for decades.

TMTP also covers most IMAP/POP use cases. And it allows short, plain-text messages (see Ping) to make first contact with others -- necessary when that server has less restrictive membership requirements.

Authenticity is a double-edged sword. For certain confidential content, you want the recipient to know that it originated with the sender, but you don't want anyone else to know that in the event the content is leaked or stolen.

I believe the extinction of email for person-to-person & app-to-person correspondence is a foregone conclusion, due principally to phishing. The question is what should we do now, and the answer is clearly not chatrooms (which are of course useful in certain circumstances).

Changing your SMTP server configuration that way would break things, so the question is whether to set up a new, company-internal SMTP server, and give your employees new addresses there. But that won't quickly stop the phishing, because your ppl still need to get email via the public network from clients and suppliers.

Setting up a new server isn't easy unless you hire an outside service provider, and if you're willing to do that, Slack et al offer a nicer UX than the well known email/webmail clients.

Orgs with sufficient IT resources commonly do run internal SMTP servers.