Subject: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix

From: Matthew Elvey <[email-masked]>
Date: Mon, 09 Aug 2004 22:46:40 -0700

1) Belatedly announcing, in case folks missed it:
    http://www1.ietf.org/internet-drafts/draft-elvey-refuse-sieve-02.txt

    Last discussion post on 'refuse' was my post on 6/8/04.
    I believe 'refuse' is ready for last call.
=-=-=

2) http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
might make a good addition to http://cyrusoft.com/sieve/.

--
Matthew

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 10 Aug 2004 11:13:57 -0400

Hi Matthew,

>     I believe 'refuse' is ready for last call.

There was some discussion at the lunch BOF last week about the utility of 
refuse. There was general consensus among the participants that it would be 
better to extend reject to allow for SMTP refusal and DSN generation rather 
than add a new command. Personally I prefer that approach - but the issue 
needs more discussion on the list.

We've probably been over this before, but can you explain in detail why you 
think a new command is better than extending the behaviour of reject?

> might make a good addition to http://cyrusoft.com/sieve/.

I am planning on several updates to our webpage and will add a link to your 
page at the same time.

-- 
Cyrus Daboo

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 10 Aug 2004 11:36:52 -0700

On 8/10/2004 8:13 AM, Cyrus Daboo sent forth electrons to convey:

> There was some discussion at the lunch BOF last week about the utility 
> of refuse. 

Cool; wish I coulda been there/participated.  Anyone take minutes?   
(edit: I just heard that Alexey has notes he may share.)

> There was general consensus among the participants that it would be 
> better to extend reject to allow for SMTP refusal and DSN generation 
> rather than add a new command. Personally I prefer that approach - but 
> the issue needs more discussion on the list.
>
> We've probably been over this before, but can you explain in detail 
> why you think a new command is better than extending the behaviour of 
> reject?

So the idea is just a syntax change, yes?
What's the gist of the argument for the change? 
I can't think of any strong arguments against the change; here are some 
less strong arguments:
1)A normal extension (the current 'refuse') is a cleaner implementation 
in the sense that it's a standard extension - something that's well 
understood, instead of something that makes the base Sieve RFC 'wrong' 
by changing it. 
2)It's already written and debugged.

Arguments for the change:
1)A change won't break anything, according to the URL below.

Have we done something like this (e.g. modify an action to accept a 
special parameter flag) before?

> I am planning on several updates to our webpage and will add a link to 
> your page at the same time.

Great.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Aug 2004 19:22:14 +0100

Cyrus Daboo wrote:

> of refuse. There was general consensus among the participants that it 
> would be better to extend reject to allow for SMTP refusal and DSN 
> generation rather than add a new command. Personally I prefer that 
> approach - but the issue needs more discussion on the list.
>

I personally don't care, this is just syntax. I think somebody has 
objected to this before.

Alexey

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 10 Aug 2004 15:16:36 -0400

Hi Matthew,

> (edit: I just heard that Alexey has notes he may share.)

The Jabber log is here:

<http://www.xmpp.org/ietf-logs/[email-masked]/2004-08-04.txt>

I will also attempt to write up a brief summary and post to the list in the 
next day or so.

> So the idea is just a syntax change, yes?

A syntax change and also a relaxation of the requirement that 'reject' must 
generate an MDN. i.e. if 'reject' occurs in an  implementation that runs 
SIEVE during SMTP then that implementation is allowed to do either an SMTP 
error code, DSN or MDN as it feels appropriate. The 'reject' text specified 
by the user would be used for DSN or MDN text, and we would add a new 
optional parameter for the SMTP error code and descriptive error text.

> What's the gist of the argument for the change? I can't think of any
> strong arguments against the change; here are some less strong arguments:

> understood, instead of something that makes the base Sieve RFC 'wrong' by
> changing it.

My argument against a new command is that it makes scripts less portable. 
By relaxing the restriction on reject the same script can run efficiently 
on an implementation that runs at SMTP time and one that runs at final 
delivery/LMTP time. It will also make switching between such 
implementations easier as scripts will not have to be changed to gain the 
benefits of SMTP time rejection.

The question is whether there is ever a case where you would care what type 
of reject behaviour is carried out: SMTP error, DSN or MDN. If there is a 
requirement to allow users to explicitly state the type of error that can 
easily be done as a parameter.

