public inbox for nncp-devel@lists.cypherpunks.ru Atom feed
* nncpmail @ 2022-01-12 22:24 John Goerzen 2022-01-15 10:16 ` nncpmail Sergey Matveev 0 siblings, 1 reply; 7+ messages in thread From: John Goerzen @ 2022-01-12 22:24 UTC (permalink / raw) To: nncp-devel Hi, I stumbled across this interesting piece of software: https://github.com/neilalexander/yggmail This is for the Yggdrasil network I just wrote about. It's a single Go binary that wraps up a Yggdrasil node, SMTP server (for exchanging mail) and IMAP server (for reading it). It uses address of the form publickey@yggmail. It occurs to me we could do something similar with NNCP. Of course, being an asynchronous network, we can't just automatically discover routes to every possible peer, but peering with a public relay could do the trick there. Then we would just need to define the conventions around transport (eg, a "nncpmail" command that takes BSMTP on stdin or something). I don't have time to work on this myself, but I thought it a quite interesting idea. There is also an Android port: https://github.com/deltachat/AndroidYggmail - John ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: nncpmail 2022-01-12 22:24 nncpmail John Goerzen @ 2022-01-15 10:16 ` Sergey Matveev 2022-01-15 20:05 ` nncpmail Sergey Matveev 2022-01-16 1:27 ` nncpmail John Goerzen 0 siblings, 2 replies; 7+ messages in thread From: Sergey Matveev @ 2022-01-15 10:16 UTC (permalink / raw) To: nncp-devel [-- Attachment #1: Type: text/plain, Size: 496 bytes --] Greetings! *** John Goerzen [2022-01-12 15:24]: >https://github.com/neilalexander/yggmail Looks interesting! >It occurs to me we could do something similar with NNCP. Honestly I do not understand what exactly can we do with NNCP and tham yggmail (or its idea). You mean creating overlay network for transferring encrypted packets, instead of current TCP<->TCP daemon? -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: nncpmail 2022-01-15 10:16 ` nncpmail Sergey Matveev @ 2022-01-15 20:05 ` Sergey Matveev 2022-01-16 0:23 ` nncpmail Koushik Roy 2022-01-16 1:29 ` nncpmail John Goerzen 2022-01-16 1:27 ` nncpmail John Goerzen 1 sibling, 2 replies; 7+ messages in thread From: Sergey Matveev @ 2022-01-15 20:05 UTC (permalink / raw) To: nncp-devel [-- Attachment #1: Type: text/plain, Size: 906 bytes --] *** Sergey Matveev [2022-01-15 13:16]: >>It occurs to me we could do something similar with NNCP. >You mean creating overlay network for transferring encrypted packets, >instead of current TCP<->TCP daemon? Answering my own question: that seems interesting. Actually I just implemented yggdrasil support completely similar as it is done in yggmail inside nncp-call* and nncp-daemon (basic uTP transport on top of Yggdrasil's packet interface). My small yggdrasil network works pretty fine! Of course there is some overhead currently: NNCP's native sync protocol encryption/authentication on top of Yggdrasil's. Unfortunately all of that fetches many dependencies: Yggdrasil for example depends on Wireguard, however actually none of its features is in use in yggmail and NNCP. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: nncpmail 2022-01-15 20:05 ` nncpmail Sergey Matveev @ 2022-01-16 0:23 ` Koushik Roy 2022-01-16 1:29 ` nncpmail John Goerzen 1 sibling, 0 replies; 7+ messages in thread From: Koushik Roy @ 2022-01-16 0:23 UTC (permalink / raw) To: Sergey Matveev, nncp-devel Sergey Matveev <stargrave@stargrave•org> writes: > Answering my own question: that seems interesting. Actually I just > implemented yggdrasil support completely similar as it is done in > yggmail inside nncp-call* and nncp-daemon (basic uTP transport on top of > Yggdrasil's packet interface). My small yggdrasil network works pretty > fine! Of course there is some overhead currently: NNCP's native sync > protocol encryption/authentication on top of Yggdrasil's. This is very cool work! > Unfortunately all of that fetches many dependencies: Yggdrasil for > example depends on Wireguard, however actually none of its features is > in use in yggmail and NNCP. Ah yes that's understandable here. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: nncpmail 2022-01-15 20:05 ` nncpmail Sergey Matveev 2022-01-16 0:23 ` nncpmail Koushik Roy @ 2022-01-16 1:29 ` John Goerzen 1 sibling, 0 replies; 7+ messages in thread From: John Goerzen @ 2022-01-16 1:29 UTC (permalink / raw) To: Sergey Matveev; +Cc: nncp-devel On Sat, Jan 15 2022, Sergey Matveev wrote: > *** Sergey Matveev [2022-01-15 13:16]: >>>It occurs to me we could do something similar with NNCP. >>You mean creating overlay network for transferring encrypted packets, >>instead of current TCP<->TCP daemon? > > Answering my own question: that seems interesting. Actually I just > implemented yggdrasil support completely similar as it is done in > yggmail inside nncp-call* and nncp-daemon (basic uTP transport on top of > Yggdrasil's packet interface). My small yggdrasil network works pretty > fine! Of course there is some overhead currently: NNCP's native sync > protocol encryption/authentication on top of Yggdrasil's. That really does! Very cool! I personally don't mind the extra encryption layer. - John ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: nncpmail 2022-01-15 10:16 ` nncpmail Sergey Matveev 2022-01-15 20:05 ` nncpmail Sergey Matveev @ 2022-01-16 1:27 ` John Goerzen 2022-01-16 14:59 ` nncpmail Sergey Matveev 1 sibling, 1 reply; 7+ messages in thread From: John Goerzen @ 2022-01-16 1:27 UTC (permalink / raw) To: Sergey Matveev; +Cc: nncp-devel On Sat, Jan 15 2022, Sergey Matveev wrote: >>It occurs to me we could do something similar with NNCP. > > Honestly I do not understand what exactly can we do with NNCP and tham > yggmail (or its idea). You mean creating overlay network for > transferring encrypted packets, instead of current TCP<->TCP daemon? No, I mean having a self-contained NNCP mailing deamon that is a regular NNCP node. So let's say we wanted to set up a global system where people could email each other across NNCP. We could use each node's NNCP public key as an identifier, as in user@publickey•nncp (just as yggmail is doing). At the NNCP layer, we would need a standard for how this will be accomplished, like rmail back in the UUCP days. Probably we would define an exec command -- maybe it would literally be rmail with the recipients on the command line and the body on stdin. Or it could be BSMTP. Whatever - what matters is that everyone agrees on the the convention. Then there is the question of transport. Of course, within one's local network, that's up to you. I'm going to hand-wave the question of how to receive mail from strangers for the moment because it's a bit difficult right now, I think. So, if you were doing this all by hand, you would need, in addition to the NNCP configuration: 1. A mail server that would handle this (exim, postfix, etc). This server would need to: verify the sender address matches the NNCP environment variable for verified sender key, understand how to deliver incoming mail to local mailboxes, understand how to route outbound mail to *.nncp via NNCP, and understand how not to relay things at its level. 2. An IMAP server that users could use to access their mail. Does that make sense? - John ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: nncpmail 2022-01-16 1:27 ` nncpmail John Goerzen @ 2022-01-16 14:59 ` Sergey Matveev 0 siblings, 0 replies; 7+ messages in thread From: Sergey Matveev @ 2022-01-16 14:59 UTC (permalink / raw) To: nncp-devel [-- Attachment #1: Type: text/plain, Size: 2972 bytes --] *** John Goerzen [2022-01-15 18:27]: >No, I mean having a self-contained NNCP mailing deamon that is a regular >NNCP node. [...] >Does that make sense? Personally I do not like that idea at all. Actually I even did not try to use yggmail just for the interest, because it takes job that definitely (in my opinion) should not be done in it at all. I am proceeding from the assumption that local MTA always exists and used by the user. It is the only correct way to deal with email. MTA, MUA, MDA, probably MRA (that delivers mail to MTA) -- is the Unix-way email setup. POP3/IMAP4 -- is a contrasting way of working with email, appeared in the age of cheap, non-Unix-aware PCs. So MTA is here and it is used. So personally I do not wish to deal with any kind of POP3/IMAP4 -- mail should be delivered directly to SMTP servers, probably by chain. MRA fetching POP3/IMAP4 mail must deliver it to MTA, that probably will use help from MDA to process and deliver as you wish. Everything is passing through that chain of agents. To use yggmail, I have to configure my MRA (that I do not want to have at all!) to poll it, just to copy messages to MTA, that will send them to MDA. yggmail sending incoming messages to MTA directly -- much more sane way to deal with it, in my opinion. Koushik Roy's nmail proposal seems more correct way of doing things. Moreover, Correct SMTP server is pretty complex thing -- it is task far from being easy to implement, as POP3/IMAP4, requiring non-trivial database state. >1. A mail server that would handle this (exim, postfix, etc). This >server would need to: verify the sender address matches the NNCP >environment variable for verified sender key, understand how to deliver >incoming mail to local mailboxes, understand how to route outbound mail >to *.nncp via NNCP, and understand how not to relay things at its level. Personally my email setups will require it anyway. My MUA send all mail to MTA, that routes it as desired. Personal one is sent over NNCP, my company's related is sent directly to its SMTP server, potential @yggmail should be routed by my local MTA too, as it is the expected place to route email. If @yggmail/@whatever-mail will be the only email network used on the computer, then probably MTA's configuration, just to relay to single default hop, looks like overkill, agreed. But I believe hardly people people will use only it on their machines. So yggmail's idea to have its own built-in SMTP/IMAP4 server is something very alien to me, that is why I do not like it :-) >2. An IMAP server that users could use to access their mail. Personally I have never ever used IMAP at all :-). So all of that also forces me to learn some completely unnecessary things and search are their supported in MRAs (which, again, I wish not to have at all). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-01-16 14:59 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-12 22:24 nncpmail John Goerzen 2022-01-15 10:16 ` nncpmail Sergey Matveev 2022-01-15 20:05 ` nncpmail Sergey Matveev 2022-01-16 0:23 ` nncpmail Koushik Roy 2022-01-16 1:29 ` nncpmail John Goerzen 2022-01-16 1:27 ` nncpmail John Goerzen 2022-01-16 14:59 ` nncpmail Sergey Matveev