ietf-mta-filters
[Top] [All Lists]

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

2008-11-14 09:34:50

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?


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard, Aaron Stone <=