Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h

From: "Matthew Elvey (FM)" <[email-masked]>
Date: Sat, 14 Feb 2004 17:08:15 -0800

Wow, lots of good feedback!  Several replies follow:

On 2/13/2004 7:47 AM, Arnt Gulbrandsen sent forth electrons to convey:

 > <foregoing discussion snipped>
 >
 > Anyway, I think the possibility of e.g. a future MAIL FROM test is
 > reason enough to __permit__ the refusal to happen at any stage of the
 > SMTP/LTMP process.

I intend to remove the text "to an end of DATA command " so that in no
case does the draft stand in the way of this.  

I think Sieve implementations supporting pre-DATA refuse is a desirable
goal.
For example, LMAP could well make pre-DATA refuse more even more useful
than RBLs and envelope checks already do.
And folks who want to receive all email addressed to them, completely
"uncensored", can do so in a new way if there's a pre-DATA Sieve 
processing/operating mode.
It's beyond the scope of this draft to explicitly facilitate it, so how
'bout a separate thread on a pre-DATA Sieve processing/operating mode?

I prefer to not add excess verbiage explicitly allowing things that are
already allowed, but we could (reluctantly) add:
"SMTP refusal may happen at any stage of the SMTP/LTMP process, up to  
the end of DATA command."

I like Cyrus' idea of the refuse extension simply changing the semantics
of "reject" for several reasons.
It's the best way to make mass search-and-replace unnecessary when
switching from an MTA that can support "refuse" to an MUA that can't.
It makes it easier for folks to switch to using "refuse".
I can't think of a situation where you would want both reject and refuse
available at the same time.
Err, Arrgh - Kriskin Hubner came up with one: "reject" results in
friendlier emails than "refuse".
I find that many people don't understand even 'friendly' refuse messages
- e.g. a doctor's and an economist's email to me were refused with a
friendly refuse message, and yet they failed to act on it.  Perhaps the
format of "refuse" messages is actually MORE easily comprehended because
it's less unique.
(email [email-masked] 
<https://www.fastmail.fm/mail2/?MLS=MR-@0,7020,;SMB-MF-SF=4_1;SMR-Part=;SMR-MsgId=7020;Ust=f496ae4c%21227841ae;SMR-FM=1;SMB-CF=40145;UDm=49;MSignal=MC-FromName@0,%257Cbugzilla3sd%2540matthewelvey.fastmail.fm%21U=1> 
to see my | 'friendly'
refuse message|.)|
(Regarding the other issues raised: I believe that anyone who would
receive an email that was rejected would receive that email if it was
refused as instead, unless they had weird email filters in place, so
don't think that's an issue.  Also, I can't recall seeing a bounce that
didn't include the rejection text; what MTA's bounces don't ?)
|3 of us like it.
Kristin, further thoughts?  Can you clarify whether SMTP rejection text 
can use another charset?  I get email (spam) with Subjects in all sorts 
of charsets, imagine this would work too, but I'm (obviously) no expert.

|
On 2/13/2004 12:29 PM, Mark E. Mallett sent forth electrons to convey:

 >On Fri, Feb 13, 2004 at 10:59:01AM -0500, Cyrus Daboo wrote:
 >  
 >
 >One might even add an option
 >to "reject" to specify the SMTP response code and the extended result 
code,
 >which could be used in the smtp-time mode and ignore otherwise.

Alexey and I had considered this and decided that the added complexity
of allowing the user to specify the SMTP response code was outweighed by
the meager benefits of providing it.  We even wrote (and later removed)
a long text on how to allow user-specified __extended__ codes to be 
supported.

"Experience with many protocols has shown that:
    protocols with few options tend towards ubiquity, whilst
    protocols with many options tend towards obscurity."
    - RFC 1651

Have a compelling argument for the option?

In any case, I will s/5.7.0/5.7.1 in the draft  (in the section that may
or may not make it into the next revsion).

 >Re the draft text: why is it "test refuse" and not "action refuse" ?
 >  
 >
Because I made a mistake :).

I will be mostly away from email next week.

--
Matthew

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Feb 2004 15:55:42 +0000

Tim Showalter wrote:

> Alexey Melnikov wrote:
>
>> I don't remember now why the Seive RFC was written to use MDNs.
>
> I do.  Reject originally (early spec, long time ago) said generate a 
> DSN, but MUAs can't do that--conceptually, anyway.  An MUA can 
> generate a good forgery, but it was inappropriate for it to do so.
>
> The guarantee advertised by a DSN is supposed to be "this is what 
> happened".  The guarantee advertised by an MDN is "this is what 
> happened, except that maybe then something else happened that negated 
> this event".  My memory of the spec is that it doesn't exactly allow 
> outright lying, but you're allowed to state "deleted" and there is no 
> guarantee that the message wasn't immediately undeleted, for instance.
>
> So I guess the short version is that MDNs were chosen because we could 
> get away with so much more. 

