Re: draft-elvey-refuse-sieve-02.txt (multi-reply)

[Matthew Elvey <[e-mail]>]

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!