On Sun, Apr 08, 2001 at 12:07:01PM +0200, Per Einar wrote:
>
> What I was suggesting was that I could do the SMTP connection myself. But
> you're right, that might involve queuing problems.
If you do this, make sure that the SMTP connection is to your local MTA,
since 'net delays could mean a mod_perl process hanging around for a
long time waiting for name resolution or a distant or slow MTA to respond.
Also, if you do fork or connect to your local MTA, make sure it's in
queueing mode and not immediate delivery mode, so your mod_perl process
doesn't wait for it to deliver the mail.
> I don't know anything about named pipes, but isn't it possible to write to
> some sort of intermediate file that is monitored by a daemon process which
> then sends it off to sendmail?
If you're planning on writing a daemon, a named pipe or Unix domain
socket is good. You'll need a multiprocessing/multithreading daemon,
though, if you don't want to risk blocking while a previous message gets
attended to. Intermediate files mean simpler code, a cron job or simple
sleep(10) polling loop can be used.
If you're sending new account info, password reminders or other things
that the user might want to immediately check his in box for, you want
them to get to the users ASAP, so forking or SMTPing to a local MTA
makes a lot of sense.
If you're already using a database for your app, it'll probably have the
locking issues dealt with, popping messages of the queue and handing
them to an MTA qould be trivial. If you're using a database that
supports triggers you might even be able to get away without perceivable
delays. And you might be able to move the mail handling off to another
machine easily.
- Barrie
