Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74117
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <533218C1.6010901@lerdorf.com>
References: <5330E319.5060302@gmail.com> <5330F2B2.1030201@sugarcrm.com>
 <5331C238.6050409@gmail.com> <1395780660.9365.606.camel@guybrush>
 <53321455.7010907@gmail.com> <533218C1.6010901@lerdorf.com>
Date: Sat, 10 May 2014 16:28:01 -0400
Message-ID: <CAC4OfRjc_rhynK_XDZdeapm2BTUHBJLWQSccUr-6rpGHZJR=SQ@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf3071cab060309404f9118f4d
Subject: Re: [PHP-DEV] Proposal: Mail Handling, feedback requested
From: garyamort@gmail.com (Gary Mort)

--20cf3071cab060309404f9118f4d
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 25, 2014 at 8:01 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 3/25/14, 4:42 PM, Gary Mort wrote:
> > At the moment the mail() function is almost useless because it cannot be
> > assumed work - on windows it is likely to generate an error.  On Linux
> > it depends on if sendmail/postfix/etc are configured.   Make it a
> > handler with a sane default setting and then it can be trusted.
>
> That's a pretty big leap there. In order combat spam, many places have
> pretty tight restrictions on who and what can send mail. Outbound port
> 25 is often blocked, for example, and the only way to send an email is
> through a local smarthost MTA relay. And how exactly you need to connect
> to that relay will vary from one environment to another. I don't see how
> we can provide a default stream handler that "can be trusted" since it
> needs the same level of local configuration attention as the current
> mail() function.
>

True, I am not interested in providing a "better" default stream handler.
 What I'm interested in is that a developer can use mail() in the same way
that they use fopen() and be reasonably confident that the function will
work during execution.

There has been a long exodus of using native PHP functionality and instead
using methods exposed by frameworks to perform simple functions.   While it
made sense in the past, it leads to this weird skill gap where all the
"learning PHP" tutorials aimed at beginners use built in functions and
global variables such as $_GET, $_POST, etc

And then "enterprise" applications have people use
someFrameworkClass::mail(), someFrameworkClass::get(), etc.

The silly thing is that these calls are almost exactly identical.

$mail = someFrameworkMailClass();
$mail->send($to, $subject, $message);
vs
mail($to, $subject, $message);

The primary difference being that the mail() function will /always/
function while creating a mail object of a particular type only works for
that framework.  So why not allow a framework to define it's own custom
"mail handler" and override the current one?  In the same manner that you
can override a session handler or a stream handler.

My goal is not to help the framework developer, their already dealing with
the complexities.  My goal is to help the developers who are going from
beginner to experienced programmers in that they don't have to learn a lot
of window dressing/new syntax to perform a simple function.

Mail does partially support this concept.  it supports using the
sendmail_wrapper ini flag to designate an external program which handles
all the mail processing.  I just feel that it should be possible to do this
internally as well - especially as it allows for more fine grained error
checking.

--20cf3071cab060309404f9118f4d--