Subject: Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

From: Cyrus Daboo <[email-masked]>
Date: Thu, 11 Sep 2008 10:38:40 -0400

Hi Matthew,

--On September 10, 2008 3:13:33 PM -0700 Matthew Elvey <[email-masked]> 
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

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Sep 2008 12:24:03 -0400

Hi.

A little additional perspective on this from someone who has
(deliberately) not been active in the SIEVE effort.   Cyrus has
alluded to some of this, but the real constraint is with SMTP,
not  SIEVE, and should be addressed in the SMTP context.

The issue of NDN blowback has come up repeatedly in discussions
of SMTP.  The bottom-line answer, despite complaints from
zealous anti-blowback advocates and clever alternate readings of
the spec, is that the SMTP model simply doesn't work without the
possibility of non-delivery messages.  While there are other
issues, the most important and obvious of them is that SMTP
permits and encourages multiple-recipient messages and has no
in-protocol mechanism for returning per-recipient replies.  

In theory, that problem could be overcome with an SMTP extension
for per-recipient replies.  There is a long-expired I-D that
discussed doing just that, but it never got an traction (and may
or may not have been the best way to do it).  However, while
per-recipient responses have other advantages, there is no
reason to assume that spammers would voluntarily make their
lives more difficult by invoking such an extension.

Conversely, the blowback problem could be solved in principle by
authenticating message senders (probably beyond their
authorization to send mail, which is more or less the problem to
which DKIM and SPF are addressed).  But there is again a
deployment problem unless one assumes that legitimate deployed
SMTP implementations can be changed in only a short period of
time.  See
http://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5
and the surrounding context for further discussion on that issue.

The bottom line is that a debate about prohibiting SIEVE from
returning NDNs is meaningless without changes to SMTP.  We don't
have any proposals on the table for such SMTP changes and don't
know how to get from "here" to "there" with any of the proposals
that have been made.    I guess that makes this I-D a more
tempting target, but it still does not make it relevant.

If the SIEVE WG somehow decided that it liked one of the
proposals for suppressing the possibility of NDNs, we would then
be having a discussion about whether or not that WG is permitted
to write a spec that requires violations of SMTP.  Fortunately,
they did not present us with that choice.

best,
     john

--On Thursday, 11 September, 2008 10:38 -0400 Cyrus Daboo
<[email-masked]> wrote:

> Hi Matthew,
> 
> --On September 10, 2008 3:13:33 PM -0700 Matthew Elvey
> <[email-masked]>  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
>...

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 14 Sep 2008 20:53:00 -0700

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>; "Matthew Elvey" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; "Alexey Melnikov" 
<[email-masked]>; <[email-masked]>; "Aaron Stone" 
<[email-masked]>
Sent: Thursday, September 11, 2008 9:24 AM
Subject: Re: Strong Opposition due to spam backscatter. Re: LastCall: 
draft-ietf-sieve-refuse-reject-07 and -08 (Sieve EmailFiltering: Reject and 
Extended Reject Extensions) to Proposed Standard

> possibility of non-delivery messages.

True and its more about that SMTP wasnt desinged to insure the delivery of 
anything. The real issue is that there may be ann increasing liability for 
being a source of backscatter or blowback traffic when reacting to being 
pummled by some smtp traffic.

> While there are other

The hurdle is in meeting the US Courts for authenticated messaging per Judge 
Grimm's standard in Lorraine v Markel which set the bar-heigth for 
commercially insured players everywhere.

> for per-recipient replies.

Or in authenticated sources of email. Ones which warrant the identity of 
their client's for instance.

> There is a long-expired I-D that
> which DKIM and SPF are addressed).

OK sure but the real issue is in not sending mail to an address which is 
different than the senders address when it bounces. That is the ONLY rule 
which will change anything.

> But there is again a
> time.

Depends - the resetting of the standard bounce failure to not send mail to 
addresses it cannot resolve will eliminate about 90%  of the backscatter 
spam A couple of years is all that's needed to wean the world off 
anonymous-only mail.

> See
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.20/1666 - Release Date: 9/11/2008 
7:03 AM