4 ms·

> In those cases, it really isn't a good idea to send mail in-process anyway due to web-process and SMTP timeouts Why is sending a message to something like Ra

• jstewartmobile 10y ago
  Job queue services have async modes where enqueueing the message returns immediately. Then the jobber can send the message under a more limited account, or even on a different machine in a different language without timeouts. Last I checked, PHP's mail() function blocks until SMTP connect/auth/submit completes, and with things like SMTP tarpitting, or just ordinary slowness, that can take a very long time. Sometimes, it takes more time than your server-side web process is alloted for execution, leading to your script being force-terminated prior to completion. [in reply to skarap] The action of mail() depends on the mail/sendmail settings in your php.ini, so the behavior could be blocking or non-blocking depending on which client is used and which parameters are passed.
  • skarap 10y ago
    The default configuration for PHP (and I guess the most frequently used one) is using sendmail command. That command does just one thing - enqueue the message on the local server. It doesn't handle the delivery of the email. That is also the case when using the mail server at 127.0.0.1 port 25. One could have configured a remote SMTP server with authentication and that would be slow and would be affected by network issues, but same would happen with a remote RabbitMQ server.
    • jstewartmobile 10y ago
      On most shared hosts, it blocks. The action taken by mail() is dependent upon your php.ini settings.
    • Piskvorrr 10y ago
      Quite the contrary: most installs I've seen have a "remote" dedicated SMTP server which is actually on local network (not significantly slower than mail()), and does other useful stuff like DKIM and SPF (which, with appropriate setup, has the added bonus that rogue app-server emails don't just appear out of nowhere, and at the very minimum have to pass through this server, giving you a place to debug). Of course, if you're making My First Blog Server on a shared host, then all of this is moot.
  • dfox 10y ago
    Both postfix and qmail are inherently incapable of blocking their clients on communication with destination/upstream smarthost because of their architecture. In both cases it works like this: client: MAIL FROM server checks whether it makes sense (outgoing smarthost has essentially nothing to check here) SMTP server: 250 Ok client: RCPT TO server checks, again there is nothing expensive to check for smarthost case SMTP server: 250 Ok client: DATA ... . server does its checks on the contents of message (again, nothing meaningful for smarthos), reformats it, adds Received and such and writes it out into queue SMTP server: 250 Ok: queued server wakes up the process that handles delivery by IPC and gives it queue ID of just created message client probably disconnects now outgoing SMTP daemon starts connecting to somewhere
    • jstewartmobile 10y ago
      exim and sendmail have synchronous options
      • dfox 10y ago
        I'm aware of that. My point is that when sending mail directly from web server process is too slow, correct solution is not building your own bug-ridden implementation of half of SMTP on top of some newfangled message queue, but simply configuring your outgoing mail server correctly. When you only enqueue event such as "this happened, there should probably be an notification for that" and have some non-trivial application logic in the queue runner it starts to make sense. But queue runner of the kind for(;;) {msg = get_message(); smtp_send(message)} is complete nonsense. By the way, I know of pretty significant line of bussiness system that has nothing to do with email except the fact that it uses smtp and postfix as it's message bus and the thing seems to just work without issue, for more than decade.
        • jstewartmobile 10y ago
          Never said to re-implement SMTP. Just stating that I've been on shared servers where PHP mail() blocks and had to job-out SMTP for responsiveness. If I've encountered it, I'm sure others have as well. As for the jobber, it was using the same PHP mail() function, it's just that the jobber runs async and does not have a time limit imposed on it. If you have control over your php.ini to where you can set agent parameters to be non-blocking, then yes, that would be ideal.
  • deleted 10y ago
    [deleted]