Than my question is: is changing "reject" to generate DSNs in MTAs and 
MDN in MUAs acceptable?
I personally have no problems with this, and I suspect most users will 
not probably care either.

Alexey

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 18 Feb 2004 11:03:08 -0500

Hi Matthew,

--On Wednesday, February 18, 2004 6:40 AM -0800 "Matthew Elvey (FM)" 
<[email-masked]> wrote:

|> Anyway, you could punt and say that a refuse implementation should use
|> SMTP/LMTP rejection _where_possible_, and allow an implementation to
|> treat refuse as reject if the implementation can't do anything else.
|
| I very much want the user to be able to know as conclusively as possible
| that if "refuse" is supported, then they will be refusing mail at SMTP
| time.

Frankly I doubt that the 'average' user will understand the distinction 
between refuse and reject - 'power' users will. I would likely expect that 
reject vs refuse is something that will be decided by site admins as a 
matter of policy and they would configure their sieve web-frontends (or 
other script generation tools) to use one or the other as appropriate with 
just a single UI widget representing a 'reject' type action that the user 
can pick.

Perhaps the following would be better:

A single new command 'refuse' that takes various arguments, the first of 
which can be one of:

'mdn'   - send an mdn rejection with supplied descriptive text
'dsn'   - send a dsn rejection with supplied descriptive text
'smtp5' - send an smtp permanent failure - ascii text provided is sent with 
smtp response
'smtp4' - send an smtp temporary failure - ascii text provided is sent with 
smtp response
'default'   - one of the above as a defined by site policy.

The only problem with this is knowing how to deal with the text for the 
'default' argument - for mdn/dsn it can be utf8, but for smtp it can only 
be ascii. Perhaps 'default' should take two strings - one utf8 one ascii - 
but that is ugly!

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 15 Feb 2004 18:05:27 +0000

> It makes it easier for folks to switch to using "refuse". 

We are basically in agreement.
The only thing that concerns me is that currently "refuse" might 
generate a DSN, while "reject" is required to generate an MDN.
Does it matter that the behavior changes when a Sieve script is moved 
between MTA and MUA or vice versa?

> available at the same time.

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

---

From: [email-masked]
Date: Fri, 20 Feb 2004 07:41:24 -0800 (PST)

> I don't remember now why the Seive RFC was written to use MDNs.

It is because MDNs are the only generally appropriate mechanism that both MTAs
and MUAs can legitimately use. Remember that the place where sieves get applied
is left intentionally fuzzy; it can be anything from just before the time of
final delivery to much later. A DSN is not an appropriate construct to use
after final delivery: The necessary information to construct the DSN may not be
available, it looks bad if final delivery produced a success DSN only to be
followed by a subsequent faileded DSN, etc.

You can only get away with using DSNs for this if you restrict the time of
application of the sieve to just before or during final delivery.

> > available at the same time.

The main problem with the idea of relaxing the rules for reject to allow it to
generate DSNs or a 5xy error when running on an MTA is that a script will
behave in a fairly different way depending on whether you run it on an MUA or a
MTA. I really don't like this. And if you use a require tag to mean "change the
semantics of reject to refuse" and make it so the tag only works  on MTAs,
you're back to having to change the scripts when you move them around. Its just
generally cleaner to have two different actions here and have one of them be
MTA-only.

				Ned

---

From: "Matthew Elvey (FM)" <[email-masked]>
Date: Sun, 22 Feb 2004 16:10:11 -0600

> generally cleaner to have two different actions here and have one of 

It's unavoidable for behavior to differ between an MUA and an MTA, if 
there is support for a "refuse" action.
What solution do you suggest to avoid a script either behaving 
differently or having to be different ?
You're almost saying you want both, but isn't that an impossibility?
A require tag that means "change the semantics of reject to refuse" 
seems to have the fewest drawbacks.
I think it's impossible for a script that uses a "refuse" action to be 
and behave the same on an MUA and an MTA.

This is still a problem with Cyrus' proposal: what would happen if 
"refuse smtp5" was attempted in a script on a MUA?  It still would 
require a change on a mail agent that couldn't do SMTP time refuses.

Here's an idea!
Perhaps "refuse" should have an "Am I an MTA capable of refusing?" test 
or constant?
Then users wouldn't have to add/remove the <require "refuse"> string 
when moving a script between MUA and MTA.

---

From: [email-masked]
Date: Sun, 22 Feb 2004 14:23:02 -0800 (PST)

> there is support for a "refuse" action.

This presupposes that refuse is supportable on an MUA. I don't think it is or
should be.

> differently or having to be different ?

I suggest that if you want a portable script you use reject and live with
its limitations. If, on the other hand, you are willing to live with an
MTA-only script, you have the option of using refuse.

> You're almost saying you want both, but isn't that an impossibility?

No. See above.

> seems to have the fewest drawbacks.

I disagree. There's only a small incremental cost of switching rejects to
refuses throughout compared to the cost of switching just the require clause.
And you lose the ability to have both behaviors, which is something a large,
composite script might want.

