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" "someone(_at_)example(_dot_)com" {
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