On Mon, Mar 28, 2005 at 03:45:57PM -0500, Mark E. Mallett wrote:
> Vacation responses are not just per address, but are per address per
> set of arguments to the vacation command.
The idea of vacation profiles is a good goal, so that you might be able
to return different vacation results to the same address depending on
different triggers. Personally I wouldn't choose to use the sum of the
vacation arguments to synthesize that profile, though. I'd like to see an
explicit vacation handle that could be used for this purpose; this would
allow you to differentiate the responses or response characteristics
based on various criteria without automatically creating a whole new
profile in the process. You could do this with a mandatory positional
argument e.g.:
vacation "standard" "I'm not in"
vacation "standard" "Hey Ralph, I told you I was going to be out"
or with a tagged argument of some sort.
My initial reaction to this was: Do we really need yet another option?
Initially, I got the discussion about using ":mime" besides ":subject"
going, and it ended up as "per set of arguments" in the new draft.
That includes ":addresses" now. Good or bad?
By now I wonder if there is an intuitive solution to this entire problem
of profiles and perhaps there isn't, besides your suggestion. If so,
I would prefer a tagged argument to specify a different profile, using
the profile "vacation" by default. But I am still not sure about this,
as we may feature vacation to death.
3.4 MIME Parameter
> The ":mime" parameter, if supplied, specifies that the reason string
> is, in fact, a MIME part, including MIME headers (see section 2.4.2.4
> of [RFC3028]).
I think more should be said about what is expected of the implementation
in this case. Does this mean that the given string is a complete mime
part that is to be contained in the message via 'multipart' in the
message header? Or that the headers in the given string are to be
extracted and folded into the message header, and the non-header portion
used as the message body?
I asked that some time ago and more or less just got the response: Yes,
it's not specified, so do whatever fits into the "specification". From
my notes:
RFC 3028 does not specify how strings using MIME parts are used to compose
messages. The vacation draft refers to RFC 3028 and does not specify it
either. As a result, different implementations generate different mails.
The Exim Sieve implementation splits the reason into header and body.
It adds the header to the mail header and uses the body as mail body.
Be aware, that other imlementations compose a multipart structure with
the reason as only part. Both conform to the specification (or lack
thereof).
So I agree, more should be said. Even the above is more helpful for
development of new implementations that the current state.
> Vacation can only be executed once per script. A script will fail if
> two vacation actions are used.
This is fuzzy. In an implementation that executes actions as they
are encountered, the first 'vacation' will have already been completed
by the time the second has been detected. It's hard to say that the
script has "failed" if the first vacation response has been issued.
And what does "fail" mean here? should stop? Any "fileinto" or
"implicit keep" should not happen? If so, that means a vacation message
would be returned, but the mailbox owner would not have a copy of
the message.
RFC 3028 2.6.10 is very clear on error handling, but a reference to that
may be in place here.
Obviously I don't care for this ... I'd rather say that only only one
vacation will succeed, and other vacation statements are silently
inhibited.
I don't know why multiple vacation responses are forbidden, but a single
autoresponder loop, should it ever happen, is bad, but not a real problem
for anything but the smallest system. One that multiplies messages may
cause real trouble. Trying to send multiple responses is a real error
to me and not something I would want to ignore silently.
Reiterate that this is not necessarily known. My environment does
not know it, for example. It's more likely to know the envelope
recipient address. What shall we do if neither of these are known,
and no ":from" appears? One obvious thing is this: in order for the
vacation response to be returned (per 3.5 above) one of the addresses
in the "To", "Cc" (etc) headers has been matched. I'd suggest using
whatever address was matched.
I disagree: Suppose the envelope recipient is a, but the header says b
and the script contains b in ":addresses". As a result, the response
would be sent with from header b, which may be a foreign address and
thus forbidden.
Michael