> and behave the same on an MUA and an MTA.

It is impossible to implement refuse on an MUA, period.

> when moving a script between MUA and MTA.

A major wart like this is entirely unwarranted IMO.

				Ned

---

From: "Matthew Elvey (FM)" <[email-masked]>
Date: Tue, 24 Feb 2004 21:11:19 -0600

On 2/22/2004 4:23 PM, [email-masked] sent forth electrons to convey:

> This presupposes that refuse is supportable on an MUA.

I didn't (mean to) communicate that.  What I meant to communicate:

It's unavoidable for behavior to differ between an MUA and an MTA, if
there is support for a "refuse" action (in Sieve when not on an MUA).

> I don't think it is or

So I am correct in concluding that you support the draft (the version 
posted to the list, which is still the latest version) insofar as refuse 
should be a new action, and MUAs must not claim to support it? 

You argued:

> And if you use a require tag to mean "change the
> you're back to having to change the scripts when you move them around.

Yes, you'd have to change scripts using 'refuse' when you move them 
around whether 'refuse' changes the semantics of reject or not. 
Here's an idea: an implementation supporting 'refuse' MUST refuse at 
smtp time whenever possible.  In other words, we make being an MUA an 
acceptable exception allowing an implementation to fail to refuse with a 
5xx reply code (and instead send an MDN).  We make script changes 
unnecessary, and yet it's still clear that your sieve client is refusing 
at smtp time whenever possible.  Anyone who cares is likely to 
understand that MUAs can't refuse at smtp time.

---

From: [email-masked]
Date: Wed, 25 Feb 2004 11:18:16 -0800 (PST)

> should be a new action, and MUAs must not claim to support it?

Yes, I think the current draft gets this right.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 27 Feb 2004 11:18:49 -0500

> there is support for a "refuse" action (in Sieve when not on an MUA).

There are at least two different concerns that are being mingled,
I think:  one of script operating context, and one of portability
within a given context.  A script running in a MUA is in an entirely
different context than a script running on an SMTP server.  I believe
most portability issues only apply to scripts within a given context.
Personally I would imagine that an MUA script is written and maintained
differently than one that runs on an SMTP server-- which may or may
not be an MTA script (it could be an MTA script or an LDA script).
So I see no reason to want a particular script to run without edits
if it is put into a different context (MUA vs MTA).

The question is whether an end user can write a server-side script
that will operate whether or not that user knows if the script will
be invoked by the MTA (so that SMTP-time refusal is possible) or
by an LDA after the message has already been accepted at SMTP time.
I believe it's valuable to have this level of portability.  Even within
the same mail server (or server farm) the operating mode might change
from time to time.  It would be good if the script could accomodate
such a change, and it would be good to minimize the amount of work
necessary to refit a script when moving from one environment to another.
This would benefit both script writers and system administrators.

This is not the only situation where it would be useful to have a more
than just the "require" facility.  (I'd like to be able to have a
script that can be conditionalized according to what extensions are
available, or according to what mode or context the script is
operating under.)  Solving that is not appropriate here, however such a
solution would be applicable to "refuse".  Without this, I believe it
makes sense to try to make "refuse" operate in a server context,
whether or not the script is running at SMTP time.

mm

---

From: [email-masked]
Date: Sat, 28 Feb 2004 11:05:10 -0800 (PST)

> different context than a script running on an SMTP server.

Not really. In our use of sieve it is fairly common for users to construct
scripts in their MUA and upload them to a server. And in some cases users may
design a script and both upload it to one server they use that supports such
things and run it locally on their MUA when dealing with another server that
doesn't support sieve filtering. 

There can also be server-specific sieve scripts that apply server-wide or to
specific groups of users, but this doesn't mean there's not substantial
overlap. The way I look at it is that server-side sieve support has to cover
all the things client-side scripts do plus some additional stuff.

> I believe

Yes, but since the contexts overlap...

> if it is put into a different context (MUA vs MTA).

Server-side scripts provided by server admins which apply server-wide or to
groups of users do have this characteristic, if for no other reason than the
fact that most GUI sieve construction tools do a poor job of constructing such
scripts. (Hardly surprising given that this isn't what the interface is
designed to do.) But saying it applies to all scrips that run server-side
is incorrect.

> This would benefit both script writers and system administrators.

Yes, which is why I believe keeping the truly universal commands separate
from the server-specific ones is a good idea.

				Ned

Date: Sat, 28 Feb 2004 11:05:10 -0800 (PST)
From: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked], "Mark E. Mallett" <[email-masked]>
Sender: [email-masked]

> different context than a script running on an SMTP server.

Not really. In our use of sieve it is fairly common for users to construct
scripts in their MUA and upload them to a server. And in some cases users may
design a script and both upload it to one server they use that supports such
things and run it locally on their MUA when dealing with another server that
doesn't support sieve filtering. 

