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.
(I thought I had harped on this in the past but can't find any record
of it.)
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?
> 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?).
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?
As an aside: where else is 2.4.2.4 referenced? It has always struck
me as an orphaned paragraph.
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. There's directed a graph from email address
to mailbox, but there is no such mapping of mailbox to email address.
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.
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")
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.
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.
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.
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. 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.
mm