> 2)It's already written and debugged.

True, but I don't think switching to 'relaxed' reject would be a 
significant change. I suspect the integration with SMTP is the biggest 
issue.

> special parameter flag) before?

Yes - the copy extension adds a :copy parameter to fileinto and redirect. 
imapflags also extends fileinto and also keep.

-- 
Cyrus Daboo

---

From: Philip Guenther <[email-masked]>
Date: Tue, 10 Aug 2004 12:23:40 -0700

Matthew Elvey <[email-masked]> writes:
...
>special parameter flag) before?

RFC 3431 (relational tests) adds the :count and :value match-types.
Even closer is draft-degener-sieve-copy-03.txt, which adds the :copy
parameter to redirect and fileinto.

Philip Guenther

---

From: Kristin Hubner <[email-masked]>
Date: Tue, 10 Aug 2004 13:17:49 -0700

On Aug 10, 2004, at 12:16 PM, Cyrus Daboo wrote:

> I will also attempt to write up a brief summary and post to the list  
> in the next day or so.
>
> A syntax change and also a relaxation of the requirement that 'reject'  
> must generate an MDN. i.e. if 'reject' occurs in an  implementation  
> that runs SIEVE during SMTP then that implementation is allowed to do  
> either an SMTP error code, DSN or MDN as it feels appropriate. The  
> 'reject' text specified by the user would be used for DSN or MDN text,  
> and we would add a new optional parameter for the SMTP error code and  
> descriptive error text.

I'm sorry I missed the discussion, as perhaps the issues I will repeat  
below have been
already discussed.

If done as a relaxation of "reject", then one will need to be able to  
handle the DNS and MDN cases differently due to the issue of character  
sets and non-ASCII text in the reason text.

The SMTP text has to be ASCII only.  The MDN text can potentially  
contain non-ASCII text.

Being able to provide a reason in their "own" language (a language that  
needs a non-ASCII
charset for proper representation) is very important to some users.   I  
can hardly stress
enough how important this is to some users and user communities!

So either: (1) A "relaxed" reject action would need another parameter  
specifying whether
SMTP level rejection vs. later MDN should be performed, and then the  
value of that
parameter would need to affect what sorts of characters are allowed in  
the reason string, or
else (2) A "relaxed" reject action would need two parameters, one being  
the SMTP rejection
text (ASCII only) and a second parameter would be the MDN text which  
would allow
non-ASCII text.   Or maybe some third approach  I haven't thought of,  
as long as it allows
non-ASCII text when non-ASCII text is legal, and uses ASCII text when  
ASCII text is required.

To me, such approaches, complicating the reason text in a single action  
("relaxed"
reject) seems uglier than adding a new action refuse that does the SMTP  
rejection case and
leaving reject alone as the MDN rejection case.  And I think that the  
necessity for scripts
to be aware of the difference between SMTP rejection and MDN rejection  
means that
they might as well be coded with different actions -- I think that  
there is no real simplicity
benefit to using a single action.

> My argument against a new command is that it makes scripts less  
> portable. By relaxing the restriction on reject the same script can  
> run efficiently on an implementation that runs at SMTP time and one  
> that runs at final delivery/LMTP time. It will also make switching  
> between such implementations easier as scripts will not have to be  
> changed to gain the benefits of SMTP time rejection.

The "portable script" argument only works for sites that are supporting  
English-only (or
at best,  
Western-European-languages-that-can-be-adequately-represented-in-ASCII- 
only)
user communities.

For other sites that are already using reject with MDN text that is not  
ASCII-only, their script
already isn't suitable for SMTP reject time interpretation.  Such sites  
are going to have to
care, in their scripts, about the different requirements for reason  
text for SMTP rejections
vs. MDNs.

Regards,

Kristin

>
> The question is whether there is ever a case where you would care what  
> type of reject behaviour is carried out: SMTP error, DSN or MDN. If  
> there is a requirement to allow users to explicitly state the type of  
> error that can easily be done as a parameter.
>
> Yes - the copy extension adds a :copy parameter to fileinto and  
> redirect. imapflags also extends fileinto and also keep.
>
>
> -- 
> Cyrus Daboo
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Aug 2004 23:21:07 +0200

> I will also attempt to write up a brief summary and post to the list in the 

Very useful, thanks.

