Subject: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt

From: Cyrus Daboo <[email-masked]>
Date: Tue, 16 Aug 2005 17:31:11 -0400

Hi folks,
I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-00.txt>

A two week working group last call of this document starts today on August 
16th 2005 and ends on Tuesday, August 30th 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, please 
send both co-chairs (or the list) an email to indicate you have looked at 
it. This will allow the chairs to gauge the scope of reviews of this 
document to aid in our determination on whether to send it to the IESG. 
Thanks.

--
Cyrus Daboo
SIEVE WG Co-chair

---

From: Michael Haardt <[email-masked]>
Date: Thu, 18 Aug 2005 15:19:21 +0200

Section 4.1:

  Syntax:   reject <reason: string>
  ^^^^^^ Usage

The example uses a string that spans multiple lines.  I don't know if
that is intentional, as the output would be different.  How about using
text:?

Section 5.1:

   If the "reason" string is multiline, than the reason text MUST be
   returned as a multiline SMTP/LMTP response, per [SMTP], section
   4.2.1.

What should happen for plain old SMTP sessions?

      require ["refuse", "spamtest"]

I miss "comparator-i;ascii-numeric".

Section 5.2:

   If a script attempts to "refuse" the same message more than once,
   the implementation may ignore the later attempts or consider it 
   an error."
            ^ extra double quotes

Section 5.3:

   implementation, the example in section 4.1 would show up in SMTP
                                          ^^^ section 5.1 instead?

But that are just minor points; all in all the draft is fine with me.

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Aug 2005 14:51:18 +0100

>  Syntax:   reject <reason: string>
Done, thanks.

>that is intentional, as the output would be different.  How about using
Good point, fixed.

>What should happen for plain old SMTP sessions?
I am not sure I understand the question.

>I miss "comparator-i;ascii-numeric".
Fixed, thanks.

>   the implementation may ignore the later attempts or consider it 
Yes, already fixed in our current version.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 18 Aug 2005 15:09:29 -0400

> 3.   Discussion of finer points
>    
>    The "refuse" action MUST refuse to accept an email for delivery at
>    the SMTP/LMTP level by returning a 5XX reply code, instead of
>    sending an MDN as required by the "reject" action, other than for
>    the two exceptions specified below.  A SIEVE implementation that
>    cannot do so MUST NOT claim to support the refuse extension.
   
This means that scripts have to be written with awareness of the site's
email delivery architecture, and if that architecture changes, all
scripts have to change.  I think this is a big burden on both script
writers and site admins.  Even if approach is to have separate "reject"
and "refuse" verbs, I'd like to see some way of avoiding this burden.

>    There is an exception when a message has multiple valid recipients,
>    and at least one but not all of them are refusing delivery (whether
>    the refusal is caused by execution of a Sieve "refuse" or for
>    another reason). In this case, the server MUST accept the message
>    and generate DSNs for all recipients that are refusing it.

I get what this is saying, but I don't think this is said exactly right.
An SMTP server can issue 4xx deferal codes for some of the valid
recipients.  This can be done for various reasons, e.g. if some of the
valid recipients are over quota, or if the SMTP server is using a trick
to allow it to do post-DATA rejection by only focusing on one recipient
at a time (I don't know if anybody actually does this, but I've heard it
proposed..).  So it's really "when more than one RCPT TO has been
accepted" instead of "when a message has multiple valid recipients."
(picky, I know.)

> 4.2  "reject" compatibility with other actions

>    Implementations MUST prohibit more than one reject in a SIEVE
>    script.

must prohibit "the execution of..."  (certainly more than one reject can
appear in a script).

> 5.1  Action refuse

>    The "refuse" action refuses delivery of a message by sending back
>    the 550 SMTP response code to an SMTP client.
> 
>    This extension can be only supported by a Sieve implementation
>    running in an MTA.
   
