Hi,
I'm on vacation next week so I haven't put this document on the Aug 14
IESG telechat. The Aug 28 telechat is the next opportunity for IESG
Evaluation. That timing gives you three weeks before the first
possible decision on the document.
The WG considered your arguments in the past year, so presumably new
arguments, a fleshed-out compromise proposal, or an IETF-wide
consensus would be needed to sway or overrule the WG. I understand
the frustration of having work you initiated and contributed to taken
in a direction you do not like, but that in itself isn't an argument
against the WG's decision. I look forward to your alternative proposal.
Thanks,
Lisa
On Aug 7, 2008, at 12:09 PM, Matthew Elvey wrote:
Hello. I am the original author of this I-D.
I am strongly opposed to the document in its current form (-07).
I wrote the original draft primarily to address the backscatter
problem* from Sieve implementations that I worked with, problems the
creation of which was mandated by the original Sieve specification.
I wrote (with assistance from Alexey Melnikov) several drafts, which
effectively addressed my concerns. Versions that accomplished the
goal that motivated the whole effort were developed that were
entirely adequate for becoming an RFC-level standard, however bitrot
set in, along with an effort to simplify the base specification
which created a need for significant changes.  They also received
a stronger level of support than -07.
I will be introducing and arguing for a revision subsequent to the
current -07 draft to address the concerns I have raised on-list, and
request that the IESG not make a decision in less than a few weeks
so I have a chance to do so and receive feedback.
Recent versions have been a fundamental departure from the versions
that have Alexey and I listed as coauthors, and pervert the goal of
the standard I initiated.
I do not believe the IETF wants to be known for knowingly
exacerbating the spam problem, in particular the backscatter
problem, and I belive adoption of -07 does that by endorsing a
practice and architecture that does so, i.e. the archaic store-and-
forward, instead of the modern 'transparent SMTP proxy'**
architecture.
*http://en.wikipedia.org/wiki/Backscatter_(e-mail)
**http://en.wikipedia.org/wiki/Transparent_SMTP_proxy
On 7/27/08 8:02 AM, The IESG wrote:
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf