Date: Wed, 17 Feb 1999 18:20:56 +0100
From: Michael Salmon <Michael(_dot_)Salmon(_at_)uab(_dot_)ericsson(_dot_)se>
| The ":days" argument is used to specify the period in which addresses
| are kept and are not responded to, and is always specified in days.
| The minimum and default value is 7.
|
| "Vacation" keeps track of all of the addresses that it has responded
| to in some period (as specified by the :days optional argument). If
| vacation has not previously responded to this address within that
| time period, it sends the "reason" argument to the Return-Path
| address of the message that is being responded to.
Shouldn't :days have a maximum as well as a minimum?
Yes, added:
The ":days" argument is used to specify the period in which
addresses are kept and are not responded to, and is always
specified in days. The minimum value used for this parameter is
1. Sites MAY define a different minimum value. Sites MAY also
define a maximum days value, which MUST be greater than 7, and
SHOULD be greater than 30.
and:
If ":days" exceeds the site-defined maximum, the site-defined
maximum is used instead.
Presumably one can have more than vacation statement in a script and
if that is the case must all :days be the same? What happens if they
aren't? Should the respondent lists be independent?
What's the problem?
I don't have strong motivation for making multiple vacations in a single
script act specially, although I believe that a given script should only
send out a vacation message once.
I think that having independent vacation messages should be allowed but
that the effect of differing dates be implementation defendant.
Why?
I also feel that it should be possible to clear the respondent lists
so that new messages are distibuted.
I oppose this on two grounds: first, how does one clear the respondant
lists? Such things are very implementation dependant, and I'd rather
just not discuss them. Second, Those features are in vacation for
safety reasons; earlier drafts had a command that did not have them
called "reply" that were removed for these reasons.
--
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>