[PB-1960]: feat/implement mail account provisioning and recovery email functionality by jzunigax2 · Pull Request #1019 · internxt/drive-server-wip

jzunigax2 · 2026-03-31T01:22:03Z

Introduced Mail module with MailService and MailController for handling mail account creation.
Implemented MailUseCases to manage mail account provisioning and validation.
Updated user model to support recovery email and added necessary DTOs for mail account creation.
Enhanced audit logging to track mail setup actions.
Attempting a log in with an internxt owned email domain would promt an address search on mail-server

apsantiso · 2026-04-08T15:28:16Z

+    dto: CreateMailAccountDto,
+  ): Promise<{ token: string; newToken: string; address: string }> {
+    await this.assertMailAccessEnabled(user);
+    this.verifyPassword(user, dto.password);


Do we expect users to send their password when creating an email address? What's the flow for this?

If not, you could try to use the gateway for any check you need and create the mail directly from mail-server instead.

I guess it depends on the other comment.

If the user uses a @inxt.com (example) to login, Drive (because it contains the auth) should ask mail to locate the uuid here by that username, and with that uuid and the password, match against drive.users. Am I wrong @jzunigax2 @apsantiso ?

In consequence, we should not ask for the password here

@sg-gs this is intended as a flow that runs the first time a user acceses mail. they choose their new internxt email address and must re enter their password right before submitting.

if succesful they would now use their new internxt email address to login and their original email becomes their recovery email.

however I do agree with @apsantiso there are many edge cases, I guess all email comunications would have to defaut to recovery email if available

Okay then, anyway, use the gateway to check the password against the auth source of truth (right now, Drive)

hmm, the reason this logic lives here in drive rather than mail is that at this point in the flow mail-server has zero user context, it doesn't know if the user exists, is authenticated, or has mail access. All of that lives here in drive.

The flow is:

User exists and is already authed (drive validates the token)

Drive checks the feature limit (mail access on their plan)

Drive verifies the password re confirmation

Drive calls mail-server via mail's gateway to provision the account

Drive handles the auth side-effects like updating the email, issuing new tokens

We can also share the token at some extend like we did with VPN @jzunigax2. Just throwing ideas tho. Not sure if that aligns with what @sg-gs thought

apsantiso · 2026-04-08T15:45:00Z

+      await this.userRepository.updateByUuid(user.uuid, {
+        email: fullAddress,
+        recoveryEmail: previousEmail,
+      });
+    } catch (error) {
+      await this.userRepository.updateByUuid(user.uuid, {
+        email: previousEmail,
+        recoveryEmail: null,
+      });
+      throw error;
+    }
+
+    const updatedUser = await this.userRepository.findByUuid(user.uuid);
+
+    const { token, newToken } =
+      await this.userUseCases.getAuthTokens(updatedUser);
+
+    return { token, newToken, address: fullAddress };


Do we really want to change how drive-server works and identifies users because of mail?
If the user downgrades then we would need to change the email again. I know it seems to be a product decision, but it could create strange edge cases here.

It might be worth to re-check this with product @jzunigax2 @sg-gs

At product level they want to make possible to login with your @inxt.com mail, which means we should match that, but just in case the user has mail enabled.

Ok, what about preserving the email field as it is and store the internxt email in another field or even table (I would go for the second option to support multiple emails in the future)?

If the user wish to change their primary email they can always change the email manually. @jzunigax2 @sg-gs

The only downside I see is related to any sharing/workspace operation that requires searching by mail. We would need to change the mail search in those usecases

Anyway, we need to think about the downgrade process. We would need to prevent new users from signing up with the recovery_email too.

Anyway, we need to think about the downgrade process. We would need to prevent new users from signing up with the recovery_email too.

Isn't this already handled by the signup itself? Or am I missing something?

Ok, what about preserving the email field as it is and store the internxt email in another field or even table (I would go for the second option to support multiple emails in the future)?

If the user wish to change their primary email they can always change the email manually.