There can also be server-specific sieve scripts that apply server-wide or to
specific groups of users, but this doesn't mean there's not substantial
overlap. The way I look at it is that server-side sieve support has to cover
all the things client-side scripts do plus some additional stuff.

> I believe

Yes, but since the contexts overlap...

> if it is put into a different context (MUA vs MTA).

Server-side scripts provided by server admins which apply server-wide or to
groups of users do have this characteristic, if for no other reason than the
fact that most GUI sieve construction tools do a poor job of constructing such
scripts. (Hardly surprising given that this isn't what the interface is
designed to do.) But saying it applies to all scrips that run server-side
is incorrect.

> This would benefit both script writers and system administrators.

Yes, which is why I believe keeping the truly universal commands separate
from the server-specific ones is a good idea.

				Ned

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 27 Feb 2004 11:18:49 -0500
To: [email-masked]
Cc: "Mark E. Mallett" <[email-masked]>
Subject: Re: New Sieve extension "refuse" proposal -	draft-elvey-refuse-sieve-01h
Sender: [email-masked]

mm

Date: Wed, 25 Feb 2004 11:18:16 -0800 (PST)
From: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
To: "Matthew Elvey (FM)" <[email-masked]>
Cc: [email-masked], "Matthew Elvey (FM)" <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>
Sender: [email-masked]

				Ned

Date: Tue, 24 Feb 2004 21:11:19 -0600
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Cc: "Matthew Elvey (FM)" <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: New Sieve extension "refuse" proposal -	draft-elvey-refuse-sieve-01h
Sender: [email-masked]

On 2/22/2004 4:23 PM, [email-masked] sent forth electrons to convey:

>> > Its just

Date: Tue, 24 Feb 2004 11:44:50 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: imapflags -- backwards compatibility
Sender: [email-masked]

Alexey, Ken, and I were discussing the new imapflags extension changes,
and it should be possible to do this in a mostly backwards-compatible
manner (excluding the :flags parameter to keep and fileinto).  This would
allow us to keep the old capability name.

If the variable arguments to addflag and setflags optional, you can
continue to have the old behavior (with the "global" flags variable).

This avoids the need to add a full dependency on variables as well -- you
would be unable to use the optional parameter unless "variables" is also
required.  Additionally, "hasflag" might also either require variables
*or* you could make the variable list to hasflag optional as well (This
is probably the most problematic aspect of doing this).

Finally, if the :flags parameter is omitted to fileinto/keep, then the
flags that are in the "global variable" would be applied to the message as
it was stored.

As an aside, it might make sense to move the "optional" arguments to the
end of the parameter lists of these actions, but that is of lesser
concern.

-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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Sun, 22 Feb 2004 14:23:02 -0800 (PST)
From: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
To: "Matthew Elvey (FM)" <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>
Sender: [email-masked]

> > Its just

No. See above.

				Ned

Date: Sun, 22 Feb 2004 16:10:11 -0600
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Cc: Alexey Melnikov <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: New Sieve extension "refuse" proposal -	draft-elvey-refuse-sieve-01h
Sender: [email-masked]

On 2/20/2004 9:41 AM, [email-masked] sent forth electrons to convey:

> Its just

Here's an idea!

Date: Fri, 20 Feb 2004 07:41:24 -0800 (PST)
From: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
To: Alexey Melnikov <[email-masked]>
Cc: "Matthew Elvey (FM)" <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>
Sender: [email-masked]

				Ned

