Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

[Aaron Stone <[e-mail]>]

Me too! :-(
I'm about to send out a pile of responses, and I've updated the draft  
to include the DISCUSS and LC wording changes suggested in September.

Document is here:
http://sodabrew.com/ietf/draft-ietf-sieve-refuse-reject-08.txt

Diffs from -07 are here:
http://sodabrew.com/ietf/draft-ietf-sieve-refuse-reject-08-from-7.diff.html

Many thanks,
Aaron

On Nov 14, 2008, at 5:36 AM, Alexey Melnikov wrote:

> Hi Spencer,
> My apologies for replying to this message so late, but I was hoping  
> that the main editor would reply first ;-).
>
> Spencer Dawkins wrote:
>
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-sieve-refuse-reject-07
>> Reviewer: Spencer Dawkins
>> Review Date: 2008-08-10
>> IETF LC End Date: 2008-08-10 (oops!)
>> IESG Telechat date: N/A
>>
>> Summary: Almost ready for publication as a Proposed Standard. I  
>> have some clarity questions below, and two technical questions  
>> involving 2119 language ...
>>
>> Comments:
>>
>> Abstract
>>
>>  This memo updates the definition of the Sieve mail filtering  
>> language
>>  "reject" extension, originally defined in RFC 3028.
>>
>>  A "Joe-job" is a spam run forged to appear as though it came from an
>>
>> Spencer (clarity): I'm OK with the use of "joe-job" (or, at a  
>> minimum, I'm OK with what you guys say it is), but there's not a  
>> clear statement in the abstract that the update to 3028 is in  
>> response to the "joe-job" practice. I'd suggest something like "...  
>> originally defined in RFC 3028, because the definition in RFC 3028  
>> did not allow messages to be refused during the STMP transaction,  
>> and experience has shown this to be valuable in response to "joe- 
>> jobs"."
>
> Sounds good to me.
>
>>  innocent party, who is then generally flooded by automated bounces,
>>  Message Disposition Notifications (MDNs), and personal messages with
>>  complaints.  The original Sieve "reject" action defined in RFC 3028
>>  required use of MDNs for rejecting messages, thus contributing to  
>> the
>>  flood of Joe-job spam to victims of Joe-jobs.
>>
>>  This memo updates the definition of the "reject" action to allow
>>  messages to be refused during the SMTP transaction, and defines the
>>  "ereject" action to require messages to be refused during the SMTP
>>  transaction, if possible.
>>
>>  The "ereject" action is intended to replace the "reject" action
>>  wherever possible.
>>
>> Spencer (clarity): a LOT later in the document, the following text  
>> appears: "The "ereject" action is similar to "reject", but will  
>> always favor protocol level message rejection". That's a really  
>> helpful summary - I'd like to see something like that much earlier  
>> in the document, maybe here.
>
> Ok.
>
>> 1.  Introduction
>>
>>  The Sieve mail filtering language [SIEVEBIS], as originally defined
>>  in RFC 3028 [SIEVE], specified that the "reject" action shall  
>> discard
>>  a message and send a Message Disposition Notification [MDN] to the
>>  envelope sender along with an explanatory message.  RFC 5228
>>  [SIEVEBIS] does not define any reject action, hence the purpose of
>>  this document.
>>
>> Spencer (clarity): hmm. I'm almost sure that "The Sieve mail  
>> filtering language [SIEVEBIS]" was NOT "originally defined in RFC  
>> 3028 [SIEVE]"... :-) If you drop the first [SIEVEBIS] reference in  
>> this sentence, I think it's correct.
>
> Good point.
>
>> Spencer (clarity): It's not particularly easy for me to understand  
>> this paragraph, given that SIEVEBIS is used as the reference for  
>> "RFC 5228" in the last sentence. I might suggest "the updated Sieve  
>> mail filtering language [SIEVEBIS] does not define any reject  
>> action ..."
>
> Ok.
>
>>  This document updates the definition of the "reject" action to  
>> permit
>>  refusal of the message during the SMTP transaction, if possible, and
>>  defines a new "ereject" action to require refusal of the message
>>  during the SMTP transaction, if possible.
>>
>> Spencer (clarity): a LOT later in the document, the following text  
>> appears: "The "ereject" action is similar to "reject", but will  
>> always favor protocol level message rejection". That's a really  
>> helpful summary - I'd like to see something like that much earlier  
>> in the document, maybe here.
>
> Ok.
>
>>  Implementations are further encouraged to use spam-detection systems
>>  to determine the level of risk associated with sending an MDN, and
>>  this document allows implementations to silently drop the MDN if the
>>  rejected message is deemed to be likely spam.
>>
>>  Further discussion highlighting the risks of generating MDNs and the
>>  benefits of protocol-level refusal can be found in [Joe-DoS].
>>
>> 2.1.1.  Rejecting a message at the SMTP/LMTP protocol level
>>
>>  Sieve implementations that are able to reject messages at the SMTP/
>>  LMTP level MUST do so and SHOULD use the 550 response code.  Note
>>
>> Spencer (technical): since rejection is a MUST, I'd expect to see  
>> guidance about why using 550 might not be the right thing to do  
>> ("why is this a SHOULD?").
>
> Actually the SHOULD refers to use of other 5XX response codes. Any  
> suggestions how to make this clearer? Maybe change the first  
> sentence to read:
>
> Sieve implementations that are able to reject messages at the SMTP/
> LMTP level MUST do so using an 4XX or 5XX response code and SHOULD  
> use the 550 response code.
>
>> There's some text at the bottom of 2.5 about using 4XX first, but  
>> it should appear here, I think.
>
> I think you are referring to the following text:
>
>  If a Sieve implementation that supports "ereject" does not wish to
>  immediately disclose the reason for rejection (for example, that it
>  detected spam), it may delay immediately sending of the 550 error
>  code by sending a 4XX error code on the first attempt to receive the
>  message.
>
> While this text can be copied to the section 2.1.1, I think the  
> updated sentence above is clear enough.
>
>>  that if a message is arriving over SMTP and has multiple recipients,
>>  some of whom have accepted the message, Section 2.1.2 defines how to
>>  reject such a message.
>>
>> 2.1.2.  Rejecting a message by sending a DSN
>>
>>  An implementation may receive a message via SMTP that has more than
>>  one RCPT TO that has been accepted by the server, and at least one
>>  but not all of them are refusing delivery (whether the refusal is
>>  caused by a Sieve "ereject" action or for some other reason).  In
>>  this case, the server MUST accept the message and generate DSNs for
>>  all recipients that are refusing it.  Note that this exception does
>>  not apply to LMTP, as LMTP is able to reject messages on a per-
>>  recipient basis.  (However, the LMTP client may then have no choice
>>  but to generate a DSN to report the error, which may result in
>>  blowback.)
>>
>> Spencer (clarity): "blowback" isn't defined (yet, at least).
>
> Ok, we will fix.
>
>> 2.2.  Action reject
>>
>>  The "reject" action cancels the implicit keep and refuses delivery  
>> of
>>  a message.  The reason string is a UTF-8 [UTF-8] string specifying
>>  the reason for refusal.  Unlike the "ereject" action described  
>> above,
>>  this action would always favor preserving the exact text of the
>>  refusal reason.  Typically the "reject" action refuses delivery of a
>>  message by sending back an MDN to the alleged sender (see
>>  Section 2.2.1).  However implementations MAY refuse delivery over
>>  protocol (as detailed in Section 2.5), if and only if all of the
>>
>> Spencer (clarity): "refuse delivery over protocol" reads roughly to  
>> me. is there an adjective for "protocol" that might make this  
>> sentence clearer? i'm not sure that "over protocol" is even  
>> required - is it?
>
> It emphasizes that this should happen during delivery, not after it  
> (as with MDN generation).
>
>> if not, you could just delete the two words.
>>
>>  following conditions are true:
>>
>>      Example:
>>              require ["reject"];
>>
>>              if size :over 100K {
>>                  reject text:
>>      Your message is to big. If you want to send me a big attachment,
>>
>> Spencer (nit): s/to/too/ :-)
>
> Thanks.
>
>> 2.3.  Silent upgrade from reject to ereject
>>
>>  Implementations MUST NOT silently upgrade reject actions to ereject
>>  actions, however user interfaces may change the specific action
>>  underlying a descriptive representation, thereby effecting a silent
>>  upgrade of sorts.
>>
>> Spencer (technical): ??? I may not understand the point here, but  
>> from the user's point of view, the requirement seems religious -  
>> protocol implementations are prohibited from silently upgrading,  
>> but user interfaces aren't, and the effect on the rejected e-mail,  
>> from the user's perspective, is the same, isn't it?
>
> It might or might not be the same from user's perspective.
> Some users only care that the message is rejected, other users care  
> that their rejection reason get sent correctly to the other end.
>
>> Or is this talking about "silently upgrading reject actions"  
>> without making sure that the other side is ereject-capable?
>
> I am not sure what do you call "the other side" in this case. Sieve  
> engine or end user who sent the message being rejected?
>
> Anyway I do agree that this sentence reads awkwardly. It is trying  
> to say 2 things:
> 1). Silently upgrading a Sieve script exposed to the user is a bad  
> thing, because it might change rejection behavior in an expected (to  
> the script owner) way.
> 2). But if the reject action is not exposed directly to the user  
> (e.g. if it is hidden behind some kind of filtering rule UI that  
> never shows Sieve script to the user, then silently upgrading might  
> be Ok.
>
> Based on this let me try to rephrase this sentence:
>
> Implementations MUST NOT silently upgrade reject actions to ereject
> actions in a Sieve script, because this might lead to unpleasant  
> change of
> behavior not expected by the owner of the Sieve script.
> However user interfaces that hide/don't present generated Sieve  
> scripts
> from the user MAY change the specific action, as long as behavior
> as far as the user is concerned hasn't changed.
>
> Is this better?
>