Custom email server

[Tcll]

Hello, I've been trying to set up a custom email server (https://maddy.email/ is what I've found that seems to be tiny, easy, and allegedly secure enough to use) which I can use through my eepsite domain rather than relying on mail.i2p, but I can't seem to find any technical information related to what I can do to receive email through my eepsite domain, nvm the gateway I'd also like to rely on to replace my existing email on the open net with my custom server...

Are there any references that could be linked here to make it easier for others to follow??

Thanks :)

[echelon]

Hello

Its a bit of a load, but rather simple.

For clarinet: setup a email server/gateway in clarinet as usual and forward ALL mail to your i2p email server, maybe you need a address rewrite.
For outgoing it is the same, from the i2p mails server, send the email to the clarinet server and that one does relay to the recipient, you do need a address rewrite and a clearnet DNS email MX record, DNS name.

For the email server, just keep it running localhost and set a i2p router with tunnels:
server to receive emails from other I2P nodes to the IP:port of your server/email program
client to send out email to your gateway and point your email software to that IP:port of that client tunnel.

If you want to receive emails in I2P from others, they do need a I2P client tunnel with your I2P destination of your server tunnel in their I2P node.
That way the clearnet gateway, which needs I2P connection/router, connects to your I2P mail service.

echelon

[Tcll]

Hello, and thank you for the detailed response :)

I can't say I've heard of Clarinet, are there any guides for it you can link me to??
(I'm not using I2P+, so if it's listed on that, I wouldn't know about it, also clearnet search engines don't display any results for it either)

Thanks :)

If you want to receive emails in I2P from others, they do need a I2P client tunnel with your I2P destination of your server tunnel in their I2P node.

See, this is kinda the crux of what I wanted to get at, I was hoping to do something that could avoid post-configuration for others, so I was hoping to use the standard ports to link my server to, and then people could just send an email to my (b32/i2p) domain instead

one of the reasons for this is because one of the things I'm trying to host is a forgejo instance for my projects, and if anyone wants to become a contributor, well, for notifications to work, I was hoping they could register their email like you'd typically expect (whatever domain, it shouldn't matter), but it would use my email server to actually forward those connections through I2P

If my idea is kinda skewed, and there's more work that needs to be done to achieve that, I'm up for doing whatever :)

I just hope it can be documented well enough for others to follow on top ;)

[anikey]

I think they mean clearnet (aka the regular internet)

Regarding receiving from other i2p users:
i believe that with current internet protocols (like smtp) that could be possible, but would require writing some programs that would interface with I2P sam bridge, so that they could talk to each other.

Another obstacle to this approach is the fact that in order to use any kind of protocol (in this case, the hypothetical SMTP over SAM) is that you would need to get people to use this setup too (so they, too, will need to use a program that does that thing).

