| > * does it generate replies to bulk mail? If not, how does it
| decide not to?
|
| Yes; what's the difference? Users can selectively do vacation
| responses, of course, but...
Tim,
Thanks for the reply.
It is generally a Bad Idea to respond automatically to any kind of bulk or
list mail. I cannot think of a single valid reason to have an automatic
response sent to a list. Even if it is possible to determine who was the
original sender of a message that was relayed through a list, it is a bad
idea to automatically reply.
For example, if you send a mail through the "IETF-MTA-FILTERS" list and got
back 100 automatic vacation responses, you would be little bit miffed, I'll
bet.
So, given that it is a Bad Idea, it seems reasonable (to me :^) that the
VACATION extension specifically state that it will not ever respond to mail
with certain attributes, including "Precedence: bulk" or "Precedence: list",
as well as certain Sender or From addresses (see next issue).
| > * does it generate replies to "mailer-daemon", "Postmaster", "root", and
| > other system accounts?
|
| Implementation dependant (as of the next revision).
It is a bad idea to leave what should be consistent behaviour as
"implementation dependant". Again, in this case certain source addresses
should *never* receive automatic responses. The VACATION spec should
enumerate the well-known system and postmaster account names in addition to
specifying a VARIABLE that can be set on a per-site basis. [Hint: Sieve
should support variables, of some kind, and not leave the details to a
"implementation dependent" spec.]
The only possible reason to not build-in a specific list of well-known
system addresses is because it is remotely possible that some site might
wish to include even these addresses in the vacation responses. This is an
extremely unusual case, and can be provided for by using an explicit Sieve
rule, without using VACATION.
It my understanding that the VACATION action is designed for common use by
end-users. For this reason, it should be constrained against Bad behaviour.
Thus, IMHO, VACATION MUST NOT generate responses to a well-known set of
addresses, and, in addition, SHOULD support a site-specific or user-specific
list of addresses for which autoresponses will be avoided. The method of
specifying the site- or user-specific SHOULD occur through the definition of
these variables:
SITE_IGNORE_ADDRS=<address-list>
IGNORE_ADDRS=<address-list>
<address-list> ::= <address> [<separator> <address-list>]*
<separator> ::= "," | ";" | " "
| > * does it generate replies to mail with any subject containing the text:
| > "[vacation]" or "[auto-response]"? If so, why? If not, are
| these the only
| > two strings that are recognized as being generated by an email
| > auto-responder.
|
| Yes, why not?
This is another Bad Idea. If my auto-responder replies to a message from
you about my being on vacation, and your auto-responder replies to that
message, you and I both will have contributed to at least one and possibly
two unecessary messages. Eventually, you and I will have to read and delete
these worthless messages at a cost of our personal time and attention. We
want the VACATION extension to relieve work, not create more of it.
Your question is cogent. There are other strings that should be avoided,
but this SHOULD be site- and user-configurable. However, even without any
site- or user-specification of specialized subject tokens, there should be a
set of DEFAULT tokens defined by the VACATION spec. So, I suggest these
VARIABLES:
SITE_AVOID_SUBJECT_TOKENS=<token list>
SITE_AVOID_SUBJECT_REGEXP=<token list>
AVOID_SUBJECT_TOKENS=<token list>
AVOID_SUBJECT_REGEXP=<regexp>
<token list> ::= <keyword phrase> [<token separator> <token list>]*
<token separator> ::= ";" | ","
The TOKENS variables are used to do case-insensitive matching of each token
phrase in the list against the subject.
The REGEXP variables are used as a regular expression match against the
Subject.
The SITE variables are applied as a default, in case the user has not
specified their own list. The VACATION spec should define a standard
default that implementations SHOULD follow, in the absence of site
definitions.
We're going to have to put regexp into the Sieve spec eventually, in order
to make it easier to write rules, so we might as well do so with the
AVOID_SUBJECT variables.
Thanks for the response. Sorry for the extremely late reply. It has been
pretty hectic lately.
--
Alan K. Stebbens <aks(_at_)software(_dot_)com>