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

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Nov 2008 13:36:52 +0000

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?

---

From: Aaron Stone <[email-masked]>
Date: Fri, 14 Nov 2008 06:26:15 -0800

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:
>
>> Summary: Almost ready for publication as a Proposed Standard. I  
>> have some clarity questions below, and two technical questions  
>> involving 2119 language ...
>>
>> Comments:
>>
>> Abstract
>>
>> 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.
>
>> 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
>>
>> 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.
>
>> 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.
>
>> 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.
>
>> guidance about why using 550 might not be the right thing to do  
>> ("why is this a SHOULD?").
>
> suggestions how to make this clearer? Maybe change the first  
> sentence to read:
>
> 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.
>
> While this text can be copied to the section 2.1.1, I think the  
> updated sentence above is clear enough.
>
>> 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).
>
>> 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?
>
> 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?
>
> Anyway I do agree that this sentence reads awkwardly. It is trying  
> to say 2 things:
> 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.
>

---

From: Aaron Stone <[email-masked]>
Date: Fri, 14 Nov 2008 06:27:45 -0800

My apologies for the extremely delayed reply to this review. I've at  
long last cleared enough time to get into the grist of the comments on  
this draft and prepare revision -08.

> and experience has shown this to be valuable in response to "joe- 

I find that the paragraph reads pretty well already, and prefer not to  
change it.

> in the document, maybe here.

Abstract modified:
"""
       The "ereject" action is intended to replace the "reject" action  
wherever
       possible. The "ereject" action is similar to "reject", but will  
always
       favor protocol level message rejection.
"""

> this sentence, I think it's correct.
Modified as suggested.

> mail filtering language [SIEVEBIS] does not define any reject  
Modified mostly suggested.

> in the document, maybe here.

Modified in the abstract, I think the text in the introduction is  
sufficiently clear.

> ("why is this a SHOULD?"). There's some text at the bottom of 2.5  
> about using 4XX first, but it should appear here, I think.
>

There may be reasons to use other response codes, hence the SHOULD.

> Spencer (clarity): "blowback" isn't defined (yet, at least).

The word "blowback" now has an earlier use in the document, in the  
context of "blowback spam", which I believe makes the meaning clear.

> sentence clearer? i'm not sure that "over protocol" is even required  
> - is it? if not, you could just delete the two words.

The phrase "over protocol", or some equivalent, is crucial because the  
meaning of "refuse" is not as clear as anybody has hoped. I prefer to  
leave the text as it is.

> Spencer (nit): s/to/too/ :-)

Just leaving work for the RFC Editor... ;-)

> 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? Or is this talking  
> about "silently upgrading reject actions" without making sure that  
> the other side is ereject-capable?

The script must be interpreted as written, no upgrades allowed by  
interpreters.

A user-interface might be used that generated a sieve script, however.  
Such a UI may have a section titled "Reject messages if they: [bunch  
of user check boxes...]". In such a situation, the user-interface is  
feeding a script generator. The output of that script generator in  
version 1 of the application might be "reject", and we're suggesting  
that it is acceptable and encouraged for version 2 of the app to  
generate scripts with "ereject" instead.

> ----- Original Message ----- From: "The IESG" <iesg- 
> [email-masked]>
> To: "IETF-Announce" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, July 27, 2008 7:02 AM
> Subject: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email  
> Filtering: Reject and Extended Reject Extensions) to Proposed Standard
>
>
>>
>> The IESG has received a request from the Sieve Mail Filtering  
>> Language
>> WG (sieve) to consider the following document:
>>
>> - 'Sieve Email Filtering: Reject and Extended Reject Extensions '
>>  <draft-ietf-sieve-refuse-reject-07.txt> as a Proposed Standard
>>
>> This document has a normative reference to RFC 2033 which documents  
>> LMTP,
>> Local Mail Transfor Protocol.  Support for LMTP is not required for
>> servers supporting the mechanisms in this specification.  The
>> procedure of RFC 3967 is applied in this last call to approve the
>> downward reference.
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to  
>> the
>> [email-masked] mailing lists by 2008-08-10. Exceptionally,
>> comments may be sent to [email-masked] instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-07.txt
>>
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13141&rfc_flag=0
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 14 Nov 2008 11:35:28 -0600

Hi, Aaron,

(dropping the IETF discussion list from the cc: list)

I think we're good, except on this point:

>> 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? if 
>> not, you could just delete the two words.
>

The great thing about last call review comments is that you can "do the 
right thing", but ... I may not have been clear, but what I was saying was 
that I don't know what "refuse delivery over protocol" actually refers to. 
Is this "refuse delivery over SMTP protocol"? That's all I was asking... I 
wasn't trying to talk you out of "over protocol", just being a little 
clearer what you were saying.

Do the right thing, of course. :-)

Thanks,

Spencer

---

From: Aaron Stone <[email-masked]>
Date: Fri, 14 Nov 2008 12:40:26 -0800

On Nov 14, 2008, at 9:35 AM, Spencer Dawkins wrote:

>>> Spencer (clarity): "refuse delivery over protocol" reads roughly  
>>> to  me. is there an adjective for "protocol" that might make this   
>>> required  - is it? if not, you could just delete the two words.
>>
>> The phrase "over protocol", or some equivalent, is crucial because  
>> the meaning of "refuse" is not as clear as anybody has hoped. I  
>> prefer to leave the text as it is.
>
> The great thing about last call review comments is that you can "do  
> the right thing", but ... I may not have been clear, but what I was  
> saying was that I don't know what "refuse delivery over protocol"  
> actually refers to. Is this "refuse delivery over SMTP protocol"?  
> That's all I was asking... I wasn't trying to talk you out of "over  
> protocol", just being a little clearer what you were saying.

Aha, I get what you mean now. Will update the document.

> Do the right thing, of course. :-)
Thanks :-)

Aaron

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 15 Nov 2008 09:10:55 +0100

> protocol", just being a little clearer what you were saying.

Maybe "refuse delivery within the mail transmission protocol", perhaps 
adding "(typically SMTP or LMTP)".

Arnt

---

From: Aaron Stone <[email-masked]>
Date: Mon, 17 Nov 2008 15:53:18 -0800

>   as far as the user is concerned hasn't changed.

I've rephrased it slightly, how's this:

    Implementations MUST NOT silently upgrade reject actions to
    ereject actions in a Sieve script, because this might lead to
    unpleasant changes of behavior not expected by the script owner.

    User interfaces that present a generic rejection option, and
    generate Sieve script output, MAY switch from generating reject
    to ereject actions, so long as doing so does not create a confusing
    change for the script owner.

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Nov 2008 07:03:45 -0600

>    change for the script owner.
Yes, this is fine with me.