The way this is worded, an implementation that communicates with an MTA
via LMTP (or any other protocol or mechanism, for that matter) is
prohibited from using "refuse."  There are multiple ways that an MDA may
be invoked by an MTA during the SMTP dialog, where refusal can be
communicated back to the SMTP client.  The MTA itself isn't necessarily
(and probably isn't likely to be) running the Sieve script itself.

And actually I am not sure that LMTP needs to be mentioned in the
document at all, other than as an example of one of the ways that an MTA
and an MDA might communicate during the SMTP dialog.  The important thing
is that the Sieve script is being run at SMTP time and its results are
somehow used by the MTA to respond to the SMTP client.

    This extension can only be supported by a Sieve implementation
    that is invoked on behalf of the MTA during SMTP time, and that
    can communicate its results to the MTA which can then return a
    status to the SMTP client.

Another somewhat thorny point is that a Sieve script may be invoked at
the time when the SMTP server sees the "RCPT TO" so that the refusal may
be communicated to the SMTP client at that time (before DATA).  At this
stage, various Sieve facilities (e.g. header tests, fileinto, keep) are
not available.  I don't know whether this has to be mentioned in this
draft, but once you have "refuse" capability, this does come into play.

>       Example:

the missing comparator was already mentioned, but it also needs
"fileinto" for the elsif to work.

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

add "}" here.

>       elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" {
>                    fileinto "Suspect";
>                   }

Yours,
-mm-

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 18 Aug 2005 15:06:36 -0400

I guess I am going to open this can of worms..

When the "refuse" extension was last discussed at length on this list,
it ended with talk about the interaction between reject and refuse,
whether the script writer really ought to care about the actual refusal
mechanism, and how to fall over between the two verbs (or even whether
two verbs was a good idea).  I thought that the concensus was that some
sort of unified action (where the user didn't really have to know
whether a notice was given at SMTP time or post-SMTP time) would be
best.  I may be looking back at that dialog with blinders on, but quotes
in the archive are pretty direct.

Anyway: my preference would be for a "reject" action by which the script
writer specifies that the message is not wanted, without having to know
which of two verbs to use.  This action would cause a reject/refusal at
the earliest possible point; it would have a default fallback behavior
that would happen if that point was not SMTP-time, and this behavior
could be overriden via some extended syntax (either a tagged option or a
code block).

The benefits of a unified approach:

 - existing scripts using "reject" would inherit SMTP-time refusal as
   soon as it was made available in the environment;

 - scripts would continue to work if the site's mail system
   architecture changes;

 - most users would not have to know or care that there were two kinds
   of refusal/rejection; they would know that their script would do
   the best thing supported by the implementation;

 - the whole thing about "this might not work if multiple recipients
   are given" wouldn't be important to the script writer.

Basically:

   reject [:discard/:keep/:notify] "reason";

where with no tagged argument, 5xx at SMTP time is done if possible, and
if not possible, a site-imposed default action would be taken (which
might be either "discard" or "keep" or "send a notification").  The
tagged argument, if given, would override the site-imposed default.
There would also be a section in the RFC directing implementors to
attempt to detect and inhibit notifications to probable forged
addresses.  One could get more elaborate, naturally, e.g. by being able
to specify the extended SMTP result code (as discussed on the list) or
by having a fallback option be "fileinto" .

Drawbacks of a unified approach that I can think of:

 - Any new syntax would have to be enabled via a new capability.  Here,
   I would say that ' require "refuse"; ' would enable the new syntax,
   but the new behavior (i.e., of attempting to turn away the message at
   SMTP time, with site-specific fallback action) would not require the
   new capability.  The new behavior would simply be specified in this
   draft.

 - If a Sieve script is invoked when "RCPT TO" is seen, various other
   Sieve facilities are not available (header tests, fileinto, etc).
   There may be a need for the script writer to be aware of this.  But I
   think that can be solved in ways outside the script itself, and this
   problem is also present in the other approach as well.

In the event that I am just whistling in the wind here, I also have
comments on the actual draft... see next rock.

mm

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 19 Aug 2005 02:16:33 +0200

On Thu, 2005-08-18 at 15:06 -0400, Mark E. Mallett wrote:
> might be either "discard" or "keep" or "send a notification").

I would prefer an option to make reject "stop" if successful, so you
could simply do:

   reject :refuse :stop "Don't send e-mail to this address";
   fileinto "INBOX.old-address";
   stop;

