Re: [Exim] queue_only_file behavior

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Bradford Carpenter
Date:  
À: exim-users
Sujet: Re: [Exim] queue_only_file behavior
On Monday, December 15, 2003, at 03:25 AM, Philip Hazel wrote:

>
>> Recently I created a startup script to just start the exim daemon when
>> my computer starts up; seemed a bit pointless starting and killing it
>> all the time.
>
> What command did you use to start up Exim? If it included -qxxx then
> the
> daemon will do queue runs. It sounds as though in your case you do not
> need to run a daemon. The job of the daemon is
>
> (a) To listen for incoming SMTP messages - not useful if not connected.
> (b) To start queue runners - not useful if you don't want them except
>     when explicitly started.


Just "exim -bd" as before with no queue runners scheduled.

Since exim is on an isolated system at the moment, everything is just
pointed to the loopback address. So if the exim daemon is *not*
running, trying to send an email from my client to exim does not work,
because 127.0.0.1 refuses the SMTP connection; the client (Apple Mail)
saves the message in "Drafts" because of the error. Our report emailing
scripts create new emails using mutt , which is apparently quieter
about dealing with this situation.

The idea is to pass along the emails to exim for queuing locally via
SMTP when not connected, then have exim send the emails via the
smarthost once connected. This is what I thought using the
queue_only_file was supposed to accomplish.

>
>> What am I missing here? Seems like exim should not be doing anything
>> with these mails except queuing them when the queue_only_file exists.
>
> Doing that doesn't go anywhere near the daemon.


Now I'm really confused. My system is set up to get mails to exim via
SMTP; if the daemon isn't running, exim receives no mails to "queue
only" as far as I know.

Obviously, I'm missing something basic. Can you clarify what I'm
misunderstanding in this? Otherwise, back to the exim specs, I guess.

Thanks,
Brad