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
