On Wed, Mar 16, 2005 at 03:51:01PM -0500, Internet-Drafts(_at_)ietf(_dot_)org
wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Sieve Mail Filtering Language Working
Group of the IETF.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-00.txt
A bunch of niggling comments, which I hope don't sound too contentious.
3.2 Previous Response Tracking
> 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.
Another reason to have this is that it solves a real problem with using
variables and vacation together. Specifically, if you use variables to
construct vacation responses containing, say, the subject line of the original
message, or worse, the message-id, duplication response elimination goes right
out the window. And I know for a fact that people will do this - as it happens
we have folks clamoring for access to this particular capability.
I'm therefore going to add this, but it will have to be done with an optional
tagged parameter at this point lest we break existing implementations. It does
add yet another parameter to what is already a fairly complex action, but
actual implementation of it is pretty simple and it solves a fairly serious
problem in the process.
An open question is whether or not I should add some discussion of the
variables interaction issue as part of this. I have not done so yet. What
do people think?
(I thought I had harped on this in the past but can't find any record
of it.)
I've been toying with the idea of adding it for a while; I don't recall who
suggested it or if I thought it up independently.
Setting that aside, though:
> If a script is changed, implementations MAY reset the records of who
> has been responded to and when they have been responded to.
> Alternatively, implementations can store records of who has received
> which message, perhaps by storing a hash of the message and the
> recipient.
I don't understand how the second sentence is an alternative to the
first. The first sentence is about flushing the database if the
script is changed; the second is about how to store things in the database.
Am I confused here?
No, this needs better wording. I'll see what I can do.
> Implementations are free to limit the number of remembered responses,
> provided the limit is no less than 1000.
> Implementations SHOULD make the limit no less than 1000 per vacation
> command if using the hash algorithm described above.
Similarly, I don't see how the second sentence above enhances the first.
Actually I don't see how the second sentence is relevant at all. If
there's a limit and a miminum on that limit, why does it depend on the
storage/uniqueness method chosen (especially given that the minimum in
the second sentence is the same as the one in the first-- what's the
distinction, and if there's no difference in the minimum, what's the
purpose of the distinction?).
Agreed. I'll delete the sentence.
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?
What's of primary importance here are the syntax/semantics of the
reason string when :mime is used. Its fairly clear that it consists
of zero or more MIME headers, a CRLF, and then a MIME body.
We have a standardized term for this defined in RFC 2045: Its a MIME
entity. I'm therefore going to change the term used to "MIME entity"
and refer to RFC 2045 section 2.4, not RFC 3028.
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?
How the MIME content is used to build a response message is a separate matter.
The MIME headers provided could either be merged into the main message header
or they could be placed inside a multipart. I personallly prefer the former,
but it isn't clear to me that we should nail this down. I'm therefore going to
leave it unspecified unless there's a clear consensus to change it.
As an aside: where else is 2.4.2.4 referenced? It has always struck
me as an orphaned paragraph.
Not my problem ;-)
3.5 Address Parameter and Limiting Replies to Personal Messages
> "Vacation" MUST NOT respond to a message unless the user's email
> address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or
> "Resent-Bcc" line of the original message. Implementations are
> assumed to know the user's email address, but users may have
> additional addresses beyond the control of the local mail system.
Implementations may or may not know the "users's email address." In
some environments (including my own) there is a many-to-one mapping of
email address to mailbox.
Actually, my environment is even more complex - there's a many-to-one mapping
of addresses to mailboxes. The way I have to perform this check is to subject
each address to a specialized form of rewriting (that doesn't respect some
"don't use this one in rewriting" flags), rewrite the address information I
have for the mailbox, and see if there are any matches between elements on the
two lists.
There's directed a graph from email address
to mailbox, but there is no such mapping of mailbox to email address.
And that's why :addresses exists - so scripts in your environment can perform
this check even though the implementation's list of known recipient addresses
is empty.
An implementation might know the address being delivered to (the
envelope recipient). UNIX "vacation" has a place to put additional
email addresses to look for, because the envelope recipient has
typically been been lost at this point. I would say that that's also
the value of the ":addresses" here too.
So I would think this would say that the envelope recipient, if known,
OR one of the addresses listed in the :addresses must appear in one of
the listed header fields.
I really don't think a change is in order here. Nothing in the present text
makes an implementation that has no knowledge of its own of the recipient's
address(es) incompliant. And OTOH I really don't think we should encourage
implementations that are ignorant of this. (It is one thing when circumstances
make it impossible, quite another where a standard in effect condones lazy
implementation practices.)
3.6 Restricting Replies to Automated Processes and Mailing Lists
> Implementations SHOULD NOT not to respond to any message with a
> header that begins with "List-".
"not respond to" (delete extra "to")
And the extra "not". Done.
3.7 Interaction with Other Sieve Actions
> 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.
It pretty much has to be fuzzy. As you say, some actions may have
already been performed, so what it means to "fail" when the second
vacation is executed is somewhat implementation dependent. But there
are plenty of other cases in sieve where execution of an action or
test can fail for some reason, so this is hardly a problem unique
to vacation.
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 especially care personally, but since it doesn't actually solve any
underlying problem I'm not going to change it.
4.1 SMTP MAIL FROM address
> NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the
> SMTP transaction if the NOTARY SMTP extension is available.
Hmm, "NOTARY" ? Assume this refers to DSN (rfc1891).. in any
case the reference should be listed.
RFC 3461 actually. Added.
4.4 From
> Unless explicitly overridden with a :from parameter, the From field
> SHOULD be set to the address of the owner of the Sieve script.
Reiterate that this is not necessarily known.
And that's why it is a SHOULD, not a MUST.
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.
Or some sort of "site vacation response" address. Again, while I understand
that some implementations may have some isuses here, I really don't want to
encourage lazy implementors to fail to dig out information they do have
available or to use it properly.
Ned