Gordon Messmer writes:

> And, in any case, starting sendmail/submit, then doing nothing for half
> an hour, that seems rather broken to me. The timeout is not issue, here.
> Something's wrong with this entire concept.

A cron job might not have output for a very long time, but cron launches
sendmail before it runs jobs, and connects the job's output to
sendmail's input.

The correct way to handle that is to redirect the message into a temporary file. When you're ready to send the message, then make the connection, and send it on the way.

I can continue to patch Courier and make the timeout longer for my own
systems, but I wanted to ask since at least for me submit running for a
long time is never an issue (particularly as esmtpd has its own timeout,
and it can be configured), but SSMTP support is.

The problem here is that there are processes that remove old files in the temporary directory where the incoming message gets initially saved. Doing nothing for hours risks the temporary message getting deleted, and causing all sorts of issues. I don't recall, at the moment, what are the expiration times for files in Courier's tmp directory, at which point they are subject to removal, but doing this risks losing all mail. This is not as simple as setting the timeout to be something unreasonably large.


Attachment: pgpIRME6PMD7M.pgp
Description: PGP signature

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to