RFC Proposal: Pluggable Mail Transports
| From: | Dolf Schimmel | Date: | Sun, 28 Feb 2016 17:55:34 +0000 |
| Subject: | RFC Proposal: Pluggable Mail Transports | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-91453@lists.php.net to get a copy of this message | ||
Howdy,
I'm planning to create an RFC on this shortly, but would like to gauge the initial response
first.
Currently whenever an email is sent through the mail() function it is sent by an invocation of a
sendmail-compatible executable. However, there are scenario's in which an alternative transport
than through a sendmail executable may be desired. For example when PHP has been locked down,
preventing it from starting any executables. It would be nice if it would be possible to allow such
an alternative e.g. through a PHP Extension. Of course there are many frameworks out there that
setup an smtp connection themselves, but in a shared hosting environment it's unfeasible to
tell users they can't use the mail() function.
This approach is akin to how sessions have a storage handler. PHP by default provides the
'file' and 'user' handlers. But the memcached extension provides a storage
mechanism of its own which is then registered through php_session_register_module().
This would only implement an extra hook to allow for overriding the default sendmail mail transport
(introducing a new ini setting) without bringing extra functionality to the php user land.
Also, this hook would allow to implement other feature requests, like #29629. [1]
The patch I'm proposing can be found here: https://github.com/php/php-src/pull/1778/files
Cheers,
Dolf
1. https://bugs.php.net/bug.php?id=29629