seems easier than to add all possible actions as options to reject :-).
clearly this requires a small change to the following text:

   Implementations SHOULD prohibit reject when used with other
   actions.

a reject without :refuse would always be successful, since it does best
effort: SMTP time or send bounce message.

we might not need a :stop, we could make :refuse work that way always,
but I think it is better to be explicit about it.

>    new capability.  The new behavior would simply be specified in this

right.  I don't see how this is a drawback?  a capability which implies
another would be a first for Sieve, but I think it is a natural thing to
do.

>    problem is also present in the other approach as well.

this problem isn't specific to the unified approach.

> comments on the actual draft... see next rock.

well, I agree with your views, at least.
-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 19 Aug 2005 11:44:39 +0100

>accepted" instead of "when a message has multiple valid recipients."
That is exactly what Matthew and I were trying to say, but your 
suggested text is much clearer. Thanks.

>must prohibit "the execution of..."  (certainly more than one reject can
Yes. Fixed.

>(and probably isn't likely to be) running the Sieve script itself.
The current copy we are editing says "running in an MTA or MDA". Does 
this address your concern?
The intent was certainly to allow for MDA.

Regarding MTA/MDA executing Sieve directly versa an external process 
MTA/MDA is talking to: I certainly would want to allow for both, as this 
is an implementation detail. So do you think "running in an MTA or MDA" 
can be interpreted to mean that an external process is not allowed?
How should we make the clear?

>somehow used by the MTA to respond to the SMTP client.
I actually disagree. The sieve engine I am working on runs in LMTP 
server, it is the one that has to implement refuse.

>draft, but once you have "refuse" capability, this does come into play.
Running Sieve scripts before message headers/body are available is 
certainly possible and not prohibited by the draft.
However I think this is somewhat outside the scope for the document, as 
this is effectively a different Sieve profile.

>>   Please call 1-900-PAY-US if you want to reach us.
Both fixed, thanks.

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 19 Aug 2005 09:09:21 -0700

FYI: Alexey and I are discussing the hurdles to merging refuse and 
reject and other options and will post about this anon.

On 8/19/05 3:44 AM, Alexey Melnikov sent forth electrons to convey:
>
> Mark E. Mallett wrote:
> .......
>> So it's really "when more than one RCPT TO has been
Right.
>> must prohibit "the execution of..."  (certainly more than one reject can
:)
> MTA/MDA is talking to: I certainly would want to allow for both, as 
> this is an implementation detail. So do you think "running in an MTA 
> or MDA" can be interpreted to mean that an external process is not 
> allowed?
I think we may need to refer to the fact that what we're concerned about 
is that if there's an SMTP connection over the open Internet, it is the 
one where we require the rejection to take place.  I'm not sure how to 
word that. Maybe that's the right wording to use. Maybe
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt has 
better terms for this.  It's an SMTP connection between Edge MTAs of 
different AUs?   Perhaps Dave Crocker would provide advice on good 
wording, using his draft.
>>    status to the SMTP client.
Getting there.
How' bout
  This extension can only be supported by a Sieve implementation
   that is invoked on behalf of the MTA during SMTP time, and that
   can communicate its results to the MTA which can then return a
   status to the SMTP client on the other side of every SMTP connection 
over the open Internet over which mail is received.

"on the other side of every SMTP connection over the open Internet" is 
intended to make clear that the 550 goes to the generally distant, 
untrusted client.

 "over which mail is received." is there just so that we aren't 
inadvertently disallowing the blocking of  connections (e.g. from known 
bad actors) before Sieve sees them.
> However I think this is somewhat outside the scope for the document, 
> as this is effectively a different Sieve profile.
>
>>
>>  <snip>
>>
> Both fixed, thanks.
>
Yeah, thanks.  :)

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 19 Aug 2005 13:48:03 -0400

> this address your concern?

I think it's too specific; as Matthew said in another note, the
important point is that it's running on behalf of an MTA, or via some
mechanism under which the response is communicated to the SMTP client at
SMTP time.  You don't have to list the ways that this can be done, other
than providing some examples.  An MDA is one example, but it doesn't
have to be the only one.

> server, it is the one that has to implement refuse.

Well I agree with you, so I must have been unclear :-)
It's the same sort of thing as my comment above, about the difference
between mandating one or more implementations or protocols (e.g. LMTP),
vs giving those protocols as examples.  It's the difference between
saying "MUST use LMTP or be implemented in the MTA" and "may, for
example, use LMTP or may, for example, be implemented in the MTA."

