Personally feel like this is business logic that doesn't belong in symfony/mailer?

2 different approaches that could be worth looking into:

• Create an abstraction of Symfony\Component\Mime\Email, overwrite the from() function to only allow whitelisted emails
• Create an implementation of Symfony\Component\Mailer\MailerInterface (that possibly extends from an existing mailer if you use a 3rd party mailer) that blocks sending of emails of non-whitelisted addresses

I'm doing this on one of my apps using a listener

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\Mailer\Event\MessageEvent;
use Symfony\Component\Mime\Address;

/**
 * - will allow sending emails to recipients matching the given regex
 * - will always add the given recipient email as additional recipient of the mails.
 */
class EnvelopeWhitelistRecipientsListener implements EventSubscriberInterface
{
    private string $whitelistRegex;
    private string $recipientEmail;

    public function __construct(string $whitelistRegex, string $recipientEmail)
    {
        $this->whitelistRegex = $whitelistRegex;
        $this->recipientEmail = $recipientEmail;
    }

    public function onMessage(MessageEvent $event): void
    {
        $recipients = [Address::create($this->recipientEmail)];

        foreach ($event->getEnvelope()->getRecipients() as $recipient) {
            if (!preg_match($this->whitelistRegex, $recipient->getAddress())) {
                continue;
            }

            $recipients[] = $recipient;
        }

        $event->getEnvelope()->setRecipients($recipients);
    }

    public static function getSubscribedEvents(): array
    {
        return [
            // should be the last one to allow header changes by other listeners first
            MessageEvent::class => ['onMessage', -255],
        ];
    }
}

An event listener would be the way to go. Not sure if we should ship such a listener with the component though.

I think a whitelist will be helpfull for staging systems. Normally I use Devmailer for staging, but in this project we generate a mass off Notifications, so the Devmailer get thausand of mails.

I won't add logic to the project only for the staging system. If this feature isn't welcome, I have to do this.

I will create in the next days a MR with your idea @dmaicher , if it is okay for you.

I’m pretty sure they meant you can replicate that in your project. Staging or not, it’s still your business logic and your project requirements.

The mailer bundle does what it needs to do, send an email using a configured mailer. Not going to gatekeep what goes into symfony but you asked if others have a need for this in the mailer bundle and it seems like most have their own solutions that serve their specific use cases. I personally don’t see the need as you should keep user emails off staging (depending on where you’re developing for this could even be illegal, im sure that GDPR doesn’t allow you to use actual user data for testing your application) so it should be impossible to send an email to someone who’s not willingly signed up to your staging environment and okay with receiving test emails..

Another method that hasn’t been discussed yet is blocking sending on your mail server. Most mail servers have blacklists/whitelists to manage bounces and error addresses. That could be another solution that doesn’t involve modifying the project.

Additionally symfony also provides config and bundles to only be loaded on specific environments, you could create an environment and a custom bundle that’s only loaded on staging, so the event subscriber or whatever method you choose to go for is only executed on that environment (see APP_ENV documentation, on mobile so don’t have it handy).

Again personally I see it as project/business logic and not so much “mailer logic”, projects that do need it already have 3 simple solutions (custom mailer, custom email, event subscribers).

@jannes-io Please try to maintain a respectful language on this issue tracker. I understand that you would've solved this issue differently, but that does not render @y4roc's request invalid.

@jannes-io Please try to maintain a respectful language on this issue tracker. I understand that you would've solved this issue differently, but that does not render @y4roc's request invalid.

My apologies, the comment was meant to simply highlight the hypocrisy of OP’s request in a joyful manner. The underlying message remains a valid concern..

So I write now an event listener to in a StagingBundle. But I found a bug in the MessageEvent. I can't manipulate the message object.

I created a PR to fix this. In Symfony 5.4 this is fixed.

When non of the recipient are respecting the delivery whitelist, I try to call setRecipients with an empty array and it throw an error. Is it possible to stop the email sent with this event dispatcher logic ?

No, it isn't possible with it. I created a MR #48409 to add the function to reject an email.