ietf-mta-filters
[Top] [All Lists]

RE: sieve vacation draft, really

1999-02-26 17:03:01
| > One think that I thought of was that if I can edit the sieve script
| > then I am not on vacation anymore or I am about to start another and
| > that the list should be cleared. What I would like is for every
| > vacation statement to have a list of it's own based on the message

I agree.  Each vacation statement should have its own cache of reply
timestamps.

Some other issues related to vacation:

From reading the Sieve Vacation spec, it isn't clear to me if vacation
generates relies to the common system manager, root, mailer-daemon, and
other well-known addresses.  Even if there is code in the implementation to
avoid auto-replies to mail from computer entities, there should be a way to
modify this list of addresses to which auto-responses should be avoided.

I do not think that this list should be specified as an argument to the
vacation action.  The list is too long, and remains fairly constant over
time.  It only periodically needs to be changed.  To me, this speaks to the
need of a variable that can be set by the user somewhere and referenced by
the vacation action.  For example, if there were an intrisic variable called
"MAILER_LIST", then the vacation should be implemented to avoid
auto-responding to the MAILER_LIST.

Similarly, it should be possible to allow the user to decide if vacation
should respond to addresses on the "To" header alone, or on both the "To"
and "Cc" headers.  For example, in my current procmail recipes, my vacation
response occurs only to "To" header mail.

Further, if the message is either a bulk mail, or is itself an auto-response
from some other program, then it probably doesn't make much sense to
auto-respond to it.

Of course, it is possible to write a complicated Sieve rule to detect these
cases, but then this ruleset will have to written throughout all of
Sieve-land, whereever it is used.  If the proper use of vacation requires
the observance of these various factors, then the implementation of vacation
ought to provide for these rules in the first place.

I've spent a considerable amount of time implementing a procmail recipe
("ackmail.rc") that is flexible yet careful about not responding
unecessarily.  The rules that govern its behaviour are:

1. Is it addressed to me (using any of my addresses)?
2. Is the mail NOT from any kind of system or mailer daemon?
3. Is the mail NOT from a mailing list or bulk mail?
5. Does the subject NOT have any text indicating some kind of automatic
   reply mechanism has already taken place?
6. Is this NOT a message we generated (a bounce, maybe)?
7. Is the message NOT from anyone on our "noack" list?
8. Is it from an address that is NOT already in our acknowledgement cache?
In my implementation, addresses in the cache have corresponding timestamps
which cause them to expire, allowing subsequent auto-responses.

If vacation doesn't observe these rules, then it will generate an unecessary
auto-response to either a program (which won't understand it, and will
likely auto-respond itself), or to a person who won't appreciate it.

I don't mean to make this vacation action more complicated than it is, but
it *is* complicated if you wish to make it useful without also inducing
anguish.

If you are familiar with procmail recipes, and wish to see the
vacation/auto-ack recipe file, send me a message with the subject "send
procmail library", and examine the "ackmail.rc" file.

--
Alan K. Stebbens <alan(_dot_)stebbens(_at_)software(_dot_)com>
Software.com, 525 Anacapa St., Santa Barbara, CA 93101
Work: 805.882.0579 Fax: 805.957.1544





<Prev in Thread] Current Thread [Next in Thread>