Subject: RE: sieve vacation draft, really

From: [email-masked] (Alan Stebbens)
Date: Wed, 7 Jul 1999 19:01:46 -0700

| > * 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 <[email-masked]>

---

From: Tim Showalter <[email-masked]>
Date: Thu, 08 Jul 1999 22:24:04 -0700

> idea to automatically reply.

I agree, and there are safeguards in the spec, as is.

> back 100 automatic vacation responses, you would be little bit miffed, I'll

The vacation spec specifies the following:

* replies go to the envelope sender, NOT the from or sender address, so
I wouldn't get the responses, the list maintainer would.

* my vacation agent may only reply to a given message if my address is
in the to or cc lines.  So those replies won't be generated in the first
place.

So this vacation spec is not contributing to that problem.
   
> as well as certain Sender or From addresses (see next issue).

Precedence is not a standard header, and is referenced only in RFCs that
say not to use it.

> "implementation dependant".

I don't want to specify the list because it's a moving target.  If we
supply the list, it will be incomplete and probably a point where people
will attack the spec.

Worse, I don't want to specify that certain IDs always belong to the
mail system; that may not be true.

Preventing replies to system accounts is not a life-or-death feature. 
Some of these messages (like the ones from MAILER-DAEMON) will come with
an envelope sender of <>, so they don't count; we won't be replying to
bounces.

What you may not have realized is that it is important that this be at
least partially implementation-dependant in case someone invents yet
another one of these names.  We already have PoStMaStER, root,
MAILER-DAEMON, possibly Administrator, System, *-request, owner-*, etc.,
and it is not at all clear that all of these addresses are always system
accounts.

If the mail comes from a human behind the guise of a system account, it
may be useful to know that someone is on vacation, or that they won't
reply because the user name isn't familiar (ever send Nathaniel
Borenstein mail?).

That is, imagine that you're a postmaster, replying to mail with the
>From line [email-masked], and having my vacation decide not to
reply with the following message because you're clearly a computer:

	Hi.  I don't read mail from people I don't know.  I will
	never get your message unless you resend it t
	[email-masked].

What I'm trying to point out is that none of these addresses are
standard.  Requiring people to not reply to them is demanding that
people base standards on ad-hoc names that there may be very good
reasons to violate.

Given the fact that vacation replies to the envelope, not the from line,
I don't consider it much of an issue.

> Again, in this case certain source addresses

What's the benefit to doing this in a variable?  That is a MAJOR amount
of complexity to introduce, and there is running code that doesn't need
it.  (We're talking about another ten pages of spec and breaking several
implementations for what immediately amounts to a minor feature.)

> rule, without using VACATION.

No, an explicit rule doesn't help.  Vacation is the only command that
responds to messages, and it won't respond to them.

> list of addresses for which autoresponses will be avoided.

I am not convinced that this is the Right Thing, but we don't need
variables to do that.  We can get by with the existing spec plus an if,
i.e.,
	if not address :is :localpart "from" ["postmaster","mailer-daemon"]
		{ vacation ... ; }

My point is that variables are overkill.

> two unecessary messages.

One of those messages is never unnecessary.  If I send you mail, and get
a vacation, that message is mandatory; it's the whole point of this
spec.

> [deleted]

> to make it easier to write rules, so we might as well do so with the

You are handing me a loaded can of worms.  We don't "need" regular
expressions.  I don't want to have to write them up or reference a POSIX
spec that I don't have and can't afford.

I object to overloading the Subject header.  It has a perfectly good
meaning that cannot be understood by (modern) computers and hacking
around it with globs or regexps is not a clean solution.

We should add yet another header that can be properly standardized that
marks a message as automatically generated without consent of a human on
the other end.  I think this solves that problem, and should probably be
written up as yet another spec so that we don't have non-Sieve solutions
dependant on Sieve's vacation extension.

Would this solve that problem?

Tim

---

