RFC: Eep2Eep mails

[AGentooCat]

(i admit i only know the basics of SMTP like "MAIL FROM/RCPT TO/DATA")
(also sorry if this is the wrong section, move if needed)

This document explores the possibility of eepsite-to-eepsite mails and a mail server for that purpose.

TL;DR:

1. A server local-listens on POP/SMTP ports and connects via SAM.
2. Both the sender and recipient have the mail server's dests in a "/.well-known/i2pmail.key" file (base64 plain) in their sites.
3. The sender ('s server) uses the recipient's file to locate their server.
4. The recipient uses the sender's file to verify the source of the message.

This would cut the requirement of a central server (like Postman's mail.i2p) or the need of a P2P network on top of a P2P network (I2P) that needs its own seeding (like Bote/pboted).

Requirements/Assumptions:

1. (Someone's) Server = This (in theory) mail server/plugin
2. Router = The I2P router covering the mail server (hosting the tunnels)
3. The sender is Alice at alice@cryptogal.i2p
4. The receiver is Bob at bob@thebuilder.i2p
5. Both routers have their SAM ports open with the servers having a session with a persistent key.
6. Both parties (in their respective sites) have this key saved as Base64 at "/.well-known/i2pmail.key". [^1]
7. Both servers listen on POP [^2] and SMTP ports for localhost [^3] running at where a party would interact with.
8. Both parties have no malicious addressbook entries.

Steps:

1. Alice sends a mail for Bob for bob@thebuilder.i2p.
2. Alice's server "GET [thebuilder.i2p]/.well-known/i2pmail.key"s via SAM. [^1]
3. Alice's server connects to the given destination (being Bob's mail server) and does a regular SMTP mail send operation. [^4]
4. Bob's server (seeing "MAIL FROM" as alice@cryptogal.i2p),
   1. GETs "cryptogal.i2p/.well-known/i2pmail.key" [^1] and compares it to who SAM says this is.
   2. Compares the receiver to be itself (aka "thebuilder.i2p").
   3. (if configured) SpamAss/rspamd/whatever's in mail-filter category
5. Bob's server tells "Mail accepted" to Alice's server and saves it for whenever Bob connects to the POP port for new mails.

Notes/Caveats:

1. Filtering the mail headers should be done at sender's server.
2. Integration with Postman's mail.i2p is just the server asking for mails every N hours. The configuration is up to the user.
3. Clearnet mails (if configured like above) can be relayed to mail.i2p (or another "i2p<->clear" mail server, if anyone has/makes one up)
4. (I think) Reach of this solution can be extended if it can be built into the router either as a plugin or alongside SusiMail, if SM can support that.
5. When an eepsite is down and if it's maildest was...
   • ...cached, then follow "use this stale until the eepsite comes back up".
   • ...not cached, or there is no maildest at all, then it might be possible to use hostname-here@mail.i2p. But this would expose the problem of: "no account is registered with that eepsite's name, an attacker does so".
6. If the mail couldn't be sent (possibly due to above) then the server would retry continuously while warning the user somehow (in the case of built-into-router, a warning message in the console).
7. This document relies on addressbook-based hostnames for both recipient-lookups and sender-lookups. It's possible (and somewhat recommended) to use "b32.i2p" addresses on the SMTP messages [^5] but this document went too complex trying to transform it from it's hostname-based nature.

[^1]: HTTP's "Cache-Control" header can be used for caching a maildest. But a default value can be used too; how often do you change your server keys?

[^2]: This can be POP+IMAP or IMAP or anything, it's up to the implementation.

[^3]: This can be "0.0.0.0/any" or anything else but in my eyes this would be a security risk. Authentication and encryption is possible (of course) but this document is not about it. Not that you should access your anonymous mail over anything clearnet anyway.

[^4]: This is to let future implementations just use the standard SMTP protocol. This also lets the send/recv functionality to be a plugin for an existing SMTP solution (if any). Example: "if from/to regexp '.*i2p$' use plugin"

[^5]: Like "MAIL FROM/RCPT TO" being alice@abcdef.b32.i2p / bob@xyz123.b32.i2p

[AGentooCat]

Here's a proof-of-concept implementation of this idea. Since phpBB didn't accept .c or spoofed .c.txt, I put it on my site (sorry but pastebins around were not working/reachable): i2pmail_poc.c
The program already gives usage instructions, but I'm gonna put them here too for reference:

Code: Select all

 0) Assuming you are in a temp.folder like [/tmp]
 1) Connect to the SAM bridge with something like "nc" and type these:
    - HELLO VERSION MIN=3.2 MAX=3.2
    - DEST GENERATE SIGNATURE_TYPE=ECDSA_SHA256_P256
    - DEST GENERATE SIGNATURE_TYPE=ECDSA_SHA256_P256
    Then exit nc.
 2) Save the first GENERATE's PUB/PRIV pair to [pub1.dat] and [priv1.dat]
    Save the second GENERATE's PUB/PRIV pair to [pub2.dat] and [priv2.dat]
    Note that the files can't contain anything else but a Base64 string.
    You can filter the files by this command (run for the 4 files above):
    $ echo -n $(cat [filehere].dat) > temp.dat
    $ mv temp.dat [filehere].dat
 3) Run these commands to generate a basic folder structure:
    $ mkdir -pv eep2eep_1 eep2eep_1/.well-known
    $ mkdir -pv eep2eep_2 eep2eep_2/.well-known
    $ cp pub1.dat eep2eep_1/.well-known/i2pmail.key
    $ cp pub2.dat eep2eep_2/.well-known/i2pmail.key
 4) On seperate terminals, launch webservers pointing to these two
    directories on different ports (here I use darkhttpd):
    $ darkhttpd eep2eep_1/ --port 2345
    (on another terminal)
    $ darkhttpd eep2eep_2/ --port 3456
 5) Create two HTTP server tunnels in your router.
    Register the first one to be "eep2eep1.i2p"
    and the second one to be "eep2eep2.i2p" in your private addrbook.
    Make sure to get the ports right, then launch them up.
 6) Run this program for the two sites:
    $ ./a.out 7001 7002 7656 test@eep2eep1.i2p $(cat priv1.dat)
    (in another terminal)
    $ ./a.out 7003 7004 7656 test@eep2eep2.i2p $(cat priv2.dat)
    Make sure the SMTP and POP ports are all different.
    Wait until both have emitted these lines and stopped
    > LINE=STREAM STATUS RESULT=OK
    >   RESULT=OK
 7) Create two profiles in your mail client.
    (search this if you don't know how to.)
    Point them to the ports selected above.
    Respecting which one got which portpair,
      set one of them to be From:"test@eep2eep1.i2p"
      and the other to be From:"test@eep2eep2.i2p"
    Make sure it's set correctly by trying to fetch mails from both sides.
    Both programs should output a lot of debug lines.

    After this point,
      1) If one of the programs crash, restart it.
         The other doesn't need a restart, unless it crashes too.
      2) If your mail client says something like
         > SMTP doesn't implement FOOBAR capability
         then you need to emulate the sessions using (again) "nc" or similar.
         Look around for example snippets for both POP and SMTP sessions.

 8) Send a mail from the e2e_1 profile to the e2e_2's address.
 9) Receive the mail from the e2e_2 profile. Again check the programs.
