Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91459
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
Message-ID: <1456754284.20636.19.camel@kuechenschabe>
To: Dolf Schimmel <dolf@transip.nl>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Date: Mon, 29 Feb 2016 14:58:04 +0100
In-Reply-To: <VI1PR02MB0782F8CC8F5B538A9559DF7BB4B90@VI1PR02MB0782.eurprd02.prod.outlook.com>
References: 
	<VI1PR02MB0782F8CC8F5B538A9559DF7BB4B90@VI1PR02MB0782.eurprd02.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-f8/ODXZVmVH1FXeoirxl"
Mime-Version: 1.0
Subject: Re: [PHP-DEV] RFC Proposal: Pluggable Mail Transports
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

--=-f8/ODXZVmVH1FXeoirxl
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2016-02-28 at 17:55 +0000, Dolf Schimmel wrote:
> Howdy,
>=20
> I'm planning to create an RFC on this shortly, but would like to gauge
> the initial response first.
>=20
> 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.

For one: Why can't they use the mail function? A hoster can easily
provide a sendmail-compatible program doing whatever is needed in the
environment.
The purpose of the function is to get rid of mail reliably and quickly
in order to have it queued somewhere. PHP shouldn't be the MTA. That's
a tough task (i.e. what to do when the SMTP server is down or slow? -
PHP shouldn't have to wait)
So I'd like to learn where mail() can't be used (aside from a dev
desktop where this might need "too much" system configuration)


And as a side note: If you really have a special case where providing a
sendmail tool is no option you could easily create an extension
replacing mail() with a custom function (mbstring functions, runkit and
other extensions show how this can be done)

> The patch I'm proposing can be found here:
> https://github.com/php/php-src/pull/1778/files

I haven't fully reviewed this. But you're not handing extension
unloading. In some SAPIs we have dl() available and serve multiple
requests. Thus in one request a mail module could be loaded by dl() on
shutdown the extension will be unloaded, but the pointer will still
exist in the handler table.

johannes


--=-f8/ODXZVmVH1FXeoirxl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAABAgAGBQJW1E5sAAoJEH3sTmn8nIPXsNwH/1D1b/KvVyvcPF4YcQPebkj9
wqxuTZkyr3H44xr9VEYMlJUr/PmO8eEHYk2rHj1OWDlP0VGkQ/ErNLujz1EFj0wL
WdKxE9IwroklRaY9dX1eHhITOFTdRBivb/8ijoYlfvcBvqmObHiduBQR4cZaDhTs
hR1QSdmJmiWR/lZvnbWdVjmM0HkapHfltHwMyZ/lf/O6p2e/vbfq9m3Ey88r4riS
pgkCr4qYtxWr6sgMvDKjmuIA91KZRCaNuuW1/w+sKZNeCKjMnRI4/a3fZD2dnNZH
LG3TL8S6gfVN+Q7alm8+CyLBl1n1ISXyVhZUx44eNfn1jGXhXuGS70hRMKHCGwI=
=RRQl
-----END PGP SIGNATURE-----

--=-f8/ODXZVmVH1FXeoirxl--