Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91633
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: <1457693235.12830.12.camel@kuechenschabe>
To: "Dolf Schimmel, TransIP" <dschimmel@exchange.transip.nl>
Cc: Dolf Schimmel <dolf@transip.nl>, keisial@gmail.com,
 internals@lists.php.net
Date: Fri, 11 Mar 2016 11:47:15 +0100
In-Reply-To: <56E2753D.8020300@exchange.transip.nl>
References: 
	<VI1PR02MB0782F8CC8F5B538A9559DF7BB4B90@VI1PR02MB0782.eurprd02.prod.outlook.com>
	 <1456754284.20636.19.camel@kuechenschabe>
	 <VI1PR02MB07827FC7D28F28B89C9E9D7EB4B50@VI1PR02MB0782.eurprd02.prod.outlook.com>
	 <56E2753D.8020300@exchange.transip.nl>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-FfISAKF4sywgnkFFk5vm"
Mime-Version: 1.0
Subject: Re: Fw: [PHP-DEV] RFC Proposal: Pluggable Mail Transports
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

--=-FfISAKF4sywgnkFFk5vm
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2016-03-11 at 08:35 +0100, Dolf Schimmel, TransIP wrote:
> They surely could. In fact that's how we've been doing it for a long
> time now. But they also want to lock down things as much as possible. In
> our case we decided to disallow PHP from doing any forking and put it in
> a (noexec) filesystem namespace that doesn't contain any exectuables.

That is indeed a good point. Thanks!

> > 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)
>=20
> Well, you're right in that PHP doesn't have to be an MTA. But, that
> doesn't mean you don't want it to communicate directly with an MTA. The
> MTA typically decides whether it will actually accept the email or
> whether it considers it spam or whether a user has reached their quota,
> just to name a few examples. It's way more convenient to let the user
> know immediately whether their mail was accepted than it is to simply
> queue it somewhere and generate a lot of bounce mails which will often
> times go unread.

Also the sendmail tool can return an error. While I admit, that we don't
have a way to transport the error reason. The user will get a simple
"false" (which hardly anybody, a least that's my assumption, checks for)

The risk I'm seeing is that mail() is a blocking function and is often
called in a loop (foreach (subscriber) { mail } ) and we should
encourage offloading as quickly as possible.

If other disagree with me on hat I'm fine :)

johannes


--=-FfISAKF4sywgnkFFk5vm
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)

iQEcBAABAgAGBQJW4qIzAAoJEH3sTmn8nIPXNQAIAJL0FQgoo+u4IeWMpAW8pXli
F5yEdKAuTVqcU0yiG9OnHShc6HlE5Pb5wOdXOI8S9skdlwaVbMXVIbm25KUBFVP3
V/jXVrCQscSeDNWiICYYsz7RPZJVyZM/FnWjXWibRRhG6UcJTW6jb8QUU0BG3CtX
nwdALXlgTVfhUINt7mLkSRNtOkPwrR2GIqaEVUF/NtnMqwrXhtKXi73VlC6AaDK6
fBO6+757/Z9F1DHmLzUHFC/OYoEtCev6PxmLoMH4Xn3dMgxshE9XYfFItbHpIvvh
4mwRbkuzKGmZS55Fu1Pky4a6P1wzctVtJ/zMRC3OviwF9slNsjHGcDcDPXYIFPQ=
=YOaH
-----END PGP SIGNATURE-----

--=-FfISAKF4sywgnkFFk5vm--