10) Reply to that mail and fetch it from the e2e_1 side.
11) Rinse and repeat these 3 steps.

[anikey]

This would cut [...] the need of a P2P network on top of a P2P network (I2P) that needs its own seeding (like Bote/pboted).

Can please tell why is this a major downside? (I didn't use it myself yet, because i didn't need it yet, so i don't know it yet).
I only see an upside with that: that you don't need to be online to receive messages.

Torrents are also a p2p inside p2p network. Yet they are popular.

[zzz]

Interesting. I like the well-known idea.


What's not so great is:

- not much discussion of how to integrate susimail ...
should be easy on the sending side, susimail already talks SMTP as a client
not so easy on the receiver side, susimail doesn't know how to talk SMTP as a server
Or would susimail connect out to the local SMTP server on localhost?
If it's susimail-only, then you don't need SAM
Also, susimail doesn't support multiple "accounts"

- no discussion of how to integrate external clients (e.g. thunderbird)
I guess they would just connect to localhost? How do they know how to send mail to example.i2p?
And would we have to implement a SMTP proxy tunnel, or is that what your C program does?

- Most of us gave up running our own mail server a decade or more ago,
it's not pleasant. This proposal is pretty hand-wavy about the complexities of configuring and running a server,
mail filtering, spam, etc. What mail server would you recommend? Have a config for it?

- If you wanted to run your server on the same destination (set of tunnels) as your website,
that would be almost "free",
you would set that up in i2ptunnel; then you couldn't do SAM;
maybe you'd want to specify the port number in i2pmail.key too.

- You could probably just put the b32 in i2pmail.key, don't need the full b64

I think for this to get any traction and have anybody use it, it would have to be
built-in to susimail and works with thunderbird,
which means not using SAM, and we'd have to write or bundle a SMTP server.

[zzz]

The .well-known solution also means that having a website is a prerequisite to receiving mail, which is another set of tunnels (unless on same tunnels as described above).

We could have a rule that a b32 address could receive email directly? Like example@xxxxx.b32.i2p? Or could we put service identifiers in the leaseset?

Similar to DNS SRV records: https://en.wikipedia.org/wiki/SRV_record

[zzz]

My quick DNS SRV-style proposal:

http://i2p-projekt.i2p/spec/proposals/167

[eyedeekay]

On the negative side: I'm still trying to figure out what concerns we need to be aware of re: spoofing in this hypothetical application, whichever paths we take. However, one thing that does concern me about it is that presumably this is regular email, i.e. not encrypted end-to-end, so it seems like it would be possible that we end up sending email through servers that can snoop the contents. Technically that's already the case now, but because it's just the one server that risk is contained to sysadmins we trust involved in the sending of those emails. I think we should think about whether we need end-to-end encryption here and what we can do to achieve it.

On the positive side: A lot of this sounds very similar to what's already partly implemented in psi's bdsmail which is a samv3 based email server. If what remains could be implemented on top of that, we would neatly sidestep the top 2 issues zzz pointed out, because it already presents a POP and SMTP server, we just configure SusiMail or Thunderbird on top of those. Arguably, it also sidesteps concern number 3, because it is intended to be "Brain Dead Simple" so that anybody could run it. Not pitching for psi's thing exactly here but I'm seeing it tick several boxes. It will definitely require modification if LS2 SRV records become a thing and SAMv3 must change to accomodate them, however.

[zzz]

LS2 SRV is about service discovery; it's not about any particular implementation of a service. I don't know how we build anything "on top" of BDS which is an external SAM app in Go.

But to publish an LS2 SRV, we'd have to simply define a I2CP/SAM config option. Proposal 167 handwaves at that, for now.

[unveiledwrath]

I advocated for simple P2P e-mail elsewhere but my idea is simpler. For one, I don't understand why bother with the well-known thing. Here's what I though about:

Everyone runs their own mail server. I envision it primarily as a Java I2P plugin that comes by default with the Java I2P client and works out of the box without any painful configuration associated with usual mail server setup. No DNS step involved. Mail is directly sent to the destination in the e-mail address.

Addresses look like this:
bob@bobsmaildestination123.b32.i2p
alice@alicesmaildestination123.b32.i2p

Spam is fought like this:
- If the address is in the contacts list, then the mail goes to the inbox directly.
- If the sender is unknown, the mail ends up in the spam folder. The sender receives a reply containing a captcha and/or a proof of work challenge. The mail is promoted to the inbox upon receiving a correct answer to the challenge.

I envision the potential proof of work challenge to be based on Argon2, because I saw it successfully being used in the wild for a similar thing, although RandomX is promising too but I guess more complicated to include. Inspiration for a solver:
https://gitgud.io/kohlchan-dev/kohlcash ... /solver.py

It is very important that if this e-mail solution is to be implemented, it becomes the I2P default. That is, it gets included in the default I2P Java installation and a way to run it with I2Pd is provided too. I2P is filled with abandonware projects. Do we need more? If you're not going to make this included by default, do not bother developing this. It will be a waste. It needs to work out of the box. I need to be able to give simple steps to strangers who have never used I2P before: 1. Install I2P. 2. Enable E-mail plugin. That's already enough steps. Do this or that to install some 3rd party plugin? No!

The primary limitation of this system is that you need to be running the server to receive mail. I'm fine with this. This will be a known limitation that is conceptually easy to explain to users. In exchange, we get to keep things very simple. Besides, it is good for the network to run your I2P node continuously, so this even makes incentive for that. Of course, if the destination is offline, the sender will periodically try again.

As for end-to-end encryption: This is pure destination to destination. Piggy backing fully on I2P. Pure and simple (I hope).

[lgillis]

Everyone runs their own mail server.

Just a quick interjection from me. MuWire has already built this in, email and chat, with short and long addresses. And if someone wants to flood you with garbage, you can lock them out permanently.