----- Original Message -----
From: "barries" <[EMAIL PROTECTED]>
To: "Per Einar" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, April 08, 2001 4:24 PM
Subject: Re: Sendmail or not?
> 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.
I will consider doing this, yes.
>
> 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.
Yes, this is exactly my case. That's why I didn't want to wait too long
before processing the message.
>
> 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.
Thanks a lot to you and to anyone else who contributed: you have helped me a
lot into finding solutions for my problem.
Per Einar Ellefsen
[EMAIL PROTECTED]
