RFC: Eep2Eep mails

I2P router issues
Post Reply
User avatar
Posts: 2
Joined: 15 Feb 2024 19:06

RFC: Eep2Eep mails

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

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

  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.
  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.
  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 "" 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
User avatar
Posts: 2
Joined: 15 Feb 2024 19:06

Re: RFC: Eep2Eep mails

Post by 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:
    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
    >   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.
Posts: 32
Joined: 30 Nov 2023 20:08

Re: RFC: Eep2Eep mails

Post by 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.
User avatar
Posts: 176
Joined: 31 Mar 2018 13:15

Re: RFC: Eep2Eep mails

Post by 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.
User avatar
Posts: 176
Joined: 31 Mar 2018 13:15

Re: RFC: Eep2Eep mails

Post by 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
User avatar
Posts: 176
Joined: 31 Mar 2018 13:15

Re: RFC: Eep2Eep mails

Post by zzz »

My quick DNS SRV-style proposal:

User avatar
Posts: 83
Joined: 21 Jul 2018 06:53

Re: RFC: Eep2Eep mails

Post by 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.
Post Reply