Date: Sun, 15 Feb 2004 18:05:27 +0000
From: Alexey Melnikov <[email-masked]>
To: "Matthew Elvey (FM)" <[email-masked]>
CC: [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

Alexey

Date: Wed, 18 Feb 2004 11:03:08 -0500
From: Cyrus Daboo <[email-masked]>
To: "Matthew Elvey (FM)" <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

Hi Matthew,

-- 
Cyrus Daboo

Date: Wed, 18 Feb 2004 15:55:42 +0000
From: Alexey Melnikov <[email-masked]>
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

Alexey

Date: Sat, 14 Feb 2004 17:08:15 -0800
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Cc: "Arnt Gulbrandsen" <[email-masked]>, "Cyrus Daboo" <[email-masked]>, "Mark E. Mallett" <[email-masked]>, [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

|

code,

--
Matthew

Date: Fri, 13 Feb 2004 15:18:42 -0800 (PST)
From: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
To: Serge Knystautas <[email-masked]>
Cc: [email-masked], Cyrus Daboo <[email-masked]>, "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Sender: [email-masked]

> [email-masked] wrote:
> > But in other cases, with more "unfriendly" bounces, rejecting the message at the SMTP level is more
> > desirable.  When it's more important to limit load on or protect your own server vs. being "friendly" to
> > the original sender, then "reject" can be more appealing.
> >
> > I can therefore envision cases of Sieve scripts that might wish to use both.

> This isn't specific to just Kristin's comment, but if you're talking
> about using sieve in the SMTP transaction, when does this happen?

I suppose it could happen anywhere in the dialogue, but as a practical matter,
any script that uses header tests (and the majority of them do) can only
after the message has been transferred.

Of course this runs into problems when there are multiple recipients.
But remember: The majority of messages have a single recipient. And there's
also LMTP to consider - a sieve implementation operating in the context
of an LMTP server has no problem returning per-recipient failures after
the data.

				Ned

Date: Fri, 13 Feb 2004 17:34:39 -0500
From: Serge Knystautas <[email-masked]>
To: [email-masked]
CC: Cyrus Daboo <[email-masked]>, "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

[email-masked] wrote:
> But in other cases, with more "unfriendly" bounces, rejecting the message at the SMTP level is more
> desirable.  When it's more important to limit load on or protect your own server vs. being "friendly" to 
> the original sender, then "reject" can be more appealing. 
> 
> I can therefore envision cases of Sieve scripts that might wish to use both.

This isn't specific to just Kristin's comment, but if you're talking 
about using sieve in the SMTP transaction, when does this happen?  After 
MAIL FROM?  After each RCPT TO?  After HELO? (the last is a bit 
far-fetched, but it can be used as a more structured way of rejecting 
servers on DNS RBL).

-- 
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [email-masked]

Date: Fri, 13 Feb 2004 13:01:20 -0800
From: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
To: =?iso-8859-1?Q?Cyrus=A0Daboo=A0?= <[email-masked]>
Cc: =?iso-8859-1?B?Ik1hdHRoZXegRWx2ZXmgKEZNKSKg?= <[email-masked]>, [email-masked]
Sender: [email-masked]

I would argue that there is a need, or at least desire, to have both "reject" and "refuse".

For one thing, you can't internationalize "refuse".  We have people who want to ensure for some
more "friendly" bounces that the original sender will see some "friendly" explanatory text.  So they
want to use "reject" so that they can: (a) ensure that their own text is presented to the original sending 
user (SMTP rejection text, in contrast, may or may not end up getting presented to the original sender),
and possibly (b) use another language/charset (language-appropriate subset of  UTF8) for their rejection
text, possibly customizing the choice of language/characters based on characteristics of the message
being rejected.

But in other cases, with more "unfriendly" bounces, rejecting the message at the SMTP level is more
desirable.  When it's more important to limit load on or protect your own server vs. being "friendly" to 
the original sender, then "reject" can be more appealing. 

I can therefore envision cases of Sieve scripts that might wish to use both.

Regards,

Kristin
[email-masked]
----- Original Message -----
From: Cyrus Daboo <[email-masked]>
Date: Friday, February 13, 2004 7:59 am
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h

> 
> Hi Matthew,
> 
> --On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey 
> (FM)" 
> | Hello, folks.  Please review and provide feedback on the "refuse"
> | extension, designed to mostly replace Sieve's "reject" command.
> 
> Question - is there any situation where you would want both reject 
> and 
> refuse available at the same time? i.e. couldn't we just get away 
> with an 
> extension that simply indicates that the existing reject command 
> will 
> actually run during the SMTP transaction and will generate an SMTP 
> error 
> instead of an MDN? Or, if modifying the base-spec reject behaviour 
> is 
> really not allowed in this way, how about having refuse do either 
> SMTP 
> error or MDN as appropriate for the system? That would mean that 
> users can 
> write one script using a single command and have it work on any 
> SIEVE 
> system, whether SIEVE runs at SMTP time or post-SMTP. I would hate 
> to have 
> to change reject<->refuse every time I moved or copied a script 
> across 
> different systems.
> 
> -- 
> Cyrus Daboo
> 
> 

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 13 Feb 2004 15:29:39 -0500
To: Cyrus Daboo <[email-masked]>
Cc: "Matthew Elvey \(FM\)" <[email-masked]>, [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

On Fri, Feb 13, 2004 at 10:59:01AM -0500, Cyrus Daboo wrote:
> Hi Matthew,
> 
> --On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey (FM)" 
> | Hello, folks.  Please review and provide feedback on the "refuse"
> | extension, designed to mostly replace Sieve's "reject" command.
> 
> Question - is there any situation where you would want both reject and 
> refuse available at the same time? i.e. couldn't we just get away with an 
> extension that simply indicates that the existing reject command will 
> actually run during the SMTP transaction and will generate an SMTP error 
> instead of an MDN? Or, if modifying the base-spec reject behaviour is 
> really not allowed in this way, how about having refuse do either SMTP 
> error or MDN as appropriate for the system? That would mean that users can 
> write one script using a single command and have it work on any SIEVE 
> system, whether SIEVE runs at SMTP time or post-SMTP. I would hate to have 
> to change reject<->refuse every time I moved or copied a script across 
> different systems.

This was my initial reaction too: rather than introduce a new action,
introduce a new "smtp-time" operating mode where the existing "reject"
action would have the desired effect.  One might even add an option
to "reject" to specify the SMTP response code and the extended result code,
which could be used in the smtp-time mode and ignore otherwise.

As I mentioned in another thread, this notion of operating mode could
also be useful in other contexts.

mm

Date: Fri, 13 Feb 2004 16:59:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Matthew Elvey (FM) writes:
>
>> http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt
>
>
> I suggest adding a sentence saying that SMTP refusal may happen at the 
> RCPT TO or DATA stages, depending on what's convenient to the 
> implementation. (I suppose it might also happen at the MAIL FROM 
> stage, if a systemwide sieve does the refusal.)
>
> The 550 result code is a fine thing, but shouldn't you also specify an 
> extended result code (1893/2034)? 5.7.1, perhaps?

This is an open issue in the document ;-). Matthew and I weren't sure 
what to do with enhanced status codes.
Do you suggest that we mandate 5.7.1 or should we instead mention it and 
allow an MTA to select another enhanced status code if appropriate?

Alexey

Date: Fri, 13 Feb 2004 16:55:42 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Cyrus Daboo writes:
>
>> But SIEVE has to operate on the message data - there isn't enough 
>> information before the DATA command to run SIEVE, unless you extend 
>> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test).
>
> As I remember the draft I read, a spamtest implementation can legally 
> arrive at a conclusion without considering the body, so if the 
> script's first rule is a spam test, the body need not be considered. 
> (I agree that the body will almost always be considered.)

In theory any Sieve script that doesn't test message headers/body can be 
executed before DATA command.
But the task of checking if a Sieve script doesn't require message 
content might not be a trivial task. Especially if the Sieve engine also 
supports variables.

So I would rather ignore the issue of executing Sieve scripts before 
DATA command in the Sieve "refuse" extension.

> reason enough to _permit_ the refusal to happen at any stage of the 
> SMTP/LTMP process.
>
>> Frankly any system-wide script like that is better left to the SMTP 
>> implentation's own filtering/ruleset behaviour.
>
> Sure, but that own filtering behaviour might just be sieve ;)

