Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt

[Matthew Elvey <[e-mail]>]

FYI: Alexey and I are discussing the hurdles to merging refuse and 
reject and other options and will post about this anon.

On 8/19/05 3:44 AM, Alexey Melnikov sent forth electrons to convey:
>
> Mark E. Mallett wrote:
> .......
>> So it's really "when more than one RCPT TO has been
>> accepted" instead of "when a message has multiple valid recipients."
>> (picky, I know.)
>>  
>>
> That is exactly what Matthew and I were trying to say, but your 
> suggested text is much clearer. Thanks.
Right.
>
>>> 4.2  "reject" compatibility with other actions
>>>   
>>>   Implementations MUST prohibit more than one reject in a SIEVE
>>>   script.
>>>   
>>
>> must prohibit "the execution of..."  (certainly more than one reject can
>> appear in a script).
>>  
>>
> Yes. Fixed.
:)
>
>>> 5.1  Action refuse
>>>   
>>>   The "refuse" action refuses delivery of a message by sending back
>>>   the 550 SMTP response code to an SMTP client.
>>>
>>>   This extension can be only supported by a Sieve implementation
>>>   running in an MTA.
>>>   
>>   The way this is worded, an implementation that communicates with an 
>> MTA
>> via LMTP (or any other protocol or mechanism, for that matter) is
>> prohibited from using "refuse."  There are multiple ways that an MDA may
>> be invoked by an MTA during the SMTP dialog, where refusal can be
>> communicated back to the SMTP client.  The MTA itself isn't necessarily
>> (and probably isn't likely to be) running the Sieve script itself.
>>  
>>
> The current copy we are editing says "running in an MTA or MDA". Does 
> this address your concern?
> The intent was certainly to allow for MDA.
>
> Regarding MTA/MDA executing Sieve directly versa an external process 
> MTA/MDA is talking to: I certainly would want to allow for both, as 
> this is an implementation detail. So do you think "running in an MTA 
> or MDA" can be interpreted to mean that an external process is not 
> allowed?
> How should we make the clear?
I think we may need to refer to the fact that what we're concerned about 
is that if there's an SMTP connection over the open Internet, it is the 
one where we require the rejection to take place.  I'm not sure how to 
word that. Maybe that's the right wording to use. Maybe
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt has 
better terms for this.  It's an SMTP connection between Edge MTAs of 
different AUs?   Perhaps Dave Crocker would provide advice on good 
wording, using his draft.
>
>> And actually I am not sure that LMTP needs to be mentioned in the
>> document at all, other than as an example of one of the ways that an MTA
>> and an MDA might communicate during the SMTP dialog.  The important 
>> thing
>> is that the Sieve script is being run at SMTP time and its results are
>> somehow used by the MTA to respond to the SMTP client.
>>  
>>
> I actually disagree. The sieve engine I am working on runs in LMTP 
> server, it is the one that has to implement refuse.
>
>>    This extension can only be supported by a Sieve implementation
>>    that is invoked on behalf of the MTA during SMTP time, and that
>>    can communicate its results to the MTA which can then return a
>>    status to the SMTP client.
Getting there.
How' bout
  This extension can only be supported by a Sieve implementation
   that is invoked on behalf of the MTA during SMTP time, and that
   can communicate its results to the MTA which can then return a
   status to the SMTP client on the other side of every SMTP connection 
over the open Internet over which mail is received.


"on the other side of every SMTP connection over the open Internet" is 
intended to make clear that the 550 goes to the generally distant, 
untrusted client.

 "over which mail is received." is there just so that we aren't 
inadvertently disallowing the blocking of  connections (e.g. from known 
bad actors) before Sieve sees them.
>>
>> Another somewhat thorny point is that a Sieve script may be invoked at
>> the time when the SMTP server sees the "RCPT TO" so that the refusal may
>> be communicated to the SMTP client at that time (before DATA).  At this
>> stage, various Sieve facilities (e.g. header tests, fileinto, keep) are
>> not available.  I don't know whether this has to be mentioned in this
>> draft, but once you have "refuse" capability, this does come into play.
>>  
>>
> Running Sieve scripts before message headers/body are available is 
> certainly possible and not prohibited by the draft.
> However I think this is somewhat outside the scope for the document, 
> as this is effectively a different Sieve profile.
>
>>
>>  <snip>
>>
> Both fixed, thanks.
>
Yeah, thanks.  :)