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.
On Aug 11, 2008, at 8:36 AM, 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"."
I find that the paragraph reads pretty well already, and prefer not to
change it.
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.
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.
"""
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.
Modified as suggested.
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 ..."
Modified mostly suggested.
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.
Modified in the abstract, I think the text in the introduction is
sufficiently clear.
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?"). 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.
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).
The word "blowback" now has an earlier use in the document, in the
context of "blowback spam", which I believe makes the meaning clear.
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? 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.
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/ :-)
Just leaving work for the RFC Editor... ;-)
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? 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-
secretary(_at_)ietf(_dot_)org>
To: "IETF-Announce" <ietf-announce(_at_)ietf(_dot_)org>
Cc: <ietf-mta-filters(_at_)imc(_dot_)org>
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
ietf(_at_)ietf(_dot_)org mailing lists by 2008-08-10. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce