<<< Date Index >>>     <<< Thread Index >>>

Re: Just a question



On Thu, Apr 01, 2004 at 02:15:40PM +0100, Richard Curnow wrote:
> * Charles Cazabon <mutt@xxxxxxxxxxxxxxxxxxxx> [2004-03-31]:
> > 
> > No, especially considering you're using your ISP's smarthost.  The only 
> > thing
> > a "real" MTA would buy you would be if you wanted to send email to another
> > user on your system (i.e. host local mail yourself).
> 
> What about queueing mails on your local system to upload to the ISP's
> smarthost when you go online?  I tend to write a lot of emails offline
> and queue them.  Having a local MTA is useful for this too.

nullmailer appears to be able to handle off-line queuing. I haven't
tried it because I have broadband.  This from man nullmailer-send:

DESCRIPTION
       This program is responsible for coordinating the transmis
       sion of messages that  have  been  queued  by  nullmailer-
       queue.   It  uses a variety of protocol modules to deliver
       the messages from the queue to remote "smart" servers.

       When the program starts, the queue is scanned to  build  a
       list  of  messages  to  send.  The queue is rescanned when
       either the trigger is pulled, or after  pausetime  seconds
       have  elapsed  after the last failed delivery.  When there
       are no messages in the queue, nullmailer does  no  rescan
       ning  until  the  trigger  is pulled.  Pulling the trigger
       consists of opening up the trigger named pipe and  writing
       a single byte to it, which causes this program to be awak
       ened (if it's not already  processing  the  queue).   This
       procedure  is done by nullmailer-queue to ensure that mes
       sages are delivered immediately.

       Delivery of messages  consists  of  reading  the  list  of
       remote  servers and then trying to deliver the messages to
       these servers as follows.  For each remote  in  the  list,
       the  named protocol handler is executed once for each mes
       sage remaining in the queue.  If the protocol handler suc
       ceeds,  the message is removed from the queue and process
       ing continues with the next message.   If  it  fails,  the
       remote  is  skipped and processing of the remaing messages
       continues with the next remote.  When all the remotes have
       been tried, nullmailer-send sleeps for a number of seconds
       specified by pausetime before retrying  sending  the  con
       tents of the queue.

My motivation for using nullmailer is two-fold:
1) it's so easy that I can manage it; on Debian stable it just worked
2) my paranoid side tells me to avoid complexity whenever possible,
   so if nullmailer provides only what I need, then I am safer 
   then if I used a full-featured MTA
-- 
Mike

Moving forward in pushing back the envelope of the corporate paradigm.