ietf-mta-filters
[Top] [All Lists]

Re: I-D ACTION:draft-ietf-sieve-vacation-00.txt

2005-03-29 10:37:54

On Tue, Mar 29, 2005 at 10:57:15AM +0200, Michael Haardt wrote:
On Mon, Mar 28, 2005 at 03:45:57PM -0500, Mark E. Mallett wrote:
    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.

I think it's a choice between several imperfect alternatives.  I
generally prefer making something like this explicit, e.g. via a profile
name, rather than implicit as in the synthesized profile; further I
don't think the synthesized profile always works correctly (in that you
can't vary anything without creating a different profile).

One of the issues is that a vacation facility really does need a lot of
parameters.  There are other ways to go about expressing them, but they
are probably not relevant to this draft.


   > 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.

(or 2.10.6)-- in fact I originally quoted from that section but removed
it in an edit before hitting send.  And shoot, the stuff about implicit
keep was a mistake, sorry.  What I was thinking about was how this
philosophy of handling multiple vacation actions is different from the
philosophy behind handling multiple fileinto actions, say.  Consistency
is good, and toward that end I would think we would treat multiple
'vacation' statements like multiple 'fileinto's -- de-duplicate them for
all the reasons that we do for fileinto, or like multiple 'reject's
which are prohibited (which I have taken to mean "inhibited" a la
duplicate fileinto).



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.

Agreed- I wasn't suggesting that encountering multiple vacation
statements would generate multiple returns.



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.

If you know that the envelope recipient is 'a' the scenario doesn't
apply.  My comment was about what to do if you don't know the envelope
recipient address, there is no "owner email address" known, and there's
no ":from" .

mm