At our level (before Stalwart) I assume we should have the local-part (this naming comes from https://datatracker.ietf.org/doc/html/rfc5322) multiplexing per user on another table.

The only downside I see is related to any sharing/workspace operation that requires searching by mail. We would need to change the mail search in those usecases

Why? I mean, we will search by the local-part and from there, get the user (in case you need the search to find the user) or are you referring to something else?

Why? I mean, we will search by the local-part and from there, get the user (in case you need the search to find the user) or are you referring to something else?

@sg-gs I mean we should change how we search for the user in the "invite user" usecase, which uses the email address to find the user. Not a big deal as we use mainly uuids tho. If I can login with john@internxt.com too, I would expect other users to find me as john@internxt.com too.

Isn't this already handled by the signup itself? Or am I missing something?

No, the current status of the code switches the user's original email to recovery_email and the internxt's email becomes the new 'email'. That's why I jumped in, as changing the main email would lead to weird things. IMO we should store the data like this:

Primary email: XXX@original-external-mail.com
Mails associated

xxx@internxt.eu

yyy@internxt.whatever

So when the users want to log in, we just need to search for the primary email + associated mails (local-parts, whatever we do).

Instead of switching them:

Primary email: xxx@internxt.eu
Recovery email

XXX@original-external-mail.com

I may be missing things so correct me if I'm just pushing things blindly haha

@sg-gs I mean we should change how we search for the user in the "invite user" usecase, which uses the email address to find the user. Not a big deal as we use mainly uuids tho. If I can login with john@internxt.com too, I would expect other users to find me as john@internxt.com too.

Let's assume this happens, in both ways:

An Internxt user that has multiple mail extensions is invited to an item. Receives the email, joins with a token, Drive's session is the same, it works.
a. The internal invitation notifications will still appear as it is invited using its uuid. (which mail would have also)

An Internxt User that does not have Mail --> not affected.

So I do not see any issue here

That's why I jumped in, as changing the main email would lead to weird things
This could be visual. I won't change it internally. Just do the following:

User without mail -> works as always.

User using a internxt mail domain -> ask Mail for the uuid, get the password on Drive with that uuid -> match password.
And Drive would still have the same thing: email, password, uuid
And Mail would store: uuid, mail.localParts.userId -> mail.users.uuid (FK), mail.localParts.value (here, there would be as many rows per user as different domains it can have)

…ality - Added migration to include recovery_email field in users table. - Introduced Mail module with MailService and MailController for handling mail account creation. - Implemented MailUseCases to manage mail account provisioning and validation. - Updated user model to support recovery email and added necessary DTOs for mail account creation. - Enhanced audit logging to track mail setup actions.

- Deleted migration for recovery_email field in users table. - Refactored MailService and AuthController to remove recovery email handling. - Updated MailUseCases and user model to eliminate recovery email references. - Introduced managed mail domains logic for email resolution in login process.

sonarqubecloud · 2026-04-16T12:17:49Z

Quality Gate failed

Failed conditions
47.6% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

jzunigax2 · 2026-04-16T12:21:03Z

@sg-gs @apsantiso addressed concerns, removed recovery mail stuff and the email replacement logic. I'll improve test coverage, but in the meantime does it look good overall?

sg-gs · 2026-04-16T13:55:05Z

I think this should not be part of Drive, rather than from payments.

sg-gs · 2026-04-16T13:56:23Z

+    const userId = await this.mailService.findUserIdByAddress(email);
+    if (!userId) return email;
+
+    const user = await this.userUseCases.findByUuid(userId).catch(() => null);


Don't hide errors, log or let them propagate

sg-gs · 2026-04-16T13:57:52Z

+    private readonly mailService: MailService,
  ) {}

+  private async resolveLoginEmail(email: string): Promise<string> {


This is part of the login logic, I will add it to the auth.service, not in the controller, as this applies to the login itself, with independence of the web login or the CLI one

sg-gs · 2026-04-16T13:58:42Z

+import { AuditLog } from '../../common/audit-logs/decorators/audit-log.decorator';
+import { AuditAction } from '../../common/audit-logs/audit-logs.attributes';
+
+@Controller('mail')


Why is this here? Shouldn't this be on mail-server?

jzunigax2 · 2026-04-22T12:40:41Z

closing in favor of internxt/mail-server#25

jzunigax2 temporarily deployed to development March 31, 2026 01:22 — with GitHub Actions Inactive

jzunigax2 self-assigned this Mar 31, 2026

jzunigax2 added the enhancement New feature or request label Mar 31, 2026

jzunigax2 temporarily deployed to development March 31, 2026 03:59 — with GitHub Actions Inactive

jzunigax2 had a problem deploying to development March 31, 2026 03:59 — with GitHub Actions Failure

jzunigax2 force-pushed the feat/mail-account-creation-flow branch from 5886722 to a07353d Compare March 31, 2026 04:21

jzunigax2 temporarily deployed to development March 31, 2026 04:21 — with GitHub Actions Inactive

jzunigax2 force-pushed the feat/mail-account-creation-flow branch from a07353d to c0b82e5 Compare March 31, 2026 04:31

jzunigax2 had a problem deploying to development March 31, 2026 04:31 — with GitHub Actions Failure

jzunigax2 temporarily deployed to development March 31, 2026 04:31 — with GitHub Actions Inactive

jzunigax2 force-pushed the feat/mail-account-creation-flow branch from c0b82e5 to 6452a6b Compare March 31, 2026 04:44

jzunigax2 temporarily deployed to development March 31, 2026 04:44 — with GitHub Actions Inactive

jzunigax2 marked this pull request as ready for review March 31, 2026 04:48

jzunigax2 requested a review from apsantiso as a code owner March 31, 2026 04:48

github-actions Bot added the ready-for-preview label Mar 31, 2026

apsantiso requested changes Apr 8, 2026

View reviewed changes

jzunigax2 added 2 commits April 15, 2026 11:56

test: add unit tests for MailService, MailController, and MailUseCases

dd84afb

jzunigax2 force-pushed the feat/mail-account-creation-flow branch from 6452a6b to dd84afb Compare April 15, 2026 09:56

jzunigax2 temporarily deployed to development April 15, 2026 09:56 — with GitHub Actions Inactive

jzunigax2 temporarily deployed to development April 16, 2026 12:14 — with GitHub Actions Inactive

jzunigax2 requested review from apsantiso and sg-gs April 16, 2026 12:18

sg-gs reviewed Apr 16, 2026

View reviewed changes

jzunigax2 closed this Apr 22, 2026

Conversation

jzunigax2 commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apsantiso Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apsantiso Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud Bot commented Apr 16, 2026

Quality Gate failed

Uh oh!

jzunigax2 commented Apr 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jzunigax2 commented Apr 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jzunigax2 commented Mar 31, 2026 •

edited

Loading

apsantiso Apr 8, 2026 •

edited

Loading

apsantiso Apr 9, 2026 •

edited

Loading