3. Vacation Action
3.1 Days Parameter
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 normally 1. Sites MAY
define a different minimum value.
is 0 a valid minimum value?
0 would effectively disable duplicate response detection. Do we want to
allow implementations to do this? My feeling is no, but I'd like to hear
from others on this one.
The optional ":handle" parameter can be used to tell the sieve
nitpick: Sieve
Fixed.
single response. (Which response is sent depends on the order in
which the messages are processed.
nitpick: missing end parenthesis
Fixed.
Note that one way to implement the necessary mechanism here is to
store a hash of either the current handle and the recipient or, if
no
handle is provided, a hash of the generated message content and the
recipient.
this text should be changed if the intent is to consider the constant
value of the reason argument rather than the result after expanding
variables.
Agreed. Changed.
3.3 Subject and from parameters
The ":subject" parameter specifies a subject line to attach to any
vacation response that is generated. UTF-8 characters can be used
in
the string argument; implementations MUST convert the string to
[RFC2047] encoded words if non-ASCII characters are present.
how should :subject "=?UTF-8?Q?whatever?=" be handled? I believe it
should encode the string since it looks like an encoded word.
There's no need to encode it; it's already encoded. It just needs to be passed
through like any other text. The most we need to do here is to point out that
users can specify encoded words in the subject argument. And frankly, I'd
rather not point that out.
in other
words, even arguments which are US-ASCII only may need encoding.
I sure don't see why unless you're transcoding, which is far beyond the scope
of this specification.
4.2 Subject Parameter
Users can specify the subject of the reply with the ":subject"
parameter. If the :subject parameter is not supplied, then the
subject is generated as follows: The subject is set to the
characters
"Re: " followed by the original subject with all leading occurrence
of the characters "Re: " stripped off.
see below.
be generated, and References need not bne changed.
nitpick: "bne"
Fixed.
5. Relationship to Recommendations for Automatic Responses to
Electronic Mail
The vacation extension implements a "Personal Responder" in the
terminology defined in [RFC3834]. Care has been taken in this
specification to comply with the recommendations [RFC3834] makes in
regards to how personal responders should behave.
RFC 3834 says:
The Subject field SHOULD contain a brief indication that the
message
is an automatic response, followed by contents of the Subject field
(or a portion thereof) from the subject message. The prefix
"Auto:"
MAY be used as such an indication. If used, this prefix SHOULD be
followed by an ASCII SPACE character (0x20).
okay, MAY isn't as strong as a recommendation, but why not use "Auto:"
rather than "Re:"? in any case, the stated algorithm in 4.2 does not
contain any indication of the message being an automatic response.
I have no problem with this. Changed. I also dropped the bit about
removing Re: since it no longer makes sense to do that.
6. Security Considerations
It is critical that implementations correctly implement the
limitations described above. Replies MUST NOT be sent out in
response to messages not sent directly to the user, and replies
MUST
NOT be sent out more often than the :days argument states.
since the spec allows the database to be reset whenever the script is
updated, I wonder if the second MUST should be changed into a SHOULD?
I'd rather qualify it with "unless the script changes".
Ned