Option to disable verification email

[sashahilton00]

Would the maintainers be open to the option of disabling the verification email that gets sent when a new mailbox is created?

The scenario we are looking at, and the rationale for this is as follows:

We are looking at using SimpleLogin as part of our email infrastructure. As part of regular business ops, we have several providers, and several organisations, each with multiple end users. These parties need to communicate with eachother on a semi-regular basis, and often in an unexpected manner. Given that there are various regulations around end user email sharing (eg. GDPR), and providers are located in different jurisdictions, we're looking to avoid any issues with that by masking emails for all parties behind aliases.

As part of user onboarding we would create a mailbox in SimpleLogin for the user, and onboard them with any relevant providers. From a UX perspective, a signup email from us, followed potentially by several automatic onboarding emails from various providers, and a verification email from SimpleLogin, is not optimal. We'd prefer to be able to create a verified mailbox without additional end user input via the API.

There are a few additional features that one would disable, such as the one click unsubscribe link, as the emails are guaranteed to be transactional in nature. Additionally one may choose to disable the user dashboard.

Is this something that could be of interest?

[nguyenkims]

@sashahilton00 unfortunately the mailbox verification can't be disabled in SimpleLogin as a bad actor can spam a victim by adding victim mailbox address on SimpleLogin. For your use case, you can self host SimpleLogin and customize the mailbox addition part to not sending verification email.

[sashahilton00]

That makes sense. If we work around the potential spam issue is it something that you guys would be interested in merging back? What we're thinking is as follows:

• No verification email on signup
• No one click unsubscribe in emails (for transactional usage)
• No dashboard enabled for end users (ie. no signup or management features)
• MFA disabled
• Signups via API only. This would require a refactor of some parts to provide an additional layer of authentication - either a static "service token" that indicates a trusted service is making the request, or some form thereof, such as a signed JWT.

Obviously this is quite a niche use-case for SimpleLogin, though it doen't look infeasible to wrap such functionality up behind a config variable such as HEADLESS_SERVICE_MODE=1 or similar.

Nevertheless, we'll fork it and see if we can make something useful for our use case.

[nguyenkims]

@sashahilton00 As the features are quite specific, we wouldn't merge them back indeed. I'd suggest to fork the repo and add the needed features. It's best to keep the features quite independent so you can update your code later without conflict.