search

FusionAuth / fusionauth-issues

FusionAuth issue submission project
https://fusionauth.io
91 stars 12 forks source link

Disallow port 25 configuration for SMTP in FusionAuth Cloud #2848

Open mooreds opened 3 months ago

mooreds commented 3 months ago

Disallow port 25 configuration for SMTP in FusionAuth Cloud

Problem

Because of limitations in our hosting infrastructure, users cannot configure port 25 as the SMTP port for FusionAuth Cloud deployments. (More here.)

Port 25 works just fine in other environments, but not on FusionAuth Cloud.

This is documented, but sometimes gets missed.

Solution

Have any FusionAuth Cloud deployments give immediate user feedback when they try to configure port 25 as the SMTP port for their instance.

I imagine it would be a configuration error message just the same as any other configuration error message, but would only be triggered if a user was running in the FusionAuth cloud environment.

Alternatives/workarounds

Additional context

Internal: https://inversoft.slack.com/archives/C01SHLAP1V3/p1724444792844459

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

lyleschemmerling commented 3 months ago

Great idea, Dan!

robotdan commented 3 months ago

If port 25 doesn't work, why do we need to block it? Does it already fail when they use the test button?

If this is a FusionAuth Cloud specific feature request, should it be moved to a separate repository? There are other considerations for configuring SMTP or any other outbound connection such as a Webhook or Connector when in FusionAuth Cloud, so we may want to address those all together in a separate issue.

mooreds commented 3 months ago

If port 25 doesn't work, why do we need to block it? Does it already fail when they use the test button?

I think the idea is to let users know as soon as they try to save the provider, rather than wait for them to use the test button. If we know something is not going to work, why let the user do it?

If this is a FusionAuth Cloud specific feature request, should it be moved to a separate repository?

I agree that this typically FusionAuth cloud specific feature requests go into a separate repository, but wanted to leave this hanging out here for customer feedback.

I think this is a low priority, nice to have, issue.