And as a final note, for this approach you would need to have the recipient online, or have your email delayed until both of you are online (because, obviously, otherwise the programs wouldn't be able to communicate).
This might not be viable for everyone.
To solve this problem (in the traditional i2p's distributed style), there would need to be something like a decentralized store (like a DHT) that stores the encrypted emails that weren't delivered immediately...

Hmm.. where could I have seen that before? (I think that's what i2p-bote does, but i haven't used it)

[Tcll]

I think they mean clearnet (aka the regular internet)

Ah yeah if it's for the clearnet (I thought clarinet was something different since they said clearnet at the bottom of their post), that kinda undoes everything I'm trying to achieve :P

I want to hide my IP over the clearnet, and I can only do that through a gateway, which I know susimail has, but I forget the actual clearnet URL for... :P

(I wouldn't be using I2P for any of my stuff if that were the case... lol)

Regarding receiving from other i2p users:
i believe that with current internet protocols (like smtp) that could be possible, but would require writing some programs that would interface with I2P sam bridge, so that they could talk to each other.

Another obstacle to this approach is the fact that in order to use any kind of protocol (in this case, the hypothetical SMTP over SAM) is that you would need to get people to use this setup too (so they, too, will need to use a program that does that thing).

And as a final note, for this approach you would need to have the recipient online, or have your email delayed until both of you are online (because, obviously, otherwise the programs wouldn't be able to communicate).
This might not be viable for everyone.
To solve this problem (in the traditional i2p's distributed style), there would need to be something like a decentralized store (like a DHT) that stores the encrypted emails that weren't delivered immediately...

Hmm.. where could I have seen that before? (I think that's what i2p-bote does, but i haven't used it)

I question if programs actually need to be written though, I feel like the router already offers core mechanisms to share those protocols over

Though you're right about the actual P2P delay nature, where THAT would likely require a program if the email server itself can't delay it (which I think it can, but don't quote me on that... lol)

As for adoption, I'd expect that to be a non-issue as the only real issue there would be susimail not integrating the support
(users wouldn't need to do anything unless they want to set up their own server, since the existing susimail interfaces would add the support for it)

The support COULD be added to the router as an update if need be.

... anyways, thanks for the insight, I hope a working solution can be figured out at the end of this. :)

[anikey]

I want to hide my IP over the clearnet, and I can only do that through a gateway, which I know susimail has, but I forget the actual clearnet URL for...

If i understand you correctly, the internet-to-i2p mail gateway is i2pmail.org. As far as i know, it is only used for Postman's email service. If that's the case, and you want your own email service instead of Postman, then you'll need to make one of these yourself too, if you want to send mail to the regular internet.

I question if programs actually need to be written though, I feel like the router already offers core mechanisms to share those protocols over

I haven't heard of programs that put SMTP over SAM.

Though you're right about the actual P2P delay nature, where THAT would likely require a program if the email server itself can't delay it (which I think it can, but don't quote me on that... lol)

I am talking about when one of 2 servers (sender, recipient) is offline, the mail won't go through. Because to send/receive smtp, the server needs to be online.
There are protocols like Bote which try to resolve this issue by storing the emails in a serverless distributed storage with redundancy, which helps avoid relying on any 1 (or 2) centralized servers.

As for adoption, I'd expect that to be a non-issue as the only real issue there would be susimail not integrating the support
(users wouldn't need to do anything unless they want to set up their own server, since the existing susimail interfaces would add the support for it)

The support COULD be added to the router as an update if need be.

Well for java i2p there is already a plugin for distributed email alternative mentioned above, and it says it does not need servers at all.

[Tcll]

If i understand you correctly, the internet-to-i2p mail gateway is i2pmail.org. As far as i know, it is only used for Postman's email service. If that's the case, and you want your own email service instead of Postman, then you'll need to make one of these yourself too, if you want to send mail to the regular internet.

Yeah it's called "Susimail" (alternatively "I2P Mail") in my router:

clipboard.png (2.61 KiB) Viewed 708 times

But the links do take me to postman.i2p

Anyways, my point was that I'd be able to use their gateway to recieve email to my server through...

Thus all the talk about them integrating whatever programs were needed in relation to adoption to achieve that

Hosting my own gateway wouldn't hide my IP, so as previously mentioned that's not an option. :P

I haven't heard of programs that put SMTP over SAM.

I never mentioned SAM, I'm just speaking in general forwarding ports over the router
(What I could use to integrate with Susimail/Postman)

The reason I'm uneasy with using Susimail/Postman is because my emails are stored on their servers

Hence why I want to host my own server, so my emails are stored on my devices instead, where Susimail/Postman would forward to my server replicating traditional email functionality (eg: how gmail is able to email protonmail over the clearnet, susimail/postman would be able to email my server over I2P)

I'd just need to know what I2P ports to bind my server to for that to work appropriately when creating my tunnels

so like for SMTP, I2P doesn't use port 25, it uses 76## which I'd create the tunnel for

(Btw no I'm not saying Susi is untrustworthy, just that it should be the general practice to not rely on a central server, even if it's reliably on 24/7)

I am talking about when one of 2 servers (sender, recipient) is offline, the mail won't go through. Because to send/receive smtp, the server needs to be online.
There are protocols like Bote which try to resolve this issue by storing the emails in a serverless distributed storage with redundancy, which helps avoid relying on any 1 (or 2) centralized servers.

P2P delay is when 1 of the 2 parties involved is offline, what's intended to be sent needs to be delayed until both parties are back online
(If I had to provide an example, Tox chat clients like uTox do this reliably, even if you close the sending client, and I'd figured some email servers would do similar for SMTP)

But when you say "distributed storage", would that be within the local router's cache storage, or would that involve another server/router??
(I'd expect it to be similar to uTox where my router would need to be online for me to send my email, and delay my email if the other party can't be reached, not cached on someone else's router, though if what's cached on their router is encrypted, that won't matter so much)

Well for java i2p there is already a plugin for distributed email alternative mentioned above, and it says it does not need servers at all.

I'm guessing that's i2p-bote, right??

Don't mind me questioning things btw, I'm just trying to clear up technicalities as I don't understand much beyond setting up local tunnels, nvm knowing what's available :)
(I have an idea as to how I'd expect things to work regarding P2P federation (locally encrypted cache and all that), but don't know the actual mechanisms within I2P for such)
^ I'd also prefer to avoid additional software if I can, since I'd expect I2P's internal mechanisms to be much more secure. ;)

Thanks for working with me on this. :)

[zzz]

What you're asking how to do is not supported by anything or anybody and hasn't even been contemplated, at least not in a long time.

There's currently an inbound and outbound mail gateway, run by echelon, that's dedicated to the mail service run by postman. Together, they provide the current email services. "susimail" is just a web UI and local cache, that is, more or less, hardcoded to point to postman's services. Susimail can be replaced by any mail client, such as Thunderbird, pointing to the POP3 and SMTP ports on localhost, and lots of people use postman's services that way.

So, if you want to run your own server, you need to find somebody to be your gateway for emails into/out of I2P. Maybe you can work that out with echelon. Or maybe echelon just forwards everything to postman and you can work it out with postman to do the forwarding. Maybe StormyCloud (our web outproxy operator) could be brought in to provide some gateway services.

Then, you'll have to fix up your MX records to make it all work.

Now, assuming you can find somebody to do the gatewaying for you, if you don't trust them, you have to design and setup all the security stuff correctly. You'll need the TLS/SSL stuff and related MX things set up. And you can't let the gateway have your private keys, you'll need them to transparently relay the inbound TLS session to you. For outbound, again, you'll need some transparent path, maybe via SOCKS, so the gateway can't spy on your outbound messages.

The gateway will have to trust you not to be sending a ton of spam, or rate limit you, and deal with any abuse reports.

And if everybody starts running in-i2p servers, then they have to figure out how to talk to each other directly, not via gateway-to-gateway, and that's another mess. We have no standardized in-i2p DNS service, no in-i2p MX records, etc. One proposed solution is Gnunet GNS, which is a huge and complex bag of stuff. Look on zzz.i2p for info about it.

tl;dr there's no turnkey solution and you'd have to design and implement it in partnership with somebody willing and able to provide you the gateway services both inbound and outbound.

[Tcll]

What you're asking how to do is not supported by anything or anybody and hasn't even been contemplated, at least not in a long time.

Dang, I was hoping there's been at least something going on behind the scenes, but ah well

At least maybe something can be done now :)

There's currently an inbound and outbound mail gateway, run by echelon, that's dedicated to the mail service run by postman. Together, they provide the current email services. "susimail" is just a web UI and local cache, that is, more or less, hardcoded to point to postman's services. Susimail can be replaced by any mail client, such as Thunderbird, pointing to the POP3 and SMTP ports on localhost, and lots of people use postman's services that way.

I had an inclination it was something like that, but couldn't be certain as I didn't understand the app, thanks for clarifying. :)

So, if you want to run your own server, you need to find somebody to be your gateway for emails into/out of I2P. Maybe you can work that out with echelon. Or maybe echelon just forwards everything to postman and you can work it out with postman to do the forwarding. Maybe StormyCloud (our web outproxy operator) could be brought in to provide some gateway services.

It's cool that echelon is hosting the gateway, and I hope that continues as well :D

Yeah I was hoping to just integrate with what's existing and have things kinda just automatically work without any extra setup

Then, you'll have to fix up your MX records to make it all work.

Now, assuming you can find somebody to do the gatewaying for you, if you don't trust them, you have to design and setup all the security stuff correctly. You'll need the TLS/SSL stuff and related MX things set up. And you can't let the gateway have your private keys, you'll need them to transparently relay the inbound TLS session to you. For outbound, again, you'll need some transparent path, maybe via SOCKS, so the gateway can't spy on your outbound messages.

See that's the thing, just as I don't want to have to add specific connections, I also don't want others to have to add specific connections for me

I'd prefer something standard be setup that I can just interface with without having to talk to anyone to add me or me add them

if email servers can do that pretty nomally over the clearnet, why should it be any different over I2P ;)

The gateway will have to trust you not to be sending a ton of spam, or rate limit you, and deal with any abuse reports.

I don't do that stuff anyways, so nobody would have anything to worry about with me there ;)

And if everybody starts running in-i2p servers, then they have to figure out how to talk to each other directly, not via gateway-to-gateway, and that's another mess. We have no standardized in-i2p DNS service, no in-i2p MX records, etc. One proposed solution is Gnunet GNS, which is a huge and complex bag of stuff. Look on zzz.i2p for info about it.

I should also note my idea

Code: Select all

   forum - clearnet - tutanota
              |
           gateway
              |
           postman
              |
     forum - I2P - email - gateway - <clearnet> - my web client
              |
     email - I2P
              |
my forgejo - I2P - my local client
              |
          my email

tutanota and every email server should be able to send emails to or recieve emails from my or other email servers

I should be able to register my email on both forums and my forgejo

the users behind their other email servers should be able to register their emails with my forgejo and both forums

my local client should be able to view emails from tutanota over I2P

my web client should be able to view emails from my email server (different domain from what tutanota would see since it's a different gateway)

tl;dr there's no turnkey solution and you'd have to design and implement it in partnership with somebody willing and able to provide you the gateway services both inbound and outbound.

I just need to know the standard ports to bind my server to so everything can work

whatever port has been decided for SMTP and such over I2P, I'd expect maddy to be compatible with (set and forget like the clearnet)

And yeah, there'd have to be TLS and SOCKS stuff to help protect the contents within the connection, that's a given ;)