I'm sad to see that ManageSieve apparently won't be on the WG agenda.
It was suggested ManageSieve was considered a "hack".  Could someone
explain that?  I'm trying to understand what it is about that is a
"hack".  To me, ManageSieve much less of a hack compared to
transferring Sieve from clients to servers over LDAP or ACAP.  I've
explained it before, but my reason for that is that to be useful, the
protocol transferring Sieve will have to support syntax validation of
the script, and crafting that on to LDAP or ACAP is to me a very big
hack.

Thanks,
Simon

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 11 Aug 2004 01:06:10 +0200

On tir, 2004-08-10 at 23:21 +0200, Simon Josefsson wrote:
> explain that?

since it was I who said it, I guess I should come forward.  I only meant
that managesieve is a stopgap measure.  the proper method would be ACAP.

> I'm trying to understand what it is about that is a

ACAP caters for dataset class specific validation rules.  you're right
there is a problem, since the ACAP server can't know which extensions
the server supports, and indeed, there may be more than one server (ACAP
consumer) using the same values.

managesieve assumes that it is run on each server instance.  I don't
think it is problematic that ACAP is used similarily.  (it can partly be
hidden by referrals, ie. multiple servers for different uses at a site
can appear as one to a user.)  the user can still easily migrate
settings between ACAP servers.
-- 
Kjetil T.

---

From: Philip Guenther <[email-masked]>
Date: Tue, 10 Aug 2004 16:18:17 -0700

Kristin Hubner <[email-masked]> writes:
..
>below have been already discussed.

Ned brought this up and it was discussed.

...
>specifying whether SMTP level rejection vs. later MDN should be
>performed, and then the value of that parameter would need to
>affect what sorts of characters are allowed in the reason string,
>or else (2) A "relaxed" reject action would need two parameters,
>one being the SMTP rejection text (ASCII only) and a second parameter
>would be the MDN text which would allow non-ASCII text.   Or maybe
>some third approach  I haven't thought of, as long as it allows
>non-ASCII text when non-ASCII text is legal, and uses ASCII text
>when ASCII text is required.

At the lunch meeting, it was felt that (2) was the preferable way
to resolve this, but that the details should be worked out on the
list.

IMHO, reject should only send an SMTP-level reject if "given
permission" by an additional tagged argument.  If this argument was
given but the implementation was unable to perform rejection at the
SMTP-level for any reason, then it would send a MDN as if the
argument hasn't been given at all.

It would be nice if the script could not only specify the SMTP
response text but also the last two digits of the enhanced status
code (i.e., y and z in the "x.y.z" after the SMTP status code),
either via another tagged argument or by pulling them from the start
of the response text whenever it starts with
	1*3digit "." 1*3digit SP

...
>And I think that the necessity for scripts to be aware of the
>difference between SMTP rejection and MDN rejection means that
>there is no real simplicity benefit to using a single action.

I disagree: just because the text for the two may be different
doesn't mean I want to be forced to choose which of the two is done.
I would prefer to be able to say "do an SMTP-level reject if you
can with _this_ text, else send an MDN with _this_ text".

>The "portable script" argument only works for sites that are
>supporting English-only (or at best, Western-European-languages-
>that-can-be-adequately-represented-in-ASCII-only) user communities.
>
>For other sites that are already using reject with MDN text that
>is not ASCII-only, their script already isn't suitable for SMTP
>reject time interpretation.  Such sites are going to have to care,
>in their scripts, about the different requirements for reason text
>for SMTP rejections vs. MDNs.

If specified as I suggested above, these scripts would see *NO*
change in behavior.

Philip Guenther

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 11 Aug 2004 01:30:03 +0200

>     I believe 'refuse' is ready for last call.

I think this draft doesn't go far enough:  it should state the rules for
running a Sieve script before the message is accepted.  it can be kept
quite simple: a Sieve script can be run after RCPT TO, but only "stop"
and "refuse" are acted on.  tests against headers before DATA will
likewise fail.  there is no implicit keep.

this allows me to write

  if envelope "To" "[email-masked]" {
     refuse "This address has been discontinued"; stop;
  }
  fileinto "INBOX.whatever";

if the test fails, control passes to the fileinto which is ignored,
otherwise, the e-mail is refused.  only after acceptance of the message
after DATA will the fileinto be executed.  (an implementation may elect
to run the Sieve script only once, after DATA.)