mm

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 19 Aug 2005 14:13:41 -0400

On Fri, Aug 19, 2005 at 09:09:21AM -0700, Matthew Elvey wrote:
> one where we require the rejection to take place.

   ...

> intended to make clear that the 550 goes to the generally distant, 

I snipped a bunch, hope that's OK, because I only wanted to remark on
the "over the open internet" part.  I don't think it's important what
the medium/network/what-have-you is, it's important that the result be
given to the originating client, probably via SMTP.  I'd even go so far
as to say that "refuse" should apply to any protocol where messages are
transported, and that SMTP is being used in the document as an example
protocol, even though it's the example that applies to the vast majority
of probable implementations.  But perhaps you can only carry
non-specificness so far.

mm

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 19 Aug 2005 14:18:11 -0700

On 8/19/05 11:13 AM, Mark E. Mallett sent forth electrons to convey:
> the "over the open internet" part.  
Me too. :)

See txt pic below (view in a fixed-width font)

Example: If the destination AU (using 
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt 
terminology; AU=Administrative Unit)
is bigcompany.dom, and Relay2 is some MTA that just relays mail, and is 
under the control of the destination AU, then if a Sieve script running 
on Dest  encounters a 'refuse', and sends a 550 to Relay 2, if Relay 2 
then generates a bounce, instead of sending a 550 to MSA, then Dest MUST 
NOT be considered compliant with 'refuse'. 

   +------------+                                    +-----------+
   | Originator |                                    | Recipient |
   +-----+------+                                    +-----------+
         |                                                 ^
         |                    Internet                     |
         |                    ___^___                      |
         V                   /       \                     |
     +---------+    +--------+       +---------+      +----+----+
     |         |    |        |       |         |      |         |
     | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
     |         |    |        |       |         |      |         |
     +----+----+    +--------+       +---------+      +---------+

                                 \_________Destination_AU__________/

Further example: If Dest was once reachable directly from the Internet 
and supported 'refuse', and was then protected by Relay2 then (depending 
on Relay2's abilities) Dest might no longer support 'refuse', through no 
fault of the coder of the software on Dest.  It would be the AU 
administrator's responsibility to support 'refuse', or stop claiming to 
support it.

BTW, fastmail handles *outgoing* mail like this - synchronously: If I 
try to send to [email-masked], I an error  message pops up in my 
mail client (Thunderbird). (I've attached a .png screen shot, which may 
well not make it through to your screen.)  (This is far superior to 
getting a message in my inbox from the postmaster/mailer-daemon.)

 error msg

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sat, 20 Aug 2005 04:46:34 +0200

On Fri, 2005-08-19 at 14:13 -0400, Mark E. Mallett wrote:
> given to the originating client, probably via SMTP.

right.  the key is that you decline a message which is sent from a
different administrative domain.  it doesn't matter what how many hops
and database checks your local system performs.  a "refuse" MUST be able
to tell the other administrative domain that the message was rejected
without instantiating the sending of a new message.
-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 21 Aug 2005 15:54:35 +0100

>than providing some examples.  An MDA is one example, but it doesn't
So, possible solutions to address this issue:
1). delete the sentence.
2). reword to be less prescriptive.

Which one do you prefer?

>Well I agree with you, so I must have been unclear :-)
Yes, I've misunderstood you.

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 22 Aug 2005 12:41:05 -0700

On 8/21/05 7:54 AM, Alexey Melnikov sent forth electrons to convey:
>>> Draft:
Let's reword/replace using the 'key' Kjetil suggested thus:
> different administrative domain.  [...] a "refuse" MUST be able
How's this replacement?

(The first sentence is unchanged.)

