Set SMTP relaying configuration with environment variables

[PabloLec]

Hello,

More of a question than a problem, currently, the SMTP relaying configuration can only be done with a yml file. Typically in my case, MailPit runs in a Docker container, the configuration is minimal but I have SMTP relaying enabled which forces me to mount a file from the host to the container. This makes my installation less portable and it weighs down the whole thing for 3 config strings.

In my case, the ideal would be to be able to set these values as environment variables. The SMTP relaying configuration is simple, there are few fields and no exotic types. Would it be conceivable to make the SMTP relaying configuration accessible, or do you see a downside?

[axllent]

Hi @PabloLec. That is a very valid question. Initially the reason for this was so that passwords etc wouldn't be in any environment variables (which can be read by anyone with docker access, however since then (due to requests) both the frontend and SMTP (receiving) passwords can be set in the environment, so that isn't a valid reason any more.

The "issue" I have with this approach is that it I would have to add all SMTP replaying configuration options, which introduces an additional 10 environment variables into the mix, and so 10 additional variables I need to separately test for and validate. Currently I calculate a total +-41 existing flags/env runtime options which I find already excessive, and this would increase that by nearly 25% just to add one feature.

Trust me, I do hear you and understand your use-case, I'm just not sure of the best approach. That runtime page with all the currently options scares to a bit to be honest (and I'm the author!), so I'm sure that's overwhelming for anyone just getting started. I can't think of any elegant solution to this problem though. I'm away at the moment so can't dig deeper into this, but in the meantime I'm open to suggestions.

[PabloLec]

Hi @axllent, thank you for your response.

Regarding testing, are there any unit tests for environment variables or configuration or are we talking about manual testing during implementation?

I understand the concern about overloading the documentation and how giving too many options to the user can create confusion. However, the possibility of configuring via various means (file, environment variable, CLI options) seems quite common to me. It's definitely a nice-to-have feature, especially if a good portion of the options can already be configured with environment variables. It can be frustrating if 100% of the configuration isn't possible this way. Well, that's my opinion, and yes, I'm trying to convince you it's a great idea 😄

Regarding the documentation, indeed, the "Runtime options" page might become quite crowded. Maybe for clarity, the page could be divided into sections, somewhat mirroring the structure of the Configuration menu in the sidebar.
But personally, I don't find it shocking to have a long options page, it's a reference after all. There's the search function, generally, someone will consult this page for a specific need. Moreover, it's entirely subjective, but I think the "Runtime options" page could be placed at the bottom of the "Configuration" menu in the sidebar. It's a more technical documentation page, less descriptive and educational than the others in this section.

In short, I don't have too many ideas. But my viewpoint is that it's not shocking to have many options available. As long as we don't throw the user into a daunting list of options as soon as they arrive at the documentation, they should be able to find their way as their needs become clearer.

[axllent]

@PabloLec Fair enough, point made.

Regarding testing, are there any unit tests for environment variables or configuration or are we talking about manual testing during implementation?

Manual testing for allowed combinations of required fields in order to consider whether the relaying is enabled. At the moment if you specify a config file you are telling Mailpit that you want to enable relaying - but if you break this down into also accepting environment variables it somewhat complicates how things are considered "enabled" in the app. I'm explaining it badly, but my point is that it's not just a matter of adding 10 new env values, it's also the validation if/else/etc logic that is required to "validate" that all required fields are in fact satisfied.

Don't worry, I will look into adding this, I just need to rewrite the code/logic and possibly break up the entire configuration stuff into a different structure (it will take me a while).

Regarding the documentation, indeed, the "Runtime options" page might become quite crowded. Maybe for clarity, the page could be divided into sections, somewhat mirroring the structure of the Configuration menu in the sidebar.

I just had a look at reordering the mailpit documentation and realise I need to do a lot of reordering as that stuff is all over the place (as features got added they didn't necessarily end in the most logical order, and the website documentation followed the order of the application). As above, I need to revisit the whole configuration and rewrite stuff, so this feature will be included in that.

[axllent]

@PabloLec This feature has been released with v1.14.4 and is documented on the SMTP replay page. I decided not to add those environment variables to the runtime options page as it was just-too-much, and in addition to this I also ended up up reordering many of the existing Mailpit flags to sort them by related functionality (it was getting messy over time).

Please confirm this works for you as you expected?

[PabloLec]

@axllent Yes, sorry for the delay in response but I was able to test and indeed everything is working correctly. Thanks for your quick response and well done on this new feature. 👍

[axllent]

Thanks for the feedback, and you are welcome!