Kristin Hubner wrote:
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:
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.
^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
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).
Right. The text in the Introduction section need to be updated.
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
ch\oices. 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?
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".
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