From: Tim Showalter <[email-masked]>
Date: 28 Jul 1999 18:13:10 -0700

> Would this solve that problem?

I have come to the conclusion that this is a good idea, and came up
with the beginnings of a spec.

Is this worth taking further?

----

The Automated Header

The "Automated" header indicates that the message came from an automated
agent.  While the From/Return-Path addresses may specify mailboxes read by
real people, the message did not strictly come from them.

Vacation autoresponders and mailing list exploders that support this header do 
not respond to messages containing this header.

Automated processes are encouraged to not generate this header, as
circumstances require.

User agents MUST NOT genertate this header (unless acting without the
knowledge of the user).  Specifically, this header MUST NOT be used to declare 
that users do not want automatic responses.  A mechanism for declaring that
automatic responses are not necessary is outside the scope of this memo.

Example: Automated: type=vacation

"type" attribute

The type attribute declares the type of the autoresponse.  Two types are
defined by this specification: vacation and mailing-list.

Vacation delcares that the message is a vacation-style autoresponse (text
specified by the sending user stating when the recipient can expect to see a
response).

Mailing-list specifies that the message was processed by a mailing list
exploder.  The original sender (whoever is on the From line) has no knowledge
that he has sent a particular mailing list subscriber a message.  The
Automated header indicates that the message was transmitted with the
assistance of such a mailing list agent, and it is unlikely that telling the
original sender that the mailing list subscriber is unavailible is helpful.

---

From: Tim Showalter <[email-masked]>
Date: 29 Jul 1999 14:55:10 -0700

> Is this worth taking further?

Alexey Melnikov pointed out that I'm reinventing the wheel, and that
Jacob Palme has already written a header that does just this.  It
looks like "Auto-submitted: auto-replied" is what I want.

Thanks.

 http://search.ietf.org/internet-drafts/draft-ietf-mailext-new-fields-15.txt

To: [email-masked]
Subject: Re: sieve vacation draft, really
From: Tim Showalter <[email-masked]>
Date: 29 Jul 1999 14:55:10 -0700
Lines: 14
Sender: [email-masked]

> Is this worth taking further?

Alexey Melnikov pointed out that I'm reinventing the wheel, and that
Jacob Palme has already written a header that does just this.  It
looks like "Auto-submitted: auto-replied" is what I want.

Thanks.

 http://search.ietf.org/internet-drafts/draft-ietf-mailext-new-fields-15.txt

To: [email-masked]
Subject: Re: sieve vacation draft, really
From: Tim Showalter <[email-masked]>
Date: 28 Jul 1999 18:13:10 -0700
Lines: 52
Sender: [email-masked]

----

The Automated Header

"type" attribute

Date: 23 Jul 1999 17:34:34 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: redirect action
Sender: [email-masked]

   We'd like to see similiar wording as to what was done for the "fileinto"
   action. I.e.  Implementations SHOULD support redirect, but in some
   environments this may be difficult.

If this is going to be done, I would like this decision to be made
soon.  We're planning on rolling out a Sieve mail filter rather soon,
and I would prefer that scripts not break because they lack a
require "redirect"
command.  (Conversely, adding require "redirect" into scripts now
would make them not work.)

On retrospect, it seems somewhat unfortunate that we didn't require a
minimal functionality from implementations.

Larry

From: "Mike Gahrns" <[email-masked]>
To: <[email-masked]>
Subject: redirect action
Date: Fri, 23 Jul 1999 13:57:29 -0700
Sender: [email-masked]

We have interest in this draft, but may have some trouble implementing the
"redirect" action however.

We'd like to see similiar wording as to what was done for the "fileinto"
action. I.e.  Implementations SHOULD support redirect, but in some
environments this may be difficult.

Would it be possible to make "redirect" symmetrical with "fileinto" in this
regard.

thx