Alexey

Date: Fri, 13 Feb 2004 11:10:27 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

Hi Arnt,

--On Friday, February 13, 2004 4:47 PM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

|> But SIEVE has to operate on the message data - there isn't enough
|> information before the DATA command to run SIEVE, unless you extend
|> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test).
|
| As I remember the draft I read, a spamtest implementation can legally
| arrive at a conclusion without considering the body, so if the script's
| first rule is a spam test, the body need not be considered. (I agree that
| the body will almost always be considered.)
|
| Anyway, I think the possibility of e.g. a future MAIL FROM test is reason
| enough to _permit_ the refusal to happen at any stage of the SMTP/LTMP
| process.

If you are going to run a script before DATA then you are going to have to 
limit the set of available sieve tests to just those that make sense - in 
other words you need to define different 'profiles' of the sieve syntax 
that are valid for different phases of the message delivery process. I 
think it would be a mistake just to say that certain tests (e.g. for header 
addresses) become no-ops when run before DATA. As such I think that a 
document that defines such a profile would allow the refusal on MAIL FROM 
or RCPT TO without needing to define that in refuse.

-- 
Cyrus Daboo

To: [email-masked]
From: Tony Finch <[email-masked]>
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Date: Fri, 13 Feb 2004 16:01:25 +0000
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> wrote:
>reason enough to _permit_ the refusal to happen at any stage of the 
>SMTP/LTMP process.

There's already an envelope from test in RFC 3028.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
CROMARTY FORTH TYNE DOGGER: WESTERLY VEERING NORTHERLY 3 OR 4. OCCASIONAL
RAIN. MODERATE OR GOOD, OCCASIONALLY POOR IN DOGGER.

Date: Fri, 13 Feb 2004 10:59:01 -0500
From: Cyrus Daboo <[email-masked]>
To: "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

Hi Matthew,

--On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey (FM)" 
<[email-masked]> wrote:

| Hello, folks.  Please review and provide feedback on the "refuse"
| extension, designed to mostly replace Sieve's "reject" command.

Question - is there any situation where you would want both reject and 
refuse available at the same time? i.e. couldn't we just get away with an 
extension that simply indicates that the existing reject command will 
actually run during the SMTP transaction and will generate an SMTP error 
instead of an MDN? Or, if modifying the base-spec reject behaviour is 
really not allowed in this way, how about having refuse do either SMTP 
error or MDN as appropriate for the system? That would mean that users can 
write one script using a single command and have it work on any SIEVE 
system, whether SIEVE runs at SMTP time or post-SMTP. I would hate to have 
to change reject<->refuse every time I moved or copied a script across 
different systems.

-- 
Cyrus Daboo

From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Cc: "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Date: Fri, 13 Feb 2004 16:47:14 +0100
Sender: [email-masked]

Cyrus Daboo writes:
> But SIEVE has to operate on the message data - there isn't enough 
> information before the DATA command to run SIEVE, unless you extend 
> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test).

As I remember the draft I read, a spamtest implementation can legally 
arrive at a conclusion without considering the body, so if the script's 
first rule is a spam test, the body need not be considered. (I agree 
that the body will almost always be considered.)

