Subject: RE: sieve vacation draft, really

From: [email-masked] (Alan Stebbens)
Date: Wed, 21 Apr 1999 23:39:35 -0700

I am resending this.  I did not receive any response on the previous try,
and there are serious usability issues with the vacation action.

Can someone answer these questions about the VACATION statement:

* does it generate replies to bulk mail?  If not, how does it decide not to?

* does it generate replies to "mailer-daemon", "Postmaster", "root", and
other system accounts?

* 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.

* does it generate mail not directly addressed to my account?  How does it
know what my account is?  How can I tell VACATION what my account is (or
are)?

* does it generate responses to mail that I sent myself?  If so, couldn't
this start a mail loop?  If not, how does it know what my account is or
accounts are?

If the issues implied by these questions are not carefully considered, then
VACATION is a tool that, unleashed, can lead to an overall increase in
mail-related work and not otherwise, as it is intended.

My original mail follows:
-------------------------------------

| > 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 <[email-masked]>
Software.com, 525 Anacapa St., Santa Barbara, CA 93101
Work: 805.882.0579 Fax: 805.957.1544

Reply-To: <[email-masked]>
From: [email-masked] (Alan Stebbens)
To: "Tim Showalter" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: sieve vacation draft, really 
Date: Wed, 21 Apr 1999 23:39:35 -0700
Importance: Normal
Sender: [email-masked]

I am resending this.  I did not receive any response on the previous try,
and there are serious usability issues with the vacation action.

Can someone answer these questions about the VACATION statement:

* does it generate replies to bulk mail?  If not, how does it decide not to?

* does it generate replies to "mailer-daemon", "Postmaster", "root", and
other system accounts?

* 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.

* does it generate mail not directly addressed to my account?  How does it
know what my account is?  How can I tell VACATION what my account is (or
are)?

* does it generate responses to mail that I sent myself?  If so, couldn't
this start a mail loop?  If not, how does it know what my account is or
accounts are?

If the issues implied by these questions are not carefully considered, then
VACATION is a tool that, unleashed, can lead to an overall increase in
mail-related work and not otherwise, as it is intended.

My original mail follows:
-------------------------------------

| > 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 <[email-masked]>
Software.com, 525 Anacapa St., Santa Barbara, CA 93101
Work: 805.882.0579 Fax: 805.957.1544

Date: Mon, 19 Apr 1999 12:10:48 -0700
To: John Beck <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: body test?
Sender: [email-masked]

I think a body test would be a useful extension.  I can see an 
implementer choosing to either not support it, offer limited support, 
or full support.  By limited support I mean perhaps only the first xx 
octets of the body can be searched, and perhaps MIME decoding is or 
is not done.  There would need to be names for each optional 
subfeature, for extension capability reporting.

Date: Sun, 11 Apr 1999 01:45:43 +0400
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: Re: body test?]
Sender: [email-masked]

Here is several letters from my conversation with John Beck.

-------- Original Message --------
Subject: Re: body test?
Date: Sat, 10 Apr 1999 02:24:34 +0400
From: Alexey Melnikov <[email-masked]>
To: John Beck <[email-masked]>
References: <[email-masked]>

John Beck wrote:

> I searched the archive and found only a couple of ancient messages that
> discussed this, and then only in passing.  There is no body test.  One of
> those messages suggested it was too expensive in general (which it may well
> be); another that it was fodder for a future extension (which it also may
> well be).

What kind of test for body do you want? Do you want to search for
substring in
any text/plain part?
Do you want to search for regular expression?

> I'm particularly interested in what others think of the tradeoffs of end-user
> usefulness vs added costs in performance and complexity of implementation.
> As a user, I want this.  As an implementor, I'm not sure.

Personally I don't want to copy every bit of code that I have in IMAP (I
mean all
types of SEARCH criteria) into SIEVE implementation.

Also I don't think that every SIEVE environment can give you access to
body.

>  Comments?
> -- John

Alexey Melnikov
---------------------------------------------------------
Execmail and ISODE have merged into Messaging Direct
---------------------------------------------------------

-------- Original Message --------
Subject: Re: body test?
Date: Sat, 10 Apr 1999 19:44:50 +0400
From: Alexey Melnikov <[email-masked]>
To: John Beck <[email-masked]>
References: <[email-masked]>

