ietf
[Top] [All Lists]

Re: Strong Opposition due to spam blowback issues - Re: Last Call: draft-ietf-sieve-refuse-reject

2008-08-18 12:38:37

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(_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

<Prev in Thread] Current Thread [Next in Thread>