Anyway, I think the possibility of e.g. a future MAIL FROM test is 
reason enough to _permit_ the refusal to happen at any stage of the 
SMTP/LTMP process.

> Frankly any system-wide script like that is better left to the SMTP 
> implentation's own filtering/ruleset behaviour.

Sure, but that own filtering behaviour might just be sieve ;)

Arnt

Date: Fri, 13 Feb 2004 10:37:30 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, "Matthew Elvey (FM)" <[email-masked]>
cc: [email-masked]
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

Hi Arnt,

--On Friday, February 13, 2004 11:28 AM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

| I suggest adding a sentence saying that SMTP refusal may happen at the
| RCPT TO or DATA stages, depending on what's convenient to the
| implementation. (I suppose it might also happen at the MAIL FROM stage,
| if a systemwide sieve does the refusal.)

But SIEVE has to operate on the message data - there isn't enough 
information before the DATA command to run SIEVE, unless you extend SIEVE 
with tests for SMTP-Envelope data (e.g. a MAIL FROM test). Frankly any 
system-wide script like that is better left to the SMTP implentation's own 
filtering/ruleset behaviour.

-- 
Cyrus Daboo

From: Arnt Gulbrandsen <[email-masked]>
To: "Matthew Elvey (FM)" <[email-masked]>
Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Cc: [email-masked]
Date: Fri, 13 Feb 2004 11:28:09 +0100
Sender: [email-masked]

Matthew Elvey (FM) writes:
> http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt

I suggest adding a sentence saying that SMTP refusal may happen at the 
RCPT TO or DATA stages, depending on what's convenient to the 
implementation. (I suppose it might also happen at the MAIL FROM stage, 
if a systemwide sieve does the refusal.)

The 550 result code is a fine thing, but shouldn't you also specify an 
extended result code (1893/2034)? 5.7.1, perhaps?

Arnt

Date: Thu, 12 Feb 2004 11:59:59 -0800
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Subject: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h
Sender: [email-masked]

Hello, folks.  Please review and provide feedback on the "refuse" 
extension, designed to mostly replace Sieve's "reject" command.

It's been accepted as an I-D (-00), but we've made some further changes 
to what's published, so please review and comment on what's at
<http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt>

We welcome feedback, particularly
  -   changes that include replacement text or
  -   suggestions from Sieve implementers.

Abstract
  
   With "refuse", Sieve gains the ability to simply not accept an
   email during the SMTP transaction (instead of accepting it and then
   sending an MDN [MDN] back to the alleged sender using "reject").
   A Joe-job is a spam run forged to appear as though it came from an
   innocent party, who is then generally flooded by the bounces, MDNs
   and messages with complaints.  With "reject", MDNs contribute to
   the flood of Joe-job spam to victims of Joe-jobs; SMTP level
   refusals usually don't.  So "refuse" provides users the latter
   method to handle unwanted email.

The further changes were limited to Section 13 'Open Issues for 
Discussion' and a typo.

-Matthew & Alexey

Date: Thu, 05 Feb 2004 20:42:55 -0500
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: I-D ACTION:draft-daboo-sieve-mime-00.txt (fwd)
Sender: [email-masked]

FYI - the following is a draft for a new SIEVE operation for testing the 
content of MIME part headers. Comments welcome...

------------ Forwarded Message -----------
Date: Thursday, February 5, 2004 3:43 PM -0500
From: [email-masked]
To: IETF-Announce
Subject: I-D ACTION:draft-daboo-sieve-mime-00.txt

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

	Title		: SIEVE Email Filtering: MIME Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-mime-00.txt
	Pages		: 8
	Date		: 2004-2-5
	
This document describes the SIEVE Email Filtering 'mime' extension
   which adds a new test for testing the values of MIME headers in a
   message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-sieve-mime-00.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-mime-00.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-mime-00.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.

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

Date: Thu, 05 Feb 2004 14:16:32 +0530
From: Madan Ganesh Velayudham <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments
Sender: [email-masked]

Lyndon Nerenberg wrote:
> --On 2004-2-3 12:05 AM +0530 Madan Ganesh Velayudham 
> <[email-masked]> wrote:
> 
>>> Section 9:
>>>
>>> * Since there's no way (that I can see) to access another users
>>> counter  data (through the protocol), this text doesn't seem
>>> relevant.
>>
>>
>>     Yes, I agree. But to be expilicit.
> 
> 
> It is "explicit" by reason of the specification simply not specifying 
> the facility. Having the security section talk about something that does 
> not exist in the protocol is just going to confuse people. The text in 
> question needs to be removed.
> 
> 

Yes, Lyndon. Thats a valid one. It is better not to confuse the people.
The updated draft will not have this text.

Thank You,
MG

