Re: Fw: [PHP-DEV] RFC Proposal: Pluggable Mail Transports

[Johannes Schlüter]

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)
> 
> 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



signature.asc
Description: This is a digitally signed message part

Re: Fw: [PHP-DEV] RFC Proposal: Pluggable Mail Transports

[Dolf Schimmel, TransIP]

> From: Ángel González 
> On Sunday, February 28, 2016 21:12,  Ángel González wrote:
> I don't think more than a direct SMTP transport will be needed (LMTP
> perhaps?), but it seems a good idea that #29629 can finally be fixed.
>

These would indeed be a few examples. Although there's of course also
QMQP, and who knows what else people may feel they need.

In our case we decided to implement an extension that fetches the smtp
credentials to be used (per user) while sending an email from a separate
system. We considered providing these through php.ini, but we didn't
want to have users accidentally expose credentials when they have a page
that does php_info() somewhere for the world to see.

> On Monday, February 29, 2016 14:58, Johannes Schlüter wrote:
> On Sun, 2016-02-28 at 17:55 +, Dolf Schimmel wrote:
>> Howdy,
>>
>> I'm planning to create an RFC on this shortly, but would like to gauge
>> the initial response first.
>>
>> 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.

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.

> 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)

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.

> 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)

We could indeed go that way, but it would introduce some code
duplication. Given how we maintain our own patches I could also just
replace the sendmail code with our own, but this is way more generic and
could benefit other users as well.

> 
>> 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.

Noted. Will add that as well. Thanks for the feedback.
> 
> johannes
> 

Dolf

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Proposal: Pluggable Mail Transports

[Johannes Schlüter]

On Sun, 2016-02-28 at 17:55 +, Dolf Schimmel wrote:
> Howdy,
> 
> I'm planning to create an RFC on this shortly, but would like to gauge
> the initial response first.
> 
> 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



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] RFC Proposal: Pluggable Mail Transports

[Ángel González]

I don't think more than a direct SMTP transport will be needed (LMTP 
perhaps?), but it seems a good idea that #29629 can finally be fixed.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC Proposal: Pluggable Mail Transports

[Dolf Schimmel]

Howdy,

I'm planning to create an RFC on this shortly, but would like to gauge the 
initial response first.

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.

This approach is akin to how sessions have a storage handler. PHP by default 
provides the 'file' and 'user' handlers. But the memcached extension provides a 
storage mechanism of its own which is then registered through 
php_session_register_module().

This would only implement an extra hook to allow for overriding the default 
sendmail mail transport (introducing a new ini setting) without bringing extra 
functionality to the php user land.

Also, this hook would allow to implement other feature requests, like #29629. 
[1]

The patch I'm proposing can be found here: 
https://github.com/php/php-src/pull/1778/files

Cheers,

Dolf


1. https://bugs.php.net/bug.php?id=29629
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php