I strongly object to section 4.2 of the draft.  it must not be possible
to "reject" a message but actually store it.  we should not condone
lying about whether a message was accepted or not.
-- 
Kjetil T.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 11 Aug 2004 01:33:45 +0200

> can with _this_ text, else send an MDN with _this_ text".

I think "reject" should be deprecated.  it is never appropriate to send
an MDN.  the tests available in Sieve today are not sufficient to have
any chance of avoiding being an accomplice in a joe-job attack.

I think a new command is best.
-- 
Kjetil T.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 10 Aug 2004 19:52:52 -0400

Hi Kristin,

--On Tuesday, August 10, 2004 1:17 PM -0700 Kristin Hubner 
<[email-masked]> wrote:

> care, in their scripts, about the different requirements for reason  text
> for SMTP rejections
> vs. MDNs.
>

In addition to Phillip's comment there is another issue here: how do you do 
deal with multiple recipients? What happens in the case where one 
recipient's script accepts the message and the other does not? In that case 
a 250 has to be returned on SMTP DATA and a DSN sent back for the recipient 
that does not accept the message (the refuse spec does describe that). 
However, the current refuse command only accepts ascii as the reason 
string, and anyone that cares about i18n charset issues will likely want 
the DSN to allow non-ascii.

So to handle the multiple recipient case there has to be a single action 
that can handle both cases: an SMTP error rejection (ascii only) or a 
DSN/MDN (potentially non-ascii) rejection - and the implementation picks 
the appropriate one based on what it is allowed to do for a given message 
and recipient list. Given that I think it makes sense to extend reject 
rather than add a new action.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 10 Aug 2004 19:51:55 -0400

Hi Kjetil,

> any chance of avoiding being an accomplice in a joe-job attack.

Well what is the difference between a DSN and an MDN joe-job? The reality 
is that even refuse suffers from this problem as there are several cases 
where refuse results in a DSN joe-job (in fact I think it will be the 
majority of cases). The only way to really address this is to only allow 
discard.

Also this assumes that you are only using sieve for spam filtering, but 
there are other legitimate uses for it!

-- 
Cyrus Daboo

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 11 Aug 2004 02:01:47 +0200

Cyrus Daboo wrote:
> Kjetil Torgrim Homme wrote:

yes, as it stands, few mail clusters will be able to do this right, but
it would be nice if we made it possible.  Sieve is today typically run
by the MDA only, and a refuce in the LMTP dialogue is as you imply of
little value.  this extension should allow the MTA to run the Sieve
script, _in_addition_to_ the MDA.  this way, we can do the refuse on the
border and avoid the DSN joejob problem (or at least drastically
minimise it).

> there are other legitimate uses for it!

but the legitimate uses are wide open for attack.  I'm getting really
tired of "Thank you for contacting Acme customer service.  You've been
assigned ticket #4378353."

-- 
Kjetil T.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 10 Aug 2004 20:25:27 -0400

Hi Kjetil,