-- 
  _____________________________________________________________
      ___
     /___\      Madan ganesh Velayudham
    |/. .\|     STSD, India
    (   ) )     +91 80 (2) 205 3108
     \ = /
     _)_(_   There are no limitation in what you can do
             except the limitations of your own mind.
_____________________________________________________________

Date: Wed, 04 Feb 2004 22:10:38 -0800
From: Lyndon Nerenberg <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>
cc: [email-masked]
Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments
Sender: [email-masked]

--On 2004-2-3 12:05 AM +0530 Madan Ganesh Velayudham 
<[email-masked]> wrote:

>> Section 9:
>>
>> * Since there's no way (that I can see) to access another users
>> counter  data (through the protocol), this text doesn't seem
>> relevant.
>
> 	Yes, I agree. But to be expilicit.

It is "explicit" by reason of the specification simply not specifying 
the facility. Having the security section talk about something that 
does not exist in the protocol is just going to confuse people. The 
text in question needs to be removed.

From: "Nigel Swinson" <[email-masked]>
To: "Madan Ganesh Velayudham" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments
Date: Wed, 4 Feb 2004 14:08:32 -0000
Sender: [email-masked]

> "SIEVE: Remove attachment(s)", Madan Velayudham, 23-Dec-03. (8185 bytes) "
>
>
http://ietf.org/internet-drafts/draft-madanganeshv-sieve-remove-attach-00.txt
>
>
> This draft introduces an action command 'fileinto-except' to [SIEVE] in
> order to move a message to a folder without certain attachments of the
> received message.

I think it might be more useful to have an action that removes an
attachment, and a test that tests for the prescence of a mime body part.  So
you'd say:

if (message contains .exe attachment) {
    remove .exe attachment
    fileinto folder;
    stop;
}

We generically want a test that allows users to examine the prescense or
absence of attachments of various kinds, so I think it would make sense to
build upon that work.  As it is, the extension you propose means that you
can only neatly remove one style of attachment.  What if you want to remove
all .exe/.bat/.pif/.vbs attachments?  You'd end up with long and nasty regex
expressions that try to match filenames that contain any of the proposed
extensions.  Much better I think would be to have four remove attachment
commands, one for each kind of extension.

Having a remove-attachment extension will end up along the lines of the
editheader extensions in the sense that they will modify the message.  So it
raises some of the issues that have already been discussed there, so I guess
we'd have to say that tests examine the current state of the message.  So if
we say:

remove .exe attachments
if (message contains .exe attachment) {
  We'd never get here.
}

Cheers

Nigel

Date: Tue, 03 Feb 2004 00:05:52 +0530
From: Madan Ganesh Velayudham <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments
Sender: [email-masked]

Hi Lyndon,

	Thank you for your review comments.

	Please find my comments in line :
> 
> Some comments based on a quick scan of the document ...
> 
> Section 4:
> 
> * "action" needs to be more clearly defined

	Sure. Shall refine it.
> 
> Section 5:
> 
> * Why two capabilities? Both commands are required, so there's     no 
> point in advertising two capability strings. The capability should be 
> changed to something like "STATISTICS".

	Thats great. Yes, Both are required capability strings. I will
	update the Capability string to STATISTICS.

> 
> Section 6:
> 
> * What does a "zero valued action counter" mean? Surely '0' is a valid 
> counter value, meaning the action has never been triggered. I think what 
> you're implying here is that a '0' value means the counter for the 
> action isn't implemented. If that's the case, just don't return a 
> response for that action.

	My initial assumption was if the discarded mail count is 0, the 
implementation may return discard 0 or dont return discard action itself.

	But as you said, the client is no way differentiating whether the 
action is supported or not.

> 
> * Presumably GETSTAT is only valid in authenticated state? (Section 7 
> explicitly calls this out, so section 6 should as well.)

	I think it is already there. "This command MUST be given after the 
client is authenticated". Pls clarify if i'm wrong.

> 
> Section 8:
> 
> * The grammar (and semantic description) for the command responses is 
> missing.

	Thanks for pointing out. I shall include it some thing like

	command-getstat-resp  =  getstat-resp-list

	getstat-resp-list = [ supported-action integer-value ] * getstat-resp-list

	supported-action  = "discard" / "divert" / "reject"

	command-resetstat=res = "OK" | "NO"
	
> 
> Section 9:
> 
> * Since there's no way (that I can see) to access another users counter 
> data (through the protocol), this text doesn't seem relevant.

	Yes, I agree. But to be expilicit.

> 
> General:
> 
> * How useful is the returned data? The fact that an action took place 
> doesn't really tell me anything. I would be much more interested in 
> seeing how often each rule fired, as that would allow me to optimize my 
> rulesets.
> 

	That is a interesting thought. I shall think of it and document it.

	Please let me know your comments.
	MG

> --lyndon

-- 
  _____________________________________________________________
      ___
     /___\      Madan ganesh Velayudham
    |/. .\|     STSD, India
    (   ) )     +91 80 (2) 205 3108
     \ = /
     _)_(_   There are no limitation in what you can do
             except the limitations of your own mind.
_____________________________________________________________