Date: Thu, 08 Jul 1999 22:24:04 -0700
From: Tim Showalter <[email-masked]>
To: [email-masked]
CC: Tim Showalter <[email-masked]>, [email-masked]
Subject: Re: sieve vacation draft, really
Sender: [email-masked]

   

Tim

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, 7 Jul 1999 19:01:46 -0700
Importance: Normal
Sender: [email-masked]

Tim,

Thanks for the reply.

Date: Tue, 6 Jul 1999 17:25:46 -0700
To: Lawrence Greenfield <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: Storing filters in LDAP
Sender: [email-masked]

At 9:26 PM -0400 7/2/99, Lawrence Greenfield wrote:

>I agree with Randy that ACAP is the best place to store sieve
>scripts.  We could define a small subset that an ACAP server must
>support to handle Sieve scripts which should be straightforward to
>implement and place no large resource requirements on servers.
>
>Locating the ACAP server would be interesting.  I would suggest
>connecting to the ACAP port on the same host as the IMAP server, but
>paying attention to referral.  (This complicates the client
>implementation somewhat, but is probably worth it.)

I suggest we use a different port, since the server may support a 
subset of ACAP.

We probably need a new email accounts dataset attribute, 
email.sieve.script.url, and should probably rename the 
email.sieve.script to email.sieve.script.text.  Then, if there is a 
general ACAP server available, the client can connect to it and 
examine the email.sieve.script.url attribute of the email accounts 
dataset.

If both are null and the client wants to store a Sieve script, the 
capabilities dataset should be queried to determine if this server 
supports Sieve.  If not, I suppose the client should try the ACAP 
Sieve profile port on the mail server.  It should then store into 
either email.sieve.script.text or into email.sieve.script.url on the 
ACAP server and into email.sieve.script.text on the mail server.

If there is no general ACAP server available, then the ACAP Sieve 
profile port of the mail server should be tried.

>I could probably produce a draft of such functionality (and perhaps a
>prototype server) if people desire.

I was going to write a draft for the ACAP Sieve profile, I'd be happy 
to either let you do it or to coauthor it with you.

I think a prototype server would be useful.  We do have some code 
we've been playing with which we were considering for inclusion in 
qpopper 3.1, if it gets finished in time.  The more the merrier.

Date: 2 Jul 1999 21:26:21 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: Storing filters in LDAP
Sender: [email-masked]

I agree with Randy that ACAP is the best place to store sieve
scripts.  We could define a small subset that an ACAP server must
support to handle Sieve scripts which should be straightforward to
implement and place no large resource requirements on servers.

Locating the ACAP server would be interesting.  I would suggest
connecting to the ACAP port on the same host as the IMAP server, but
paying attention to referral.  (This complicates the client
implementation somewhat, but is probably worth it.)

I could probably produce a draft of such functionality (and perhaps a
prototype server) if people desire.

Larry

Date: Fri, 2 Jul 1999 17:33:16 -0700
To: "Bruce Steinback" <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: Storing filters in LDAP
Sender: [email-masked]

I think we'll see UIs that expose a subset of Sieve functionality to 
users, very much like today's mail client filter UIs.  The UI itself 
will generate and interpret Sieve syntax (and will probably punt on 
interpreting complex Sieve scripts and present an edit box).

How the UI accesses the Sieve script is n interesting question.  My 
Email Accounts draft (draft-ietf-acap-email-02.txt) suggests using an 
ACAP dataset for email account information.

We have prototype code that includes an NT GUI for Sieve creation and 
editing, a mini-ACAP server for accessing the Sieve script, and a 
Sieve execution engine.  The actual Sieve script is stored in a file, 
but this is invisible except to the mini-ACAP server and the Sieve 
execution engine.

I can also see people implementing various other access methods 
including email and HTTP.

I think ACAP is attractive because it allows the client to get 
extension information and syntax errors and the syntax is very easy 
on both the client and the server, and there is no need for a full 
ACAP server -- the mini-server (just for Sieve) works well.