> border and avoid the DSN joejob problem (or at least drastically

The effectiveness of reducing joe-job DSNs depends on exactly how the 
original spam message is being submitted and sent. If the submission server 
(MSA) is the client that connects to the final delivery server (MDA) where 
SIEVE is being run, then the DSN/MDN is avoided. However, if there is one 
or more intervening MTA's relaying the message, then a DSN will always be 
generated by the client connecting to the MDA when the script does the SMTP 
error refuse. So the question is how many messages fall into these two 
categories: 'direct' delivery vs 'relayed' delivery. That will determine 
the real effectiveness of refuse.

-- 
Cyrus Daboo

---

From: Kristin Hubner <[email-masked]>
Date: Tue, 10 Aug 2004 17:27:42 -0700

> to resolve this, but that the details should be worked out on the

I also prefer (2).

> argument hasn't been given at all.

Ok, this is sounding good to me: if the latest plan is to extend 
"reject" by adding
some explicit "do-refuse-if-possible" tag and include both possible 
texts, then that
satisfies my concerns.   I was under the (clearly wrong) impression 
that the latest
plan was that just one text would suffice.

In such a case, though, it's still not clear to me why extending 
"reject" with a
"refuse-if-possible" tag and two texts is then necessarily any simpler 
than making a
new "refuse-if-possible" action with two texts.  But I don't have any 
objections to the
way that such an extended "reject" would work.

> can with _this_ text, else send an MDN with _this_ text".

Yes, I agree that that is exactly what users will tend to want.

> If specified as I suggested above, these scripts would see *NO*

Yes.

Regards,

Kristin

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 11 Aug 2004 02:31:47 +0200

> the real effectiveness of refuse.

indeed.  I claim that most spam is submitted directly to an MX
responsible for the final recipient.  the spammer software will
obviously not produce an MDN in response to the DSN.

I want to make it possible to run a user's Sieve script on the border.
this can't be guaranteed in general, but a system designer can make sure
that the MTA on the border supports the same Sieve extensions as the
MDA.
-- 
Kjetil T.

---

From: [email-masked]
Date: Tue, 10 Aug 2004 17:39:59 -0700 (PDT)

> any chance of avoiding being an accomplice in a joe-job attack.

I certainly agree that using reject to block spam or virii is inappropriate.
But this assumes that this is the only think you'd use it for. There are
other uses - not all email is spam. At least not yet...

I guess I'm slightly in favor of a new command, but only slightly.

				Ned

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 11 Aug 2004 16:30:04 -0700

I sure wish for an SMTP extension that allows for transmission of 
non-ASCII reply
text in a response. Can the scheme used to put such text in Subject 
headers be easily applied here?

Revisions:
Two texts is a necessary hack given the multiple recipient case and the 
non-ASCII text issue. Given
<action> <SMTP> <MDN>, an implementation supporting "refuse" MUST do an 
SMTP-time reject with SMTP, unless
a)a message has multiple valid recipients
or
b)MDN contains non-ASCII characters.

I am concerned that adding
c)or it is unable to do so
 is an invitation to an implementation that can't to SMTP-time refusals, 
but says (either in marketing material OR by accepting a script 
requiring it) that requires "refuse")
that it supports 'refuse'. This could be addressed by introducing the 
term <Sieve "refuse" syntax-only compatibility>.
and saying that only implementations that support SMTP-time refusals are 
to be termed "refuse"-compatible or "refuse"-supporting.

Sending MDNs where SMTP rejects can be done is simply not BCP.  
(Exception:  MDN contains a non-ASCII supported language inexpressible 
in the reject.)   I wish not to go out of my way to change the spec to 
facilitate poor policy.

On 8/10/2004 1:17 PM, Kristin Hubner sent forth electrons to convey:

>
>
> Being able to provide a reason in their "own" language (a language 
> that  needs a non-ASCII
> charset for proper representation) is very important to some users.   
> I  can hardly stress
> parameter would need to affect what sorts of characters are allowed 
> in  the reason string, or
> else (2) A "relaxed" reject action would need two parameters, one 
> being  the SMTP rejection
> To me, such approaches, complicating the reason text in a single 
> action  ("relaxed"
> reject) seems uglier than adding a new action refuse that does the 
> SMTP  rejection case and
> to be aware of the difference between SMTP rejection and MDN 
> rejection  means that
> Elvey wrote:
>>> What's the gist of the argument for the change [modify 'reject' 
>>> instead of
>>> create 'refuse']?  
>>

Small procedural note: The above question (from me) needed to be 
answered on the list.  That's how the IETF is supposed to work. I'm not 
strongly opposed to the idea, but an argument for it needed to be 
presented!  Cyrus has argued that the multiple recipient case makes it 
preferable, and at first I agreed.  But the multiple recipient case can 
be handled by a new action with two texts, as Kristin suggested.  So 
there's no argument for the change right now.

Allowing the user to specify the response code is a bad idea - 
featuritits.  It provides very little to no benefit, violates KISS, and 
introduces complications.
What if the user specifies 200 as the response code?  :) 

I want refuse to have all the features it must have, and no more.

> likewise fail. there is no implicit keep.

This is out of scope.  An extension allowing sieve scripts to run early 
in the SMTP conversation may well be a good idea, however.
Normally, Sieve should (BCP) run after the end-of-data (CRLF.CRLF) has 
been sent, but not acknowledged.

My sieve script would do all sorts of crazy things under the scheme 
suggested.   I'd probably have to very carefully debug it, e.g.  |not 
header ||:||contains ||"Subject"... would always trigger?...
|

