Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73436
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
Message-ID: <53321455.7010907@gmail.com>
Date: Tue, 25 Mar 2014 19:42:13 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
References: <5330E319.5060302@gmail.com> <5330F2B2.1030201@sugarcrm.com>	 <5331C238.6050409@gmail.com> <1395780660.9365.606.camel@guybrush>
In-Reply-To: <1395780660.9365.606.camel@guybrush>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Proposal: Mail Handling, feedback requested
From: garyamort@gmail.com (Gary Mort)

On 03/25/2014 04:50 PM, Johannes Schlüter wrote:
> On Tue, 2014-03-25 at 13:51 -0400, Gary Mort wrote:
>> Sending mail is just passing a stream of bytes to a stream.  That stream
>> could be an SMTP server, it can be an executable program, or it can be a
>> file.
>
> Even that is not that easy, as Rasmus wrote.

The only reason people think of it as complicated is because of 
combining the different elements of e-mail:
Formatting an e-mail
Sending an e-mail
Relaying an e-mail
Delivering an e-mail
Verifying an e-mail

When you send an e-mail you are submitting it to a Mail Delivery Agent 
for delivery.  The MDA either accepts your submission or rejects it. 
There are only 3 items of data are mandated by RFC: sender, recipient, 
and message.

Of those, only sender and recipient have a specified format.  The 
message itself just has to be a string of some sort.


>
>> Frameworks are encouraged to subclass MailMessage and extend it's
>> functionality to suite their requirements - ie if they to synchronize
>> the header property with the recipients/from/subject properties they are
>> free to do so - there is no rule/standard saying they cannot.
>
> So frameworks should still contain their own mail classes working
> differently? So this is neither solving the sending problem nor the
> "it's different everywhere" problem.
>

Yes, frameworks should still contain their own mail classes - the issue 
is not that they have them, but that PHP Applications[as opposed to 
frameworks] such as Drupal, Wordpress, and Joomla require application 
specific code to perform the simple task of sending e-mail.

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.

Take writing a simple "contact us" form processor.  A theoretical 
contact form could have fields for:
Category of Problem, $category
Summary of Problem, $summary
Full details of Problem, $details

Who it is to be sent to is pre-defined.  Subject is pre-defined.
It only takes a few lines to send this e-mail:
$message = <<<EOT
Category: $category.\n
Summary: $summary.\n
Details: $$details.\n
EOT;
mail($to, $subject, $message);

I would guess that over half of all sending of e-mail can be 
accomplished with these types of simple steps.


Instead, for some applications like drupal you have to use the 
relatively simple:
drupal_mail($module, $key, $to, $language, $params = array(), $from = 
NULL, $send = TRUE)
https://api.drupal.org/api/drupal/includes!mail.inc/function/drupal_mail/7

Joomla is more complex with a nice OO interface:
http://docs.joomla.org/Sending_email_from_extensions

$mailer = JFactory::getMailer();
$mailer->addRecipient($to);
$mailer->setSubject($subject);
$mailer->setBody($message);
$mailer->send();


By making it possible to register a mail handler, a Drupal website 
merely has to call:
set_mail_handler(
  function ( $to ,  $subject ,  $message ) {
     $module = 'drupal';
     $key = unique();
     $language = language_default();
     $params = array('body' => $message);
     return drupal_mail($module, $key, $params);
     return strtoupper($match[1]);
}
);

And all simple e-mail can now be generated and sent with the PHP mail 
function, rather then requiring custom use.

A Joomla website would just call:
set_mail_handler(
  function ( $to ,  $subject ,  $message ) {
   $mailer = JFactory::getMailer();
   $mailer->addRecipient($to);
   $mailer->setSubject($subject);
   $mailer->setBody($message);
   return $mailer->send();
}
);


The basic concept here is to not require application developers to keep 
changing how they write code based on the underlying application - 
instead always use basic PHP function unless your needs go beyond that.

IE $myvar = _SESSION['somekey'] is the best way to retrieve session 
data.  The framework/application can use the SessionHandler 
functionality to implement specific custom methods of dealing with 
session data.  The Session Handler can deal with sanitizing/filtering data.

$filedata = file_get_contents($filepath) is the best way to get the 
contents of a file.  Don't worry about if the file is local, from the 
web, stored in some weird virtual file system, etc.  The 
Framework/Application can use Stream Handlers to deal with oddball 
situations.

Sending an e-mail message is a basic requirement for PHP, as such mail() 
should be the preferred method of doing so.   If you have custom 
formatting needs, then use a library to format the e-mail message.

Consider this list itself, it's using an archaic web interface[ezmlm] 
because to implement an email list in /any/ language requires a stupid 
amount of work.

When this list receives an e-mail message, it has to loop through a list 
of all subscribers and: skip subscribers who are set to nomail, add it 
to a periodic digest for subscribers who are set to digest, send it 
directly to subscribers who want mail immediately.

Using registered e-mail handlers, in PHP this becomes a simple process:
foreach ($subscribers as $recipient)
{
mail($recipient, $subject, $message);
}

All the heavy lifting is offloaded to the Mail Handler, which is only 
required to deal with one thing - delivering e-mail.  A hypothetical 
list handler would check the subscriber database for the recipient, if 
the recipient is set to nomail it can return immediately, if the 
recipient is in digest it can append queue it for a future digest 
generator, and if the recipient is immediate invoke the default PHP mail 
handler.