Re: Sieve Vacation and draft-moore-auto-email-response-04

[Jutta Degener <[e-mail]>]

On Fri, Oct 31, 2003 at 06:44:17PM -0800, Tim Showalter wrote:
> 
> [e-mail] wrote:
> 
> >I suppose the obvious thing to do would be to let the user edit the 
> >charset field separately from the content of the field. But this
> >gets very complex very quickly -- there are lots and lots of charsets
> >and what do you do when they pick a charset that doesn't support all
> >the characters that were specified?
> >Simply allowing access to the raw encoded words in the editor is probably
> >what's going to happen in any case.
> 
> Do you think it's worth noting this as a SHOULD?

I don't think we should describe or limit the behavior of editor
applications at all.

One, clients aren't our core competency.  We're describing a language,
not the diverse applications that produce scripts written in it.

Secondly, if we have advice to give, surely it'll be of value to e-mail
client user interfaces everywhere.  It should go into a Best Practices
RFC for e-mail clients in general, not into a sieve extension's option.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA13oZkT023906 for <[e-mail]>; Fri, 31 Oct 2003 19:50:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA13oZJV023905 for ietf-mta-filters-bks; Fri, 31 Oct 2003 19:50:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA13oYkT023900 for <[e-mail]>; Fri, 31 Oct 2003 19:50:34 -0800 (PST) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id hA13oa69008369 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Fri, 31 Oct 2003 19:50:37 -0800 (PST)
Received: from jutta.sendmail.com ([10.210.112.12]) by foon.sendmail.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id hA13oaN2022231 for <[e-mail]>; Fri, 31 Oct 2003 19:50:36 -0800
Received: by jutta.sendmail.com (Postfix, from userid 500) id 7EDCF179BC; Fri, 31 Oct 2003 19:50:26 -0800 (PST)
Date: Fri, 31 Oct 2003 19:50:26 -0800
From: Jutta Degener <[e-mail]>
To: [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Oct 31, 2003 at 06:44:17PM -0800, Tim Showalter wrote:
> 
> [e-mail] wrote:
> 
> >I suppose the obvious thing to do would be to let the user edit the 
> >charset field separately from the content of the field. But this
> >gets very complex very quickly -- there are lots and lots of charsets
> >and what do you do when they pick a charset that doesn't support all
> >the characters that were specified?
> >Simply allowing access to the raw encoded words in the editor is probably
> >what's going to happen in any case.
> 
> Do you think it's worth noting this as a SHOULD?

I don't think we should describe or limit the behavior of editor
applications at all.

One, clients aren't our core competency.  We're describing a language,
not the diverse applications that produce scripts written in it.

Secondly, if we have advice to give, surely it'll be of value to e-mail
client user interfaces everywhere.  It should go into a Best Practices
RFC for e-mail clients in general, not into a sieve extension's option.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA13DbkT022746 for <[e-mail]>; Fri, 31 Oct 2003 19:13:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA13Dbo2022745 for ietf-mta-filters-bks; Fri, 31 Oct 2003 19:13:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA13DZkT022739 for <[e-mail]>; Fri, 31 Oct 2003 19:13:36 -0800 (PST) (envelope-from [e-mail])
X-Sasl-enc: Xe1DMoPIdCnWAZQXtZKjXw 1067656415
Received: from elvey.fastmail.fm (adsl-66-126-170-81.dsl.snfc21.pacbell.net [66.126.170.81]) by mail.messagingengine.com (Postfix) with ESMTP id 401D539EA9E; Fri, 31 Oct 2003 22:13:33 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 31 Oct 2003 19:13:33 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
References: <[e-mail]> <[e-mail]> <052801c39fd4$b2df07f0$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks, Mark, Nigel for comments, and Kjetil for a template (though I'll 
probably use RFC3285's, which I just became aware of).   Alexey and I 
plan to co-author the I-D.

On 10/31/2003 10:06 AM, Mark E. Mallett sent forth electrons to convey:

>On Fri, Oct 31, 2003 at 05:30:37PM -0000, Nigel Swinson wrote:
>  
>
>>The problem with filtering before storing in the end users mailbox is as Ned
>>says, the concept of the mail envelope.  At the SMTP level, the envelope
>>probably has many recipients, 
>>
s/probably/very occasionally/, so it's not as much of an issue.  I think 
a 'refuse' that works perfectly as long as there aren't multiple 
*envelope* recipients (which, keep in mind, is much rarer than multiple 
recipients of any kind) ( and handles the special case by causing an MDN 
to be sent on behalf of the rejecting recipients) is much better than no 
'refuse' at all.

A LONG and often technical discussion of issues you needn't read if 
you're not comfortable with the above:
  In my proto-draft (security section), I suggest this be handled as 
follows:
"Sieve evaluation as typically implemented requires having the entire 
message on hand.
In SMTP this means the only response code that's left is the final one, 
where the server accepts or rejects the message on behalf of all 
recipients. This becomes a problem when there are multiple recipients 
and some reject the message and some do not.  In this case, reject MUST 
cause an MDN to be sent on behalf of the rejecting recipients. (Idea: 
allow MTA to tempfail the rejecting recipients and accept the others, 
until all recipients are rejecting the email; then it can be refused.)"
[I now reject that latter idea:] Is the additional complexity introduced 
by specifying how the tempfail would work to make SMTP rejects work even 
in the relatively rare case of multiple recipients on the envelope 
really worth it?  Making this mandatory would make the implementation of 
this spec considerably more work, I think.   I don't want to make it 
optional, I'd rather leave it out than make it optional.  (By the way, 
tempfail means to send a 4xx SMTP response code)  It would work as 
follows:  when there are multiple recipients and some reject the message 
and some do not, a tempfail response code is sent.  The recipient server 
has to maintain state about the message so it can recognize it when (if) 
delivery is reattempted. (some spamware never reattempts delivery!)  
When delivery is reattempted, the rejecting recipients are tempfailed, 
but the others aren't.  (This is perfectly acceptable, per RFC2821.) 
When the third delivery attempt is made, the previously rejecting 
recipients are not tempfailed and (assuming) all the recipients in this 
delivery are confirmed to be rejecting recipients, the whole email can 
be permanently refused.  (Unfortunately, some spamware reattempts 
delivery even after permanent failures!)  I'd be surprised if a spec 
requiring this would be broadly implemented, even though I think it 
would reliably provide the desired result.  I don't want to write a 
Standards Track document that never gets past the I-D stage!

>>so who's configuration do you use?  It's only
>>when you are about to put a message in a users INBOX will you know that you
>>can take action on behalf of all the recipients (cos there is only one).
>>Hence when MailSite rejects a message at the SMTP level it is using a global
>>server level script.
>>    
>>
(And technically violating the RFC - but I'm NOT complaining about that! 
- it's effectively crying out for this extension.)

>
>Yeah- what one would need to do is do an attempted delivery for
>each SMTP "mail to" recipient and deal with rejections based on
>that attempt.  You would have to have access to each individual's
>filter program to do this.  Furthermore you would need something
>other than SMTP, since once you have said "OK" to the "mail to"
>you can't take it back later. 
>
No.  Actually RFC2821 specifies when the server takes responsibility:
"In sending a positive completion reply to the end of data indication, 
the receiver takes

   full responsibility for the message (see section 6.1).'
Until then, the server can drop the message and connection and be RFC compliant, even if it has said OK to all the recipients.
Also there is no such thing as a "mail to" command; I assume you mean 'rcpt to'.



>  Or you would have to have a way
>of enforcing only one recipient per SMTP session.  (accepting
>the first "mail to" and giving 4xx responses for each subsequent
>one would be very hackish.)  
>
I would be open to something like: an implementation MAY tempfail 
recipients after the first one to facilitate per-user 'refuse' actions.  
An implementation could, for example choose to do this for mail from any 
blacklisted IPs, and safely do so even using aggressive blacklists that 
list IPs that send both ham and spam.  It's not clear whether this would 
violate any RFCs.  RFC 2821 does not allow "Rejection of messages (for 
excessive recipients)" < 100 but a 450 rejection of that sender because 
the mailbox is unavailable for policy reasons seems acceptable to my 
reading.

>Here it would be great to have an SMTP
>enhancement allowing post-DATA rejections.
>  
>
SMTP already allows this.  It's clearly permitted by RFC 2821 to send a 
negative completion reply to the end of data indication.  Were it not, 
this I-D would be a non-starter!

> 
>  
>
>>A comment on your I-Draft.  I've never heard of "joe-job spam".  Now I know
>>I only code mail servers, not use them, so perhaps I'm just ignorant, but
>>I'm wondering if "joe-job spam" is a well established enough term to be
>>using without describing what it means?  I see you do describe it
>>eventually, but wonder if you can avoid the term completly in the I-Draft.
>>    
>>
>
>JoeJob is a very common term referring to forging somebody else's
>address as a return address, so that unfortunate victim gets bounces.
>It's a googlable term.
>  
>
I'll be sure that it's clear if we use it.
http://members.cox.net/joejob/

>mm
>  
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA12jokT022193 for <[e-mail]>; Fri, 31 Oct 2003 18:45:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA12jovG022192 for ietf-mta-filters-bks; Fri, 31 Oct 2003 18:45:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eddie.psaux.com (eddie.psaux.com [66.92.250.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA12jikT022186 for <[e-mail]>; Fri, 31 Oct 2003 18:45:44 -0800 (PST) (envelope-from [e-mail])
Received: from psaux.com (zaphod.psaux.com [66.92.250.4]) by eddie.psaux.com (Postfix) with ESMTP id AF60C23CB2; Fri, 31 Oct 2003 18:45:50 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 31 Oct 2003 18:44:17 -0800
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: Arnt Gulbrandsen <[e-mail]>, Jutta Degener <[e-mail]>, Rob Siemborski <[e-mail]>, [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

> I suppose the obvious thing to do would be to let the user edit the 
> charset field separately from the content of the field. But this
> gets very complex very quickly -- there are lots and lots of charsets
> and what do you do when they pick a charset that doesn't support all
> the characters that were specified?
> Simply allowing access to the raw encoded words in the editor is probably
> what's going to happen in any case.

Do you think it's worth noting this as a SHOULD?

Tim




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA11A1kT019602 for <[e-mail]>; Fri, 31 Oct 2003 17:10:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA11A1aH019601 for ietf-mta-filters-bks; Fri, 31 Oct 2003 17:10:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA119ukT019593 for <[e-mail]>; Fri, 31 Oct 2003 17:09:56 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 31 Oct 2003 17:09:56 -0800 (PST)
Date: Fri, 31 Oct 2003 17:06:16 -0800 (PST)
From: [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
In-reply-to: "Your message dated Fri, 31 Oct 2003 16:29:21 -0800" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: [e-mail], Arnt Gulbrandsen <[e-mail]>, Jutta Degener <[e-mail]>, Rob Siemborski <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [e-mail] wrote:
> >
> >> Ned Freed writes:
> >> > Is there any reason it can't be both?
> >
> >
> >> Not particularly - I just like protocols that make up their mind. Call
> >> it OSI/ISO-induced paranoia.
> >
> >
> > Personally, I'm more afraid of introducing silly states. What does it
> > mean when the switch is set to "non-mime" and there are encoded words
> > present. Or vice versa.

> I agree; I think this is likely the right thing to do.  I intend to
> write this up.  However I'm concerned about two things.

> First, what is an editor client supposed to do when it encounters an
> encoded-word string?  Obviously it could present =?ISO-8859-1?....?= and
> invite the user to edit it by hand.  Perhaps that's the appropriate
> thing, but I'm worried how such things could be misinterpreted.  This is
> at least consistent with some of the other things we've done, and I
> think it's the right way to go, though.

I suppose the obvious thing to do would be to let the user edit 
the charset field separately from the content of the field. But this
gets very complex very quickly -- there are lots and lots of charsets
and what do you do when they pick a charset that doesn't support all
the characters that were specified? 

Simply allowing access to the raw encoded words in the editor is probably
what's going to happen in any case.

> I also suspect that some regions expect UTF-8 input in this context to
> be in a more favored charset on outbound.  I think permitting implicit
> transcoding (or at least not forbidding it) is appropriate.

Agreed.

				Ned



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA10UbkT014532 for <[e-mail]>; Fri, 31 Oct 2003 16:30:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA10UbRk014531 for ietf-mta-filters-bks; Fri, 31 Oct 2003 16:30:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sift.mirapoint.com (IDENT:[e-mail] [63.107.133.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA10UXkT014508 for <[e-mail]>; Fri, 31 Oct 2003 16:30:33 -0800 (PST) (envelope-from [e-mail])
Received: from psaux.com (gw.mirapoint.com [63.107.133.2]) by sift.mirapoint.com (MOS 3.4.1-PR) with ESMTP id AFX05675; Fri, 31 Oct 2003 16:29:38 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 31 Oct 2003 16:29:21 -0800
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: Arnt Gulbrandsen <[e-mail]>, Jutta Degener <[e-mail]>, Rob Siemborski <[e-mail]>, [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:
> 
>> Ned Freed writes:
>> > Is there any reason it can't be both?
> 
> 
>> Not particularly - I just like protocols that make up their mind. Call
>> it OSI/ISO-induced paranoia.
> 
> 
> Personally, I'm more afraid of introducing silly states. What does it
> mean when the switch is set to "non-mime" and there are encoded words
> present. Or vice versa.

I agree; I think this is likely the right thing to do.  I intend to 
write this up.  However I'm concerned about two things.

First, what is an editor client supposed to do when it encounters an 
encoded-word string?  Obviously it could present =?ISO-8859-1?....?= and 
invite the user to edit it by hand.  Perhaps that's the appropriate 
thing, but I'm worried how such things could be misinterpreted.  This is 
at least consistent with some of the other things we've done, and I 
think it's the right way to go, though.

I also suspect that some regions expect UTF-8 input in this context to 
be in a more favored charset on outbound.  I think permitting implicit 
transcoding (or at least not forbidding it) is appropriate.

Tim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIY2kT001666 for <[e-mail]>; Fri, 31 Oct 2003 10:34:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIY2xg001665 for ietf-mta-filters-bks; Fri, 31 Oct 2003 10:34:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9VIXwkT001660 for <[e-mail]>; Fri, 31 Oct 2003 10:34:01 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 19213 invoked from network); 31 Oct 2003 13:33:59 -0500
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 31 Oct 2003 13:33:59 -0500
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 3284 invoked by uid 101); 31 Oct 2003 13:33:58 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 31 Oct 2003 13:33:58 -0500
To: "Gu?bj?rn S. Hreinsson" <[e-mail]>
Cc: [e-mail]
Subject: Re: Relay control in SIEVE ???
Message-ID: <[e-mail]>
References: <[e-mail]> <001601c39faf$3ff32b60$3ce62a0f@nt23060> <[e-mail]> <047501c39fce$ca01c9a0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <047501c39fce$ca01c9a0$[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> But if anyone is interested enough they can produce MIEVE or similar, 
> based on SIEVE but intended for MTA filtering... although I like better 
> the idea of extensions to SIEVE. 

There are already good ways to tighten up mail servers against
relaying.  But I'm curious about what other MTA filtering you are
thinking of.  sieve (and sieve-like equivalents) can be used for
filtering things other than final delivery.  For example, we use
sieve filtering here for damping bounces resulting from bad
target addresses.  There are other pass-through kinds of filtering
that sieve-like programs could be appropriate for.  There are
other applications that they are not appropriate for (e.g. relay
control).



> From: <ned.freed>
> > 
> > This really could not be clearer. We need to guard against mission creep,
> > especially since we have so much work left to do in the space sieve is actually
> > intended for. (I count no fewer than 10 drafts in process that relate to
> > sieve.)

Indeed- all of the drafts likely contain worthwhile things, but
cumulatively could have the effect of extending the language without
regard to language consistency.

mm


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIQmkT001430 for <[e-mail]>; Fri, 31 Oct 2003 10:26:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIQmuw001429 for ietf-mta-filters-bks; Fri, 31 Oct 2003 10:26:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIQjkT001423 for <[e-mail]>; Fri, 31 Oct 2003 10:26:47 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 31 Oct 2003 10:26:43 -0800 (PST)
Date: Fri, 31 Oct 2003 10:18:42 -0800 (PST)
From: [e-mail]
Subject: Re: Relay control in SIEVE ???
In-reply-to: "Your message dated Fri, 31 Oct 2003 16:48:19 +0000" <047501c39fce$ca01c9a0$[e-mail]>
To: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <001601c39faf$3ff32b60$3ce62a0f@nt23060> <[e-mail]> <047501c39fce$ca01c9a0$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Just my 5 cents. I have Brightmail installed in 3 MTA machines running
> proprietary software on Solaris.

> Brightmail includes a SIEVE implementation for filtering out site specific
> BAD email messages.

> After using this, I wish every MTA would have a SIEVE filtering capability
> so I don't have to learn all the different methods for filtering by the myriad
> MTA software out there.

Please compare what you have written here with the subject of this thread.

Specifying filters that are applicable to more than one user, or applicable
to all users, is one thing. Specifying filters that control MTA behavior,
especially behavior as it pertains to detecting and controlling unauthorized
relay attempts, is quite another.

I view the former as being well within the purview of sieve. I view the
latter as being far out of scope.

> Since we have a filtering language RFC, why not
> use it? Let's simplify the world - it's complex enough.

As it happens we have not one but two drafts in this general area:
draft-degener-sieve-multiscript-00.txt and
draft-daboo-sieve-include-00.txt. So this idea is already being pursued.

> But the case in point is, SIEVE is intended for final delivery filtering, not
> at the MTA level.

The conflation of sieve with final delivery offers no real impediment to
performing system level actions.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIPbkT001352 for <[e-mail]>; Fri, 31 Oct 2003 10:25:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VIPbxK001351 for ietf-mta-filters-bks; Fri, 31 Oct 2003 10:25:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VIPVkT001346 for <[e-mail]>; Fri, 31 Oct 2003 10:25:36 -0800 (PST) (envelope-from [e-mail])
Received: from birkihlid42 ([212.30.210.227] [212.30.210.227]) by quasar.skima.is; Fri, 31 Oct 2003 18:25:28 Z
Message-Id: <000e01c39fdc$615cf790$a900000a@birkihlid42>
From: =?iso-8859-1?Q?Gu=F0bj=F6rn_Hreinsson?= <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <052801c39fd4$b2df07f0$[e-mail]>
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Date: Fri, 31 Oct 2003 18:25:36 -0000
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> The problem with filtering before storing in the end users mailbox is as
Ned
> says, the concept of the mail envelope.  At the SMTP level, the envelope
> probably has many recipients, so who's configuration do you use?  It's
only
> when you are about to put a message in a users INBOX will you know that
you
> can take action on behalf of all the recipients (cos there is only one).
> Hence when MailSite rejects a message at the SMTP level it is using a
global
> server level script.

You can reject per Recipient and accept others. Nothing wrong with it.
You can do this per domain or recipient, the recipient could modify this
configuration option and the data could be in a SQL or LDAP server.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VI6okT000655 for <[e-mail]>; Fri, 31 Oct 2003 10:06:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VI6ouS000654 for ietf-mta-filters-bks; Fri, 31 Oct 2003 10:06:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9VI6kkT000649 for <[e-mail]>; Fri, 31 Oct 2003 10:06:49 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 10734 invoked from network); 31 Oct 2003 13:06:47 -0500
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 31 Oct 2003 13:06:47 -0500
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 14887 invoked by uid 101); 31 Oct 2003 13:06:47 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 31 Oct 2003 13:06:46 -0500
To: Nigel Swinson <[e-mail]>
Cc: "Matthew Elvey \(FM\)" <[e-mail]>, [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <052801c39fd4$b2df07f0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <052801c39fd4$b2df07f0$[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Oct 31, 2003 at 05:30:37PM -0000, Nigel Swinson wrote:
> 
> The problem with filtering before storing in the end users mailbox is as Ned
> says, the concept of the mail envelope.  At the SMTP level, the envelope
> probably has many recipients, so who's configuration do you use?  It's only
> when you are about to put a message in a users INBOX will you know that you
> can take action on behalf of all the recipients (cos there is only one).
> Hence when MailSite rejects a message at the SMTP level it is using a global
> server level script.

Yeah- what one would need to do is do an attempted delivery for
each SMTP "mail to" recipient and deal with rejections based on
that attempt.  You would have to have access to each individual's
filter program to do this.  Furthermore you would need something
other than SMTP, since once you have said "OK" to the "mail to"
you can't take it back later.   Or you would have to have a way
of enforcing only one recipient per SMTP session.  (accepting
the first "mail to" and giving 4xx responses for each subsequent
one would be very hackish.)  Here it would be great to have an SMTP
enhancement allowing post-DATA rejections.

 
> A comment on your I-Draft.  I've never heard of "joe-job spam".  Now I know
> I only code mail servers, not use them, so perhaps I'm just ignorant, but
> I'm wondering if "joe-job spam" is a well established enough term to be
> using without describing what it means?  I see you do describe it
> eventually, but wonder if you can avoid the term completly in the I-Draft.

JoeJob is a very common term referring to forging somebody else's
address as a return address, so that unfortunate victim gets bounces.
It's a googlable term.

mm


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHWUkT099172 for <[e-mail]>; Fri, 31 Oct 2003 09:32:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VHWUfA099171 for ietf-mta-filters-bks; Fri, 31 Oct 2003 09:32:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHWTkT099166 for <[e-mail]>; Fri, 31 Oct 2003 09:32:29 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id E9BF81C01EE2; Fri, 31 Oct 2003 09:32:28 -0800 (PST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id XAA08735; Fri, 31 Oct 2003 23:01:16 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Relay control in SIEVE ???
Date: Fri, 31 Oct 2003 23:02:29 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000101c39fd4$f5385a20$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Ned,

	Thanks again for your comments.

> > 	Do you suggest to have a generic mechanism ( out of sieve ) for
> > 	"don't relay" functionality at SMTP level.
> 
> No, I don't. I agree with Cyrus: This is an SMTP server 
> administrative function and moreover one that tends to be 
> done in very server-specific ways. Having gone through the 
> exercise of designing one generic frameworks at the SMTP 
> server level -- the MADMAN MTA MIB -- I can tell you that 
> this sort of thing is VERY difficult to do in a meaningful 
> way, assuming it can even be done at all. And it definitely 
> lies far outside of sieve's purview. The first sentence in 
> RFC 3028 abstract states:
> 

	I understand that this lies outside the scope of sieve. I
thought
	we can leverage many sieve language semantics aspects to define 
	a new specifiation for MTA level controling.

>   This document describes a language for filtering e-mail 
> messages at time of
>   final delivery. 
> 
> This really could not be clearer. We need to guard against 
> mission creep, especially since we have so much work left to 
> do in the space sieve is actually intended for. (I count no 
> fewer than 10 drafts in process that relate to
> sieve.)

	Yaah ! I'm more happy to work in sieve wg.

	Cheers,
	MG



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHUfkT099123 for <[e-mail]>; Fri, 31 Oct 2003 09:30:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VHUfvl099122 for ietf-mta-filters-bks; Fri, 31 Oct 2003 09:30:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHUdkT099116 for <[e-mail]>; Fri, 31 Oct 2003 09:30:39 -0800 (PST) (envelope-from [e-mail])
Received: from SCOTTY (unverified [129.215.188.222]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <[e-mail]>; Fri, 31 Oct 2003 17:30:37 +0000
Message-ID: <052801c39fd4$b2df07f0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Matthew Elvey \(FM\)" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Date: Fri, 31 Oct 2003 17:30:37 -0000
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> In other words, what Sieve implementations can be configured such that a
> reject causes the email to be refused/not accepted during the SMTP
> transaction, instead of accepted, and then bounced back to the alleged
> sender (often, in the case of spam, a Joe-Job victim).  Someone just
> told me that Cyrus' implementation can't do this.

Somewhat of a late post I know, but Rockliffe's Mailsite has a Server Sieve
Script where if you use "Reject" it will reject at the SMTP protocol level.
I doubt this is much use to you as presumably you are looking for something
that is available at the end user level (as I can see in your I-Draft).

The problem with filtering before storing in the end users mailbox is as Ned
says, the concept of the mail envelope.  At the SMTP level, the envelope
probably has many recipients, so who's configuration do you use?  It's only
when you are about to put a message in a users INBOX will you know that you
can take action on behalf of all the recipients (cos there is only one).
Hence when MailSite rejects a message at the SMTP level it is using a global
server level script.

A comment on your I-Draft.  I've never heard of "joe-job spam".  Now I know
I only code mail servers, not use them, so perhaps I'm just ignorant, but
I'm wondering if "joe-job spam" is a well established enough term to be
using without describing what it means?  I see you do describe it
eventually, but wonder if you can avoid the term completly in the I-Draft.

Nigel




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGmNkT097543 for <[e-mail]>; Fri, 31 Oct 2003 08:48:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VGmNUN097541 for ietf-mta-filters-bks; Fri, 31 Oct 2003 08:48:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGmLkT097533 for <[e-mail]>; Fri, 31 Oct 2003 08:48:22 -0800 (PST) (envelope-from [e-mail])
Received: from ls7528 ([192.147.34.142] [192.147.34.142]) by quasar.skima.is with ESMTP; Fri, 31 Oct 2003 16:48:19 Z
Message-Id: <047501c39fce$ca01c9a0$[e-mail]>
From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <001601c39faf$3ff32b60$3ce62a0f@nt23060> <[e-mail]>
Subject: Re: Relay control in SIEVE ???
Date: Fri, 31 Oct 2003 16:48:19 -0000
Organization: =?iso-8859-1?Q?S=EDminn?=
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9VGmMkT097537
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just my 5 cents. I have Brightmail installed in 3 MTA machines running 
proprietary software on Solaris. 

Brightmail includes a SIEVE implementation for filtering out site specific 
BAD email messages. 

After using this, I wish every MTA would have a SIEVE filtering capability 
so I don't have to learn all the different methods for filtering by the myriad 
MTA software out there. Since we have a filtering language RFC, why not 
use it? Let's simplify the world - it's complex enough. 

But the case in point is, SIEVE is intended for final delivery filtering, not 
at the MTA level.

But if anyone is interested enough they can produce MIEVE or similar, 
based on SIEVE but intended for MTA filtering... although I like better 
the idea of extensions to SIEVE. 


Rgds,
-GSH

----- Original Message ----- 
From: <[e-mail]>
To: "Madan Ganesh Velayudham" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, October 31, 2003 3:41 PM
Subject: RE: Relay control in SIEVE ???


> 
> 
> > Hi Ned,
> 
> > >
> > > > Oops ! My assumption and understanding about sieve was
> > > > that sieve scripts can be executed when MTA recieves a
> > > > client request. Can't we have checks like, if the connection
> > > > is from... Like that ? Adminstrators can enforce restrictions
> > > > that "I don't relay even spam mails..." :)
> > >
> > > Such checks could be added, I suppose, but they aren't there
> > > now. Again, this just isn't what sieve is intended to be used for.
> > >
> 
> > Thanks for your comments.
> 
> > Do you suggest to have a generic mechanism ( out of sieve ) for
> > "don't relay" functionality at SMTP level.
> 
> No, I don't. I agree with Cyrus: This is an SMTP server administrative function
> and moreover one that tends to be done in very server-specific ways. Having
> gone through the exercise of designing one generic frameworks at the SMTP
> server level -- the MADMAN MTA MIB -- I can tell you that this sort of thing is
> VERY difficult to do in a meaningful way, assuming it can even be done at all.
> And it definitely lies far outside of sieve's purview. The first sentence in
> RFC 3028 abstract states:
> 
>   This document describes a language for filtering e-mail messages at time of
>   final delivery. 
> 
> This really could not be clearer. We need to guard against mission creep,
> especially since we have so much work left to do in the space sieve is actually
> intended for. (I count no fewer than 10 drafts in process that relate to
> sieve.)
> 
> Ned
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFoIkT095435 for <[e-mail]>; Fri, 31 Oct 2003 07:50:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VFoIKc095434 for ietf-mta-filters-bks; Fri, 31 Oct 2003 07:50:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFoGkT095423 for <[e-mail]>; Fri, 31 Oct 2003 07:50:16 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 31 Oct 2003 07:50:14 -0800 (PST)
Date: Fri, 31 Oct 2003 07:41:16 -0800 (PST)
From: [e-mail]
Subject: RE: Relay control in SIEVE ???
In-reply-to: "Your message dated Fri, 31 Oct 2003 18:32:33 +0530" <001601c39faf$3ff32b60$3ce62a0f@nt23060>
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <001601c39faf$3ff32b60$3ce62a0f@nt23060>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Ned,

> >
> > > 	Oops ! My assumption and understanding about sieve was
> > > 	that sieve scripts can be executed when MTA recieves a
> > > 	client request. Can't we have checks like, if the connection
> > > 	is from... Like that ? Adminstrators can enforce restrictions
> > > 	that "I don't relay even spam mails..." :)
> >
> > Such checks could be added, I suppose, but they aren't there
> > now. Again, this just isn't what sieve is intended to be used for.
> >

> 	Thanks for your comments.

> 	Do you suggest to have a generic mechanism ( out of sieve ) for
> 	"don't relay" functionality at SMTP level.

No, I don't. I agree with Cyrus: This is an SMTP server administrative function
and moreover one that tends to be done in very server-specific ways. Having
gone through the exercise of designing one generic frameworks at the SMTP
server level -- the MADMAN MTA MIB -- I can tell you that this sort of thing is
VERY difficult to do in a meaningful way, assuming it can even be done at all.
And it definitely lies far outside of sieve's purview. The first sentence in
RFC 3028 abstract states:

  This document describes a language for filtering e-mail messages at time of
  final delivery. 

This really could not be clearer. We need to guard against mission creep,
especially since we have so much work left to do in the space sieve is actually
intended for. (I count no fewer than 10 drafts in process that relate to
sieve.)

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFXckT094914 for <[e-mail]>; Fri, 31 Oct 2003 07:33:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VFXcKd094913 for ietf-mta-filters-bks; Fri, 31 Oct 2003 07:33:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VFXXkT094903 for <[e-mail]>; Fri, 31 Oct 2003 07:33:33 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 31 Oct 2003 07:33:30 -0800 (PST)
Date: Fri, 31 Oct 2003 07:31:59 -0800 (PST)
From: [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
In-reply-to: "Your message dated Fri, 31 Oct 2003 12:03:06 +0100" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>, Jutta Degener <[e-mail]>, Rob Siemborski <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Ned Freed writes:
> > Is there any reason it can't be both?

> Not particularly - I just like protocols that make up their mind. Call
> it OSI/ISO-induced paranoia.

Personally, I'm more afraid of introducing silly states. What does it
mean when the switch is set to "non-mime" and there are encoded words
present. Or vice versa.

> > Allow UTF-8 and if it is present encode it. And if it is ASCII just
> > let it go through, encoded words and all.

> Yes. That would work.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VD2akT089268 for <[e-mail]>; Fri, 31 Oct 2003 05:02:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VD2a4b089267 for ietf-mta-filters-bks; Fri, 31 Oct 2003 05:02:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VD2ZkT089262 for <[e-mail]>; Fri, 31 Oct 2003 05:02:35 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id 216EA1C01910; Fri, 31 Oct 2003 05:02:34 -0800 (PST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id SAA22100; Fri, 31 Oct 2003 18:31:21 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Relay control in SIEVE ???
Date: Fri, 31 Oct 2003 18:32:33 +0530
Organization: Hewlett-Packard STSD
Message-ID: <001601c39faf$3ff32b60$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Ned,

> 
> > 	Oops ! My assumption and understanding about sieve was
> > 	that sieve scripts can be executed when MTA recieves a
> > 	client request. Can't we have checks like, if the connection
> > 	is from... Like that ? Adminstrators can enforce restrictions
> > 	that "I don't relay even spam mails..." :)
> 
> Such checks could be added, I suppose, but they aren't there 
> now. Again, this just isn't what sieve is intended to be used for.
> 

	Thanks for your comments.

	Do you suggest to have a generic mechanism ( out of sieve ) for 
	"don't relay" functionality at SMTP level.

	MG



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VAxTkT083455 for <[e-mail]>; Fri, 31 Oct 2003 02:59:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VAxTLA083454 for ietf-mta-filters-bks; Fri, 31 Oct 2003 02:59:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VAxSkT083448 for <[e-mail]>; Fri, 31 Oct 2003 02:59:28 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Arnt Gulbrandsen <[e-mail]>
To: Ned Freed <[e-mail]>
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Cc: Tim Showalter <[e-mail]>, Jutta Degener <[e-mail]>, Rob Siemborski <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Date: Fri, 31 Oct 2003 12:03:06 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed writes:
> Is there any reason it can't be both?

Not particularly - I just like protocols that make up their mind. Call 
it OSI/ISO-induced paranoia.

> Allow UTF-8 and if it is present encode it. And if it is ASCII just 
> let it go through, encoded words and all.

Yes. That would work.

--Arnt


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UJJbkT081493 for <[e-mail]>; Thu, 30 Oct 2003 11:19:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UJJa6k081492 for ietf-mta-filters-bks; Thu, 30 Oct 2003 11:19:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epost.de (mail.epost.de [193.28.100.187] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UJJZkT081484 for <[e-mail]>; Thu, 30 Oct 2003 11:19:35 -0800 (PST) (envelope-from [e-mail])
Received: from [145.254.156.161] (145.254.156.161) by mail.epost.de (6.7.015) (authenticated as [e-mail]) id 3F8A95B900218F39 for [e-mail]; Thu, 30 Oct 2003 20:19:34 +0100
From: Marc Mutz <[e-mail]>
Organization: KDE
To: [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Date: Thu, 30 Oct 2003 19:41:47 +0100
User-Agent: KMail/1.5.93
References: <[e-mail]> <yyaoO9lv/[e-mail]> <2147483647.1067514396@[10.0.1.8]>
In-Reply-To: <2147483647.1067514396@[10.0.1.8]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_HuVo/MQCk13OTvv"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Boundary-02=_HuVo/MQCk13OTvv
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 30 October 2003 17:46, Cyrus Daboo wrote:
<snip>
> vacation :from "Jos=E9 <[e-mail]>" "I'm away";
>
> vacation :from :mime "=3D?ISO-8859-1?Q?Jos=3DE9?=3D <[e-mail]>"
> "I'm away";
<snip>

Nah, violates a SHOULD in rfc 3028/2.6.2:

   A tagged argument is an argument for a command that begins with ":"
   followed by a tag naming the argument, such as ":contains".  This
   argument means that zero or more of the next tokens have some
   particular meaning depending on the argument.
=2D> These next tokens may
   be numbers or strings but they are never blocks.

[...]

=2D> To simplify this specification, tagged arguments SHOULD NOT take
   tagged arguments as arguments.

OTOH, since vacation has an overall :mime parameter, I think it should=20
affect both :from and the text.

Marc

=2D-=20
Eternal vigilance is the price of liberty   -- Thomas Jefferson

--Boundary-02=_HuVo/MQCk13OTvv
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/oVuH3oWD+L2/6DgRAgjIAKDBfomhF7Cqe2aDc4rQbv7re4XgLQCgzEoq
xZLq0cxOSiqqRf3q7OI3eSU=
=7s5g
-----END PGP SIGNATURE-----

--Boundary-02=_HuVo/MQCk13OTvv--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIpwkT080271 for <[e-mail]>; Thu, 30 Oct 2003 10:51:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UIpwSs080270 for ietf-mta-filters-bks; Thu, 30 Oct 2003 10:51:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIpvkT080264 for <[e-mail]>; Thu, 30 Oct 2003 10:51:57 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 30 Oct 2003 10:51:56 -0800 (PST)
Date: Thu, 30 Oct 2003 10:49:10 -0800 (PST)
From: [e-mail]
Subject: RE: Relay control in SIEVE ???
In-reply-to: "Your message dated Thu, 30 Oct 2003 23:28:42 +0530" <000801c39f0f$747b2860$3ce62a0f@nt23060>
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <000801c39f0f$747b2860$3ce62a0f@nt23060>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Ned,

> 	Thanks for your comments.

> > > 	Does sieve have control on relaying of mails at SMTP?
> >
> > No. Sieve is designed to operate at or around the time of
> > final delivery. The language simply isn't oriented for use on
> > MTAs. In particular, sieve provides access to a limited
> > amount of the envelope, the message header, and maybe at some
> > point the message content. Conspicuously absent from this
> > list is access to the sorts of information an MTA has and
> > that are typically used to make relay decisions, such as
> > whether or not the client is considered to be "internal" or
> > "external", whether or not the session is authenticated, and so on.

> 	Oops ! My assumption and understanding about sieve was
> 	that sieve scripts can be executed when MTA recieves a
> 	client request. Can't we have checks like, if the connection
> 	is from... Like that ? Adminstrators can enforce restrictions
> 	that "I don't relay even spam mails..." :)

Such checks could be added, I suppose, but they aren't there now. Again,
this just isn't what sieve is intended to be used for.

> >
> > > 	When I went through elvey's proposal on "refuse". Good one!
> >
> > > 	dontrelay :
> >
> > > 	Administrator of the domain can decide to accept the mails
> > > 	but they donot want to relay mails to other. This requires
> > > 	an extension "dontrelay" in sieve .
> >
> > Even if you grant that use of sieve is appropriate in this
> > context -- and I don't think it is -- I have no idea what the
> > semantics of a "dontrelay" action would be. Sieve can cause
> > messages to be redirected or rejected, but marking them as
> > being ineligable for subsequent relay seems pretty problematic to me.

> 	Yes. First Action would be to reject the mail and return
> "Relaying
> 	denied" message to the originator. It could be redirect the mail
> to
> 	"junk folder" or simply drop the mail.

> 	Do we have a specification for this earlier ( generically also )
> ?

Sieve already has a reject action which could specify "relay denied",
a fileinto action to send the mail to a folder, and a discard action.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHwikT076548 for <[e-mail]>; Thu, 30 Oct 2003 09:58:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHwiCC076547 for ietf-mta-filters-bks; Thu, 30 Oct 2003 09:58:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHwhkT076542 for <[e-mail]>; Thu, 30 Oct 2003 09:58:43 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id C8C741C007D0; Thu, 30 Oct 2003 09:58:42 -0800 (PST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id XAA04720; Thu, 30 Oct 2003 23:27:30 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Relay control in SIEVE ???
Date: Thu, 30 Oct 2003 23:28:42 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000801c39f0f$747b2860$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Ned,

	Thanks for your comments.

> > 	Does sieve have control on relaying of mails at SMTP?
> 
> No. Sieve is designed to operate at or around the time of 
> final delivery. The language simply isn't oriented for use on 
> MTAs. In particular, sieve provides access to a limited 
> amount of the envelope, the message header, and maybe at some 
> point the message content. Conspicuously absent from this 
> list is access to the sorts of information an MTA has and 
> that are typically used to make relay decisions, such as 
> whether or not the client is considered to be "internal" or 
> "external", whether or not the session is authenticated, and so on.

	Oops ! My assumption and understanding about sieve was 
	that sieve scripts can be executed when MTA recieves a 
	client request. Can't we have checks like, if the connection 
	is from... Like that ? Adminstrators can enforce restrictions 
	that "I don't relay even spam mails..." :)
> 
> > 	When I went through elvey's proposal on "refuse". Good one!
> 
> > 	dontrelay :
> 
> > 	Administrator of the domain can decide to accept the mails
> > 	but they donot want to relay mails to other. This requires
> > 	an extension "dontrelay" in sieve .
> 
> Even if you grant that use of sieve is appropriate in this 
> context -- and I don't think it is -- I have no idea what the 
> semantics of a "dontrelay" action would be. Sieve can cause 
> messages to be redirected or rejected, but marking them as 
> being ineligable for subsequent relay seems pretty problematic to me.

	Yes. First Action would be to reject the mail and return
"Relaying 
	denied" message to the originator. It could be redirect the mail
to 
	"junk folder" or simply drop the mail.

	Do we have a specification for this earlier ( generically also )
?

	Please let me know your views.

	Thanks,
	MG
	



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHOhkT074279 for <[e-mail]>; Thu, 30 Oct 2003 09:24:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHOhRX074278 for ietf-mta-filters-bks; Thu, 30 Oct 2003 09:24:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHOekT074272 for <[e-mail]>; Thu, 30 Oct 2003 09:24:42 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 30 Oct 2003 09:24:38 -0800 (PST)
Date: Thu, 30 Oct 2003 09:23:15 -0800 (PST)
From: [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
In-reply-to: "Your message dated Thu, 30 Oct 2003 11:47:14 +0100" <yyaoO9lv/[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Jutta Degener <[e-mail]>, Tim Showalter <[e-mail]>, Rob Siemborski <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-transfer-encoding: 8BIT
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Jutta Degener writes:
> > Makes sense. So it would look like this:
> >
> >         :from "Jane Random <[e-mail]>"
> > or this
> >         :from "[e-mail] (Jane Random)"

> How about if the display-name is Jäñé Ràndôm? Who does the 2047
> encoding, the program that writes the script, or the one that runs the
> script?

Is there any reason it can't be both? Allow UTF-8 and if it is present
encode it. And if it is ASCII just let it go through, encoded words
and all.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHNGkT074226 for <[e-mail]>; Thu, 30 Oct 2003 09:23:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UHNGIP074225 for ietf-mta-filters-bks; Thu, 30 Oct 2003 09:23:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UHNFkT074220 for <[e-mail]>; Thu, 30 Oct 2003 09:23:15 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel7.hp.com (Postfix) with ESMTP id D79FC1C00AF1; Thu, 30 Oct 2003 12:23:13 -0500 (EST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id WAA00979; Thu, 30 Oct 2003 22:52:01 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: "'Cyrus Daboo'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Relay control in SIEVE ???
Date: Thu, 30 Oct 2003 22:53:12 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000401c39f0a$7f56f340$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <2147483647.1067512806@[10.0.1.8]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Cyrus,

	Thanks for your comemnts.

> | 	Does sieve have control on relaying of mails at SMTP?
> |
> | 	When I went through elvey's proposal on "refuse". Good one!
> |
> | 	dontrelay :
> |
> | 	Administrator of the domain can decide to accept the mails
> | 	but they donot want to relay mails to other. This requires
> | 	an extension "dontrelay" in sieve .
> 
> Control of relaying is not a user action but an admin action 
> and as such I 
> don't see any reason why sieve needs to support it given that 
> SMTP servers 
> already have a way for the admin to control it. Perhaps you 
> can explain why 
> this should be built into sieve rather than just using the existing 
> anti-relaying setup servers offer?

	I'm not sure whether I understood the sentence "sieve is not
tied 
	to any particular operating system or mail architecture". And I
believe
	sieve can be used to do filter at the MTA itself.

	I don't know whether we have /generic mechanism/ by which the
relaying
	control is done at the MTA level. 

	I assume all users can have sieve scripts to filter their mails.
Does
	sieve documents describe anything about system level sieve
script ?
	Pls clarify.  I thought an administrator can have a sieve script
which
	can be executed when client contacts the SMTP server. The sieve
script
	may decide to refuse/reject to accept mail client connection.
But 
	administrator do not have an mechanism to say that I accept this
mail,
	but do not relay the mail.

	Please help me if I'm wrong.

	Thanks,
	+MG

> 
> -- 
> Cyrus Daboo
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGoqkT072098 for <[e-mail]>; Thu, 30 Oct 2003 08:50:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UGoq1p072097 for ietf-mta-filters-bks; Thu, 30 Oct 2003 08:50:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGopkT072092 for <[e-mail]>; Thu, 30 Oct 2003 08:50:51 -0800 (PST) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 30 Oct 2003 08:50:50 -0800 (PST)
Date: Thu, 30 Oct 2003 08:43:22 -0800 (PST)
From: [e-mail]
Subject: Re: Relay control in SIEVE ???
In-reply-to: "Your message dated Thu, 30 Oct 2003 09:54:12 +0530" <000201c39e9d$ac092380$3ce62a0f@nt23060>
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <000201c39e9d$ac092380$3ce62a0f@nt23060>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 	Does sieve have control on relaying of mails at SMTP?

No. Sieve is designed to operate at or around the time of final delivery. The
language simply isn't oriented for use on MTAs. In particular, sieve provides
access to a limited amount of the envelope, the message header, and maybe at
some point the message content. Conspicuously absent from this list is access
to the sorts of information an MTA has and that are typically used to make
relay decisions, such as whether or not the client is considered to be
"internal" or "external", whether or not the session is authenticated, and so
on.

> 	When I went through elvey's proposal on "refuse". Good one!

> 	dontrelay :

> 	Administrator of the domain can decide to accept the mails
> 	but they donot want to relay mails to other. This requires
> 	an extension "dontrelay" in sieve .

Even if you grant that use of sieve is appropriate in this context -- and I
don't think it is -- I have no idea what the semantics of a "dontrelay" action
would be. Sieve can cause messages to be redirected or rejected, but marking
them as being ineligable for subsequent relay seems pretty problematic to me.

> 	Please share your comments on this.

I don't think it is an appropriate sieve extension.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGkdkT071870 for <[e-mail]>; Thu, 30 Oct 2003 08:46:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UGkdYU071869 for ietf-mta-filters-bks; Thu, 30 Oct 2003 08:46:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGkckT071864 for <[e-mail]>; Thu, 30 Oct 2003 08:46:39 -0800 (PST) (envelope-from [e-mail])
Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9UGceEG032374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2003 11:38:41 -0500
Date: Thu, 30 Oct 2003 11:46:36 -0500
From: Cyrus Daboo <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>, Jutta Degener <[e-mail]>
cc: Tim Showalter <[e-mail]>, Rob Siemborski <[e-mail]>, [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Message-ID: <2147483647.1067514396@[10.0.1.8]>
In-Reply-To: <yyaoO9lv/[e-mail]>
References: <[e-mail]> <[e-mail]> <yyaoO9lv/[e-mail]>
X-Mailer: Mulberry/3.1.0b9 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9UGkdkT071865
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Arnt,

--On Thursday, October 30, 2003 11:47 +0100 Arnt Gulbrandsen 
<[e-mail]> wrote:

| How about if the display-name is Jäñé Ràndôm? Who does the 2047 encoding,
| the program that writes the script, or the one that runs the script?
|
| I'd prefer the former since the Sieve interpreter may not know the right
| charset, but OTOH I know more people who write Sieve scripts by hand than
| by program, and they'd hate doing 2047 encoding.

We could probably follow the behaviour used for the 'reason' string in 
vacation and allow a ':mime' parameter for ':from' to indicate a MIME 
encoded header, as opposed to the normal sieve utf8 text. Without :mime, 
SIEVE has to figure out a suitable charset itself (simple solution is use 
utf8 if there are any non-ascii chars). With :mime SIEVE will not do any 
type of encoding and instead assumes the supplied data is already valid.

e.g.:

vacation :from "José <[e-mail]>" "I'm away";

vacation :from :mime "=?ISO-8859-1?Q?Jos=E9?= <[e-mail]>" "I'm 
away";

-- 
Cyrus Daboo



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGK3kT070435 for <[e-mail]>; Thu, 30 Oct 2003 08:20:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UGK3Fn070434 for ietf-mta-filters-bks; Thu, 30 Oct 2003 08:20:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UGK1kT070429 for <[e-mail]>; Thu, 30 Oct 2003 08:20:02 -0800 (PST) (envelope-from [e-mail])
Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9UGCAEG031910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2003 11:12:14 -0500
Date: Thu, 30 Oct 2003 11:20:06 -0500
From: Cyrus Daboo <[e-mail]>
To: Madan Ganesh Velayudham <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: Relay control in SIEVE ???
Message-ID: <2147483647.1067512806@[10.0.1.8]>
In-Reply-To: <000201c39e9d$ac092380$3ce62a0f@nt23060>
References:  <000201c39e9d$ac092380$3ce62a0f@nt23060>
X-Mailer: Mulberry/3.1.0b9 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Madan,

--On Thursday, October 30, 2003 9:54 +0530 Madan Ganesh Velayudham 
<[e-mail]> wrote:

| 	Does sieve have control on relaying of mails at SMTP?
|
| 	When I went through elvey's proposal on "refuse". Good one!
|
| 	dontrelay :
|
| 	Administrator of the domain can decide to accept the mails
| 	but they donot want to relay mails to other. This requires
| 	an extension "dontrelay" in sieve .

Control of relaying is not a user action but an admin action and as such I 
don't see any reason why sieve needs to support it given that SMTP servers 
already have a way for the admin to control it. Perhaps you can explain why 
this should be built into sieve rather than just using the existing 
anti-relaying setup servers offer?

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UAhOkT051117 for <[e-mail]>; Thu, 30 Oct 2003 02:43:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UAhOtv051116 for ietf-mta-filters-bks; Thu, 30 Oct 2003 02:43:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UAhJkT051106 for <[e-mail]>; Thu, 30 Oct 2003 02:43:24 -0800 (PST) (envelope-from [e-mail])
Message-Id: <yyaoO9lv/[e-mail]>
From: Arnt Gulbrandsen <[e-mail]>
To: Jutta Degener <[e-mail]>
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Cc: Tim Showalter <[e-mail]>, Rob Siemborski <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
MIME-Version: 1.0
Date: Thu, 30 Oct 2003 11:47:14 +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9UAhOkT051111
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jutta Degener writes:
> Makes sense. So it would look like this:
>
>         :from "Jane Random <[e-mail]>"
> or this
>         :from "[e-mail] (Jane Random)"

How about if the display-name is Jäñé Ràndôm? Who does the 2047 
encoding, the program that writes the script, or the one that runs the 
script?

I'd prefer the former since the Sieve interpreter may not know the right 
charset, but OTOH I know more people who write Sieve scripts by hand 
than by program, and they'd hate doing 2047 encoding.

--Arnt



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U4OGkT065212 for <[e-mail]>; Wed, 29 Oct 2003 20:24:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U4OGjS065211 for ietf-mta-filters-bks; Wed, 29 Oct 2003 20:24:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U4OFkT065206 for <[e-mail]>; Wed, 29 Oct 2003 20:24:15 -0800 (PST) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id A5E981C0184A; Wed, 29 Oct 2003 20:24:14 -0800 (PST)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id JAA29042; Thu, 30 Oct 2003 09:53:01 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Relay control in SIEVE ???
Date: Thu, 30 Oct 2003 09:54:12 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000201c39e9d$ac092380$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

	Does sieve have control on relaying of mails at SMTP?

	When I went through elvey's proposal on "refuse". Good one!

	dontrelay :

	Administrator of the domain can decide to accept the mails 
	but they donot want to relay mails to other. This requires 
	an extension "dontrelay" in sieve .

	Please share your comments on this.

	======================================

	Syntax : dontrelay <reason string>
	
	SIEVE implementations that implement the "dontrelay" action have
an
	identifier of "dontrelay" for use with the capability mechanism.

	Capability name: dontrelay
	Capability keyword: dontrelay
	Capability arguments: N/A

	======================================
	
	Shall I come up with formal draft ?

	Thanks in advance for your comments.

	Sincerely,
	MG

	**************************
	Madan Ganesh Velayudham
	[e-mail]	
	[phone]
	**************************
	+HP/STSD/Internet Services
	Bangalore, India

	Everything is possible



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U0iikT055900 for <[e-mail]>; Wed, 29 Oct 2003 16:44:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U0iija055899 for ietf-mta-filters-bks; Wed, 29 Oct 2003 16:44:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U0ihkT055892 for <[e-mail]>; Wed, 29 Oct 2003 16:44:43 -0800 (PST) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id h9U0ie69010949 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 29 Oct 2003 16:44:40 -0800 (PST)
Received: from jutta.sendmail.com ([10.210.112.12]) by foon.sendmail.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id h9U0idN2002376; Wed, 29 Oct 2003 16:44:39 -0800
Received: by jutta.sendmail.com (Postfix, from userid 500) id 8CEE3179BC; Wed, 29 Oct 2003 16:44:35 -0800 (PST)
Date: Wed, 29 Oct 2003 16:44:35 -0800
From: Jutta Degener <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: Rob Siemborski <[e-mail]>, [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Oct 29, 2003 at 04:01:37PM -0800, Tim Showalter wrote:
> I'm wondering if :from should be name, address, or both.

Display names are important to people whose names contain characters
beyond US-ASCII, or who want to indicate roles in the display name
	
	From: Vacation Autoresponder <[e-mail]> ;

e-mail addresses are important to people who want to direct
replies somewhere.

	From: [e-mail] (Jane Random's Vacation program)

So, I think it needs to be both.  

> It might even make sense to override the :addresses parameter.
> Obviously the implementation doesn't know the correct address
> or you wouldn't need to use :from; perhaps vacation should use the
> first (or only) argument to :addresses.  (I'm not sure if it
> SHOULD, MUST, or MAY; I am inclined to think it may be preferable
> to what vacation "knows".)

That would be getting too artful for me.  I'd like the default
to be that the message is sent from the recipient address.

I'd give the sieve implementation permission to copy a display
name from the RFC822 header if the RCPT or ORCPT is repeated in
the To: or Cc: list next to it, but wouldn't use :addresses for
anything but matching.

Jutta


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U01rkT053647 for <[e-mail]>; Wed, 29 Oct 2003 16:01:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U01rt8053646 for ietf-mta-filters-bks; Wed, 29 Oct 2003 16:01:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sift.mirapoint.com (IDENT:[e-mail] [63.107.133.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U01qkT053641 for <[e-mail]>; Wed, 29 Oct 2003 16:01:52 -0800 (PST) (envelope-from [e-mail])
Received: from mirapoint.com (gw.mirapoint.com [63.107.133.2]) by sift.mirapoint.com (MOS 3.4.1-PR) with ESMTP id AFV06514; Wed, 29 Oct 2003 16:01:45 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2003 16:01:37 -0800
From: Tim Showalter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rob Siemborski <[e-mail]>
CC: Jutta Degener <[e-mail]>, [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Rob Siemborski wrote:
>>>I suspect that this can be done with a simple :from parameter added to the
>>>vacation command.
>>
>>Makes sense.  So it would look like this:
>>
>>	:from "Jane Random <[e-mail]>"
>>or this
>>	:from "[e-mail] (Jane Random)"
>>
>>We've had requests for :from, too, independent of Keith's draft.
> 
> 
> The example is accurate.  And we've recieved similar reuqests.

This makes sense to me, and I'll make sure it's in the next version.  I 
haven't read Keith's document so I'll double-check and make sure it's 
what we want.

I'm wondering if :from should be name, address, or both.  It might even 
make sense to override the :addresses parameter.  Obviously the 
implementation doesn't know the correct address or you wouldn't need to 
use :from; perhaps vacation should use the first (or only) argument to 
:addresses.  (I'm not sure if it SHOULD, MUST, or MAY; I am inclined to 
think it may be preferable to what vacation "knows".)

Tim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNn6kT052833 for <[e-mail]>; Wed, 29 Oct 2003 15:49:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNn6bS052832 for ietf-mta-filters-bks; Wed, 29 Oct 2003 15:49:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.andrew.cmu.edu (SMTP1.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNn4kT052826 for <[e-mail]>; Wed, 29 Oct 2003 15:49:04 -0800 (PST) (envelope-from [e-mail])
Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9TNn6E7015951; Wed, 29 Oct 2003 18:49:06 -0500
Date: Wed, 29 Oct 2003 18:49:05 -0500 (EST)
From: Rob Siemborski <[e-mail]>
To: Jutta Degener <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
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-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 29 Oct 2003, Jutta Degener wrote:

> You're referring to
>
> # However it MUST be possible for
> # a recipient on whose behalf the responder is acting to explicitly
> # specify the human-readable name and address to be used in the From
> # header fields of responses.
>
> Right?

Yes.

> > I suspect that this can be done with a simple :from parameter added to the
> > vacation command.
>
> Makes sense.  So it would look like this:
>
> 	:from "Jane Random <[e-mail]>"
> or this
> 	:from "[e-mail] (Jane Random)"
>
> We've had requests for :from, too, independent of Keith's draft.

The example is accurate.  And we've recieved similar reuqests.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [e-mail] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNgHkT052391 for <[e-mail]>; Wed, 29 Oct 2003 15:42:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNgHFZ052390 for ietf-mta-filters-bks; Wed, 29 Oct 2003 15:42:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNgGkT052384 for <[e-mail]>; Wed, 29 Oct 2003 15:42:16 -0800 (PST) (envelope-from [e-mail])
Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id h9TNgC69002480 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 29 Oct 2003 15:42:12 -0800 (PST)
Received: from jutta.sendmail.com ([10.210.112.12]) by foon.sendmail.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id h9TNg9N2023254; Wed, 29 Oct 2003 15:42:12 -0800
Received: by jutta.sendmail.com (Postfix, from userid 500) id DE146179BC; Wed, 29 Oct 2003 15:42:05 -0800 (PST)
Date: Wed, 29 Oct 2003 15:42:05 -0800
From: Jutta Degener <[e-mail]>
To: Rob Siemborski <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.24i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Oct 29, 2003 at 04:46:08PM -0500, Rob Siemborski wrote:
> 
> It looks like the current draft of the sieve vacation extension isn't good
> enough to satisfy the requirements of draft-moore-auto-email-response-04.
> Specifically, it needs a way to specify the From: address explicitly in
> the script (see Section 3.1.1 of draft-moore-auto-email-response-04).

You're referring to

# However it MUST be possible for
# a recipient on whose behalf the responder is acting to explicitly
# specify the human-readable name and address to be used in the From
# header fields of responses.

Right?

> I suspect that this can be done with a simple :from parameter added to the
> vacation command.

Makes sense.  So it would look like this:

	:from "Jane Random <[e-mail]>"
or this
	:from "[e-mail] (Jane Random)"

We've had requests for :from, too, independent of Keith's draft.
People don't want to leak their internal mail organization, they want
to be able to use display names (especially in non-US-ASCII markets),
and they want to control where responses to these "vacation" messages
go.

In the latter context, there's also been interest to set the envelope-from,
something that Keith doesn't address other than a matter of safety.

Jutta <[e-mail]>


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNHBkT050860 for <[e-mail]>; Wed, 29 Oct 2003 15:17:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNHBPh050859 for ietf-mta-filters-bks; Wed, 29 Oct 2003 15:17:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNH8kT050853 for <[e-mail]>; Wed, 29 Oct 2003 15:17:09 -0800 (PST) (envelope-from [e-mail])
Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id BC1D43868B0; Wed, 29 Oct 2003 18:17:07 -0500 (EST)
Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Wed, 29 Oct 2003 18:17:07 -0500
X-Mail-from: [e-mail]
X-Epoch: 1067469427
X-Sasl-enc: p8DnlSShc0QJ4sQtf0OfMA
Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id E12A13863C8; Wed, 29 Oct 2003 18:17:04 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2003 15:17:01 -0800
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: draft-elvey-refuse-sieve-00 (was Re: Sieve reject at SMTP time possible with which implementations?)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
X-NoArchive: yes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 10/25/2003 9:48 PM, [e-mail] sent forth electrons to convey:

>
>> > Of course nothing prevents an implementation from adding a separate 
>> action
>> > other than reject for this. But SMTP level errors don't match up to 
>> sieve
>> > actions very well. Why? Because sieve evaluation almost always 
>> requires having
>> > the entire message on hand. In SMTP this means the only reponse 
>> code that's
>> > left is the last one, where the server accepts or rejects the 
>> message on behalf
>> > of all recipients. This becomes a problem when there are multiple 
>> recipients
>> > and some reject the message and some do not.
>
>
>> I would like to see such an action (Shall we call it "refuse"?) in the
>> next version of the spec, or in an extension.  Anyone else?
>> Something like "refuse MUST reject an email at the SMTP level, instead
>> of sending an MDN, where possible, as this would be an anti-Joe-Job 
>> feature"
>> It will otherwise behave like reject, but only permit a single line of
>> response text.  Issues of specifying response codes (4xx, 5xx, 4.x.x,
>> etc) would need to be hashed out, 'where possible' would address the
>> problem Ned raised, above.
>
>
> It would have to be done as an extension; adding something like this to
> the base specification isn't realistic at this point.
>
> I personally would have no objection to this extension. 

Here goes!


I hope someone here will help shepherd such an extension through the 
IETF process.

The procedure is rather overwhelming; while I'd like to contribute,
perhaps I need not become a certified IETF labyrinth navigator in the 
process. :)
OTOH, there's a son-of-GTUBE EICAR-like standard I'd like to create, so 
if no one is willing,
I can try to kill two birds with one stone. (Learn the skills to 
shepherd two specs, that is.)
If no one is willing, I'll need to figure out stuff like
Is there a WG for handling Sieve extensions?   Do I need to be a paying 
IETF member (prohibitive cost?)
Is there a good editor/emacs mode/Windows app for writing 
Internet-Drafts/RFCs?
Put the following into the boilerplate, etc?  I see Ned is a prolly very 
busy Apps director(!)

First draft!  (With some commentary about open issues mixed in; I know 
it's not in the right format, and it's totally unedited, but I'm 
drained, so here goes.)  Feedback welcomed by email or on-list.

Abstract

MDNs cause returned Joe-job spam to hit the Joe-job victim's mailbox; 
SMTP level refusals usually don't.  'refuse' uses the latter method to 
return unwanted email.

In other words, Sieve should have the capability such that  email may be 
flat out not accepted

during the SMTP transaction, instead of accepted, and then bounced back 
to the alleged sender (often, in the case of spam, a

Joe-Job victim). 

Discussion
   
    The SIEVE mail filtering language [SIEVE] "refuse" extension, if 
supported, permits users to handle unwanted email in a

way that is sometimes preferable to the existing 'discard' and 'reject' 
capabilities.  When a spam-detection system suspects

a message is spam, but isn't certain, discarding the email is considered 
too risky for some users, for example, those who

receive sales leads by email.  They are willing to use the reject 
command.  Users are willing to reject but not discard because the sender 
of an email incorrectly marked as spam will receive a notification that 
the email was refused, and will likely try again to contact the intended 
recipient, perhaps via another method of communication.  Unfortunately, 
using is problematic, because in the usual case, the email is indeed 
spam, and the alleged sender to whom the MDN caused by the reject will 
be sent will often be an innocent "Joe-job" victim.  'Refuse' is 
intended to be superior to 'reject' because it

will be less likely to result in email to an innocent victim (a 
'Joe-job').  'refuse' refuses to accept an email for delivery instead of 
accepting it and then sending an MDN.  Most spam is sent through open 
proxies, so 'refuse' eliminates most Joe-job bounces resulting from 
usage of reject. 'Reject' will also reduce Joe-jobs caused by virus 
self-propagation via emails with false sender information.


   
Change History (to be removed prior to publication as an RFC)
   
       
    Changes from -00 to -01:
       
       
Table of Contents
       
     1  Introduction and Overview . . . . . . . . . . . . . . . . . .  3
     2  Conventions Used in This Document  . . . . . . . . . . . . . . 3
     3  SIEVE Extensions  . . . . . . . . . . . . . . . . . . . . . .  4
       3.1  General Considerations . . . . . . . . . . . . . . . . . . 4
       3.2  Test spamtest . . . . . . . . . . . . . . . . . . . . . .  4

     4  Security Considerations . . . . . . . . . . . . . . . . . . . 
     5  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .
       5.1  spamtest registration . . . . . . . . . . . . . . . . . . 
     6  References  . . . . . . . . . . . . . . . . . . . . . . . . . 
       6.1  Normative References . . . . . . . . . . . . . . . . . . .
       6.2  Non-Normative References  . . . . . . . . . . . . . . . . 
     7  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .
     8  Author's Address  . . . . . . . . . . . . . . . . . . . . . . 


     9  Intellectual Property Rights Statement . . . . . . . . . . . .
    10  Full Copyright Statement  . . . . . . . . . . . . . . . . . . 
       
       
1 Introduction and Overview
   

'refuse' MUST refuse to accept for an email delivery at the SMTP level, 
instead of sending an MDN, other than for the specified exceptions.  A 
SIEVE implementation that cannot do so MUST NOT claim to support the 
refuse extension.

Where the suspected spam source is believed to be an open relay (e.g. as 
determined by a RBLDNS lookup), the implementation MAY send an MDN when 
'refuse' is indicated, as an MDN allows more opportunity for being 
handled in an automated fashion by its recipient because of its 
prescribed, relatively informative format.  Systems that support the 
extension MUST encourage use of "refuse" over 'discard' and 'reject' 
where it is an appropriate alternative. 
 
"Extensions which define actions MUST state how they interact with
   actions discussed in the base specification." - [SIEVE]

Reject is considered incompatible with most other actions:
For Cyrus, the list is 
:FILEINTO_KEEP_REDIRECT_REJECT_VACATION_SETFLAG_ADDFLAG_REMOVEFLAG__MARK_UNMARK); 
refuse should be consistent.
(I actually think reject should be considered compatible though! What if 
I want to log rejected email?  As a user, I can't!)

The spamtest and virustest extensions SHOULD be supported.


Specifying response codes (4xx, 5xx, 4.x.x, etc)

Refused emails are refused with a response code of 550.

This is a really messy topic.  Should we allow the user to specify the 
response code?  Should they be able to select just one of a set of 
standard codes?  Or should they have no choice?
RFC2821, an Internet Standard, says a 550 is appropriate in response to 
DATA, but in one part frets about 550 as a response code when there are 
multiple recipients, a case that is dealt with in the security portion 
of this document.
550 and 552 are common responses, but 552 is not appropriate per RFC2821.
As originally conceived, 'refuse' is only for use with email identified 
as spam or virus-infested, however users may wish to refuse mail for 
other reasons, such as a wish to only accept encrypted email.  Although 
concievably not all possible reasons may fall under the umbrella of 550, 
the KISS principle suggests that it's good enough.

There does not seem to be an RFC that specifies the way for extended 
status codes of RFC1893 to be provided during an SMTP session.  It seems 
that RFC1891 codes are only for use in emailed DSNs, not as SMTP reply 
codes.  I haven't heard of a usage such as "550 5.7.0 SpamAssassin 
thinks the message is spam."
RFC1891 specifies a way for RFC1894-compliant DSN emails using extended 
status codes of RFC1893 to be requested during an SMTP session, but it 
does NOT specify a way for them to be used during the SMTP session itself.
RFC1893 specifies the extended codes, but not where/how they should be used.
It also doesn't specify codes that seem well well suited to the case of 
email unwanted by the recipient.
The only one the makes sense (and only for a small subset of email one 
might want refused) is 5.6.x for unwanted HTML email.
Email from IPs in blocklists, or that has failed a virus-detection, 
Bayesian or DCC type test doesn't fit well in any category. 5.7.0 
("undefined security status") is the best fit.  Again, the KISS 
principle suggests that a fixed code of 550 is good enough.

SMTP command replies containing response codes can be multi-line, per 
RFC2821, p.44.


   
   
2 Conventions Used in This Document
   
    Conventions for notations are as in [SIEVE] section 1.1, including
    use of [KEYWORDS].
   
    This document does not attempt to define
    what exactly constitutes a spam or virus containing email or how it 
should be identified, or
    what actions should be taken when detected.
   
   
3 SIEVE Extensions
   
3.1 General Considerations
   
    The "refuse" action described below ...
   
3.2 Test spamtest
   
        Syntax: refuse <reason: string>
   
   In the following script, messages that test highly positive for spam 
are refused.

   Example:
    if spamtest :value "ge" :comparator "i;ascii-numeric" "6" {
                refuse text:
         5.7.0 SpamAssassin thinks the message is spam.
     It is therefore being refused.
         Please call 1-900-PAY-US if you want to reach us.
.
                         ;       
    elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" {
                fileinto "Suspect";
                 }

    SIEVE implementations that implement the "refuse" action have an
    identifier of "refuse" for use with the capability mechanism.
   
   
4 Security Considerations
   
    SIEVE implementations SHOULD ensure that 
    can only occur for messages that have gone through a
    legitimate spam or virus check process. 


Sieve evaluation as typically implemented requires having the entire 
message on hand.
In SMTP this means the only response code that's left is the final one, 
where the server accepts or rejects the message on behalf of all 
recipients. This becomes a problem when there are multiple recipients 
and some reject the message and some do not.  In this case, reject MUST 
cause an MDN (multiple MDNs?) to be sent on behalf of the rejecting 
recipients. (Idea: allow MTA to tempfail the rejecting recipients and 
accept the others, until all recipients are rejecting the email; then it 
can be refused.)
   
   
    Beyond that, the "refuse" extension does not raise
    any security considerations that are not present in the base [SIEVE]
    protocol, and these issues are discussed in [SIEVE].
   
   
5 IANA Considerations
   
    The following templates specify the IANA registration of the Sieve
    extensions specified in this document:



5.1 spamtest registration
   
    To: [e-mail]
    Subject: Registration of new Sieve extension

    Capability name: refuse
    Capability keyword: refuse
    Capability arguments: N/A
    Standards Track/IESG-approved experimental RFC number: this RFC
    Person and email address to contact for further information:

    Matthew Elvey
    3042 Sacramento-ietf St Ste 04
    San Francisco, CA
    U.S.A.

    <mailto:[e-mail]>

    This information should be added to the list of sieve extensions
    given on http://www.iana.org/assignments/sieve-extensions.
   
   
   
6 References
   
6.1 Normative References
   
    [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
    Requirement Levels", RFC 2119, March 1997.
   
    [SIEVE] Showalter, "Sieve:  A Mail Filtering Language", RFC 3028,
    January 2001.
   
7 Acknowledgments
   
    Thanks to ... for comments and corrections.
   
   
8 Author's Addresses
   
    Matthew Elvey
    3042 Sacramento-ietf St Ste 04
    San Francisco, CA
    U.S.A.

    <mailto:[e-mail]>

  
   
9 Intellectual Property Rights Statement
    <boilerplate>

   
   
10 Full Copyright Statement
    <boilerplate>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLkBkT046329 for <[e-mail]>; Wed, 29 Oct 2003 13:46:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLkB0Z046328 for ietf-mta-filters-bks; Wed, 29 Oct 2003 13:46:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.andrew.cmu.edu (SMTP1.andrew.cmu.edu [128.2.10.81]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLk7kT046322 for <[e-mail]>; Wed, 29 Oct 2003 13:46:07 -0800 (PST) (envelope-from [e-mail])
Received: from CYRUS.andrew.cmu.edu (CYRUS.andrew.cmu.edu [128.2.10.175]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9TLk9E7009855; Wed, 29 Oct 2003 16:46:09 -0500
Date: Wed, 29 Oct 2003 16:46:08 -0500 (EST)
From: Rob Siemborski <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Sieve Vacation and draft-moore-auto-email-response-04
Message-ID: <[e-mail]>
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-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It looks like the current draft of the sieve vacation extension isn't good
enough to satisfy the requirements of draft-moore-auto-email-response-04.
Specifically, it needs a way to specify the From: address explicitly in
the script (see Section 3.1.1 of draft-moore-auto-email-response-04).

I suspect that this can be done with a simple :from parameter added to the
vacation command.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [e-mail] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q4s6I7028869 for <[e-mail]>; Sat, 25 Oct 2003 21:54:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q4s6b7028868 for ietf-mta-filters-bks; Sat, 25 Oct 2003 21:54:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q4s3I7028863 for <[e-mail]>; Sat, 25 Oct 2003 21:54:04 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 25 Oct 2003 21:54:04 -0700 (PDT)
Date: Sat, 25 Oct 2003 21:48:17 -0700 (PDT)
From: [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
In-reply-to: "Your message dated Thu, 23 Oct 2003 15:39:06 -0700" <[e-mail]>
To: "Matthew Elvey (FM)" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Of course nothing prevents an implementation from adding a separate action
> > other than reject for this. But SMTP level errors don't match up to sieve
> > actions very well. Why? Because sieve evaluation almost always requires having
> > the entire message on hand. In SMTP this means the only reponse code that's
> > left is the last one, where the server accepts or rejects the message on behalf
> > of all recipients. This becomes a problem when there are multiple recipients
> > and some reject the message and some do not.

> I would like to see such an action (Shall we call it "refuse"?) in the
> next version of the spec, or in an extension.  Anyone else?
> Something like "refuse MUST reject an email at the SMTP level, instead
> of sending an MDN, where possible, as this would be an anti-Joe-Job feature"
> It will otherwise behave like reject, but only permit a single line of
> response text.  Issues of specifying response codes (4xx, 5xx, 4.x.x,
> etc) would need to be hashed out, 'where possible' would address the
> problem Ned raised, above.

It would have to be done as an extension; adding something like this to
the base specification isn't realistic at this point.

I personally would have no objection to this extension.

> MDNs cause rejected joe-job spam to hit the victim's mailbox; SMTP level
> refusals usually don't.

Currently the best way to deal with this sort of trash is to use discard,
not reject. Reject really isn't intended to be used as an antispam tool.
As such, a refuse action is best compared to discard, not reject.

> Revising reject's behaviour instead might be problematic as
> long/multiline responses that reject currently allows might be imposible
> to send at SMTP time.  (I'm guessing on this one; maybe it isn't a
> problem to stuff multiline responses as one very long line.)

Revising reject's behasvior is a nonstarter IMO.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9P7hlI7050464 for <[e-mail]>; Sat, 25 Oct 2003 00:43:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9P7hlvl050463 for ietf-mta-filters-bks; Sat, 25 Oct 2003 00:43:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9P7hiI7050448 for <[e-mail]>; Sat, 25 Oct 2003 00:43:44 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 25 Oct 2003 00:43:40 -0700 (PDT)
Date: Sat, 25 Oct 2003 00:43:05 -0700 (PDT)
From: [e-mail]
Subject: Re: Is draft-daboo-sieve-spamtest-04.txt ready for IETF last call?
In-reply-to: "Your message dated Thu, 23 Oct 2003 16:11:32 -0700" <[e-mail]>
To: "Matthew Elvey (FM)" <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On 10/22/2003 12:48 AM, [e-mail] sent forth electrons to
> convey:

> >I noted that a new version of this document was just posted so I reviewed
> >it. I spotted only two minor things that need changing <snip>
> >
> >
> >Both of these can be fixed with an RFC Editor note if need be.
> >
> >This document was already last called on the list some time back and the -04
> >version appears to me to reflect the changes that were agreed to at that time.
> >Does everyone else feel this is now ready for IETF last call? If so I'd be
> >happy to start one.
> >
> >				Ned
> >
> >
> Two more fixes needed:
> s/definately/definitely

Added to the corrections list.

> s/implementors/implementers

American Heritage says either spelling is OK.

>  I reviewed it and feel it's ready.

Good. Thanks.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NNBlI7084756 for <[e-mail]>; Thu, 23 Oct 2003 16:11:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NNBlva084755 for ietf-mta-filters-bks; Thu, 23 Oct 2003 16:11:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NNBjI7084750 for <[e-mail]>; Thu, 23 Oct 2003 16:11:46 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id E24F9337B93; Thu, 23 Oct 2003 19:11:36 -0400 (EDT)
Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Thu, 23 Oct 2003 19:11:36 -0400
X-Mail-from: [e-mail]
X-Epoch: 1066950696
X-Sasl-enc: OIG34q/Ns6GL194q+IrCHA
Received: from elvey.fastmail.fm (adsl-64-168-27-105.dsl.snfc21.pacbell.net [64.168.27.105]) by mail.messagingengine.com (Postfix) with ESMTP id 4D824337A4D; Thu, 23 Oct 2003 19:11:34 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 23 Oct 2003 16:11:32 -0700
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031020
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: Is draft-daboo-sieve-spamtest-04.txt ready for IETF last call?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 10/22/2003 12:48 AM, [e-mail] sent forth electrons to 
convey:

>I noted that a new version of this document was just posted so I reviewed
>it. I spotted only two minor things that need changing <snip>
>
>
>Both of these can be fixed with an RFC Editor note if need be.
>
>This document was already last called on the list some time back and the -04
>version appears to me to reflect the changes that were agreed to at that time.
>Does everyone else feel this is now ready for IETF last call? If so I'd be
>happy to start one.
>
>				Ned
>  
>
Two more fixes needed:
s/definately/definitely
s/implementors/implementers  

 I reviewed it and feel it's ready.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NMdCI7083500 for <[e-mail]>; Thu, 23 Oct 2003 15:39:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NMdCan083499 for ietf-mta-filters-bks; Thu, 23 Oct 2003 15:39:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NMd7I7083490 for <[e-mail]>; Thu, 23 Oct 2003 15:39:11 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 698D93448E6; Thu, 23 Oct 2003 18:39:07 -0400 (EDT)
Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Thu, 23 Oct 2003 18:39:07 -0400
X-Mail-from: [e-mail]
X-Epoch: 1066948747
X-Sasl-enc: 5VKgNePxldCw7TnI9/8TqQ
Received: from elvey.fastmail.fm (adsl-64-168-27-105.dsl.snfc21.pacbell.net [64.168.27.105]) by mail.messagingengine.com (Postfix) with ESMTP id 2AA4934310F; Thu, 23 Oct 2003 18:39:06 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 23 Oct 2003 15:39:06 -0700
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031020
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 10/23/2003 5:24 AM, Rob Siemborski sent forth electrons to convey:

>On Thu, 23 Oct 2003 [e-mail] wrote:
>  
>
>>Which in turn means that handling reject at the SMTP level would be incompliant
>>with the sieve specification.
>>    
>>
>>Of course nothing prevents an implementation from adding a separate action
>>other than reject for this. But SMTP level errors don't match up to sieve
>>actions very well. Why? Because sieve evaluation almost always requires having
>>the entire message on hand. In SMTP this means the only reponse code that's
>>left is the last one, where the server accepts or rejects the message on behalf
>>of all recipients. This becomes a problem when there are multiple recipients
>>and some reject the message and some do not.
>>    
>>
I would like to see such an action (Shall we call it "refuse"?) in the 
next version of the spec, or in an extension.  Anyone else?
Something like "refuse MUST reject an email at the SMTP level, instead 
of sending an MDN, where possible, as this would be an anti-Joe-Job feature"
It will otherwise behave like reject, but only permit a single line of 
response text.  Issues of specifying response codes (4xx, 5xx, 4.x.x, 
etc) would need to be hashed out, 'where possible' would address the 
problem Ned raised, above.
MDNs cause rejected joe-job spam to hit the victim's mailbox; SMTP level 
refusals usually don't.
Revising reject's behaviour instead might be problematic as 
long/multiline responses that reject currently allows might be imposible 
to send at SMTP time.  (I'm guessing on this one; maybe it isn't a 
problem to stuff multiline responses as one very long line.)

Thanks for all the comments, everyone!


>
>While difficult/impossible in the SMTP situation, it can be done at the
>"SMTP level," provided the last hop is over LMTP instead of SMTP, since
>LMTP gives per-recipient status codes.
>  
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NCOrI7061251 for <[e-mail]>; Thu, 23 Oct 2003 05:24:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NCOr89061250 for ietf-mta-filters-bks; Thu, 23 Oct 2003 05:24:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NCOpI7061245 for <[e-mail]>; Thu, 23 Oct 2003 05:24:52 -0700 (PDT) (envelope-from [e-mail])
Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9NCOok4015432; Thu, 23 Oct 2003 08:24:50 -0400
Date: Thu, 23 Oct 2003 08:24:50 -0400 (EDT)
From: Rob Siemborski <[e-mail]>
To: [e-mail]
cc: "Matthew Elvey (FM)" <[e-mail]>, [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 23 Oct 2003 [e-mail] wrote:

> Which in turn means that handling reject at the SMTP level would be incompliant
> with the sieve specification.

Yes, thats what I meant ;)

> Of course nothing prevents an implementation from adding a separate action
> other than reject for this. But SMTP level errors don't match up to sieve
> actions very well. Why? Because sieve evaluation almost always requires having
> the entire message on hand. In SMTP this means the only reponse code that's
> left is the last one, where the server accepts or rejects the message on behalf
> of all recipients. This becomes a problem when there are multiple recipients
> and some reject the message and some do not.

While difficult/impossible in the SMTP situation, it can be done at the
"SMTP level," provided the last hop is over LMTP instead of SMTP, since
LMTP gives per-recipient status codes.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [e-mail] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NCIOI7061083 for <[e-mail]>; Thu, 23 Oct 2003 05:18:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NCIOFt061082 for ietf-mta-filters-bks; Thu, 23 Oct 2003 05:18:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NCIMI7061077 for <[e-mail]>; Thu, 23 Oct 2003 05:18:22 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 23 Oct 2003 05:18:21 -0700 (PDT)
Date: Thu, 23 Oct 2003 05:10:15 -0700 (PDT)
From: [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
In-reply-to: "Your message dated Wed, 22 Oct 2003 10:23:47 -0400 (EDT)" <[e-mail]>
To: Rob Siemborski <[e-mail]>
Cc: "Matthew Elvey (FM)" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > In other words, what Sieve implementations can be configured such that a
> > reject causes the email to be refused/not accepted during the SMTP
> > transaction, instead of accepted, and then bounced back to the alleged
> > sender (often, in the case of spam, a Joe-Job victim).  Someone just
> > told me that Cyrus' implementation can't do this.

> Note that Cyrus's implementation is actually LMTP, which presumes an
> SMTP server will be sitting right next to it, so even if a 5xx failure was
> issued, a bounce would still be generated by the SMTP server.

> In any case, RFC3028 specifically says that an MDN is sent back when a
> reject action happens.

Which in turn means that handling reject at the SMTP level would be incompliant
with the sieve specification.

Of course nothing prevents an implementation from adding a separate action
other than reject for this. But SMTP level errors don't match up to sieve
actions very well. Why? Because sieve evaluation almost always requires having
the entire message on hand. In SMTP this means the only reponse code that's
left is the last one, where the server accepts or rejects the message on behalf
of all recipients. This becomes a problem when there are multiple recipients
and some reject the message and some do not. The result is that SMTP level
rejection can never be anything but a special case for user sieves.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N9BtI7051364 for <[e-mail]>; Thu, 23 Oct 2003 02:11:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9N9Btmf051363 for ietf-mta-filters-bks; Thu, 23 Oct 2003 02:11:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N9BsI7051354 for <[e-mail]>; Thu, 23 Oct 2003 02:11:54 -0700 (PDT) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id B468B1C0176B; Thu, 23 Oct 2003 02:11:45 -0700 (PDT)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id OAA04200; Thu, 23 Oct 2003 14:40:31 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: "'Mark E. Mallett'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
Date: Thu, 23 Oct 2003 14:41:42 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000001c39945$ae3fb630$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I would agree that there is no necessity of having an 
> argument to LISTSCRIPTS.  However, some wording about 
> namespace might be in order.  It may be true that a single 
> user will not have a lot of scripts, but a single user may 
> have a lot of files hanging around. The server will need to 
> be able to determine which files are scripts. It would 
> probably be enough to say that this is outside the scope of 
> the document, and is implementation-specific and all that, 
> but still it might be said somewhere that the scripts 
> collection is identifiable somehow.

These comments would avoid assumption during implementaion. Agreed
	




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MLGdI7062636 for <[e-mail]>; Wed, 22 Oct 2003 14:16:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MLGdBI062635 for ietf-mta-filters-bks; Wed, 22 Oct 2003 14:16:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9MLGbI7062629 for <[e-mail]>; Wed, 22 Oct 2003 14:16:37 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 820 invoked from network); 22 Oct 2003 17:16:38 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 22 Oct 2003 17:16:38 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 23211 invoked by uid 101); 22 Oct 2003 17:16:37 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 22 Oct 2003 17:16:37 -0400
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Subject: Re: Review comments on draft-martin-managesieve-04.txt
Message-ID: <[e-mail]>
References: <0ade01c35e55$f9904a80$6501a8c0@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Oct 22, 2003 at 10:21:07PM +0200, Kjetil Torgrim Homme wrote:
> 
> On Tue, 2003-10-21 at 22:44, Mark E. Mallett wrote:
> 
> > I would also like to see support for address-space for the
> > authenticated user.  A user might have different controls for various
> > email addresses that are mapped to that user's account.
> 
> you could just as easily set up each e-mail address as an account in
> Managesieve.

That would be cumbersome as a general solution.


> the use of the extensions "include" (still in draft form) and
> "subaddress" (RFC 3598) is probably more convenient for most people.

Yup, I did mention that that sort of thing was an option (although not
the best one).

mm


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKMMI7060496 for <[e-mail]>; Wed, 22 Oct 2003 13:22:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MKMMAq060495 for ietf-mta-filters-bks; Wed, 22 Oct 2003 13:22:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MKMLI7060484 for <[e-mail]>; Wed, 22 Oct 2003 13:22:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1ACPUn-0001dF-Uv for [e-mail]; Wed, 22 Oct 2003 22:22:17 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1ACPTf-0003ht-TK for [e-mail]; Wed, 22 Oct 2003 22:21:07 +0200
Subject: Re: Review comments on draft-martin-managesieve-04.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <0ade01c35e55$f9904a80$6501a8c0@nigelhome> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Wed, 22 Oct 2003 22:21:07 +0200
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning.
X-UiO-MailScanner: No virus found
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2003-10-21 at 22:44, Mark E. Mallett wrote:

> I would also like to see support for address-space for the
> authenticated user.  A user might have different controls for various
> email addresses that are mapped to that user's account.

you could just as easily set up each e-mail address as an account in
Managesieve.

the use of the extensions "include" (still in draft form) and
"subaddress" (RFC 3598) is probably more convenient for most people.

> HAVESPACE:  Is there really a point to this?  PUTSCRIPT will already
> tell you if the operation fails due to quota.  There's no guarantee
> that resource availability at HAVESPACE-time will be the same as the
> availability at PUTSCRIPT-time.

sounds like a reasonable argument.  I don't remember the rationale for
it?

> I'm not really fond of that byte-counted argument imapism in this
> context.  Am I the only one?  I'd much prefer to see some sort of
> terminated content a la SMTP.

terminated content a la SMTP means dot stuffing.  I don't think that's a
cleaner solution.

-- 
Kjetil T.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGDqI7049115 for <[e-mail]>; Wed, 22 Oct 2003 09:13:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MGDq8b049114 for ietf-mta-filters-bks; Wed, 22 Oct 2003 09:13:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MGDoI7049109 for <[e-mail]>; Wed, 22 Oct 2003 09:13:51 -0700 (PDT) (envelope-from [e-mail])
Received: from [63.163.82.24] (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9MG7GEG012727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 22 Oct 2003 12:07:16 -0400
Received: from mx2.andrew.cmu.edu (MX2.andrew.cmu.edu [128.2.10.112]) by mail1.andrew.cmu.edu (Cyrus v2.1.15-077) with LMTP; Tue, 21 Oct 2003 17:28:03 -0400
X-Sieve: CMU Sieve 2.2
Received: from mx2.andrew.cmu.edu ([unix socket]) by mx2.andrew.cmu.edu (Cyrus v2.1.12-075) with LMTP; Tue, 21 Oct 2003 17:28:02 -0400
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx2.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id h9LLS15K020274; Tue, 21 Oct 2003 17:28:01 -0400
Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AC2lu-0005RA-0m for [e-mail]; Tue, 21 Oct 2003 16:06:26 -0400
Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AC2fb-0005C6-Hj for [e-mail]; Tue, 21 Oct 2003 15:59:55 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04477 for <[e-mail]>; Tue, 21 Oct 2003 15:59:44 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
From: [e-mail]
Reply-to: [e-mail]
Date: Tue, 21 Oct 2003 15:59:44 -0400
Subject: I-D ACTION:draft-daboo-sieve-spamtest-04.txt
X-Resent-Mailer: Mulberry/3.1.0b8 (Mac OS X)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========57A256D164316BE92B78=========="
X-Spam-Level: ****
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--==========57A256D164316BE92B78==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIEVE Spamtest and Virustest Extensions
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-spamtest-04.txt
	Pages		: 9
	Date		: 2003-10-21
	
The SIEVE [SIEVE] 'spamtest' and 'virustest' extensions permit users
to use simple, portable commands for spam and virus tests on email
messages.  Each extension provides a new test using matches against
numeric 'scores'.  It is the responsibility of the underlying SIEVE
implementation to do the actual checks that result in values
returned by the tests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-sieve-spamtest-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-daboo-sieve-spamtest-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-daboo-sieve-spamtest-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--==========57A256D164316BE92B78==========
Content-Type: multipart/alternative;
 boundary="==========087876DB7328463AA623=========="

--==========087876DB7328463AA623==========
Content-Type: message/external-body; ACCESS-TYPE=mail-server;
 SERVER="[e-mail]"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-daboo-sieve-spamtest-04.txt

--==========087876DB7328463AA623==========
Content-Type: message/external-body;
 name="draft-daboo-sieve-spamtest-04.txt"; SITE="ftp.ietf.org";
 ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[e-mail]>

--==========087876DB7328463AA623==========--

--==========57A256D164316BE92B78==========--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MENnI7043171 for <[e-mail]>; Wed, 22 Oct 2003 07:23:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MENnX6043170 for ietf-mta-filters-bks; Wed, 22 Oct 2003 07:23:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MENlI7043165 for <[e-mail]>; Wed, 22 Oct 2003 07:23:47 -0700 (PDT) (envelope-from [e-mail])
Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9MENkk4013633; Wed, 22 Oct 2003 10:23:46 -0400
Date: Wed, 22 Oct 2003 10:23:47 -0400 (EDT)
From: Rob Siemborski <[e-mail]>
To: "Matthew Elvey (FM)" <[e-mail]>
cc: [e-mail]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
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-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 22 Oct 2003, Matthew Elvey (FM) wrote:

> In other words, what Sieve implementations can be configured such that a
> reject causes the email to be refused/not accepted during the SMTP
> transaction, instead of accepted, and then bounced back to the alleged
> sender (often, in the case of spam, a Joe-Job victim).  Someone just
> told me that Cyrus' implementation can't do this.

Note that Cyrus's implementation is actually LMTP, which presumes an
SMTP server will be sitting right next to it, so even if a 5xx failure was
issued, a bounce would still be generated by the SMTP server.

In any case, RFC3028 specifically says that an MDN is sent back when a
reject action happens.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [e-mail] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MBT9I7036818 for <[e-mail]>; Wed, 22 Oct 2003 04:29:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9MBT9Lq036817 for ietf-mta-filters-bks; Wed, 22 Oct 2003 04:29:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9MBT6I7036809 for <[e-mail]>; Wed, 22 Oct 2003 04:29:08 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <wU/[e-mail]>
From: Arnt Gulbrandsen <[e-mail]>
To: "Matthew Elvey (FM)" <[e-mail]>
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Cc: [e-mail]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Date: Wed, 22 Oct 2003 13:32:20 +0200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Matthew Elvey (FM) writes:
> Sieve reject at SMTP time possible with which implementations?

None that I know about.

> In other words, what Sieve implementations can be configured such that 
> a reject causes the email to be refused/not accepted during the SMTP 
> transaction, instead of accepted, and then bounced back to the 
> alleged sender (often, in the case of spam, a Joe-Job victim).  
> Someone just told me that Cyrus' implementation can't do this.

That sounds correct.

--Arnt


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M88HI7099518 for <[e-mail]>; Wed, 22 Oct 2003 01:08:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9M88Hev099517 for ietf-mta-filters-bks; Wed, 22 Oct 2003 01:08:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M88GI7099506 for <[e-mail]>; Wed, 22 Oct 2003 01:08:16 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 36ED13270BC; Wed, 22 Oct 2003 04:06:32 -0400 (EDT)
Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Wed, 22 Oct 2003 04:06:32 -0400
X-Mail-from: [e-mail]
X-Epoch: 1066809992
X-Sasl-enc: RWk9+wBqSE2HxfJu13IVIw
Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id B3A4D32601E; Wed, 22 Oct 2003 04:06:29 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 22 Oct 2003 01:06:25 -0700
From: "Matthew Elvey (FM)" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031020
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Sieve reject at SMTP time possible with which implementations?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sieve reject at SMTP time possible with which implementations?

In other words, what Sieve implementations can be configured such that a 
reject causes the email to be refused/not accepted during the SMTP 
transaction, instead of accepted, and then bounced back to the alleged 
sender (often, in the case of spam, a Joe-Job victim).  Someone just 
told me that Cyrus' implementation can't do this.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M7t3I7096211 for <[e-mail]>; Wed, 22 Oct 2003 00:55:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9M7t3KV096210 for ietf-mta-filters-bks; Wed, 22 Oct 2003 00:55:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M7t2I7096205 for <[e-mail]>; Wed, 22 Oct 2003 00:55:02 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 22 Oct 2003 00:54:58 -0700 (PDT)
Date: Wed, 22 Oct 2003 00:48:24 -0700 (PDT)
From: [e-mail]
Subject: Is draft-daboo-sieve-spamtest-04.txt ready for IETF last call?
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
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-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I noted that a new version of this document was just posted so I reviewed
it. I spotted only two minor things that need changing:

(1) As we saw with the subaddress sieve extension, the term "sieve" is
    used for other purposes in the IETF so the title needs to be more
    specific. I suggest "SIEVE Email Filtering: Spamtest and
    VirusTest Extensions".

(2) There's a bracket out of alignment in the example in section 3.3.

Both of these can be fixed with an RFC Editor note if need be.

This document was already last called on the list some time back and the -04
version appears to me to reflect the changes that were agreed to at that time.
Does everyone else feel this is now ready for IETF last call? If so I'd be
happy to start one.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M1DEI7048976 for <[e-mail]>; Tue, 21 Oct 2003 18:13:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9M1DElO048975 for ietf-mta-filters-bks; Tue, 21 Oct 2003 18:13:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9M1DCI7048970 for <[e-mail]>; Tue, 21 Oct 2003 18:13:13 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 21481 invoked from network); 21 Oct 2003 21:13:14 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 21 Oct 2003 21:13:14 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 740 invoked by uid 101); 21 Oct 2003 21:13:13 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 21 Oct 2003 21:13:13 -0400
To: Marc Mutz <[e-mail]>
Cc: [e-mail]
Subject: Re: Review comments on draft-martin-managesieve-04.txt
Message-ID: <[e-mail]>
References: <0ade01c35e55$f9904a80$6501a8c0@nigelhome> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Oct 22, 2003 at 02:18:22AM +0200, Marc Mutz wrote:
> Hi Mark,

Hi-


> On Tuesday 21 October 2003 22:44, Mark E. Mallett wrote:
> > On Fri, Oct 17, 2003 at 09:08:41AM -0700, [e-mail] wrote:
> > > It was recently mentioned on the imapext list that it is time to
> > > get the managesieve protocol spec moving forward. So I decided to
> > > take a look at the specification as it stands. My comments are as
> > > follows:
> <snip>
> > A few comments:
> <snip>
> 
> Thanks for your comments, but I don't think that we should talk about 
> new features in managesieve such as those you detailed in this thread 
> _now_. That opens all sorts of cans of worms as anyone tries to push 
> his or her pet feature.
> 
> managesieve is implemented at least in the Cyrus server suite and at 
> least Mulberry and KDE have client implementations for this protocol. 
> It's not that we start from scratch here. Some things you asked for 
> might be nice to have - but as an _extension_. Others, like supporting 
> different script languages might never be implemented. And there's 
> certainly no room to debate whether size literals are to be used or not 
> - they are already.

Hmm- maybe I should have started out by asking what the real draft
status was (as opposed to the "expired" status on the document).  I
understand that some drafts exist to sanctify existing implementations,
others (such as various other sieve drafts out there) to work out how
to do things.  Sounds like this one is the former.  That's kind of a
shame, because what you call "pet features" I, well, don't.  As you
might expect :-)  Not to mention that any call for discussion seems
moot now.

Sorry to hear about the size literals being mandated by an existing
implementation.  It's not a make-or-break thing with me, I just don't
like them.  I'll live.

Yours,
-mm-


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M0T5I7047314 for <[e-mail]>; Tue, 21 Oct 2003 17:29:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9M0T55H047313 for ietf-mta-filters-bks; Tue, 21 Oct 2003 17:29:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epost.de (mail.epost.de [193.28.100.165] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9M0T3I7047308 for <[e-mail]>; Tue, 21 Oct 2003 17:29:03 -0700 (PDT) (envelope-from [e-mail])
Received: from [212.144.44.81] (212.144.44.81) by mail.epost.de (6.7.015) (authenticated as [e-mail]) id 3F8E4D49000C9321 for [e-mail]; Wed, 22 Oct 2003 02:29:02 +0200
From: Marc Mutz <[e-mail]>
Organization: KDE
To: [e-mail]
Subject: Re: Review comments on draft-martin-managesieve-04.txt
Date: Wed, 22 Oct 2003 02:18:22 +0200
User-Agent: KMail/1.5.9
References: <0ade01c35e55$f9904a80$6501a8c0@nigelhome> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_jzcl/rOf6uBHv6W"; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Boundary-02=_jzcl/rOf6uBHv6W
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Mark,

On Tuesday 21 October 2003 22:44, Mark E. Mallett wrote:
> On Fri, Oct 17, 2003 at 09:08:41AM -0700, [e-mail] wrote:
> > It was recently mentioned on the imapext list that it is time to
> > get the managesieve protocol spec moving forward. So I decided to
> > take a look at the specification as it stands. My comments are as
> > follows:
<snip>
> A few comments:
<snip>

Thanks for your comments, but I don't think that we should talk about=20
new features in managesieve such as those you detailed in this thread=20
_now_. That opens all sorts of cans of worms as anyone tries to push=20
his or her pet feature.

managesieve is implemented at least in the Cyrus server suite and at=20
least Mulberry and KDE have client implementations for this protocol.=20
It's not that we start from scratch here. Some things you asked for=20
might be nice to have - but as an _extension_. Others, like supporting=20
different script languages might never be implemented. And there's=20
certainly no room to debate whether size literals are to be used or not=20
=2D they are already.

Marc

=2D-=20
It seems that the only thing worse than being an enemy of the US is
being a close friend and ally.
     -- John Horvath, "The Meaning of Friendship", Telepolis #14395

--Boundary-02=_jzcl/rOf6uBHv6W
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/lczj3oWD+L2/6DgRAiYSAJsFvmuyeH8JZhtg0vVQB6qo0y8aYgCgvWd7
JWMpZWqklwUrYRLi5filIhM=
=PMUP
-----END PGP SIGNATURE-----

--Boundary-02=_jzcl/rOf6uBHv6W--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LMSBI7044084 for <[e-mail]>; Tue, 21 Oct 2003 15:28:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LMSB58044083 for ietf-mta-filters-bks; Tue, 21 Oct 2003 15:28:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from orthanc.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LMS9I7044077 for <[e-mail]>; Tue, 21 Oct 2003 15:28:09 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.42.6] (peregrin.orthanc.ca [192.168.42.6]) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id h9LMS0P5079914; Tue, 21 Oct 2003 16:28:04 -0600 (MDT) (envelope-from [e-mail])
Date: Tue, 21 Oct 2003 16:28:00 -0600
From: Lyndon Nerenberg <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>, Cyrus Daboo <[e-mail]>
cc: Marc Mutz <[e-mail]>, [e-mail]
Subject: Re: managesieve + include
Message-ID: <2147483647.1066753680@[192.168.42.6]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <2147483647.1066577862@[10.0.1.8]> <[e-mail]>
X-Mailer: Mulberry/3.1.0b8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> And personally I disagree with the notion that an "include" of a
> nonexistent file should be treated as a no-op.  Mistakes should generate
> error reports.

Or if resources permit, incoming messages could be queued for processing 
later, once the errors are fixed. This is a gnarly problem, though. The 
closest analogy I can think of is a sendmail :include: alias that 
references an unreadable file.

This sort of error handling gets very complicated very quickly. It might 
be better to just say "deliver to the INBOX" if the include fails.

--lyndon


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LLRwI7041618 for <[e-mail]>; Tue, 21 Oct 2003 14:27:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LLRwNF041617 for ietf-mta-filters-bks; Tue, 21 Oct 2003 14:27:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LLRvI7041612 for <[e-mail]>; Tue, 21 Oct 2003 14:27:57 -0700 (PDT) (envelope-from [e-mail])
Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9LLLTEG031887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 21 Oct 2003 17:21:30 -0400
Received: from mx1.andrew.cmu.edu (MX1.andrew.cmu.edu [128.2.10.111]) by mail1.andrew.cmu.edu (Cyrus v2.1.15-077) with LMTP; Tue, 21 Oct 2003 17:24:51 -0400
X-Sieve: CMU Sieve 2.2
Received: from mx1.andrew.cmu.edu ([unix socket]) by mx1.andrew.cmu.edu (Cyrus v2.1.12-075) with LMTP; Tue, 21 Oct 2003 17:24:50 -0400
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx1.andrew.cmu.edu (8.12.10/8.12.9) with ESMTP id h9LLOm3N026128; Tue, 21 Oct 2003 17:24:49 -0400
Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AC2lt-0005Qr-Ra for [e-mail]; Tue, 21 Oct 2003 16:06:25 -0400
Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AC2fU-0005C2-Il for [e-mail]; Tue, 21 Oct 2003 15:59:48 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04441 for <[e-mail]>; Tue, 21 Oct 2003 15:59:38 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
From: [e-mail]
Reply-to: [e-mail]
Date: Tue, 21 Oct 2003 15:59:37 -0400
Subject: I-D ACTION:draft-daboo-sieve-include-01.txt
X-Resent-Mailer: Mulberry/3.1.0b8 (Mac OS X)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========98DA9165824312A7D97F=========="
X-Spam-Level: ****
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--==========98DA9165824312A7D97F==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIEVE Include Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-include-01.txt
	Pages		: 9
	Date		: 2003-10-21
	
The SIEVE [SIEVE] 'include' extension permits users to include one
SIEVE script inside another.  This can make managing large scripts
or multiple sets of scripts much easier, as well as supporting
common 'libraries' of scripts.  Users are able to include their own
personal scripts or site-wide scripts provided by the local SIEVE
implementation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-sieve-include-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-daboo-sieve-include-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-daboo-sieve-include-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--==========98DA9165824312A7D97F==========
Content-Type: multipart/alternative;
 boundary="==========1A874164982146395165=========="

--==========1A874164982146395165==========
Content-Type: message/external-body; ACCESS-TYPE=mail-server;
 SERVER="[e-mail]"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-daboo-sieve-include-01.txt

--==========1A874164982146395165==========
Content-Type: message/external-body; name="draft-daboo-sieve-include-01.txt";
 SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[e-mail]>

--==========1A874164982146395165==========--

--==========98DA9165824312A7D97F==========--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LLR8I7041581 for <[e-mail]>; Tue, 21 Oct 2003 14:27:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LLR8lX041580 for ietf-mta-filters-bks; Tue, 21 Oct 2003 14:27:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9LLR6I7041575 for <[e-mail]>; Tue, 21 Oct 2003 14:27:07 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 27621 invoked from network); 21 Oct 2003 17:27:08 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 21 Oct 2003 17:27:08 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 22775 invoked by uid 101); 21 Oct 2003 17:27:07 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 21 Oct 2003 17:27:07 -0400
To: Cyrus Daboo <[e-mail]>
Cc: Marc Mutz <[e-mail]>, [e-mail]
Subject: Re: managesieve + include
Message-ID: <[e-mail]>
References: <[e-mail]> <2147483647.1066577862@[10.0.1.8]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2147483647.1066577862@[10.0.1.8]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> | 3. Either the managesieve or the include spec need to clarify that
> | scripts that other scripts depend on (e.g. "includees") may not be
> | removed from the script store (return NO) and that includees have to be
> | uploaded before their includers.
> 
> That kind of dependency is going to be a pain.

Indeed- there has to be a line drawn for how much the managesieve
server can know.  Might want to put some text in with dire warnings
about what can happen if you remove a script that's included by
another, but I would frown on having the server having to have
a dependency graph far outside of its current operation.

If somebody does remove a needed included file, their mail delivery
should start generating error messages soon thereafter.  Shift the
focus towards error handling and recovery in the scripting language
and execution environment, and not to the tool used to install and
delete individual files.

And personally I disagree with the notion that an "include" of a
nonexistent file should be treated as a no-op.  Mistakes should generate
error reports.

Agree with the desire for CHECKSCRIPT.

-mm-


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKiCI7039566 for <[e-mail]>; Tue, 21 Oct 2003 13:44:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LKiCVR039565 for ietf-mta-filters-bks; Tue, 21 Oct 2003 13:44:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9LKiAI7039559 for <[e-mail]>; Tue, 21 Oct 2003 13:44:10 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 2234 invoked from network); 21 Oct 2003 16:44:11 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 21 Oct 2003 16:44:11 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 20658 invoked by uid 101); 21 Oct 2003 16:44:10 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 21 Oct 2003 16:44:10 -0400
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Review comments on draft-martin-managesieve-04.txt
Message-ID: <[e-mail]>
References: <0ade01c35e55$f9904a80$6501a8c0@nigelhome> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Oct 17, 2003 at 09:08:41AM -0700, [e-mail] wrote:
> 
> It was recently mentioned on the imapext list that it is time to get
> the managesieve protocol spec moving forward. So I decided to take a look
> at the specification as it stands. My comments are as follows:

Hi-

A few comments:

As I mentioned in another note, I think it would be worth making the
interface a little more generic: rather than being sieve-specific,
allow it to be used for whatever sort of scripting language is
officially available on the mail server.  There could be more than one
such language available.

I would also like to see support for address-space for the
authenticated user.  A user might have different controls for various
email addresses that are mapped to that user's account.  My own
account here receives mail for a number of different addresses and
domains, each with its own control area and associated filter(s).  I
doubt that I'm the only one that would like to be able to individually
manage filters for different address spaces under my control.  Thus
I'd like to see this interface take multiple address/filter spaces
into account.  Each address space might also (or might not, depending
on the server configuration) have its own namespace for filters, so
that "myscript" for [e-mail] could be a different file than
"myscript" for [e-mail] .

Perhaps an optional argument to PUTSCRIPT/GETSCRIPT/SETACTIVE/etc that
indicates the specific address space:

    PUTSCRIPT :address-space "[e-mail]" "myscript"
    PUTSCRIPT :address-space "[e-mail] "myscript"
    SETACTIVE :address-space "[e-mail]" "myscript"


HAVESPACE:  Is there really a point to this?  PUTSCRIPT will already
tell you if the operation fails due to quota.  There's no guarantee
that resource availability at HAVESPACE-time will be the same as the
availability at PUTSCRIPT-time.  Not only that, but I could imagine
that a for given implementation you would not be able to predict the
required space for a script (say, if PUTSCRIPT caused a compiled
version to be stored along with the source).  For a variety of
reasons, HAVESPACE doesn't necessarily tell you what would happen if
you try to upload a script.


PUTSCRIPT/GETSCRIPT:  Regarding this:
  putscript "myscript" {nnn+}
    nnn bytes

I'm not really fond of that byte-counted argument imapism in this
context.  Am I the only one?  I'd much prefer to see some sort of
terminated content a la SMTP.

-mm-


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LJqkI7037855 for <[e-mail]>; Tue, 21 Oct 2003 12:52:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LJqk3N037854 for ietf-mta-filters-bks; Tue, 21 Oct 2003 12:52:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9LJqiI7037848 for <[e-mail]>; Tue, 21 Oct 2003 12:52:45 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 20992 invoked from network); 21 Oct 2003 15:52:43 -0400
Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 21 Oct 2003 15:52:43 -0400
X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net
Received: (qmail 11987 invoked by uid 101); 21 Oct 2003 15:52:42 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 21 Oct 2003 15:52:42 -0400
To: [e-mail]
Cc: Madan Ganesh Velayudham <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Clarification on draft-martin-managesieve-04.txt ?
Message-ID: <[e-mail]>
References: <[e-mail]> <000001c394de$ed994000$3ce62a0f@nt23060> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Oct 17, 2003 at 10:21:03PM -0700, [e-mail] wrote:
> 
> 
> > Martin,
> 
> > 	Recently I have given a draft on "organize extension" in imap.
> > 	I'm new to mta-filters group. Pls correct me if I'm wrong.
> 
> > 	I would like to participate in managesieve too.
> 
> > 	2.7 LISTSCRIPTS.
> 
> > 	Can we have an [ script-name ] optional parameter to this
> > 	command to list the given script-name.
> 
> Why? Getting the content of the script is what GETSCRIPT is for.
> 
> An optional argument specifying a pattern to match script names to
> return would make sense. However, I don't think it is particularly
> useful since it seems quite unlikely a single user will have so many
> scripts that filtering the list is necessary.

I would agree that there is no necessity of having an argument to
LISTSCRIPTS.  However, some wording about namespace might be in
order.  It may be true that a single user will not have a lot of
scripts, but a single user may have a lot of files hanging around.
The server will need to be able to determine which files are scripts.
It would probably be enough to say that this is outside the scope of
the document, and is implementation-specific and all that, but still
it might be said somewhere that the scripts collection is identifiable
somehow.

[ I was going to muddy the waters by talking about script libraries,
and individuals being able to publish there, but it looks like that's
in another thread. ]

But this leads me to a couple of tangential comments.

In the managesieve thread(s) there have been the comments that:

 - a user will not have many script files;
 - a user will only have one active script.

I do not think either is necessarily true, and I think this is a
deficiency in the managesieve outline.  There is at least one mail
system (qmail) where an individual user can manage multiple email
addresses through different control files.  The user might have
multiple domain names being delivered to their account via different
control files in that account.  And with qmail each address can be
extended, with each extension being controlled individually.
Some of this control *can* be mapped through the same place, but
that's not always the best thing to do.

At anyrate, each email address (or address space) that the user is
responsible for can have its own set of controls, including a filter
for that address.  And in fact each control can have more than one
action in nsequence, e.g.:

  1.  Apply first filter
  2.  first filter passed, take some other action
  3.  Step 2 passed, apply second filter
  4.  etc.

Here one would have 2 active filters for a single destination (and
one might have multiple destinations for a single user).  This may
sound like a pathological invention, but it is not.  Personally
I would like to see some consideration for:

 - selection of destination address space within a user space;
 - selection of filter step within a destination address space.

I also think it would be more interesting to talk about "manage mail
delivery filter" rather than "manage sieve".  Do we have to lock
the manage interface into the filter language being used?

There are more comments but they relate more to the document than
to this message, so I'll take a breath :-)

-mm-


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KF9OI7095742 for <[e-mail]>; Mon, 20 Oct 2003 08:09:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KF9O8A095741 for ietf-mta-filters-bks; Mon, 20 Oct 2003 08:09:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KF9NI7095736 for <[e-mail]>; Mon, 20 Oct 2003 08:09:23 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 20 Oct 2003 08:09:22 -0700 (PDT)
Date: Mon, 20 Oct 2003 08:07:49 -0700 (PDT)
From: [e-mail]
Subject: Re: managesieve + include
In-reply-to: "Your message dated Mon, 20 Oct 2003 10:30:04 -0400" <[e-mail]>
To: Ken Murchison <[e-mail]>
Cc: Marc Mutz <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <2147483647.1066577862@[10.0.1.8]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > > There could be a new "INCLUDE" capability for ManageSIEVE to do that.
> > > Whether that is part of the ManageSIEVE draft or the include draft or
> > > a separate document is open for debate.

> > I don't think it's good to allow any user to access the global script
> > space. List it, yes, so the Sieve editor can present the global scripts
> > in the GUI to choose from, but adding new ones should be left to the
> > admin or another role. So if the person filling the role of global
> > script manager needs to access the global script store, then she can
> > just as well log in as that role.

> IMO this is an authorization issue which should not be enforced by
> MANAGESIEVE.

> I agree with Cyrus that MANAGESIEVE should provide a facility to access
> the global script space.  Who has access to this space is a site policy
> decision which would most likely be tied to the authid/authzid.

I agree as well. To the extent that MANAGESIEVE provides a means to
use sophisticated tools for sieve construction and maintenance, it doesn't
seem reasonable to deny these tools to admins maintaining global scripts, or
allow them but require an implementation-specific step on the server to
turn an admin user script into a global script.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KERJI7094314 for <[e-mail]>; Mon, 20 Oct 2003 07:27:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KERJdY094313 for ietf-mta-filters-bks; Mon, 20 Oct 2003 07:27:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KERII7094304 for <[e-mail]>; Mon, 20 Oct 2003 07:27:18 -0700 (PDT) (envelope-from [e-mail])
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id h9KERDo5003519; Mon, 20 Oct 2003 10:27:13 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 20 Oct 2003 10:30:04 -0400
From: Ken Murchison <[e-mail]>
Organization: Oceana Matrix Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Marc Mutz <[e-mail]>
CC: [e-mail]
Subject: Re: managesieve + include
References: <[e-mail]> <2147483647.1066577862@[10.0.1.8]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Marc Mutz wrote:

> Hi Cyrus,
> 
> On Sunday 19 October 2003 21:37, Cyrus Daboo wrote:
> <snip>
> 
>>| 1. The managesieve draft needs to mention that it acts on the local
>>| script storage, not on the global one.
>>
>>Actually it might be nice to allow access to the global script space.
>>That could be done by adopting the new syntax used in include, e.g.:
>>
>>a PUTSCRIPT :global "aGlobalScript" {31+}
>>
>>etc
>>
>>There could be a new "INCLUDE" capability for ManageSIEVE to do that.
>>Whether that is part of the ManageSIEVE draft or the include draft or
>>a separate document is open for debate.
> 
> 
> I don't think it's good to allow any user to access the global script 
> space. List it, yes, so the Sieve editor can present the global scripts 
> in the GUI to choose from, but adding new ones should be left to the 
> admin or another role. So if the person filling the role of global 
> script manager needs to access the global script store, then she can 
> just as well log in as that role.

IMO this is an authorization issue which should not be enforced by 
MANAGESIEVE.

I agree with Cyrus that MANAGESIEVE should provide a facility to access 
the global script space.  Who has access to this space is a site policy 
decision which would most likely be tied to the authid/authzid.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KBsOI7089023 for <[e-mail]>; Mon, 20 Oct 2003 04:54:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KBsORC089022 for ietf-mta-filters-bks; Mon, 20 Oct 2003 04:54:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.hrz.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.90]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KBsMI7089017 for <[e-mail]>; Mon, 20 Oct 2003 04:54:23 -0700 (PDT) (envelope-from [e-mail])
Received: from conversion-daemon.mail2.hrz.uni-bielefeld.de by mail2.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Mon, 20 Oct 2003 13:54:20 +0200 (MEST)
Received: from dirichlet.physik.uni-bielefeld.de ([129.70.125.234]) by mail2.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003)) with ESMTPPSA id <[e-mail]> for [e-mail]; Mon, 20 Oct 2003 13:54:16 +0200 (MEST)
Date: Mon, 20 Oct 2003 13:49:11 +0200
From: Marc Mutz <[e-mail]>
Subject: Re: managesieve + include
In-reply-to: <2147483647.1066577862@[10.0.1.8]>
To: [e-mail]
Message-id: <[e-mail]>
Organization: KDE
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Fv8k/cAqKjBzT+h"; charset=iso-8859-1
Content-transfer-encoding: 7BIT
User-Agent: KMail/1.5.9
X-PGP-Key: 0xBDBFE838
References: <[e-mail]> <2147483647.1066577862@[10.0.1.8]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Boundary-02=_Fv8k/cAqKjBzT+h
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Cyrus,

On Sunday 19 October 2003 21:37, Cyrus Daboo wrote:
<snip>
> | 1. The managesieve draft needs to mention that it acts on the local
> | script storage, not on the global one.
>
> Actually it might be nice to allow access to the global script space.
> That could be done by adopting the new syntax used in include, e.g.:
>
> a PUTSCRIPT :global "aGlobalScript" {31+}
>
> etc
>
> There could be a new "INCLUDE" capability for ManageSIEVE to do that.
> Whether that is part of the ManageSIEVE draft or the include draft or
> a separate document is open for debate.

I don't think it's good to allow any user to access the global script=20
space. List it, yes, so the Sieve editor can present the global scripts=20
in the GUI to choose from, but adding new ones should be left to the=20
admin or another role. So if the person filling the role of global=20
script manager needs to access the global script store, then she can=20
just as well log in as that role.

> | 2. It needs to be clarified that the active script is the "start
> | script" and that included (local) scripts need not (and cannot) be
> | set active to be executed.
>
> Why would you prevent a script that can be used as an include from
> being made active?

Sorry, I was not precise enough. Of course, if your scripts form the=20
following DAG:

A
+ B
  + C
+ D

where A is the active script, you can make any one of B, C, D active and=20
it becomes the start script, at which execution starts. What I wanted=20
to say is that only the start script needs and can be made active and=20
that B can then be included, even though it isn't set active. In short,=20
the active flag does not act like an exec permission.

> | 3. Either the managesieve or the include spec need to clarify that
> | scripts that other scripts depend on (e.g. "includees") may not be
> | removed from the script store (return NO) and that includees have
> | to be uploaded before their includers.
>
> That kind of dependency is going to be a pain.

Then
  include "non-existant-script.siv";
needs to be made legal and a noop. I've got no strong preferences either=20
way, and can see nice use cases for the include-if-exists behaviour,=20
but execution of a formerly valid script MUST not error out only b/c=20
one of the included scripts has been deleted meanwhile.

> | 4. There needs to be a managesieve protocol extension to report
> | more precise errors (machine-readable) for PUTSCRIPT: E.g. parse,
> | syntax, site policy, and dependency errors, together with line and
> | optionally column number. Actually, I think this should go into
> | managesieve proper.
>
> With includes it may actually be useful to have a 'CHECKSCRIPT'
> command that verifies a script and produces verbose error comments.
> That would be useful when constructing a set of scripts with includes
> dependencies.

According to the current draft, PUTSCRIPT must (or should?) not accept=20
invalid scripts. So it needs to parse them for validity and probably=20
also perform some more sophisticated analysis on it (various nesting=20
depths, site policy violations, etc.) anyway. So you can just as well=20
tell the client about your findings. CHECKSCRIPTS duplicates=20
PUTSCRIPT-in-non-authenticated-state.

> | 5. A method (read: managesieve extension) to specify more than one
> | active script and the order in which those are to be processed
> | would also be nice, although personally, I'd be fine with using
> | driver scripts (which, however, requires the include extension).
>
> That would be just the same as having one top level script that
> includes all the 'active' scripts in the order you want - I don't see
> why ManageSIEVE should allow that directly if include is supported in
> SIEVE itself.

That's what I meant by driver script. ;-)

Marc

=2D-=20
[...] the USA needs a German product: Vergangenheitsbew=E4ltigung
   -- Craig Morris: US boycott of products from countries against war?
      www.telepolis.de

--Boundary-02=_Fv8k/cAqKjBzT+h
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/k8vF3oWD+L2/6DgRAumwAJ0ZVGKNcMKhyoRdD/voJQqRLiP+pwCg1tmT
xB8k6m1/0xA1NUzYvEzKGpc=
=+QIu
-----END PGP SIGNATURE-----

--Boundary-02=_Fv8k/cAqKjBzT+h--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JMnMI7097807 for <[e-mail]>; Sun, 19 Oct 2003 15:49:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9JMnMhM097806 for ietf-mta-filters-bks; Sun, 19 Oct 2003 15:49:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JMnKI7097796 for <[e-mail]>; Sun, 19 Oct 2003 15:49:20 -0700 (PDT) (envelope-from [e-mail])
Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h9JMnGXa029661 for <[e-mail]>; Sun, 19 Oct 2003 17:49:17 -0500
Received: from att.com (unknown[135.210.96.92](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20031019224630gw100lr6kbe> (Authid: tony); Sun, 19 Oct 2003 22:46:31 +0000
Message-ID: <[e-mail]>
Date: Sun, 19 Oct 2003 18:49:11 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
X-Accept-Language: en-us, en, es
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: Marc Mutz <[e-mail]>, [e-mail]
Subject: Re: managesieve + include
References: <[e-mail]> <2147483647.1066577862@[10.0.1.8]>
In-Reply-To: <2147483647.1066577862@[10.0.1.8]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo wrote:
> --On Sunday, October 19, 2003 18:53 +0200 Marc Mutz <[e-mail]> wrote:
> | 2. It needs to be clarified that the active script is the "start script"
> | and that included (local) scripts need not (and cannot) be set active
> | to be executed.
> 
> Why would you prevent a script that can be used as an include from being 
> made active? For example, I would like to 'wrap' my default script 
> inside of a 'vacation' script. So most of the time the default script is 
> active, but sometimes I will make the vacation one active.

I agree with Cyrus.

	Tony Hansen
	[e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JJbnI7092685 for <[e-mail]>; Sun, 19 Oct 2003 12:37:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9JJbnRn092684 for ietf-mta-filters-bks; Sun, 19 Oct 2003 12:37:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JJbkI7092677 for <[e-mail]>; Sun, 19 Oct 2003 12:37:48 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.1.8] (pool-151-201-234-166.pitt.east.verizon.net [151.201.234.166]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id h9JJVTEG026946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Oct 2003 15:31:34 -0400
Date: Sun, 19 Oct 2003 15:37:42 -0400
From: Cyrus Daboo <[e-mail]>
To: Marc Mutz <[e-mail]>, [e-mail]
Subject: Re: managesieve + include
Message-ID: <2147483647.1066577862@[10.0.1.8]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/3.1.0b8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Marc,

--On Sunday, October 19, 2003 18:53 +0200 Marc Mutz <[e-mail]> wrote:

| Now that managesieve is being moved forward, we should consider it's
| relation to draft-daboo-sieve-include.

(A new version of include has just been sent to the draft repository)

| I've got a few points that I think have to be added to the managesieve
| draft or would suffice to do in an extension of the protocol.
|
| 1. The managesieve draft needs to mention that it acts on the local
| script storage, not on the global one.

Actually it might be nice to allow access to the global script space. That 
could be done by adopting the new syntax used in include, e.g.:

a PUTSCRIPT :global "aGlobalScript" {31+}

etc

There could be a new "INCLUDE" capability for ManageSIEVE to do that. 
Whether that is part of the ManageSIEVE draft or the include draft or a 
separate document is open for debate.

| 2. It needs to be clarified that the active script is the "start script"
| and that included (local) scripts need not (and cannot) be set active
| to be executed.

Why would you prevent a script that can be used as an include from being 
made active? For example, I would like to 'wrap' my default script inside 
of a 'vacation' script. So most of the time the default script is active, 
but sometimes I will make the vacation one active.

| 3. Either the managesieve or the include spec need to clarify that
| scripts that other scripts depend on (e.g. "includees") may not be
| removed from the script store (return NO) and that includees have to be
| uploaded before their includers.

That kind of dependency is going to be a pain.

| 4. There needs to be a managesieve protocol extension to report more
| precise errors (machine-readable) for PUTSCRIPT: E.g. parse, syntax,
| site policy, and dependency errors, together with line and optionally
| column number. Actually, I think this should go into managesieve
| proper.

With includes it may actually be useful to have a 'CHECKSCRIPT' command 
that verifies a script and produces verbose error comments. That would be 
useful when constructing a set of scripts with includes dependencies.

| 5. A method (read: managesieve extension) to specify more than one
| active script and the order in which those are to be processed would
| also be nice, although personally, I'd be fine with using driver
| scripts (which, however, requires the include extension).

That would be just the same as having one top level script that includes 
all the 'active' scripts in the order you want - I don't see why 
ManageSIEVE should allow that directly if include is supported in SIEVE 
itself.

-- 
Cyrus Daboo


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JJW5I7092545 for <[e-mail]>; Sun, 19 Oct 2003 12:32:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9JJW5HQ092544 for ietf-mta-filters-bks; Sun, 19 Oct 2003 12:32:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JJW4I7092538 for <[e-mail]>; Sun, 19 Oct 2003 12:32:04 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 19 Oct 2003 12:31:50 -0700 (PDT)
Date: Sun, 19 Oct 2003 12:23:58 -0700 (PDT)
From: [e-mail]
Subject: Re: managesieve + include
In-reply-to: "Your message dated Sun, 19 Oct 2003 18:53:35 +0200" <[e-mail]>
To: Marc Mutz <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi!

> Now that managesieve is being moved forward, we should consider it's
> relation to draft-daboo-sieve-include.

Seems reasonable.

> I've got a few points that I think have to be added to the managesieve
> draft or would suffice to do in an extension of the protocol.

> 1. The managesieve draft needs to mention that it acts on the local
> script storage, not on the global one.

Agreed.

> 2. It needs to be clarified that the active script is the "start script"
> and that included (local) scripts need not (and cannot) be set active
> to be executed.

Agreed.

> 3. Either the managesieve or the include spec need to clarify that
> scripts that other scripts depend on (e.g. "includees") may not be
> removed from the script store (return NO) and that includees have to be
> uploaded before their includers.

I think this belongs in the include specification. It should deal with the
generic issue of how sieve storage schemes (including but not limited to
managesieve) manage dependencies.

> 4. There needs to be a managesieve protocol extension to report more
> precise errors (machine-readable) for PUTSCRIPT: E.g. parse, syntax,
> site policy, and dependency errors, together with line and optionally
> column number. Actually, I think this should go into managesieve
> proper.

I've like to hear how others feel about how much checking the managesieve
facility should perform on the sieves it processes.

> 5. A method (read: managesieve extension) to specify more than one
> active script and the order in which those are to be processed would
> also be nice, although personally, I'd be fine with using driver
> scripts (which, however, requires the include extension).

I think this is the topic for an extension, assuming it is done at all.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JIlQI7091362 for <[e-mail]>; Sun, 19 Oct 2003 11:47:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9JIlQXA091360 for ietf-mta-filters-bks; Sun, 19 Oct 2003 11:47:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epost.de (mail.epost.de [193.28.100.164] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JIlNI7091348 for <[e-mail]>; Sun, 19 Oct 2003 11:47:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [212.144.45.206] (212.144.45.206) by mail.epost.de (6.7.015) (authenticated as [e-mail]) id 3F8F970400043CE6 for [e-mail]; Sun, 19 Oct 2003 20:47:23 +0200
From: Marc Mutz <[e-mail]>
Organization: KDE
To: [e-mail]
Subject: Re: Clarification on draft-martin-managesieve-04.txt ?
Date: Sun, 19 Oct 2003 18:30:58 +0200
User-Agent: KMail/1.5.9
References: <00c901c3955e$53edbe60$3ce62a0f@nt23060>
In-Reply-To: <00c901c3955e$53edbe60$3ce62a0f@nt23060>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Oxrk/ZsyLDvD2mL"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Boundary-02=_Oxrk/ZsyLDvD2mL
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 18 October 2003 11:58, Madan Ganesh Velayudham wrote:
<snip>
> =A0=A0=A0=A0=A0=A0=A0=A0Rather DELETESCRIPT a* which would remove all the=
 scripts and
> require only one server/
> =A0=A0=A0=A0=A0=A0=A0=A0client interaction.
<snip>

v04 of the managesieve draft requires command pipelining support. You=20
can write a _lot_ of DELETESCRIPT commands in one packet.

Marc

=2D-=20
There's a lot of "throwing the baby out with the bathwater" going on,
but the bathwater is so foul that many companies don't mind the
occasional loss of baby. -- Bruce Schneier on spam filters,
                            Crypto-Gram 07/2003

--Boundary-02=_Oxrk/ZsyLDvD2mL
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/krxO3oWD+L2/6DgRAo/hAKDndZTOtvj/hl3I5bTH9GB6ldP+1wCgj0Pa
t4TLo1hjfdhJ48XZQ+0kjD8=
=i+Vy
-----END PGP SIGNATURE-----

--Boundary-02=_Oxrk/ZsyLDvD2mL--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JIlQI7091361 for <[e-mail]>; Sun, 19 Oct 2003 11:47:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9JIlQfx091359 for ietf-mta-filters-bks; Sun, 19 Oct 2003 11:47:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.epost.de (mail.epost.de [193.28.100.164] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JIlNI7091349 for <[e-mail]>; Sun, 19 Oct 2003 11:47:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [212.144.45.206] (212.144.45.206) by mail.epost.de (6.7.015) (authenticated as [e-mail]) id 3F8F970400043CE7 for [e-mail]; Sun, 19 Oct 2003 20:47:24 +0200
From: Marc Mutz <[e-mail]>
Organization: KDE
To: [e-mail]
Subject: managesieve + include
Date: Sun, 19 Oct 2003 18:53:35 +0200
User-Agent: KMail/1.5.9
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_QGsk/e8zz/Erl7E"; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Boundary-02=_QGsk/e8zz/Erl7E
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi!

Now that managesieve is being moved forward, we should consider it's=20
relation to draft-daboo-sieve-include.

I've got a few points that I think have to be added to the managesieve=20
draft or would suffice to do in an extension of the protocol.

1. The managesieve draft needs to mention that it acts on the local=20
script storage, not on the global one.

2. It needs to be clarified that the active script is the "start script"=20
and that included (local) scripts need not (and cannot) be set active=20
to be executed.

3. Either the managesieve or the include spec need to clarify that=20
scripts that other scripts depend on (e.g. "includees") may not be=20
removed from the script store (return NO) and that includees have to be=20
uploaded before their includers.

4. There needs to be a managesieve protocol extension to report more=20
precise errors (machine-readable) for PUTSCRIPT: E.g. parse, syntax,=20
site policy, and dependency errors, together with line and optionally=20
column number. Actually, I think this should go into managesieve=20
proper.

5. A method (read: managesieve extension) to specify more than one=20
active script and the order in which those are to be processed would=20
also be nice, although personally, I'd be fine with using driver=20
scripts (which, however, requires the include extension).

Marc

=2D-=20
It takes 5 minutes to create [a OpenPGP key].
Of course it takes a bit more time to get it signed...
                                                 -- David Faure

--Boundary-02=_QGsk/e8zz/Erl7E
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/ksGQ3oWD+L2/6DgRAuAZAKDPHZP1RpfR8hW6BGmIxmV2l10+MQCeNn/+
GqoVxeFgdq9RwY584DN5YEY=
=6ky6
-----END PGP SIGNATURE-----

--Boundary-02=_QGsk/e8zz/Erl7E--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JG9hI7023984 for <[e-mail]>; Sun, 19 Oct 2003 09:09:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9JG9gi9023983 for ietf-mta-filters-bks; Sun, 19 Oct 2003 09:09:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9JG9fI7023978 for <[e-mail]>; Sun, 19 Oct 2003 09:09:41 -0700 (PDT) (envelope-from [e-mail])
Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id h9JG9fk4008069; Sun, 19 Oct 2003 12:09:41 -0400
Date: Sun, 19 Oct 2003 12:09:41 -0400 (EDT)
From: Rob Siemborski <[e-mail]>
To: [e-mail]
cc: Madan Ganesh Velayudham <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <00c901c3955e$53edbe60$3ce62a0f@nt23060> <[e-mail]>
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-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, 18 Oct 2003 [e-mail] wrote:

> > 	do LISTSCRIPT, then delete one by one which requires more
> > server/client interactions.
> > 	Rather DELETESCRIPT a* which would remove all the scripts and
> > require only one server/
> > 	client interaction.
>
> Sure, but that presupposes client interactions are at a premium here.
> I don't think they are.
>
> > 	For GETSCRIPT, if I compare with 'cat'. I thought it is useful.
>
> Useful in some abstract sense, perhaps. But I don't think the benefits
> outweigh the costs.
>
> All IMO, of course. Others may feel differently.

For what its worth, I agree that these features add significant
implementation complexities and don't see much benefit in the real world.

Its very rare that we see users with more than one script stored on the
server at any given time.  Maybe this would change if there was an
"include" sieve functionality (actually, I seem to remember seeing a draft
for this at one point), but even then I don't see this being a frequent
occurance.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [e-mail] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IEOAI7020144 for <[e-mail]>; Sat, 18 Oct 2003 07:24:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IEOAQS020143 for ietf-mta-filters-bks; Sat, 18 Oct 2003 07:24:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IEO9I7020138 for <[e-mail]>; Sat, 18 Oct 2003 07:24:09 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 18 Oct 2003 07:23:59 -0700 (PDT)
Date: Sat, 18 Oct 2003 07:23:28 -0700 (PDT)
From: [e-mail]
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
In-reply-to: "Your message dated Sat, 18 Oct 2003 19:26:33 +0530" <000201c3957f$a956d050$3ce62a0f@nt23060>
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <000201c3957f$a956d050$3ce62a0f@nt23060>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 	Thanks for sharing your thoughts.

> > All IMO, of course. Others may feel differently.

> 	Since I'm new to filters, I did not get what IMO means ?

IMO means In My Opinion.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IDukI7019500 for <[e-mail]>; Sat, 18 Oct 2003 06:56:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IDuklM019499 for ietf-mta-filters-bks; Sat, 18 Oct 2003 06:56:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IDujI7019494 for <[e-mail]>; Sat, 18 Oct 2003 06:56:45 -0700 (PDT) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel8.hp.com (Postfix) with ESMTP id 058111C01DD0; Sat, 18 Oct 2003 09:56:44 -0400 (EDT)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id TAA17893; Sat, 18 Oct 2003 19:25:23 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
Date: Sat, 18 Oct 2003 19:26:33 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000201c3957f$a956d050$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

	Thanks for sharing your thoughts.

> All IMO, of course. Others may feel differently.

	Since I'm new to filters, I did not get what IMO means ?

	+MG

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Saturday, October 18, 2003 6:53 PM
> To: Madan Ganesh Velayudham
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
> 
> 
> 
> > > Why? Getting the content of the script is what GETSCRIPT is for.
> 
> > 	When I gone through the draft, I co-related things with 
> unix commands
> > 	ls and cat.
> 
> > 	If I just want to know whether a script is there or 
> not, LISTSCRIPT 
> > would
> > 	return all the script names.
> > 	like,
> > 	ls filename
> 
> OK.
> 
> > > > 	In GETSCRIPT/DELETESCRIPT, I'm not clear whether
> > > > 	regular expression are entertained. Pls clarify.
> > > > 	Otherwice can we have a defined keyword like ALL.
> > >
> > > Again, why? You use LISTSCRIPT to list the scripts 
> available, then 
> > > use GETSCRIPT to get the scripts you want. Adding facilities to 
> > > GETSCRIPT to return more than one script would require adding 
> > > additional structure to responses to delimit and identify 
> multiple 
> > > scripts.
> 
> > 	I just thought that adding some more flexibility to 
> that would be a 
> > value add.
> 
> Only if it is a genuinely useful feature. This has to be 
> weighed against the complexity of the facility and the cost 
> of implementation. In this particular case the complexity 
> cost is not completely trivial given that we'd be dealing 
> with utf-8 globs or worse, regexps.
> 
> > 	If I have n scripts and If I want to delete scripts 
> which start with 
> > a*. I will
> > 	do LISTSCRIPT, then delete one by one which requires more 
> > server/client interactions.
> > 	Rather DELETESCRIPT a* which would remove all the 
> scripts and require 
> > only one server/
> > 	client interaction.
> 
> Sure, but that presupposes client interactions are at a 
> premium here. I don't think they are.
> 
> > 	For GETSCRIPT, if I compare with 'cat'. I thought it is useful.
> 
> Useful in some abstract sense, perhaps. But I don't think the 
> benefits outweigh the costs.
> 
> All IMO, of course. Others may feel differently.
> 
> 				Ned
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IDR2I7018928 for <[e-mail]>; Sat, 18 Oct 2003 06:27:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IDR2ig018927 for ietf-mta-filters-bks; Sat, 18 Oct 2003 06:27:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IDR0I7018922 for <[e-mail]>; Sat, 18 Oct 2003 06:27:01 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 18 Oct 2003 06:26:52 -0700 (PDT)
Date: Sat, 18 Oct 2003 06:22:54 -0700 (PDT)
From: [e-mail]
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
In-reply-to: "Your message dated Sat, 18 Oct 2003 15:28:05 +0530" <00c901c3955e$53edbe60$3ce62a0f@nt23060>
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <00c901c3955e$53edbe60$3ce62a0f@nt23060>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Why? Getting the content of the script is what GETSCRIPT is for.

> 	When I gone through the draft, I co-related things with unix
> commands
> 	ls and cat.

> 	If I just want to know whether a script is there or not,
> LISTSCRIPT would
> 	return all the script names.
> 	like,
> 	ls filename

OK.

> > > 	In GETSCRIPT/DELETESCRIPT, I'm not clear whether
> > > 	regular expression are entertained. Pls clarify.
> > > 	Otherwice can we have a defined keyword like ALL.
> >
> > Again, why? You use LISTSCRIPT to list the scripts available,
> > then use GETSCRIPT to get the scripts you want. Adding
> > facilities to GETSCRIPT to return more than one script would
> > require adding additional structure to responses to delimit
> > and identify multiple scripts.

> 	I just thought that adding some more flexibility to that would
> be a value add.

Only if it is a genuinely useful feature. This has to be weighed against the
complexity of the facility and the cost of implementation. In this particular
case the complexity cost is not completely trivial given that we'd be dealing
with utf-8 globs or worse, regexps.

> 	If I have n scripts and If I want to delete scripts which start
> with a*. I will
> 	do LISTSCRIPT, then delete one by one which requires more
> server/client interactions.
> 	Rather DELETESCRIPT a* which would remove all the scripts and
> require only one server/
> 	client interaction.

Sure, but that presupposes client interactions are at a premium here.
I don't think they are.

> 	For GETSCRIPT, if I compare with 'cat'. I thought it is useful.

Useful in some abstract sense, perhaps. But I don't think the benefits
outweigh the costs.

All IMO, of course. Others may feel differently.

				Ned


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IBMaI7016279 for <[e-mail]>; Sat, 18 Oct 2003 04:22:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IBMan2016278 for ietf-mta-filters-bks; Sat, 18 Oct 2003 04:22:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IBMYI7016271 for <[e-mail]>; Sat, 18 Oct 2003 04:22:34 -0700 (PDT) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel7.hp.com (Postfix) with ESMTP id 83AE11C01584; Sat, 18 Oct 2003 07:22:33 -0400 (EDT)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id QAA10880; Sat, 18 Oct 2003 16:51:22 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: "'Kjetil Torgrim Homme'" <[e-mail]>, <[e-mail]>
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
Date: Sat, 18 Oct 2003 16:52:32 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000001c3956a$1fb6c6d0$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > 	When I gone through the draft, I co-related things with 
> unix commands 
> > ls and cat.
> 
> it is better to compare the protocol to the Unix system calls:
> readdir(2) and  open(2)/unlink(2).  you can't specify a 
> pattern to either of these, that work is left to the client 
> application (actually sh(1), not ls(1) or rm(1)).

	Excellent comment ! I agree.
	
	My only concern was that client and server systems could be 
	different, ie., In between network comes into picture. The
	no. of transactions between server and client also matters.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IAupI7012294 for <[e-mail]>; Sat, 18 Oct 2003 03:56:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9IAupv0012293 for ietf-mta-filters-bks; Sat, 18 Oct 2003 03:56:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9IAuoI7012287 for <[e-mail]>; Sat, 18 Oct 2003 03:56:50 -0700 (PDT) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.20) id 1AAolL-00045z-Ew for [e-mail]; Sat, 18 Oct 2003 12:56:47 +0200
Received: from rovereto.ifi.uio.no ([129.240.68.185]) by mail-mx3.uio.no with esmtp (Exim 4.14) id 1AAolH-0002zW-Qn for [e-mail]; Sat, 18 Oct 2003 12:56:43 +0200
Subject: Re: Clarification on draft-martin-managesieve-04.txt ?
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <00c901c3955e$53edbe60$3ce62a0f@nt23060>
References: <00c901c3955e$53edbe60$3ce62a0f@nt23060>
Content-Type: text/plain
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Sat, 18 Oct 2003 12:56:43 +0200
Content-Transfer-Encoding: 7bit
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact [e-mail] if you have questions about this scanning.
X-UiO-MailScanner: No virus found
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, 2003-10-18 at 11:58, Madan Ganesh Velayudham wrote:
> > Why? Getting the content of the script is what GETSCRIPT is for.
> 
> 	When I gone through the draft, I co-related things with unix
> commands ls and cat.

it is better to compare the protocol to the Unix system calls:
readdir(2) and  open(2)/unlink(2).  you can't specify a pattern to
either of these, that work is left to the client application (actually
sh(1), not ls(1) or rm(1)).

-- 
Kjetil T.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9I9wBI7009472 for <[e-mail]>; Sat, 18 Oct 2003 02:58:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9I9wBMo009471 for ietf-mta-filters-bks; Sat, 18 Oct 2003 02:58:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9I9w8I7009465 for <[e-mail]>; Sat, 18 Oct 2003 02:58:08 -0700 (PDT) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id ED2301C01444; Sat, 18 Oct 2003 02:58:06 -0700 (PDT)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id PAA06976; Sat, 18 Oct 2003 15:26:55 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
Date: Sat, 18 Oct 2003 15:28:05 +0530
Organization: Hewlett-Packard STSD
Message-ID: <00c901c3955e$53edbe60$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Why? Getting the content of the script is what GETSCRIPT is for.

	When I gone through the draft, I co-related things with unix
commands 
	ls and cat.

	If I just want to know whether a script is there or not,
LISTSCRIPT would 
	return all the script names.
	like,
	ls filename

> > 	In GETSCRIPT/DELETESCRIPT, I'm not clear whether
> > 	regular expression are entertained. Pls clarify.
> > 	Otherwice can we have a defined keyword like ALL.
> 
> Again, why? You use LISTSCRIPT to list the scripts available, 
> then use GETSCRIPT to get the scripts you want. Adding 
> facilities to GETSCRIPT to return more than one script would 
> require adding additional structure to responses to delimit 
> and identify multiple scripts.

	I just thought that adding some more flexibility to that would
be a value add.

	If I have n scripts and If I want to delete scripts which start
with a*. I will 
	do LISTSCRIPT, then delete one by one which requires more
server/client interactions.
	Rather DELETESCRIPT a* which would remove all the scripts and
require only one server/
	client interaction.

	For GETSCRIPT, if I compare with 'cat'. I thought it is useful.

	+MG

> 
> An optional argument specifying a pattern to match script 
> names to return would make sense. However, I don't think it 
> is particularly useful since it seems quite unlikely a single 
> user will have so many scripts that filtering the list is necessary.
> 
> > 	In GETSCRIPT/DELETESCRIPT, I'm not clear whether
> > 	regular expression are entertained. Pls clarify.
> > 	Otherwice can we have a defined keyword like ALL.
> 
> Again, why? You use LISTSCRIPT to list the scripts available, 
> then use GETSCRIPT to get the scripts you want. Adding 
> facilities to GETSCRIPT to return more than one script would 
> require adding additional structure to responses to delimit 
> and identify multiple scripts.
> 
> > 	GETSCRIPT ALL
> 
> > 	DELETESCRIPT ALL
> 
> > 	Thoughts please.
> 
> I don't any of these changes are either necessary or useful.
> 
> 				Ned
> 
> 	
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9I5RfI7043964 for <[e-mail]>; Fri, 17 Oct 2003 22:27:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9I5RfEL043963 for ietf-mta-filters-bks; Fri, 17 Oct 2003 22:27:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9I5RdI7043955 for <[e-mail]>; Fri, 17 Oct 2003 22:27:40 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 17 Oct 2003 22:27:39 -0700 (PDT)
Date: Fri, 17 Oct 2003 22:21:03 -0700 (PDT)
From: [e-mail]
Subject: Re: Clarification on draft-martin-managesieve-04.txt ?
In-reply-to: "Your message dated Sat, 18 Oct 2003 00:15:59 +0530" <000001c394de$ed994000$3ce62a0f@nt23060>
To: Madan Ganesh Velayudham <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
References: <[e-mail]> <000001c394de$ed994000$3ce62a0f@nt23060>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Martin,

> 	Recently I have given a draft on "organize extension" in imap.
> 	I'm new to mta-filters group. Pls correct me if I'm wrong.

> 	I would like to participate in managesieve too.

> 	2.7 LISTSCRIPTS.

> 	Can we have an [ script-name ] optional parameter to this
> 	command to list the given script-name.

Why? Getting the content of the script is what GETSCRIPT is for.

An optional argument specifying a pattern to match script names to
return would make sense. However, I don't think it is particularly
useful since it seems quite unlikely a single user will have so many
scripts that filtering the list is necessary.

> 	In GETSCRIPT/DELETESCRIPT, I'm not clear whether
> 	regular expression are entertained. Pls clarify.
> 	Otherwice can we have a defined keyword like ALL.

Again, why? You use LISTSCRIPT to list the scripts available, then use
GETSCRIPT to get the scripts you want. Adding facilities to GETSCRIPT
to return more than one script would require adding additional
structure to responses to delimit and identify multiple scripts.

> 	GETSCRIPT ALL

> 	DELETESCRIPT ALL

> 	Thoughts please.

I don't any of these changes are either necessary or useful.

				Ned

	




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HIkAI7021734 for <[e-mail]>; Fri, 17 Oct 2003 11:46:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HIkApI021733 for ietf-mta-filters-bks; Fri, 17 Oct 2003 11:46:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HIk9I7021728 for <[e-mail]>; Fri, 17 Oct 2003 11:46:09 -0700 (PDT) (envelope-from [e-mail])
Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id ADF6E1C014E5; Fri, 17 Oct 2003 11:46:09 -0700 (PDT)
Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id AAA21925; Sat, 18 Oct 2003 00:14:50 +0530 (IST)
From: "Madan Ganesh Velayudham" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Clarification on draft-martin-managesieve-04.txt ?
Date: Sat, 18 Oct 2003 00:15:59 +0530
Organization: Hewlett-Packard STSD
Message-ID: <000001c394de$ed994000$3ce62a0f@nt23060>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Martin,

	Recently I have given a draft on "organize extension" in imap. 
	I'm new to mta-filters group. Pls correct me if I'm wrong.

	I would like to participate in managesieve too.

	2.7 LISTSCRIPTS.

	Can we have an [ script-name ] optional parameter to this 
	command to list the given script-name. 

	In GETSCRIPT/DELETESCRIPT, I'm not clear whether
	regular expression are entertained. Pls clarify. 
	Otherwice can we have a defined keyword like ALL.

	GETSCRIPT ALL

	DELETESCRIPT ALL

	Thoughts please.

	+MG

	




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HHRNI7018663 for <[e-mail]>; Fri, 17 Oct 2003 10:27:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9HHRNNH018662 for ietf-mta-filters-bks; Fri, 17 Oct 2003 10:27:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9HHRLI7018657 for <[e-mail]>; Fri, 17 Oct 2003 10:27:21 -0700 (PDT) (envelope-from [e-mail])
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 17 Oct 2003 10:27:05 -0700 (PDT)
Date: Fri, 17 Oct 2003 09:08:41 -0700 (PDT)
From: [e-mail]
Subject: Review comments on draft-martin-managesieve-04.txt
In-reply-to: "Your message dated Sat, 09 Aug 2003 10:09:44 +0100" <0ade01c35e55$f9904a80$6501a8c0@nigelhome>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It was recently mentioned on the imapext list that it is time to get
the managesieve protocol spec moving forward. So I decided to take a look
at the specification as it stands. My comments are as follows:

(0) In keeping with IESG feedback on the sieve subaddress specification, I
    think the title needs to be changed to "A Protocol for Remotely Managing
    Sieve Email Filtering Scripts".

(1) The second paragraph of the introduction regarding ACAP should only
    appear in the introduction (see next point), not in the abstract.

(2) This specification really needs an introduction. Currently the
    introduction section is blank. I suggest an extended version of the
    abstract, something along the lines of:

  Scripts written in the sieve [SIEVE] language allow users to specify
  filters for the email they receive. Typically each user of a message
  store can have his or her own private sieve script or scripts.
  However, message stores are commonly sealed servers so users cannot
  log into them, yet users must be able to update their scripts on them.

  This document describes a protocol "sieve" for securely managing Sieve
  scripts on a remote server.  This protocol allows a user to have multiple
  scripts, and also alerts a user to syntactically flawed scripts.

  This an interim measure as it is hoped that eventually Sieve scripts
  will be stored on ACAP. This document is intended to proceed on the
  experimental track.

(3) Section 1.1 needs to be marked as needing to be removed prior to
    publication.

(4) Sections 1.3 and later really don't belong as subsections of the
    introduction. I suggest moving all of these up a level.

(5) Section 1.3, first paragraph, second sentence. Three types of what?
    Tokens? And why is ATOMS capitalized?

(6) It seems to me section 1.3, Syntax, should provide a prose description
    of the syntax of responses as well as that for commands.

(7) The bit about the port number in section 1.3 really needs to be in a
    section other than one on syntax. Perhaps a section of its own is
    appropriate? It could contain the usual prose about how managesieve
    servers listen for connections on TCP port <tbd>. It also should be
    make it clear that the prose about port 2000 needs to be removed prior
    to publication.
   
(8) Section 1.7 and probably elsewhere. "UTF8" -> "UTF-8".

(9) Sieve script names are UTF-8 identifiers, and as such would seem to me
    to be subject to UTF-8 normalization concerns. The usual way this is
    dealt with is to specify an appropriate stringprep scheme to use. (Indeed,
    the specification appears to be silent on whether or not even ASCII
    script names are case sensitive.) I'm tempted to say that the right
    course of action is to simply reuse the nameprep stringprep profile
    defined in RFC 3491, but this assumes case-insensitivity is what you want.

(10) Section 1.8, paragraph prior to example. "any other capabilities given" ->
     "any capabilities given".

(11) Section 2.1, second example. There probably should be an ellipsis or
    something similar at the begining to indicate these aren't the first
    commands in a session.

(12) Section 2.8. Should make it clear any previously active script is
     deactivated. There's also the question of what happens to the currently
     active script when SETACTIVE is specified with a bogus script name.
     Does the currently active script remain active or is no script active
     after this is done? Need to be specific either way.

(13) Section 3, Sieve URL scheme. A couple of problems here. First, the
     function of this URL scheme needs to be stated in prose prior to the
     registration template. Second, given that the URL can either be
     used to identify either a managesieve server or a script on that
     server, doesn't the scriptname have to be an optional part of the
     URL? Third, I think the name "sieve" is too general for any URL
     scheme in this document -- it is entirely possible there will be other
     URLs that deal with sieve in some way. I suggest "managesieve" instead. 
     And finally, the usage section talks about a "sieve server". Isn't
     this a "managesieve" server?

(14) Section 4, ABNF. The rules iana-token and extension-data
     aren't defined in this specification and the only external rules that
     are inherited are the ones from the base ABNF specification. It looks
     to me like the reference for these rules that needs to be added is
     ACAP (RFC 2244). And there's also the issue of references to the
     sieveurl ABNF given in section 3. The simplest way to deal with this
     would be one more sentence saying it also refers to the sieveurl
     production defined in section 3.

(15) Section 5, second paragraph. Doesn't TLS, properly implemented, also
     provide protection against passive observation and MITM attacks?
     A pointer to the security considerations for sieve itself in RFC 3028
     would probably be a good thing to add as well.

(16) This document needs an IANA considerations section that tells IANA
     to register the URL scheme defined in section 3 and to assign a port
     for the managesieve protocol to use.

(17) Reference to [imap4rev1] needs to be updated from RFC 2060 to RFC 3501.

(18) References need to be split into normative and informative groups.

(19) Indentation of first reference doesn't match the rest.

(20) The required IPR boilerplate section is missing from this document.
     See, say, RFC 3598 section 8 for what this needs to contain.

That's it!

				Ned