I want site admins to be able to configure the MAILER_DSN at runtime, and change it without needing a system administrator to change the MAILER_DSN environment variable on the server. This involves creating a doctrine entity to write/read the mailer configuration from. I've done considerable research into how to achieve this.

I do have a working method, but it's pretty hacky. I wrote a custom environment variable processor to replace the mailer.dsn parameter every time the Mailer fetches it, as environment variables are resolved at runtime:

class MailerEnvVarProcessor implements EnvVarProcessorInterface
{
    public function __construct(private MailerSettingsRepository $mailerRepo)
    {
    }

    public function getEnv(string $prefix, string $name, \Closure $getEnv): string
    {
        $mailerConfig = $this->mailerRepo->findOneBy([]);

        if ($mailerConfig === null)
        {
            return match ($prefix) {
                'mailer_dsn' => 'null://null',
                'mailer_sender' => 'admin@example.com',
            };
        }

        return match ($prefix) {
            'mailer_dsn' => 'smtp://'.$mailerConfig->getMailerEmail() . ':' . $mailerConfig->getPassword() . '@' . $mailerConfig->getMailerDomain() . ':' . $mailerConfig->getMailerPort(),
            'mailer_sender' => $mailerConfig->getEnvelopeSender(),
        };

    }

    public static function getProvidedTypes(): array
    {
        return [
            'mailer_dsn' => 'string',
            'mailer_sender' => 'string',
        ];
    }
}

The two environment variable processors are used in the config file:

// config/packages/mailer.yaml
framework:
    mailer:
        dsn: '%env(mailer_dsn:MAILER_DSN)%'
        envelope:
            sender: '%env(mailer_sender:MAILER_SENDER)%'

And this works just great in the dev environment (currently not tested in prod):

                $loginLinkDetails = $loginLinkHandler->createLoginLink($user);

                $notification = new LoginLinkNotification(
                    $loginLinkDetails,
                    'Welcome to NAME OF PLATFORM'
                );

                $recipient = new Recipient($user->getEmail());
                $notifier->send($notification, $recipient);

This is obviously a pretty dirty hack. I can't see any obvious downsides to it other than it maybe not working in the future if EnvVarProcessors are changed somehow to prevent this. The upside is that it requires very little code and I don't need to understand the interfaces/implementations for Mailer, Notifier, EmailChannel, LoginLinkNotification, etc.

The 'proper' way, I assume, would be to write a service that implements MailerInterface and replaces the current Mailer. So I did that too:

#[Autoconfigure(shared: false)]
class DbBackedMailer implements MailerInterface
{
    private MailerInterface $mailer;

    public function __construct(
        MailerSettingsRepository $mailerSettingsRepository,
    ){
        $dsn = 'null://null';
        $mailerConfig = $mailerSettingsRepository->findOneBy([]);

        if ($mailerConfig !== null)
        {
            $dsn = 'smtp://'.$mailerConfig->getMailerEmail() . ':' . $mailerConfig->getPassword() . '@' . $mailerConfig->getMailerDomain() . ':' . $mailerConfig->getMailerPort();
        }

        $transport = Transport::fromDsn($dsn);
        $this->mailer = New Mailer($transport);
    }

    public function send(RawMessage $message, ?Envelope $envelope = null): void
    {
        $this->mailer->send($message, $envelope);
    }
}

It uses shared: false because the object needs to be recreated every time in case the database configuration has changed. This will have a performance impact on every invocation of the Mailer service. You might be able to write some code in send() to decide whether to recreate the service based on cache to mitigate this.

You configure it to override the Mailer service here:

    mailer.mailer:
        class: App\Service\DbBackedMailer

    Symfony\Component\Mailer\MailerInterface:
        alias: mailer.mailer

And this...actually works. As long as you invoke the Mailer service directly instead of via Notifier, and hardcode the sender (you could just replace the envelope in the DbBackedMailer too if you wanted):

                $htmlEmail = (new Email())
                ->from('email@example.com')
                ->to($user->getEmail())
                ->subject('Welcome to NAME OF PLATFORM')
                ->html("Click here to log in: <a href=\"{$loginLinkDetails}\">Login</a>");
                $mailer->send($htmlEmail);

But as this doesn't work for my LoginLinkNotification which uses Notifier, I guess I need to replace the Notifier service. I wasn't able to understand the logic very well, and I'm at the point where I really want to move on from this. The EnvVarProcessor is hacky but it was easy to write and understand, plus it's easy to maintain. And it doesn't have a performance impact.

I just wanted to know...am I doing something wrong here?

These methods do not work for the purpose:

• Compiler Passes - Using them to replace the mailer.dsn parameter right before service compilation. This wouldn't work the simple way because, while you can potentially use $container->setParameter to override dsn, you can't inject any services like Doctrine's EntityManager or a Repository because the service container is not ready for use. It would be possible to use Doctrine classes directly without the service container, but this is more prone to error. You would also need some way to clear the cache in the Controller after an admin saves the mailer settings so the service container gets recompiled; probably running the cache:clear console command directly. So it could be made to work, but I don't think it's a great solution.
• Configurators - The MailerInterface class' send() method does not take the Transport as an argument and instead uses it from the constructor, which configurators can't override.
• Service Decoration - for the same reason as configurators, this wouldn't work without replacing the entire send() method.