Michael Haardt skrev:
> We may have a different understanding of "alias". On my system, there
> are mailboxes and aliases. Some aliases do not point to a local mailbox,
> but to a mailbox on a foreign system.
We probably do have very different ideas of what aliases are. On my
system I've given up on the idea of aliases. The database that deals
with mail has 3 primary tables: Users, domains and locals. Think of
a user as a mailstore to get the mental image. I like this model as
there are no special cases for addresses/aliases.
>>vacation :addresses "bob@???" "I'll be back for newyears";
>>vacation :addresses "alias@???" "I'll be back for newyears";
>
> Vacation MUST be executed only once per script, so this fails right away,
Sure, but someone could send a message first to bob@ and then later
to alias@. In that case I think the draft says you are REQUIRED to
respond to both (see below).
> I think (not sure here) the draft does not specify this, but has the
> intention of using all parameters to vacation to compare different
> statements in the sense of the draft. It fails to mention using ":mime",
> too, but intends to use that. Your patch is wrong, no matter how the
> draft is interpreted, but I may have to add the :addresses parameter to
> build the database name and indeed two notices would result from that.
> I will look at it.
From draft-showalter-sieve-vacation-06:
"Vacation responses are not just per address, but are per address per
set of arguments to the vacation command."
And:
"The 'per set of arguments' described above is intended to ensure that
a respondee gets all of the various possible responses, not merely the
first one. So, if the :subject or :mime parameters would result in a
different message, a different message MUST be sent by the
implementation."
If you look at the first statement, it would seem you need to add the
addresses from :addresses to the hash. But the second statement seems
to indicate that this is only required if the Subject: or message
content would be different (which is what the current code does).
Maybe this should be clarified in the draft before it is published
as en RFC?
One "problem" if you where to add :addresses to the hash would be that
the following two scripts would (in my opinion) violate the "principal
of least astonishment", whereas my patch would result in (again in my
opinion) the expected (though probably not standard compliant) behavior.
----------------------------------------------------------------------
vacation :addresses "a@b" "I'll be back for newyears";
vacation :addresses "c@d" "I'll be back for newyears";
----------------------------------------------------------------------
vacation :addresses ["a@b","c@d"] "I'll be back for newyears";
----------------------------------------------------------------------
>> days=VACATION_MIN_DAYS>7 ? VACATION_MIN_DAYS : 7;
>> First line; shouldn't that be VACATION_MAX_DAYS in that calculation?
>
> No. From section 3.1, too:
> If ":days" is omitted, the default value is either 7 or the minimum
> value (as defined above), whichever is greater.
>
> And that's what the code does, setting the default days value.
You are 100% correct. I had trouble with the same thing when I read the
draft. For some reason I mixed up the site defined minimum with the
default minimum. Sorry about that :-)
> It's this kind of critically looking at the code that lets open source
> work best. Too bad it happens so rarely, so thank you twice for doing it!
And thank you for being so responsive. This is what makes it both fun
and productive to do this sort of thing. Do you have any plans to
implement some of the other Sieve extensions? If so, please feel free
to ask for help with testing or a review...
Bob
