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

From: Rob Siemborski <[email-masked]>
Date: Wed, 29 Oct 2003 16:46:08 -0500 (EST)

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

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 29 Oct 2003 18:49:05 -0500 (EST)

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.

> Makes sense.  So it would look like this:
>
> 	:from "Jane Random <[email-masked]>"
> or this
> 	:from "[email-masked] (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

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Jutta Degener <[email-masked]>
Date: Wed, 29 Oct 2003 15:42:05 -0800

You're referring to

Right?

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

---

From: Tim Showalter <[email-masked]>
Date: Wed, 29 Oct 2003 16:01:37 -0800

> 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

---

From: Jutta Degener <[email-masked]>
Date: Wed, 29 Oct 2003 16:44:35 -0800

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

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

	From: [email-masked] (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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 30 Oct 2003 11:47:14 +0100

>         :from "[email-masked] (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

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 30 Oct 2003 11:46:36 -0500

Hi Arnt,

--On Thursday, October 30, 2003 11:47 +0100 Arnt Gulbrandsen 
<[email-masked]> 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é <[email-masked]>" "I'm away";

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

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Thu, 30 Oct 2003 09:23:15 -0800 (PST)

> encoding, the program that writes the script, or the one that runs the

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

---

From: Marc Mutz <[email-masked]>
Date: Thu, 30 Oct 2003 19:41:47 +0100

On Thursday 30 October 2003 17:46, Cyrus Daboo wrote:
<snip>
> vacation :from :mime "=?ISO-8859-1?Q?Jos=E9?= <[email-masked]>"
> "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.
-> These next tokens may
   be numbers or strings but they are never blocks.

[...]

-> 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 
affect both :from and the text.

Marc

-- 
Eternal vigilance is the price of liberty   -- Thomas Jefferson

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 31 Oct 2003 12:03:06 +0100

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

---

From: [email-masked]
Date: Fri, 31 Oct 2003 07:31:59 -0800 (PST)

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

				Ned

---

From: Tim Showalter <[email-masked]>
Date: Fri, 31 Oct 2003 16:29:21 -0800

> mean when the switch is set to "non-mime" and there are encoded words

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

---

From: [email-masked]
Date: Fri, 31 Oct 2003 17:06:16 -0800 (PST)

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

> transcoding (or at least not forbidding it) is appropriate.

Agreed.

				Ned

---

From: Tim Showalter <[email-masked]>
Date: Fri, 31 Oct 2003 18:44:17 -0800

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

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

Tim

---

From: Jutta Degener <[email-masked]>
Date: Fri, 31 Oct 2003 19:50:26 -0800

> 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

Date: Fri, 31 Oct 2003 19:50:26 -0800
From: Jutta Degener <[email-masked]>
To: [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

> 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

Date: Fri, 31 Oct 2003 19:13:33 -0800
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Sender: [email-masked]

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

Date: Fri, 31 Oct 2003 18:44:17 -0800
From: Tim Showalter <[email-masked]>
To: [email-masked]
Cc: Arnt Gulbrandsen <[email-masked]>, Jutta Degener <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

Tim

Date: Fri, 31 Oct 2003 17:06:16 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
To: Tim Showalter <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, Jutta Degener <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Sender: [email-masked]

Agreed.

				Ned

Date: Fri, 31 Oct 2003 16:29:21 -0800
From: Tim Showalter <[email-masked]>
To: [email-masked]
CC: Arnt Gulbrandsen <[email-masked]>, Jutta Degener <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

Tim

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 31 Oct 2003 13:33:58 -0500
To: "Gu?bj?rn S. Hreinsson" <[email-masked]>
Cc: [email-masked]
Subject: Re: Relay control in SIEVE ???
Sender: [email-masked]

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

Date: Fri, 31 Oct 2003 10:18:42 -0800 (PST)
From: [email-masked]
Subject: Re: Relay control in SIEVE ???
To: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 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

From: =?iso-8859-1?Q?Gu=F0bj=F6rn_Hreinsson?= <[email-masked]>
To: <[email-masked]>
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Date: Fri, 31 Oct 2003 18:25:36 -0000
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 31 Oct 2003 13:06:46 -0500
To: Nigel Swinson <[email-masked]>
Cc: "Matthew Elvey \(FM\)" <[email-masked]>, [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Sender: [email-masked]

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Relay control in SIEVE ???
Date: Fri, 31 Oct 2003 23:02:29 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

From: "Nigel Swinson" <[email-masked]>
To: "Matthew Elvey \(FM\)" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Date: Fri, 31 Oct 2003 17:30:37 -0000
Sender: [email-masked]

> 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

From: "=?iso-8859-1?Q?Gu=F0bj=F6rn_S._Hreinsson?=" <[email-masked]>
To: <[email-masked]>
Subject: Re: Relay control in SIEVE ???
Date: Fri, 31 Oct 2003 16:48:19 -0000
Organization: =?iso-8859-1?Q?S=EDminn?=
Sender: [email-masked]

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: <[email-masked]>
To: "Madan Ganesh Velayudham" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
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
> 

Date: Fri, 31 Oct 2003 07:41:16 -0800 (PST)
From: [email-masked]
Subject: RE: Relay control in SIEVE ???
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 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

Date: Fri, 31 Oct 2003 07:31:59 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
To: Arnt Gulbrandsen <[email-masked]>
Cc: Ned Freed <[email-masked]>, Tim Showalter <[email-masked]>, Jutta Degener <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Relay control in SIEVE ???
Date: Fri, 31 Oct 2003 18:32:33 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

From: Arnt Gulbrandsen <[email-masked]>
To: Ned Freed <[email-masked]>
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Cc: Tim Showalter <[email-masked]>, Jutta Degener <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Date: Fri, 31 Oct 2003 12:03:06 +0100
Sender: [email-masked]

Yes. That would work.

--Arnt

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Date: Thu, 30 Oct 2003 19:41:47 +0100
Sender: [email-masked]

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

> vacation :from "Jos=E9 <[email-masked]>" "I'm away";
>
> vacation :from :mime "=3D?ISO-8859-1?Q?Jos=3DE9?=3D <[email-masked]>"
> "I'm away";
<snip>

=2D> These next tokens may

[...]

=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

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

--Boundary-02=_HuVo/MQCk13OTvv--

Date: Thu, 30 Oct 2003 10:49:10 -0800 (PST)
From: [email-masked]
Subject: RE: Relay control in SIEVE ???
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Relay control in SIEVE ???
Date: Thu, 30 Oct 2003 23:28:42 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

Date: Thu, 30 Oct 2003 09:23:15 -0800 (PST)
From: [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
To: Arnt Gulbrandsen <[email-masked]>
Cc: Jutta Degener <[email-masked]>, Tim Showalter <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Cyrus Daboo'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Relay control in SIEVE ???
Date: Thu, 30 Oct 2003 22:53:12 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

Date: Thu, 30 Oct 2003 08:43:22 -0800 (PST)
From: [email-masked]
Subject: Re: Relay control in SIEVE ???
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Thu, 30 Oct 2003 11:46:36 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, Jutta Degener <[email-masked]>
cc: Tim Showalter <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

Hi Arnt,

e.g.:

-- 
Cyrus Daboo

Date: Thu, 30 Oct 2003 11:20:06 -0500
From: Cyrus Daboo <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: Relay control in SIEVE ???
Sender: [email-masked]

Hi Madan,

--On Thursday, October 30, 2003 9:54 +0530 Madan Ganesh Velayudham 
<[email-masked]> 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

From: Arnt Gulbrandsen <[email-masked]>
To: Jutta Degener <[email-masked]>
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Cc: Tim Showalter <[email-masked]>, Rob Siemborski <[email-masked]>, [email-masked]
Date: Thu, 30 Oct 2003 11:47:14 +0100
Sender: [email-masked]

--Arnt

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Relay control in SIEVE ???
Date: Thu, 30 Oct 2003 09:54:12 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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
	[email-masked]	
	+91-80-205-3108
	**************************
	+HP/STSD/Internet Services
	Bangalore, India

	Everything is possible

Date: Wed, 29 Oct 2003 16:44:35 -0800
From: Jutta Degener <[email-masked]>
To: Tim Showalter <[email-masked]>
Cc: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

	

Jutta

Date: Wed, 29 Oct 2003 16:01:37 -0800
From: Tim Showalter <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: Jutta Degener <[email-masked]>, [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

Tim

Date: Wed, 29 Oct 2003 18:49:05 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Jutta Degener <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

Yes.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

Date: Wed, 29 Oct 2003 15:42:05 -0800
From: Jutta Degener <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

You're referring to

Right?

Date: Wed, 29 Oct 2003 15:17:01 -0800
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: draft-elvey-refuse-sieve-00 (was Re: Sieve reject at SMTP time possible with which implementations?)
Sender: [email-masked]

On 10/25/2003 9:48 PM, [email-masked] 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: [email-masked]
    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:[email-masked]>

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

9 Intellectual Property Rights Statement
    <boilerplate>

10 Full Copyright Statement
    <boilerplate>

Date: Wed, 29 Oct 2003 16:46:08 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Sieve Vacation and draft-moore-auto-email-response-04
Sender: [email-masked]

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

Date: Sat, 25 Oct 2003 21:48:17 -0700 (PDT)
From: [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
To: "Matthew Elvey (FM)" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

Date: Sat, 25 Oct 2003 00:43:05 -0700 (PDT)
From: [email-masked]
Subject: Re: Is draft-daboo-sieve-spamtest-04.txt ready for IETF last call?
To: "Matthew Elvey (FM)" <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> On 10/22/2003 12:48 AM, [email-masked] 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

Date: Thu, 23 Oct 2003 16:11:32 -0700
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Is draft-daboo-sieve-spamtest-04.txt ready for IETF last call?
Sender: [email-masked]

On 10/22/2003 12:48 AM, [email-masked] 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.

Date: Thu, 23 Oct 2003 15:39:06 -0700
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Sender: [email-masked]

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

>On Thu, 23 Oct 2003 [email-masked] 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.
>  
>

Date: Thu, 23 Oct 2003 08:24:50 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Sender: [email-masked]

On Thu, 23 Oct 2003 [email-masked] 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

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

Date: Thu, 23 Oct 2003 05:10:15 -0700 (PDT)
From: [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
To: Rob Siemborski <[email-masked]>
Cc: "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Sender: [email-masked]

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Mark E. Mallett'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
Date: Thu, 23 Oct 2003 14:41:42 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

> 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

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 22 Oct 2003 17:16:37 -0400
To: Kjetil Torgrim Homme <[email-masked]>
Cc: [email-masked]
Subject: Re: Review comments on draft-martin-managesieve-04.txt
Sender: [email-masked]

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

Subject: Re: Review comments on draft-martin-managesieve-04.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Wed, 22 Oct 2003 22:21:07 +0200
Sender: [email-masked]

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.

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Date: Tue, 21 Oct 2003 15:59:44 -0400
Subject: I-D ACTION:draft-daboo-sieve-spamtest-04.txt
Sender: [email-masked]

--==========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:
	[email-masked].
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="[email-masked]"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

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

Date: Wed, 22 Oct 2003 10:23:47 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: "Matthew Elvey (FM)" <[email-masked]>
cc: [email-masked]
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Sender: [email-masked]

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

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

From: Arnt Gulbrandsen <[email-masked]>
To: "Matthew Elvey (FM)" <[email-masked]>
Subject: Re: Sieve reject at SMTP time possible with which implementations?
Cc: [email-masked]
Date: Wed, 22 Oct 2003 13:32:20 +0200
Sender: [email-masked]

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

Date: Wed, 22 Oct 2003 01:06:25 -0700
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Subject: Sieve reject at SMTP time possible with which implementations?
Sender: [email-masked]

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.

Date: Wed, 22 Oct 2003 00:48:24 -0700 (PDT)
From: [email-masked]
Subject: Is draft-daboo-sieve-spamtest-04.txt ready for IETF last call?
To: [email-masked]
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Oct 2003 21:13:13 -0400
To: Marc Mutz <[email-masked]>
Cc: [email-masked]
Subject: Re: Review comments on draft-martin-managesieve-04.txt
Sender: [email-masked]

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

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked]
Subject: Re: Review comments on draft-martin-managesieve-04.txt
Date: Wed, 22 Oct 2003 02:18:22 +0200
Sender: [email-masked]

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

--Boundary-02=_jzcl/rOf6uBHv6W--

Date: Tue, 21 Oct 2003 16:28:00 -0600
From: Lyndon Nerenberg <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>, Cyrus Daboo <[email-masked]>
cc: Marc Mutz <[email-masked]>, [email-masked]
Subject: Re: managesieve + include
Sender: [email-masked]

> 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

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Date: Tue, 21 Oct 2003 15:59:37 -0400
Subject: I-D ACTION:draft-daboo-sieve-include-01.txt
Sender: [email-masked]

--==========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:
	[email-masked].
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="[email-masked]"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

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

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Oct 2003 17:27:07 -0400
To: Cyrus Daboo <[email-masked]>
Cc: Marc Mutz <[email-masked]>, [email-masked]
Subject: Re: managesieve + include
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Oct 2003 16:44:10 -0400
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Review comments on draft-martin-managesieve-04.txt
Sender: [email-masked]

On Fri, Oct 17, 2003 at 09:08:41AM -0700, [email-masked] 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 [email-masked] could be a different file than
"myscript" for [email-masked] .

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

    PUTSCRIPT :address-space "[email-masked]" "myscript"
    PUTSCRIPT :address-space "[email-masked] "myscript"
    SETACTIVE :address-space "[email-masked]" "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-

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Oct 2003 15:52:42 -0400
To: [email-masked]
Cc: Madan Ganesh Velayudham <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Clarification on draft-martin-managesieve-04.txt ?
Sender: [email-masked]

On Fri, Oct 17, 2003 at 10:21:03PM -0700, [email-masked] 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-

Date: Mon, 20 Oct 2003 08:07:49 -0700 (PDT)
From: [email-masked]
Subject: Re: managesieve + include
To: Ken Murchison <[email-masked]>
Cc: Marc Mutz <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Mon, 20 Oct 2003 10:30:04 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Marc Mutz <[email-masked]>
CC: [email-masked]
Subject: Re: managesieve + include
Sender: [email-masked]

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

Date: Mon, 20 Oct 2003 13:49:11 +0200
From: Marc Mutz <[email-masked]>
Subject: Re: managesieve + include
To: [email-masked]
Organization: KDE
Sender: [email-masked]

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

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

Date: Sun, 19 Oct 2003 18:49:11 -0400
From: Tony Hansen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Marc Mutz <[email-masked]>, [email-masked]
Subject: Re: managesieve + include
Sender: [email-masked]

Cyrus Daboo wrote:
> --On Sunday, October 19, 2003 18:53 +0200 Marc Mutz <[email-masked]> 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
	[email-masked]

Date: Sun, 19 Oct 2003 15:37:42 -0400
From: Cyrus Daboo <[email-masked]>
To: Marc Mutz <[email-masked]>, [email-masked]
Subject: Re: managesieve + include
Sender: [email-masked]

Hi Marc,

--On Sunday, October 19, 2003 18:53 +0200 Marc Mutz <[email-masked]> 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

Date: Sun, 19 Oct 2003 12:23:58 -0700 (PDT)
From: [email-masked]
Subject: Re: managesieve + include
To: Marc Mutz <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 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

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked]
Subject: Re: Clarification on draft-martin-managesieve-04.txt ?
Date: Sun, 19 Oct 2003 18:30:58 +0200
Sender: [email-masked]

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

--Boundary-02=_Oxrk/ZsyLDvD2mL--

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked]
Subject: managesieve + include
Date: Sun, 19 Oct 2003 18:53:35 +0200
Sender: [email-masked]

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

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

Date: Sun, 19 Oct 2003 12:09:41 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: Madan Ganesh Velayudham <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
Sender: [email-masked]

On Sat, 18 Oct 2003 [email-masked] 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

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

Date: Sat, 18 Oct 2003 07:23:28 -0700 (PDT)
From: [email-masked]
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> 	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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
Date: Sat, 18 Oct 2003 19:26:33 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

	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: [email-masked] [mailto:[email-masked]] 
> Sent: Saturday, October 18, 2003 6:53 PM
> To: Madan Ganesh Velayudham
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> 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
> 

Date: Sat, 18 Oct 2003 06:22:54 -0700 (PDT)
From: [email-masked]
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: "'Kjetil Torgrim Homme'" <[email-masked]>, <[email-masked]>
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
Date: Sat, 18 Oct 2003 16:52:32 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

Subject: Re: Clarification on draft-martin-managesieve-04.txt ?
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Sat, 18 Oct 2003 12:56:43 +0200
Sender: [email-masked]

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.

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Clarification on draft-martin-managesieve-04.txt ?
Date: Sat, 18 Oct 2003 15:28:05 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

Date: Fri, 17 Oct 2003 22:21:03 -0700 (PDT)
From: [email-masked]
Subject: Re: Clarification on draft-martin-managesieve-04.txt ?
To: Madan Ganesh Velayudham <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 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

From: "Madan Ganesh Velayudham" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Clarification on draft-martin-managesieve-04.txt ?
Date: Sat, 18 Oct 2003 00:15:59 +0530
Organization: Hewlett-Packard STSD
Importance: Normal
Sender: [email-masked]

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

Date: Fri, 17 Oct 2003 09:08:41 -0700 (PDT)
From: [email-masked]
Subject: Review comments on draft-martin-managesieve-04.txt
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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