Re: 2 questions

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Neal Becker
CC: exim-users
Subject: Re: 2 questions
On Wed, 13 Nov 1996, Neal Becker wrote:

> 1) I just read "simplified vacation processing".  I don't understand
>    it.  It says, "A local part prefix suach as 'vacation-' can be
>    specifed on a director ..."  What exactly does that mean?


It means setting the option

prefix = "vacation-"

on a director, which constrains it to acting only on local parts that
start "vacation-".

>    "...message to be delivered directly to the vacation program, or
>    uses Exim's autoreply transport."  What determines which one?  


The configuration. For example, you might have

vacation_director:
driver = smartuser,
prefix = "vacation-",
transport = vacation_transport;

which would catch all local parts starting with "vacation-" (but no
others) and pass them on to

vacation_transport:
driver = pipe;
command = "/usr/bin/vacation ${local_part}"

or instead you could have something like

vacation_transport:
  driver = autoreply;
  text = "$local_part is on vacation",
  file = /home/$local_part/.vacation.msg,
  file_optional       


With a configuration like this, all the user has to do is to put

user, vacation-user

in a .forward file to turn it on. Alternatively, you could use
require_files to trigger the whole thing on the existence of a file
called .vacation.msg in the user's home directory.

> 2) I asked on this list before about handling of accounts for persons
>    who have left.  I got lots of interesting responses.  It looks to
>    me that most people are not using a vacation program, but just a
>    shell script that returns a message.  Am I the only one paranoid
>    about mail loops?


We cause mail for such people to be piped to the following script

#! /bin/sh

cat <<End
Your mail to $LOCAL_PART@$DOMAIN was not delivered because that user no
longer has an account on this system.
End

from a pipe transport that has "return_output" set. This causes the
message to go back as a delivery error message, which should not cause a
mail loop (but I'm increasingly seeing automatic replies to such things
from systems that ignore the RFCs).

> exim-release request: Before release, can we try to collect some more
> examples of configurations? I think new exim admins will find it a
> whole lot easier to see some examples than to pour over the manual.


I think "release" is a nebulous concept. In some sense it has already
happened. However, I'm all in favour of collecting configurations, but I
don't think I have time myself. I'll be happy to include them in future
distributions if people will care to contribute. I might also be tempted
to criticize. :-))

--
Philip Hazel                   University Computing Service,
ph10@???             New Museums Site, Cambridge CB2 3QG,
P.Hazel@???          England.  Phone: +44 1223 334714