On Aug 13, 2008, at 11:16 PM, Matthew Elvey wrote:
Hi.
I have a court-imposed filing deadline to meet of Aug 31 (See www.caringaboutsecurity.wordpress.com
and/or www.elvey.com/spam/70-ORDER-GrantingElveyLeaveToFileMemorandumExplainingObjections.pdf
- it's apropos my representation of 6 million TD Ameritrade
customers in an Identity Theft Class Action lawsuit) and am working
and going camping this month as well, so I anticipate being unable
to respond this month. If you would wait 'till the first September
telechat, please. Will you do that?
I can do that.
I will state that I don't believe your characterization of the WG
view is accurate, or appropriate. There was WG rough consensus
earlier versions of the draft which, unlike the current one, would
not knowingly exacerbate the spam problem. There was not much
evidence of either broad support for or opposition to the current
draft in the WG. Who do you count as having expressed being in
consensus.
I asked the WG chairs. If you question their evaluation, the
appropriate thing for the chairs to do is to make an explicit call for
consensus (they are following this discussion of course). The
appropriate thing for you to do, independent of what the chairs do, is
make your case and ask people to speak up to agree with you. More on
making that case below...
*ECONOMICS*
There's a strong economic incentive for those behind implementations
that would require a lot of work to fix to make a concerted effort
to actively support weakening the standard. The economic costs due
to the blowback are very diffuse - spread out over most of the
Internet-using population, in contrast to the concentrated, but IMO
relatively small cost of fixing the archaic implementations... I'm
all for considering economic efficiency, but both sides need to be
weighed and weighed fairly
Can you make or point to arguments (perhaps you've posted them to the
SIEVE list already) about why the changes "weaken the standard"?
Another point that needs a little more explanation is why the original
design would be more expensive to implement than the current
requirements, although implementation costs aren't always the same
across implementations anyway. Then we might be able to get to the
economic arguments. At this point your economic arguments are
impugning the motives of strawman opponents rather than addressing the
fitness of the proposed RFC.
You do/did do work for Sun, right? Seems like there's the
appearance of a conflict of interest to me. Note: I'm not accusing
you of anything; I'm just saying that there seems to be a conflict
of interest, and you did request the Last Call and characterize the
WG views.
I do not and have not worked for Sun. I requested the Last Call in
order to get input about the fitness of this document as a proposed
RFC, which is standard practice, as I'm the Advising Area Director for
the SIEVE WG and process all the documents of that WG. I did a
personal review before requesting the Last Call. I did not, and still
do not, see how this knowingly exacerbates the spam problem -- in fact
it encourages servers to reduce backscatter, itself a form of spam.
Lisa
-Matthew
On 8/7/08 6:44 PM, Lisa Dusseault wrote:
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@xxxxxxxx mailing lists by 2008-08-10. Exceptionally,
comments may be sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf