YourMailer: A blochain-based email service

Cartesi Grants Program CGP Pilot
1

Problem Statement

In early 2023, Bard (Google’s A.I chatbot) made claims that Google used Gmail data to train its A.I model. Part of this data included users’ personal emails and conversations.

This brings into focus whether we can trust these big companies that manage our email servers, hence the need for a decentralized email service - YourMailer.

Aims and Objectives

  • To build an email service where all interactions between the client and server are logged onto the blockchain (1)
  • To build an email service where any access to user data is logged onto the blockchain (2)

Project Benefit to the Cartesi Community

Here are the key reusable features or ideas that YourMailer brings to the Cartesi community:

  1. An architecture that can be used by other messaging apps that want to deploy on Cartesi. The design ideas can also be reused. E.g the proxy and data processing design

  2. API for integrating YourMailer in any Web2 or Web3 application.

  3. Anyone can fork the repo & customize the email DApp. Ideally, corporate and other private entities that would like to manage their own domains & mail servers.

How the Email Service Works

Architecture
Architecture746×426 32.6 KB

This is a description of the architecture.

  1. On the client side, you have an email client. For this, you can use an open-source email client called Thunderbird.

  2. The email client interacts with the Nginx server. This server is a transparent proxy that is used to route email requests for various email protocols (IMAP, SMTP, POP3).

  3. By design, Nginx requires that you have an HTTP Authentication server that will determine the Upstream server for a given email request. We will use the embedded Tomcat Server, which ships with Spring Boot for our email service. The authentication server can also carry out some processing defined by the logic in your code.

  4. This authentication server is where our application will interact with the Cartesi Rollups. Our application frontend sends a hash of the email body to the blockchain. Our Cartesi backend then gets the data (i.e. the hash) and sends it to the Authentication server. This server checks if the hash matches the one it has.

If yes, it sends a response to the Nginx proxy allowing it to route the email request to the appropriate Upstream server and port.

  1. The Upstream server is Java Apache Mail Enterprise Server(JAMES). This processes the email request and relays it back to the Nginx server.

Milestones

Milestone 1 (2 weeks )

  1. Building the PoC. Objective (1), should be achieved. The demo setup will be in a local development environment.

After completing this milestone, the following should be realized:

  • Users can send/ receive emails using their email client with the standard protocols and ports ( IMAP, SMTP, and POP3).

Funds request for milestone 1: $ 1500

Milestone 2 (5 weeks + 1)

  1. Web interface for accessing mail
  2. Create and deploy Rollups Smart contract to Ethereum Goerli
  3. Deploy DApp validator node to Cartesi infrastructure
  4. Provide options for data storage:
  • Decentralized
  • OR other centralized service providers like Google Drive or One Drive)

After completing this milestone, the following should be realized:

  • Users can access emails using a standard Web browser over the internet. The web interface is where users will be able to access information about their previous account interactions.
  • Users can choose where their data is stored

Funds request for milestone 2: $ 2800

Milestone 3 (3 weeks + 1)

  • Secure the mail server
  • Performance tuning
  • Engage various communities about the product ( will be very grateful for help from Cartesi when it comes to this part!)

Deliverables:

  • Provide a Report

Funds request for milestone 3: $ 1500

===========================

Total funds requested: USD 5,800

ERC 20 Address: 0xaDb7fC24BbEaF6af359d2d4b1c5AB97013B26a63

About the team:

Currently, 1 member. If approved, will onboard 2 more team members.

Portfolio work:

  1. Participated in Cartesi Online Hackathon 2023 (This very project)
  2. Roulette (Cross-chain game built on Axelar using Chainlink’s VRF)
2

Thank you for the proposal, and the illustrations. Can you tell me if your POC that you allude to includes Cartesi functionality or is it only web2?

As for your request for engaging various communities, of course the Cartesi project’s units are here to connect you to the broader ecosystem.

For transparency, this project proposal was submitted as a rapid grant before they were discontinued in favor of forum-only “lean” submissions. And one point of concern from the grants council was that although this is a neat idea, they were not sure that it was technically feasible for use with Cartesi tech. Let’s wait for their feedback.

3

Thanks for your response.

Yes, the application always includes Cartesi functionality. Otherwise, it would defeat the purpose of creating the application in the first place.

Let me go a little more into the details:

The server side always uses Cartesi Rollups. Hence, it’s always a Web 3 application. The server side includes the Nginx mail proxy, the HTTP authentication server that interacts with Cartesi Rollups, and the JAMES mail server - as shown in the diagram.

However, on the client side, it’s different. There are 2 ways in which we can have the client:

  1. Desktop or mobile email client( such as Thunderbird or Samsung Email or Gmail mobile app)
  2. Web browser

In both cases, the client is a Web 2 application. Remember: a key design decision in building this email service is that users continue to use familiar technologies & infrastructure. Therefore, no change at all in how users usually interface with their email service.

Access through the Web browser is where some extra functionality that isn’t in traditional email apps will be included.