the 550 SMTP response code to an SMTP client. This extension can be 
supported only by a Sieve implementation capable of sending the 550 over 
an SMTP connection between Administrative Units.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 23 Aug 2005 14:08:17 -0400

> an SMTP connection between Administrative Units.

Well, I'm probably being anal (again).  To me, the use of "between
Administrative Units" and "over the open Internet" are birds of a
feather.  I don't think it's important to specify where the message is
transported, or between whom-- only that the message is turned away by
the receiver during transport, thus avoiding a later asynchronous
notification via a separate email message.  e.g. I think refusal should
apply to a transmission to the SMTP server running on localhost.

mm

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 23 Aug 2005 20:56:57 +0200

On Tue, 2005-08-23 at 14:08 -0400, Mark E. Mallett wrote:
> feather.

the current draft doesn't say "over the open Internet", so I don't see
how this is relevant?

"Administrative Units" would have to be defined, though.

> I don't think it's important to specify where the message is

is an e-mail system which accepts all e-mail but sticks it in a
directory where it is subsequently picked up by a spam classifier, which
in turn resubmits the message via SMTP on localhost where the Sieve
script is run (*deep breath*) allowed to offer "refuse"?  I'd say no,
since the 550 will not be able to reach the previous e-mail system.

an MTA which doesn't double as a MDA will have to use a callout to the
next hop in the system and wait for its response before passing the
answer back to the other e-mail system.  (a system which does queueing
in some circumstances is fine, but queueing shouldn't be normal
behaviour.)
-- 
Kjetil T.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 23 Aug 2005 15:02:57 -0400

> the current draft doesn't say "over the open Internet", so I don't see

It's relevant because I thought the use of "administrative unit" was
a suggested replacement for "over the open internet" elsewhere in
this thread.  Did I misunderstand?

mm

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 23 Aug 2005 12:21:39 -0700

> apply to a transmission to the SMTP server running on localhost.
No, that doesn't address my concern from a previous email:

On 8/19/05 2:18 PM, Matthew Elvey sent forth electrons to convey:
> ...[If] a Sieve script running on Dest  encounters a 'refuse', and 
> sends a 550 to Relay 2, if Relay 2 then generates a bounce, instead of 
> sending a 550 to MSA, then Dest MUST NOT be considered compliant with 
> 'refuse'. 
That's why we need something like "between Administrative Units" of 
"over the open Internet".

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 23 Aug 2005 16:01:09 -0400

> "over the open Internet".

Yeah, I'd been kind of stewing on that for a while :-)

I think there's some schizophrenia in this discussion as relates to
refuse compliance.  There's one view of compliance that you get when you
focus on any given piece, and another when you combine that piece with
other pieces into a system.  To me, the idea is to make the pieces
compliant, and build compliant systems out of it.  Thus the spec should
say how to make compliant pieces, probably with a discussion about how the
pieces fit into the overall mail system.

If a Sieve implementation exists only in a tool that implements LMTP,
and it does indeed generate a 5xx LMTP response from a refuse verb, then
that specific tool could be viewed as refuse-compliant.  If that tool is
being called by some other program that delivers messages that are
already queued (as LMTP is described in rfc2033 as doing), then that
queue-running tool will probably generate a bounce response, and you
then have system that doesn't implement refuse correctly even if though
the Sieve implementation does.

On the other hand if the LMTP tool is being called by an MTA that's
engaged in an SMTP dialog, and the LMTP's 5xx response results in a
synchronous 5xx SMTP response by the MTA, then the system that combines
the MTA and LMTP tool is refuse-compliant.  However if then that MTA is
part of a larger email system that doesn't convey that result
synchronously, that larger system is no longer compliant with refuse.

Now: is the Sieve implementation correct, even though bounce messages
are generated?  I say yes it is, because it is correctly conveying the
result of the "refuse" action.  The spec should be about correct Sieve
implementations regardless of their place in the architecture.