John Beck wrote:

> +> I searched the archive and found only a couple of ancient messages that
> +> discussed this, and then only in passing. There is no body test. One of
> +> those messages suggested it was too expensive in general (which it may well
> +> be); another that it was fodder for a future extension (which it also may
> +> well be).
>
> Alexey> What kind of test for body do you want? Do you want to search for
> Alexey> substring in any text/plain part? Do you want to search for regular
> Alexey> expression?
>
> Yes and Yes.  Also, the ability to determine if the message contained an
> arbitrary MIME type.  E.g.,:
>         if body.content :contains "image/*" {
>                 fileinto "X";
>         } elsif body.text :contains "<regex for 10+ '$' characters>" {
>                 fileinto "Y";
>         }

It seems that you want to have something like IMAP BODYSTRUCTURE (i.e.
you want
headers of enclosed parts).
I think that in some environment it is more likely to get BODYSTRUCTURE
than
arbitrary access to message body.

Alexey

To: [email-masked]
Subject: body test?
Date: Fri, 09 Apr 1999 14:48:31 -0700
From: John Beck <[email-masked]>
Sender: [email-masked]

I searched the archive and found only a couple of ancient messages that
discussed this, and then only in passing.  There is no body test.  One of
those messages suggested it was too expensive in general (which it may well
be); another that it was fodder for a future extension (which it also may
well be).

I'm particularly interested in what others think of the tradeoffs of end-user
usefulness vs added costs in performance and complexity of implementation.
As a user, I want this.  As an implementor, I'm not sure.  Comments?

-- John

Date: 8 Apr 1999 17:22:23 -0400
From: Tim Showalter <[email-masked]>
To: John Beck <[email-masked]>
Cc: [email-masked]
Subject: Re: sieve vacation draft 
Sender: [email-masked]

> Tim> "Vacation" never responds to a message unless the user's email address
> Tim> is in the "To" or "Cc" line of the original message. Implementations are
> Tim> assumed to know the user's email address, but users may have additional
> Tim> addresses beyond the control of the local mail system.
> 
> Tim> Users can supply additional mail addresses that are theirs with the
> Tim> ":addresses" argument, which takes a string-list listing additional
> Tim> addresses that a user might have. These addresses are considered in
> Tim> addition to the addresses that the implementation knows.

> I like the above, but what about the following?  An implementation would
> be assumed to know that my address is <[email-masked]>, but I'd like a
> response to go out for mail to <jbeck@[*.]eng.sun.com>.  Is this covered
> by the "Implementations are assumed" clause?  The Unix vacation program
> only looks at the local part, and I think it would be a Good Idea to make
> it easy for people to specify the same behavior (if not the default).

I can buy that.  I guess we could make vacation take a comparator for
the aliases parameter.

I don't see any reason why implementations would be forbidden from that
behavior, but I can see reasons why it would be good for users to be
able to specify it.

Tim

-- 
Tim Showalter <[email-masked]>

To: Tim Showalter <[email-masked]>
cc: [email-masked]
Subject: Re: sieve vacation draft 
Date: Thu, 08 Apr 1999 14:18:37 -0700
From: John Beck <[email-masked]>
Sender: [email-masked]

Tim> This is a Sieve vacation draft. I would like to get the nits out of it

Tim> 3.6. Address Parameter and Limiting Replies to Personal Messages

Tim> "Vacation" never responds to a message unless the user's email address
Tim> is in the "To" or "Cc" line of the original message. Implementations are
Tim> assumed to know the user's email address, but users may have additional
Tim> addresses beyond the control of the local mail system.

Tim> Users can supply additional mail addresses that are theirs with the
Tim> ":addresses" argument, which takes a string-list listing additional
Tim> addresses that a user might have. These addresses are considered in
Tim> addition to the addresses that the implementation knows.

(If this was covered previously, forgive me, but I didn't notice it.)

I like the above, but what about the following?  An implementation would
be assumed to know that my address is <[email-masked]>, but I'd like a
response to go out for mail to <jbeck@[*.]eng.sun.com>.  Is this covered
by the "Implementations are assumed" clause?  The Unix vacation program
only looks at the local part, and I think it would be a Good Idea to make
it easy for people to specify the same behavior (if not the default).

-- John