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