Hi Matthew,
--On September 10, 2008 3:13:33 PM -0700 Matthew Elvey
<matthew(_at_)elvey(_dot_)com>
wrote:
Lisa D reported being told: "There is strong WG consensus behind [-07]".
Lisa D specifically claimed the WG chairs indicated there was. CHAIRS:
Can you each please confirm that you stated that there is strong WG
consensus behind [-07]?
Yes, I can confirm that and firmly believe that the overall consensus of
the WG is to publish the -07 draft. I don't believe there is a need to
re-poll the WG on this, but if the IESG would be more comfortable doing so
given your comments I am happy to do so. Also, if other WG participants
wish to speak up in support of one position or another right now, they are
certainly free to do so.
The history of this effort is quite clear in my opinion. The WG decided to
enhance the existing 3028 reject command to allow use of "reject" behavior
at SMTP/LMTP protocol time. At the moment I believe your main point is that
you want the spec to mandate that ereject MUST only result in SMTP/LTMP
protocol rejection and indeed that all implementations must support
protocol level rejection. On the several occasions you have brought this
issue to the WG mailing list it has been explained in detail that there are
plenty of key use cases where only doing SMTP protocol rejection is not
possible (e.g. in the very common case where there are multiple recipients
of the message and one recipient's script erejects, whilst another does
not).
I think the current wording in the -07 spec is perfectly clear that
implementations must make every effort to do protocol level rejection
whenever possible. For example, the first section of 2.1.1 states:
Sieve implementations that are able to reject messages at the SMTP/
LMTP level MUST do so and SHOULD use the 550 response code.
Also, section 2.1 states:
The ereject action MUST NOT be available in environments that do not
support protocol level rejection
I think those are pretty strong statements about the use of ereject and
protocol level rejections. I don't see why or how these need to be changed.
Unfortunately, claiming that the current specification results in a
"spam-friendly RFC" is going to anger a lot of people who have spent a lot
of time trying to address spam issues as best as possible. It totally
misrepresents the efforts of the SIEVE WG. I realize, Matthew, that you
have very strong opinions on this, but I fear such comments are not going
to result in forward progress.
If you feel that the IETF needs to publish a document stating that all
email systems MUST support protocol level rejections (which I think is what
you want to require of all implementors), then I suggest that you publish a
new I-D to do just that and garner support for moving that forward in the
IETF. At this point I consider WG consensus to be for publishing -07 -
albeit with the various comments from IETF last call appropriately
addressed by the authors.
--
Cyrus Daboo
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf