Subject: Sieve reject draft open issue: non-ascii text in reject string

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Jul 2006 20:55:30 +0100

Hi,
During the Sieve WG meeting in Montreal the group discussed handling of 
the non-ascii characters in the reject reason string, when Sieve engine 
can return reject errors over SMTP/LMTP. Several choices were suggested:

1). Strip (replace with '?' or any other ascii character) UTF-8 from string
  reason: can preserve ascii, for some multilingual strings.
2). Send DSN instead
3). Replace the reject string with an implementation defined string in 
ascii.
4). Runtime error
5). Use 2 strings, one in ASCII and one possible containing non-ascii.

Discussions on the choices lead to the following conclusions:
1). Use of 2 and 4 is highly undesirable.
2). Use of 2 strings (choice 5) is confusing to users. Besides 
implementations would need to check both strings for non-ascii text (and 
the check would have to be delayed till runtime if Sieve Variables are 
also used), which would result in one of the other choices. So the 
consensus was not to have 2 separate string.
[I would note that this choice was discussed at least once before]
3). The group spent some time discussing choices 1 and 3, which resulted 
in rough consensus to use # 3.

Does anybody have any objections to recommending # 3 in the draft?

Alexey, who would be really happy to close this issue.

**

---

From: Kristin Hubner <[email-masked]>
Date: Thu, 13 Jul 2006 14:12:16 -0700

On Jul 13, 2006, at 12:55 PM, Alexey Melnikov wrote:

>
> Hi,
> During the Sieve WG meeting in Montreal the group discussed handling 
> of the non-ascii characters in the reject reason string, when Sieve 
> engine can return reject errors over SMTP/LMTP. Several choices were 
> suggested:
>
       ^^^^^^^^       ^^^^^^^^^^^^^^^^^^^^^
I cannot agree with this.  Sometimes (at least for some of our 
customers and
their priorities, and for some of their rejection cases) sending a DSN 
_in
their own language_ will be more important than the efficiency of 
issuing the
rejection at the SMTP protocol level.

Also, it seems to me that the Introduction, attempting to justify that 
SMTP
level rejection is _always_ better than later rejection, is assuming 
that
the only use of "reject" is to reject spam.  In the case of spam, indeed
SMTP protocol level rejection is indeed greatly preferable to sending
back a DSN or MDN.  But there are other reasons for using "reject".  For
instance "your message is too big for me to accept right now; please 
send me
a URL to somewhere I can look at it instead", or "I don't want to hear 
any
more from this sender on this topic" (translated into some other 
language
and charset, since in English as shown, one could send it as an SMTP
rejection).

> implementations would need to check both strings for non-ascii text 
> (and the check would have to be delayed till runtime if Sieve 
> Variables are also used), which would result in one of the other 
> ch\oices. So the consensus was not to have 2 separate string.
> 3). The group spent some time discussing choices 1 and 3, which 
> resulted in rough consensus to use # 3.
>

Yes, I object.

Note that I would not have any objection to making # 3 the _default_ 
behavior,
as long as there is also some way in the "reject" action syntax to "opt 
out" of
the SMTP level rejection -- to say "reject with this non-ASCII text, 
even when it
means that a rejection that could otherwise have been done at the SMTP 
protocol
level instead results in a DSN or MDN".  For instance, adding something 
like an
optional :exacttext argument to "reject".

Note that on the user interface side of things (what does the user need 
to enter
to make a Sieve?), my suggestion of an "opt out of protocol level 
rejection"
argument gets one right back to the issue of users needing to care 
about whether
or not their rejection text has non-US-ASCII in it.  But it does allow 
the behavior
you're proposing to be the default, with only those who really care 
about their
exact text needing to bother with doing anything more.

Regards,

Kristin

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 15 Jul 2006 02:46:15 +0100

Kristin Hubner wrote:

>> 3). Replace the reject string with an implementation defined string 
>> in ascii.
>> 4). Runtime error
> level rejection is _always_ better than later rejection, is assuming that
> more from this sender on this topic" (translated into some other language

Right. The text in the Introduction section need to be updated.

> as long as there is also some way in the "reject" action syntax to 
> "opt out" of
> level instead results in a DSN or MDN".  For instance, adding 
> something like an

I am personally fine with this.

So here is the updated proposal:

1). Make 3) the default when no tagged parameter to the reject action is 
specified.
2). Add :exacttext that will make the implementation return DSN instead 
of protocol level refusal. This will be controlled by another Sieve 
capability.
An administrator can choose to disable support for this capability [The 
last sentence is an operational issue, so maybe it doesn't belong to the 
document.]

Comments?

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 15 Jul 2006 15:07:17 +0100

Alexey Melnikov wrote:

> 1). Make 3) the default when no tagged parameter to the reject action 
> is specified.
> 2). Add :exacttext that will make the implementation return DSN 
> instead of protocol level refusal. This will be controlled by another 
> Sieve capability.
> An administrator can choose to disable support for this capability 
> [The last sentence is an operational issue, so maybe it doesn't belong 
> to the document.]

This proposal assumes that a reject* *without :exacttext will always 
replace non-ascii text with an implementation defined ascii string, so 
it would never be a noop.

An alternative would be to change the bare reject to become "reject with 
non-ascii over protocol if you can, but do nothing if you can't" and add 
:stop as discussed in Kjetil/Mark's proposal.