For example, through the Web app, users will be able to:

  • View their account access history ( hashes, time, etc)
  • Choose between centralized or decentralized storage for their email data
4

Hello!

A decentralized email would be quite a cool addition to a decentralized suite of tools! But I’m not sure Cartesi rollups (or even the blockchain) is a good fit for this.

Are you using Cartesi just for data availability? Cartesi Rollup applications do not have the ability of sending information to web2, so I don’t understand how it would send the data to the Authentication server. Or, if the authentication server is running inside the Cartesi Machine, it woulnd’t have the ability to foward that to the NGINX proxy running outside it.

Also, woudn’t this represent a privacy issue? Would everyone have access to the emails that you sent? I mean, even if the body is not available because you just send the hash, they’d know the sender/recepient right? But, at the same time, if the body doesnt touch the blockchain how does the recepient has access to it? I’m a little bit confused by this design.

Bear in mind that I don’t have any experience with the tools and protocols that you’re mentioning, so I might be way off here.

Thanks so much for sending a proposal! I hope you don’t feel put off by the questions, I’m just trying to understand the project : )

5

No problem at all. The better the community understands the project, the easier it is to make a decision.

I believe these are the questions that you are asking:

1. Why use blockchain? Why not just Web 2?

First, let’s go back to the problem we are trying to solve - we do not trust that the centralized email providers are "playing by the rules " that they claim to be adhering to.

At the moment, the blockchain has proven to be a secure publicly verifiable way to keep a trustless account of events. Must the verification be public? Yes - otherwise, we would still have to trust whatever measures they claim to have in place to guarantee that there’s no access to a user’s server/data without their prior authorization/consent.

2. Why Cartesi? Why not any other blockchain service? Why the design decisions?

The best way to answer this is by using Attribute Driven Design (ADD). ADD is a set of steps for designing an architecture to satisfy both quality requirements and functional requirements.

Please note that you don’t need to understand how ADD works to follow through with the explanations below. ( I’ll do my best to make the description as reader-friendly as possible).

To begin with, the process takes in the following three inputs: function requirements, quality attributes, and design constraints. The output is the software architecture.

After ensuring that we have enough requirements to build our system, we can choose candidate architectural drivers. These are simply considerations that have a system-wide impact on the architecture of the system. In our case, the design constraints are the major architectural drivers.

Now, ADD follows a stepwise refinement approach i.e. the output of the previous step serves as a basis for the next. Let’s see this is in action:

The first constraint (C1) on our email service is that it should use blockchain for all interactions between client and server.

So we have this:

Client----- Blockchain----- Server

