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).
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".
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
Alexey, who would be really happy to close this issue.
**