Subject: Finishing draft-ietf-sieve-refuse-reject-06.txt

From: Ned Freed <[email-masked]>
Date: Wed, 21 May 2008 15:00:14 -0700 (PDT)

I think the time has come to reach closure on this draft and move it forward.
I've therefore done a careful review. I think the draft is technically fine but
I do have a number of suggestions for editorial improvements. I will also
respond to the final comments Mathhew made on this back in January - I don't
believe anyone else responded to him.

The third paragraph of the abstract says:

   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.

The last sentence here isn't quite right - ereject makes it possible for
SMTP level refusal to occur but cannot guarantee it. I suggest changing
this to read:

   This memo updates the definition of the "reject" action to allow
   messages to be refused during the SMTP transaction, and defines the
   "ereject" action, which unlike "reject" requires messages be
   refused during the SMTP transaction whenever possible.

The second paragraph of the introduction has the same issue. I suggest
adding "if possible" at the end:

   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.

Section 1.1, second paragraph, last sentence:

   Implementations are advised to follow best practices and
   keep abreast of current research in these fields.

I think my implementation is pretty cool but I doubt it is capable of this.
How about "implementors" rather than "implementations"?

Section 2.1. The section on reject has an example at the end, how about having
one here? (I really want ereject to appear on a par with reject in every
way.) A simple one showing rejecting all mail from a particular address would
be good, so how about:

       require ["ereject"];

       if address "from" "[email-masked]" {
         ereject "Sorry, I no longer accept mail from this address";
       }

Section 2.1.2, first paragraph. What's here is fine, however, the text fails to
know that while per-recipient rejection after DATA is possible in LMTP it may
not help prevent blowback, because in most cases the LMTP server  is talking to
an MTA's LMTP client and that MTA has already accepted the message. It has
little choice but to turn an LMTP-level rejection into a DSN. I therefore
suggest adding an additional parenthetical note:

   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.)

Section 2.2, numbered list. The formatting here is a little unclear,
but maybe the best thing to do is leave it to the RFC Editor to
deal with.

Additionally, I don't think of messages as "containing" recipients. I therefore
suggest changing "message contains a single recipient" to "message has
a single recipient".

Section 2.2, last two paragraphs before example. This text discusses
the script generation issue and is of sufficient importance I suggest moving
it to a separate section by itself.

Finally, the [SIEVEBIS] and [VACATION] references need to be updated. Thie
[Joe-DOS] reference also looks a bit off to me.

THat's it!

And now a response to Matthew's comments.

> There is reluctance to change the current behaviour for what was
> presented as nothing more than an unwillingness to explain what we all
> agreed were net good reasons for the change to a customer!

It's customers  plural, and we're talking about organizations with millions of
users. This is a much bigger issue than you seem to think.

> The push to
> change the draft in a way that (unlike the versions I worked on - i.e.
> from pre-00 to Change log entry 07) makes it significantly fail to
> address the blowback issue that was my primary motivation for getting
> involved is not an improvement; it changes a view that had on-list
> consensus for a long time, through many revision changes.

> My last long post to the list to draw out views on this issue in order
> to move forward was answered by the blocker, Ned, IIRC.

> I just reread the "Spam blowback from Sieve implementations." thread to
> refresh my memory.

This was back in 2006, so I also went back and reread it just now.

>  I reread Ned's posts, which made it explicit that
> he had no intention of directly responding to the question I posed to
> him, but his view is clear.   Ned's answer to my question below is (an
> implicit but clear) yes:

On the contrary, what I said back them was that my objection was essentially
orthogonal to this issue. Specifically, my concern was and is that existing
useage of reject (which to the extent we use it is NOT used as a means of
dealing with spam) not be mucked with gratuitously. I never expressed or
implied any preference for how some additional action should behave or what the
requirements associated with it should be.

