Re: sieve vacation draft, really

[Tim Showalter <[e-mail]>]

Tim Showalter <[e-mail]> writes:

> 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?

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



Received: by mail.proper.com (8.9.3/8.9.3) id OAA24115 for ietf-mta-filters-bks; Thu, 29 Jul 1999 14:52:22 -0700 (PDT)
Received: from mail.mirapoint.com (IDENT:[e-mail] [209.157.59.162]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA24111 for <[e-mail]>; Thu, 29 Jul 1999 14:52:22 -0700 (PDT)
Received: from tim-bsd.mirapoint.com (tim-bsd.mirapoint.com [192.168.0.117]) by mail.mirapoint.com  with SMTP id ANK00031 Thu, 29 Jul 1999 14:54:47 -0700 (PDT)
X-Spook: supercomputer Janet Reno Roswell Ft. Bragg smuggle Noriega bomb
To: [e-mail]
Subject: Re: sieve vacation draft, really
References: <001101bec8e5$d545f3f0$[e-mail]> <[e-mail]> <[e-mail]>
From: Tim Showalter <[e-mail]>
Date: 29 Jul 1999 14:55:10 -0700
In-Reply-To: Tim Showalter's message of "28 Jul 1999 18:13:10 -0700"
Message-ID: <[e-mail]>
Lines: 14
User-Agent: Gnus/5.070093 (Pterodactyl Gnus v0.93) XEmacs/21.1 (Arches)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Showalter <[e-mail]> writes:

> 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?

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



Received: by mail.proper.com (8.9.3/8.9.3) id SAA00178 for ietf-mta-filters-bks; Wed, 28 Jul 1999 18:10:27 -0700 (PDT)
Received: from mail.mirapoint.com (IDENT:[e-mail] [209.157.59.162]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA00166 for <[e-mail]>; Wed, 28 Jul 1999 18:10:25 -0700 (PDT)
Received: from tim-bsd.mirapoint.com (tim-bsd.mirapoint.com [192.168.0.117]) by mail.mirapoint.com  with SMTP id ANG00028 Wed, 28 Jul 1999 18:12:49 -0700 (PDT)
X-Spook: $400 million in gold bullion Croatian assassination Watergate Noriega counter-intelligence diskless workstation
To: [e-mail]
Subject: Re: sieve vacation draft, really
References: <001101bec8e5$d545f3f0$[e-mail]> <[e-mail]>
From: Tim Showalter <[e-mail]>
Date: 28 Jul 1999 18:13:10 -0700
In-Reply-To: Tim Showalter's message of "Thu, 08 Jul 1999 22:24:04 -0700"
Message-ID: <[e-mail]>
Lines: 52
User-Agent: Gnus/5.070093 (Pterodactyl Gnus v0.93) XEmacs/21.1 (Arches)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim Showalter <[e-mail]> writes:

> 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?

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.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02592 for ietf-mta-filters-bks; Fri, 23 Jul 1999 14:32:34 -0700 (PDT)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02588 for <[e-mail]>; Fri, 23 Jul 1999 14:32:32 -0700 (PDT)
Received: from platypus.cc.cmu.edu (PLATYPUS.CC.CMU.EDU [128.2.121.154]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id RAA12959; Fri, 23 Jul 1999 17:34:34 -0400 (EDT)
Date: 23 Jul 1999 17:34:34 -0400
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.2
To: [e-mail]
In-reply-to: <000b01bed54d$f9f3dfe0$[e-mail]>
Subject: Re: redirect action
References: <000b01bed54d$f9f3dfe0$[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

   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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA02153 for ietf-mta-filters-bks; Fri, 23 Jul 1999 13:56:24 -0700 (PDT)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02149 for <[e-mail]>; Fri, 23 Jul 1999 13:56:23 -0700 (PDT)
Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by doggate.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id PB77XXAA; Fri, 23 Jul 1999 13:56:08 -0700
Received: from PTDOG.dfpt.extest.microsoft.com ([172.30.236.159]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2072.0072.0); Fri, 23 Jul 1999 13:58:58 -0700
Received: from mikega9 ([157.59.254.144]) by PTDOG.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2072.0072.0); Fri, 23 Jul 1999 13:58:57 -0700
Message-ID: <000b01bed54d$f9f3dfe0$[e-mail]>
From: "Mike Gahrns" <[e-mail]>
To: <[e-mail]>
Subject: redirect action
Date: Fri, 23 Jul 1999 13:57:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-OriginalArrivalTime: 23 Jul 1999 20:58:57.0836 (UTC) FILETIME=[2E90CEC0:01BED54E]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02393 for ietf-mta-filters-bks; Thu, 8 Jul 1999 22:27:39 -0700 (PDT)
Received: from mail.mirapoint.com ([e-mail] [209.157.59.162]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02387 for <[e-mail]>; Thu, 8 Jul 1999 22:27:37 -0700 (PDT)
Received: from mirapoint.com (tim-bsd.mirapoint.com [192.168.0.117]) by mail.mirapoint.com  with ESMTP id AIS00720 Thu, 8 Jul 1999 22:23:59 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 08 Jul 1999 22:24:04 -0700
From: Tim Showalter <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: sieve vacation draft, really
References: <001101bec8e5$d545f3f0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Stebbens wrote:

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

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

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

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

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

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

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 [e-mail], 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
	[e-mail].

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

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

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

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

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

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.

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

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.

> 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:
> [deleted]

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

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA12002 for ietf-mta-filters-bks; Wed, 7 Jul 1999 19:01:49 -0700 (PDT)
Received: from nome.software.com (nome.software.com [207.175.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11978 for <[e-mail]>; Wed, 7 Jul 1999 19:01:43 -0700 (PDT)
Received: from frankfurt ([10.2.5.26]) by nome.software.com (Post.Office MTA v3.5.3 release 223 ID# 0-0L0S0V35) with SMTP id com; Wed, 7 Jul 1999 19:01:54 -0700
Reply-To: <[e-mail]>
From: [e-mail] (Alan Stebbens)
To: "Tim Showalter" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: sieve vacation draft, really 
Date: Wed, 7 Jul 1999 19:01:46 -0700
Message-ID: <001101bec8e5$d545f3f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

| > * 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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA05763 for ietf-mta-filters-bks; Tue, 6 Jul 1999 17:34:05 -0700 (PDT)
Received: from strange.qualcomm.com (strange.qualcomm.com [129.46.2.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA05758 for <[e-mail]>; Tue, 6 Jul 1999 17:34:04 -0700 (PDT)
Received: from 129.46.158.108 (randy-mac.qualcomm.com [129.46.158.108]) by strange.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA07841; Tue, 6 Jul 1999 17:33:11 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v0421010bb3a84ba16944@129.46.158.108>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v0420550fb3a3093448b6@129.46.158.108> <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh
Date: Tue, 6 Jul 1999 17:25:46 -0700
To: Lawrence Greenfield <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Storing filters in LDAP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b12
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA04408 for ietf-mta-filters-bks; Fri, 2 Jul 1999 18:22:32 -0700 (PDT)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA04400 for <[e-mail]>; Fri, 2 Jul 1999 18:22:30 -0700 (PDT)
Received: from platypus.cc.cmu.edu (PLATYPUS.CC.CMU.EDU [128.2.121.154]) by smtp2.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id VAA06844; Fri, 2 Jul 1999 21:26:18 -0400 (EDT)
Date: 2 Jul 1999 21:26:21 -0400
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.2
To: [e-mail]
In-reply-to: <v0420550fb3a3093448b6@129.46.158.108>
Subject: Re: Storing filters in LDAP
References: <[e-mail]> <v0420550fb3a3093448b6@129.46.158.108>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA29991 for ietf-mta-filters-bks; Fri, 2 Jul 1999 17:35:14 -0700 (PDT)
Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA29987 for <[e-mail]>; Fri, 2 Jul 1999 17:35:12 -0700 (PDT)
Received: from 129.46.158.108 (randy-mac.qualcomm.com [129.46.158.108]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA19836; Fri, 2 Jul 1999 17:38:50 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v0420550fb3a3093448b6@129.46.158.108>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh
Date: Fri, 2 Jul 1999 17:33:16 -0700
To: "Bruce Steinback" <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Storing filters in LDAP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b12
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.