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

From: "Matthew Elvey" <[email-masked]>
Date: Thu, 07 Aug 2008 12:09:51 -0700

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.
*[1]http://en.wikipedia.org/wiki/Backscatter_(e-mail)
**[2]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
[3][email-masked] mailing lists by 2008-08-10. Exceptionally,
comments may be sent to [4][email-masked] instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
[5]http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-07.
txt

IESG discussion can be tracked via
[6]https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa
g=13141&rfc_flag=0

References

1. http://en.wikipedia.org/wiki/Backscatter_(e-mail)
2. http://en.wikipedia.org/wiki/Transparent_SMTP_proxy
3. mailto:[email-masked]
4. mailto:[email-masked]
5. http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-07.txt
6. https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13141&rfc_flag=0
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 7 Aug 2008 18:44:43 -0700

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:

> 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.
> 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
>
>> [email-masked] mailing lists by 2008-08-10. Exceptionally,
>> comments may be sent to [email-masked] instead. In either case, please
>> http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-07.txt
>>
>>
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13141&rfc_flag=0
>>
>>
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 11 Aug 2008 10:36:57 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sieve-refuse-reject-07
Reviewer: Spencer Dawkins
Review Date: 2008-08-10
IETF LC End Date: 2008-08-10 (oops!)
IESG Telechat date: N/A

Summary: Almost ready for publication as a Proposed Standard. I have some 
clarity questions below, and two technical questions involving 2119 language 
...

Comments:

Abstract

   This memo updates the definition of the Sieve mail filtering language
   "reject" extension, originally defined in RFC 3028.

   A "Joe-job" is a spam run forged to appear as though it came from an

Spencer (clarity): I'm OK with the use of "joe-job" (or, at a minimum, I'm 
OK with what you guys say it is), but there's not a clear statement in the 
abstract that the update to 3028 is in response to the "joe-job" practice. 
I'd suggest something like "... originally defined in RFC 3028, because the 
definition in RFC 3028 did not allow messages to be refused during the STMP 
transaction, and experience has shown this to be valuable in response to 
"joe-jobs"."

   innocent party, who is then generally flooded by automated bounces,
   Message Disposition Notifications (MDNs), and personal messages with
   complaints.  The original Sieve "reject" action defined in RFC 3028
   required use of MDNs for rejecting messages, thus contributing to the
   flood of Joe-job spam to victims of Joe-jobs.

   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, if possible.

   The "ereject" action is intended to replace the "reject" action
   wherever possible.

Spencer (clarity): a LOT later in the document, the following text appears: 
"The "ereject" action is similar to "reject", but will always favor protocol 
level message rejection". That's a really helpful summary - I'd like to see 
something like that much earlier in the document, maybe here.

1.  Introduction

   The Sieve mail filtering language [SIEVEBIS], as originally defined
   in RFC 3028 [SIEVE], specified that the "reject" action shall discard
   a message and send a Message Disposition Notification [MDN] to the
   envelope sender along with an explanatory message.  RFC 5228
   [SIEVEBIS] does not define any reject action, hence the purpose of
   this document.

Spencer (clarity): hmm. I'm almost sure that "The Sieve mail filtering 
language [SIEVEBIS]" was NOT "originally defined in RFC 3028 [SIEVE]"... :-) 
If you drop the first [SIEVEBIS] reference in this sentence, I think it's 
correct.

Spencer (clarity): It's not particularly easy for me to understand this 
paragraph, given that SIEVEBIS is used as the reference for "RFC 5228" in 
the last sentence. I might suggest "the updated Sieve mail filtering 
language [SIEVEBIS] does not define any reject action ..."

   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.

Spencer (clarity): a LOT later in the document, the following text appears: 
"The "ereject" action is similar to "reject", but will always favor protocol 
level message rejection". That's a really helpful summary - I'd like to see 
something like that much earlier in the document, maybe here.

   Implementations are further encouraged to use spam-detection systems
   to determine the level of risk associated with sending an MDN, and
   this document allows implementations to silently drop the MDN if the
   rejected message is deemed to be likely spam.

   Further discussion highlighting the risks of generating MDNs and the
   benefits of protocol-level refusal can be found in [Joe-DoS].

2.1.1.  Rejecting a message at the SMTP/LMTP protocol level

   Sieve implementations that are able to reject messages at the SMTP/
   LMTP level MUST do so and SHOULD use the 550 response code.  Note

Spencer (technical): since rejection is a MUST, I'd expect to see guidance 
about why using 550 might not be the right thing to do ("why is this a 
SHOULD?"). There's some text at the bottom of 2.5 about using 4XX first, but 
it should appear here, I think.

   that if a message is arriving over SMTP and has multiple recipients,
   some of whom have accepted the message, Section 2.1.2 defines how to
   reject such a message.

2.1.2.  Rejecting a message by sending a DSN

   An implementation may receive a message via SMTP that has more than
   one RCPT TO that has been accepted by the server, and at least one
   but not all of them are refusing delivery (whether the refusal is
   caused by a Sieve "ereject" action or for some other reason).  In
   this case, the server MUST accept the message and generate DSNs for
   all recipients that are refusing it.  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.)

Spencer (clarity): "blowback" isn't defined (yet, at least).

2.2.  Action reject

   The "reject" action cancels the implicit keep and refuses delivery of
   a message.  The reason string is a UTF-8 [UTF-8] string specifying
   the reason for refusal.  Unlike the "ereject" action described above,
   this action would always favor preserving the exact text of the
   refusal reason.  Typically the "reject" action refuses delivery of a
   message by sending back an MDN to the alleged sender (see
   Section 2.2.1).  However implementations MAY refuse delivery over
   protocol (as detailed in Section 2.5), if and only if all of the

Spencer (clarity): "refuse delivery over protocol" reads roughly to me. is 
there an adjective for "protocol" that might make this sentence clearer? i'm 
not sure that "over protocol" is even required - is it? if not, you could 
just delete the two words.

   following conditions are true:

       Example:
               require ["reject"];

               if size :over 100K {
                   reject text:
       Your message is to big. If you want to send me a big attachment,

Spencer (nit): s/to/too/ :-)

2.3.  Silent upgrade from reject to ereject

   Implementations MUST NOT silently upgrade reject actions to ereject
   actions, however user interfaces may change the specific action
   underlying a descriptive representation, thereby effecting a silent
   upgrade of sorts.

Spencer (technical): ??? I may not understand the point here, but from the 
user's point of view, the requirement seems religious - protocol 
implementations are prohibited from silently upgrading, but user interfaces 
aren't, and the effect on the rejected e-mail, from the user's perspective, 
is the same, isn't it? Or is this talking about "silently upgrading reject 
actions" without making sure that the other side is ereject-capable?

----- Original Message ----- 
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 27, 2008 7:02 AM
Subject: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: 
Reject and Extended Reject Extensions) to Proposed Standard

> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 13 Aug 2008 23:16:23 -0700

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 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.

*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

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.

-Matthew

On 8/7/08 6:44 PM, Lisa Dusseault wrote:
>> 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.
>> 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.
>> 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.
>>

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 18 Aug 2008 10:37:19 -0700

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...

> 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

>> 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  
>> 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
>>
>>> 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.