Fixed sendmail transport blocking HTTP requests

[fballiano]

Problem

When using the default sendmail transport, transactional emails (customer registration, password reset, etc.) block the entire HTTP request, causing the page to hang until the email is fully delivered.

This happens because Symfony's sendmail://default DSN invokes sendmail with the -bs flag, which opens an interactive SMTP session with the local MTA. The MTA then performs synchronous operations (DNS lookups, connecting to remote MX servers, relaying) before returning control — blocking the PHP process for the entire duration.

In OpenMage/Magento 1 this was never a problem because Zend_Mail_Transport_Sendmail used PHP's mail() function, which invokes sendmail via php.ini's sendmail_path (typically /usr/sbin/sendmail -t -i). In -t mode, sendmail accepts the message into its local spool and returns immediately — delivery happens asynchronously in the background.

Solution

Changed the sendmail DSN from sendmail://default to native://default.

Symfony's native://default transport reads sendmail_path from php.ini and passes it directly to SendmailTransport. Since php.ini typically configures sendmail with -t mode, this restores the non-blocking behavior that OpenMage had.

Why -t vs -bs matters

Flag	Mode	Behavior
-bs	Interactive SMTP	Opens a full SMTP conversation (EHLO → MAIL FROM → RCPT TO → DATA → QUIT), blocks until MTA processes the message
-t	Pipe/stdin	Reads recipients from headers, accepts message into local spool, returns immediately