30 ms·
Both postfix and qmail are inherently incapable of blocking their clients on communication with destination/upstream smarthost because of their architecture. I
by 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 agoexim and sendmail have synchronous options
- dfox 10y agoI'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 agoNever 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.