Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73411
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.213.50 cause and error)
Message-ID: <53310270.1030607@lerdorf.com>
Date: Mon, 24 Mar 2014 21:13:36 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Gary Mort <garyamort@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <5330E319.5060302@gmail.com> <5330F2B2.1030201@sugarcrm.com>
In-Reply-To: <5330F2B2.1030201@sugarcrm.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="Iln6OQ9RSkJVSgpGTbiFAMScXARnMekUA"
Subject: Re: [PHP-DEV] Proposal: Mail Handling, feedback requested
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--Iln6OQ9RSkJVSgpGTbiFAMScXARnMekUA
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3/24/14, 8:06 PM, Stas Malyshev wrote:
> Gary Mort wrote:
>> My goal is that the creation and sending of basic e-mail should be a=20
>> simple operation.  It should be possible for a developer to simply cal=
l=20
>> the mail() function and not be concerned about possible e-mail handlin=
g=20
>> configurations.
>=20
> I'm not sure - so how you actually configure the email server in your
> model and what advantage it gives over mail()? Is it just the framework=

> for mail() to call? Then it probably should just have one send() method=

> and not contain any business logic - that should be either in mail() or=

> in specific handlers. I actually like the idea of such class for mail()=

> alike to what we did for sessions, but the API should be refined so tha=
t
> it matches what people do with emails, and error reporting capabilities=

> should be added (e.g. for some applications what email server answered
> is actually important).

Right, the real complication is actually at the PHP configuration level.
At the userspace level it is hard to know how a particular PHP
installation has been configured in terms of what happens when you call
mail(). That is partially by design. Not the information hiding part,
but the separation between the configuration and the mail function
itself and the relative dumbness of that mail() function.

The way I intended, and the way I hoped, people would configure their
PHP and underlying mail setups when I initially wrote the mail()
function (nearly 20 years ago now) was for sendmail (or equivalent) to
run in queue-only mode with a periodic queue run. This has multiple
advantages:

 1. Sending an email is virtually instantaneous as far as PHP is
    concerned since the email is just written to the local queue (which
    could be on the same or a different host on the local network)

 2. A high percentage of people have their emails hosted by a small
    number of large companies. gmail, hotmail, yahoo mail, etc. So by
    using a queue and batch process mode your mail transfer agent will
    make a single connection to gmail and send every message destined
    for gmail in a single connection even if those messages originated
    from many different scripts on your end.

 3. Mail transfer agents are incredibly complex. Trying to do any of
    this in PHP to any acceptable level of completeness would have been
    way too much of a timesink.

I know some frameworks have tried to tackle #3 there because they can't
rely on a sane local mail configuration. I read your suggestions through
twice and honestly I can't quite figure out what you are trying to
solve. Is it #3? It didn't quite seem like it. You still want to let the
system admin define the actual underlying mail stream mechanism, I
think, since #1 and #2 are essential for performance and efficiency. So
it is just a really complicated version of the mail() function, right?

-Rasmus


--Iln6OQ9RSkJVSgpGTbiFAMScXARnMekUA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlMxAnEACgkQlxayKTuqOuC79QCcDXIJeVQKHnF697AnCQlUl5Re
ESEAn0OSngUa5cipioNcyhua2ccLFrxc
=k4qJ
-----END PGP SIGNATURE-----

--Iln6OQ9RSkJVSgpGTbiFAMScXARnMekUA--