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
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.
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.
On 8/10/2004 4:30 PM, Kjetil Torgrim Homme sent forth electrons to convey:
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 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>
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.
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!