> <snip>

It says :
...

> "Implementations SHOULD prohibit reject when used with other
> actions." However we feel that "refuse" should be permitted when
> used with other actions such as "fileinto" and "redirect". This
> could be useful for analyzing, tracking or reporting spam. Also,
> users can use tricks (such as multiple redirects back to their own
> email addresses) to get around such a prohibition anyway.)

Anyone else have feelings on this?

On 8/10/2004 4:51 PM, Cyrus Daboo sent forth electrons to convey:

> The reality is that even refuse suffers from this problem as there are 
> several cases where refuse results in a DSN joe-job (in fact I think 
> it will be the majority of cases). The only way to really address this 
> is to only allow discard.

I disagree. The draft states that
"a message has multiple valid recipients" is the ONLY case where DSN may 
be sent by Sieve. The only other issue is relays that don't themselves 
run Sieve.
Most spam (80%-90%, IIRC) is sent with one RCPT TO. Note, a refuse in an 
LMTP dialog is NOT allowed by the spec!
"This extension can be only supported by a Sieve implementation running 
in a MTA."

I'm going to be way for a couple weeks, folks. Sorry.  I hope Alexey has 
time to handle things.

Thanks for all the feedback!

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 12 Aug 2004 11:45:18 +0200

> in the SMTP conversation may well be a good idea, however.

I don't agree, since I can't think of any other actions than "refuse"
which make any sense before DATA.

> header ||:||contains ||"Subject"... would always trigger?...

I don't quite understand your example, but I don't think it is a problem
according to the set of rules I quickly outlined.  think of "stop" as
"accept", "refuse" as, well, "refuse", and every other action as "no-
op".  default behaviour (when the execution of the script reaches the
end of file) is "accept".

it may be worth noting that an MTA can compile a script into two forms,
one for running after RCPT TO, one for after DATA.  a very simple
optimisation is to transform any script which isn't using both the
"refuse" and the "envelope" extensions into simply "stop" (or "accept",
if you will).

-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Aug 2004 20:23:28 +0100

Matthew Elvey wrote:

> [...]

> special parameter flag) before? 

Yes, :copy parameter to fileinto.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 12 Aug 2004 15:26:19 -0400

Hi Matthew,

> I want refuse to have all the features it must have, and no more.

Actually we are talking about enhanced error codes here, so the user cannot 
touch the response code (i.e. it will always be a 5xx response).

If you want to really apply KISS then I would argue that the sieve script 
shouldn't even have a way to set the SMTP error text, let alone the 
response or enhanced codes. Why not leave the SMTP error message to the 
SMTP server implementation? That eliminates the need to have two text 
parameters for ascii and non-ascii - you just need the one for 'non-ascii' 
which only gets used for DSN/MDN.

I also strongly dislike the idea of changing the behaviour of the command 
based on whether non-ascii text is present in the reason string or not.

Here is my suggestion in a little bit more detail:

Relax the behaviour of the reject command to allow it to also be used for 
SMTP errors and to allow generation of DSNs in addition to MDNs as needed. 
New syntax would be:

	reject [":auto" / ":dsn" / ":mdn"] <reason: string>
	
	optional arguments:
	
	":auto" - the sieve implementation decides which of SMTP error, DSN
	or MDN is appropriate to use when the action is executed. This is
	also the default behaviour if none of the optional tags is
	specified. The 'reason' string is used in a DSN or MDN if one of
	those is generated. The 'reason' string is not used in any SMTP error.
	
	":dsn" - a DSN is always generated when the reject action is
	executed. The 'reason' string is used in the DSN.
	
	":mdn" - a MDN is always generated when the reject action is
	executed. The 'reason' string is used in the MDN.

This deals with the KISS issue and having the command do different things 
based on ascii/non-ascii in reason. A user has the option to explicitly 
require a DSN or MDN if they know they always want the reason string to get 
back to the sender, bypassing the possibility of a meaningless SMTP error.

-- 
Cyrus Daboo

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 12 Aug 2004 21:51:16 +0200

> 	executed. The 'reason' string is used in the DSN.

make it explicit and add "If a DSN can't be generated, the message is
discarded silently."
	
> 	executed. The 'reason' string is used in the MDN.

since this is the old behaviour, I think this should be the default.
-- 
Kjetil T.