Our second constraint (C2) is that the client should continue to use familiar technologies (i.e. the protocols (IMAP, SMTP…) and ports (143, 25…). This constraint is necessary unless we are planning on building our own email protocols! Let’s see how C2 affects our design.

Now, we know that smart contract platforms like Ethereum don’t use email protocols for their interaction. That leads us to use a blockchain solution that can have our email protocols.

Here is where Cartesi comes in. We can place our email server on the Cartesi infrastructure while still incorporating blockchain in our email solution.

About the design

Now, our problem is where to place the Cartesi Frontend. If we place it on the client side, that would mean creating a new app for the user to download ( and “possibly” violating C2). So now our Cartesi frontend is on the server side (C3) - and of course the backend as well.

Our problem is now to ensure that email communications are routed through Cartesi before reaching the email server, hence the Nginx mail proxy.

3. How secure is the email data via decentralized storage?

First, it’s important to acknowledge that there are various models of decentralized storage.

It’s possible to have private data accessible in a decentralized manner. There are many things to consider here: access control, provenance, etc. You can check out database projects like Chromia & Ocean Protocol to see how you can build a decentralized database system.

6

I noticed that I didn’t clearly answer some of your concerns. Here is a more curated Q&A based on your questions:

Yes, all the server-side components run in the Cartesi Machine. Please note that this is only for the initial concept - the MVP.

Client-Cartesi

However, if we were to scale the application later, then we would put:

  • The Nginx server in its own Cartesi Machine
  • Multiple JAMES servers in their own Cartesi Machine. An authentication server would also be included in each instance.

We would have an architecture like the one below:

Scaled Client-Cartesi
Scaled Client-Cartesi817×682 42.9 KB

Each component still performs the same role as described. The only difference is that the Nginx server gets to choose which IP to route a request ( load balancing )

You also asked about information flow. In particular, what role the Cartesi Rollups plays:

[“Are you using Cartesi just for data availability?”]

Cartesi Rollups acts as our receipt book for client-server interactions. Remember, our goal is to ensure that the email provider “plays by the rules.” That is, they do not access our data or email server without our prior authorization.

So why not make them log every interaction to the blockchain, where we can verify for ourselves what took place & when. By posting a hash on the Rollups network, we are doing this.

[“I don’t understand how it would send the data to the Authentication server. Or, if the authentication server is running inside the Cartesi Machine, it wouldn’t have the ability to forward that to the NGINX proxy running outside it.”]

Nginx is a proxy server. Just like any proxy, its work is to forward requests. However, the Nginx design allows you to first send the request to an HTTP server that has some custom logic. In our case, we have the Cartesi frontend & backend logic here.

After the server is done with whatever processing, it sends the following HTTP response to Nginx (if successful):

HTTP/1.0 200 OK
Auth-Status: OK
Auth-Server: # the server name or IP address of the upstream server that will be used for mail processing
Auth-Port: # the port of the upstream server

[“Also, wouldn’t this represent a privacy issue? Would everyone have access to the emails that you sent? I mean, even if the body is not available because you just send the hash, they’d know the sender/recipient right?”]

We are only sending a hash of the email message. During development, we might actually consider hashing 4 things: email body + sender + receiver + timestamp. Therefore, there is no way of telling the sender or receiver from the blockchain data.

However, from the Transactions Dashboard in the Web app, a user can get the data that was hashed and rehash it manually to verify if indeed that was the data used to generate the hash on the blockchain.

[“But, at the same time, if the body doesn’t touch the blockchain how does the recipient have access to it? I’m a little bit confused by this design.”]

There are other possible interactions with the email server. For example, logging in or requesting to view past emails. In such a case, they would simply hash the request type (& some important details).

Let’s look at a use case of a user that would like to access their emails:

The email client sends a request. The Nginx server receives it and generates an HTTP request.

Here is a sample HTTP request body from the Nginx server to the authentication server:

GET /auth HTTP/1.0
Host: localhost
Auth-Method: apop
Auth-User: user
Auth-Salt: 238188073.1163692009@mail.example.com
Auth-Pass: auth_response
Auth-Protocol: imap
Auth-Login-Attempt: 1
Client-IP: 192.0.2.42
Client-Host: client.example.org

Now, at the auth server. For the login request above, we could hash the IP + Protocol + Encrypted Password. After our Cartesi backend has validated that this hash has been recorded on the blockchain, the Auth server will send an HTTP Response to Nginx directing it to send the request to the appropriate email server (i.e IMAP server in this case)

The email server will then process the request, send a response to Nginx and Nginx will relay this message back to the client.

I hope this use-case scenario has brought things into perspective :slight_smile:

7

@felipeargento @joe-cartesi any comments for me?

8

Thank you for the very detailed answers to the questions presented. As far as the requirements for responding to inquiry in a clear, and detailed manner, I feel you have accomplished this.

What stands now, is for some of our technical committee members to give their endorsement to move this proposal to a vote, if they are convinced that your responses have sufficiently addressed their concerns.

9

Hi there, I still struggle to understand a basic design concept.
When you say you are only sending a hash of the message, I wonder where the original email data lives. Only in the client? How does ‘JAMES’ get access to the email body and recipients?

10

When the email request reaches Nginx, it (Nginx) makes a copy of the request and translates it into an HTTP request. This request is sent to an HTTP server ( our authentication server).

The auth server processes it using the custom logic we have defined there.

After it will send an HTTP response to Nginx telling it “OK, now you can send the original email request to this server and port.” Alternatively, the auth server could tell Nginx to drop the email request.

Ideally, our Auth server is the brains of Nginx server. It tells the Nginx server what to do with the email request.

[I wonder where the original email data lives. Only in the client? How does ‘JAMES’ get access to the email body and recipients?]

So to answer your question. Nginx forwards the original email request to JAMES ( of course, after our auth server has told it to do so).

Then, JAMES processes the request and stores it on the database server it’s connected to.

I hope that I’ve answered your question

1 Like
11

Hey @mavelricks! First thanks for making your submission and for clearly putting a lot of time on thinking about this.

I do have some doubts about the project, specially considering the motivation (not allowing your email data to be processed by 3rd parties without your consent). The first doubt I have is that I am assuming the JAMES server is running natively on a 3rd party machine (controlled by the 3rd party email provider) and that the Cartesi “transparent, reproducible and verifiable” interactions are restricted to the authorization server (which interfaces with the nginx proxy). If that is the case, you would have to trust this 3rd party provider not to do anything nasty with your data as if they did you would have of no evidence of that (they have direct access to the machine running the JAMES server, including the files/database in with email data are stored into - Apache James Server 3.0 - Apache James Server 3 - Dev - Database Schema). Also there would be no guarantees the 3rd party is actually running a reference node for your email application - you have no way of detecting that from the authenticator Cartesi-running code AFAIU.

I do think the problem you want to tackle is extremely relevant, but I’m unsure of how to implement it given the requirements (no unauthorized access/usage of your email data, running the email server on a 3rd party machine, compatibile with current email standard). Both me and the rest of my team (Prototype and Support Unit) are available to have a call with you and would love to brainstorm and try to come up with some way to tackle this.

1 Like
12

Hello @carlofragni . Thanks for your response. I’m going to reach out to your team on discord

1 Like