> > Do we want to have the spec allow implementers to not bother to
> > implement the ability to do proper smtp-time refusals, even though all
> > implementers at the meeting indicated that it was possible for the
> > implementations to be changed so that they could do so, and not doing so
> > produces and will continue to produce immense economic harm caused by
> > spam blowback?

> We've discussed the issue pretty throughly in that thread and though Ned
> and others have made notable points, we still disagree, or at least my
> opinion remains the same.  My answer, after balancing the pros and cons,
> is still no.

And so is mine - if we're talking about ereject rather than reject.

> I strongly support requiring a change to the default behaviour, and most
> certainly requiring that all implementations implement the ability to do
> proper smtp-time (or lmtp-time) protocol-level refusals (other than
> MUA-based implementations).  It's an important interoperability issue.

Yes, but the current draft already does this.

> Given the current draft, the latter requires a small change:

> To the sentence that begins:

> "The Sieve interpreter MUST carry out one of the following actions
> (listed in order from most to least preferred),"
> add something like:
> "MUST support the user's choice to carry out the most preferable action
> possible"

But the draft already says "SHOULD carry out the most preferable action". RFC
2119 SHOULD means "MUST do it unless you have a really good reason not to". And
since the possibility of multiple recipients means we cannot require SMTP level
rejection, a SHOULD is the best we can do here.

Now, this can actually be phrased using MUST by adding an additional
qualifier: "MUST carry out the most preferable action possible". I have
no problem with such a change if it makes you happier.

As for your suggested text, I confess I haven't a clue what you mean by "user's
choice" in this context, so I really cannot evaluate it.

> An alternate (perhaps clearer) way of accomplishing this would be to
> require that all (but MUA-based) implementations supporting 'reject'
> also support 'ereject': change
> "   The ereject action MUST NOT be available in environments that do not
>    support protocol level rejection, e.g. an MUA."
> to
> "   The ereject action MUST NOT be available in environments that do not
>    support protocol level rejection, e.g. an MUA, but MUST be available
>    in all other environments that support the reject action"

I would say "and MUST" instead of "but MUST", but aside from that I have no
problem with requiring implementations that can support ereject offer it as an
alternative to reject. So, if others agree, by all means add this.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 22 May 2008 17:17:13 +0200

FWIW. My silence is because I don't greatly care. I don't recall much 
about the remaining issues, but I do recall reading the thread and 
thinking that I'd be happy no matter what. So +1 on everything, 
anything, that leads to RFC publication.

Arnt

---

From: Aaron Stone <[email-masked]>
Date: Tue, 27 May 2008 21:14:29 -0700

Thank you! I took on the document at a time when I had time to work on
such things, and shortly thereafter a project at my day job expanded to
absorb all waking hours for a few months. Apologies for the delay this
caused; I look forward to finishing up the document as soon as possible.

I've adopted all of the changes suggested, albeit some with editorial
changes, with one exception:

  The Sieve interpreter MUST carry out one of the
  following actions (listed in order from most to least preferred),
  SHOULD carry out the most preferable action, and
  SHOULD fall back to lesser actions if a preferred action fails.

If we change one of those SHOULDs to MUST then I think we have to change
both. Note that it prevents people who have a good reason to take things
slightly out of order to do so and remain compliant. I am of the mind
that SHOULD makes more sense because it allows for wiggle room.

Aaron

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 May 2008 09:34:04 -0700 (PDT)

> that SHOULD makes more sense because it allows for wiggle room.

That's the issue I was getting at when I said that changing this to a MUST
requires additional qualification, e.g. add "possible" to the end so you have:

   The Sieve interpreter MUST carry out one of the
   following actions (listed in order from most to least preferred),
   MUST carry out the most preferable action possible, and
   MUST fall back to lesser actions if a preferred action fails.

You cannot say just "MUST carry out the most preferable action" because that
means you are required to carry out the first action on the list. That's
clearly nonsensical.

Again, I have no problem with making such a change if it makes people happier
but I think the text is fine as-is.

				Ned