This is at least one of the things that I am getting at when I say that
focusing on LMTP or SMTP or "over the internet" are all too specific.
It's not important that an implemenation uses LMTP or SMTP to give a 5xx
result, or uses a command line interface and exit with a status code
that indicates refusal, or anything else.  It's important only that that
specific implementation (no matter where or what it is) implement and
report refuse in some way.  That implementation can then be used as part
of some larger system implementation which then has a chance of itself
implementing refuse correctly.  And so on.

IMHO, as always.

mm

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 23 Aug 2005 13:40:22 -0700

Misleading the user into thinking that he's reducing bounces is 
unacceptable.  I am extremely firmly opposed to any changes that allow 
refuse and reject to have the exact same results from the users/victim's 
viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
system is compliant when just a piece theoretically could be, but when 
in actual use, the system isn't compliant makes no sense.  It seems 
we'll have to go for rough consensus, noting this as a point of 
disagreement. 
Consider: You can't deduce that 'a boa constrictor is harmless' from the 
fact that 'a dead boa constrictor is harmless'.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 24 Aug 2005 01:36:36 +0200

> implementations regardless of their place in the architecture.

I think you are right.  Sieve compliance and overall system architecture
requirements are separate things.  I think both should be addressed in
the spec, though.

the document could benefit from some editorial reorganisation.  in
particular I don't think it flows well to have this TOC:

  1. Introduction                                                   4
  2. Conventions Used in this Document                              4
  3. Discussion of finer points                                     4
  4. SIEVE "reject" extension                                       5
  5. SIEVE "refuse" extension                                       6
  6. Security Considerations                                        8

in my opinion, section 3 should be renamed ("Server architecture
requirements", perhaps) and made a subsection of section 5.

(sorry for not bringing this up before.)
-- 
Kjetil T.

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 23 Aug 2005 17:40:27 -0700

(Mark, have I convinced you? It wasn't clear from your last email.)

On 8/23/05 4:36 PM, Kjetil Torgrim Homme sent forth electrons to convey:
> the document could benefit from some editorial reorganisation. 
> ...
>
Yup.  Holdover from when there was one action defined.  But let's 
finalize whether we're merging the two actions first...

> reject and other options and will post about this anon. 
My feelings: I kind of like this proposal (at least the one-action 
part), but IIRC, we had run into an issue where some folks demanded to 
be able to send (non ASCII) text that would only fit in an MDN or DSN, 
it wouldn't fit in an SMTP response code.    So how can we have one 
action w/o brushing this issue under the rug? 

Idea: We can say that a bounce is sent instead of a 550 if the 
characters specified in the reason string aren't compatible with the 
character set permitted in an SMTP response.  We can be baroque and add 
another option, but I'd REALLY like to keep the thing as simple as possible.
Good idea?

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 24 Aug 2005 03:19:49 +0200

> we'll have to go for rough consensus, noting this as a point of 

I don't think we disagree much, really.

A) a Sieve implementation offering "refuse" is compliant if it is able
to reject the message during the submission attempt.

B) the e-mail system which the Sieve implementation is part of, is only
compliant if the same is true for the submission attempt coming from the
remote system.

it should be possible to evaluate a Sieve implementation's compliance to
the specification on its own.  e.g., Cyrus-IMAPD may be compliant even
if it is impossible to make a compliant system with AcmeMTA and
Cyrus-IMAPD together.  this implies that an implementation of the
"refuse" specification MUST allow the administrator to disable the
extension manually.

> finalize whether we're merging the two actions first..

ah, good.

> another option, but I'd REALLY like to keep the thing as simple as possible.

when combined with "variables", non-ASCII characters from the message
can be captured and included in the reject message.  since this would
happen during runtime, we can't make it fail too badly.  I think we have
only two options:  turn the reject action into a no-op, or send a DSN.
I prefer the no-op option, with the addition that an implementation
SHOULD reject uploaded scripts which employs the "refuse" extension and
contain verbatim non-ASCII characters in the rejection text.
-- 
Kjetil T.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 25 Aug 2005 15:27:01 -0400

> (Mark, have I convinced you? It wasn't clear from your last email.)

Not really.  I understand your point of view, though, and agree that
refusal is a good goal, but with a different outlook on the specifics of
getting there.

Anyway, nothing new for me to add.. 

mm