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

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

Attachment: [application/pgp-signature] This is a digitally signed message part signature.asc