Re: draft-ietf-sieve-refuse-reject-07.txt

[Arnt Gulbrandsen <[e-mail]>]

Dave Cridland writes:
> I suspect that using a 2xx in this case might be best, since it would  
> become a "discard", in effect, if the LMTP client didn't understand  
> it, and the additional bandwidth and processing for LMTP connections  
> is negligable. For SMTP, a 4xx might be more sensible, which would  
> reduce the bandwidth, but not generate a DSN instantly.

200 2.7.1 Blah blah blah?

Arnt




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4UIIwPF037646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2008 11:18:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4UIIwrk037645; Fri, 30 May 2008 11:18:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4UIItWY037634 for <[e-mail]>; Fri, 30 May 2008 11:18:57 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 1E6EA4AC30; Fri, 30 May 2008 20:18:53 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1212171472-75142-1227; Fri, 30 May 2008 20:17:52 +0200
Message-Id: <4JDIs/[e-mail]>
Date: Fri, 30 May 2008 20:17:23 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
Cc: Ned Freed <[e-mail]>, Dave Cridland <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland writes:
> I suspect that using a 2xx in this case might be best, since it would  
> become a "discard", in effect, if the LMTP client didn't understand  
> it, and the additional bandwidth and processing for LMTP connections  
> is negligable. For SMTP, a 4xx might be more sensible, which would  
> reduce the bandwidth, but not generate a DSN instantly.

200 2.7.1 Blah blah blah?

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4U4ve8p090953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2008 21:57:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4U4ve0m090952; Thu, 29 May 2008 21:57:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4U4vdVr090938 for <[e-mail]>; Thu, 29 May 2008 21:57:40 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.11] (atomnet2.ttr.ru [195.245.249.86])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 30 May 2008 05:57:38 +0100
Message-ID: <[e-mail]>
Date: Fri, 30 May 2008 08:58:07 +0400
From: Alexey Melnikov <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: SIEVE <[e-mail]>
Subject: [Fwd: RFC 5183 on Sieve Email Filtering: Environment Extension]
Content-Type: multipart/mixed; boundary="------------090606060407060709080506"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------090606060407060709080506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Well done Ned!


--------------090606060407060709080506
Content-Type: message/rfc822;
 name="RFC 5183 on Sieve Email Filtering: Environment Extension.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="RFC 5183 on Sieve Email Filtering: Environment Extension.eml"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine.isode.net (Isode M-Box/14.2v0) with LMTP; Fri, 30 May 2008 00:37:53 +0100 (BST)
Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Fri, 30 May 2008 00:37:53 +0100
X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CF24C3A6C03;
	Thu, 29 May 2008 16:31:45 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CA4A13A6BFE
	for <[e-mail]>;
	Thu, 29 May 2008 16:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.989
X-Spam-Level: 
X-Spam-Status: No, score=-16.989 tagged_above=-999 required=5
	tests=[AWL=0.010, BAYES_00=-2.599, J_CHICKENPOX_93=0.6,
	USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id R-8+5VZDbdTd for <[e-mail]>;
	Thu, 29 May 2008 16:31:42 -0700 (PDT)
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207])
	by core3.amsl.com (Postfix) with ESMTP id 788633A6BD1
	for <[e-mail]>; Thu, 29 May 2008 16:30:54 -0700 (PDT)
Received: by bosco.isi.edu (Postfix, from userid 70)
	id 3E0A212D82C; Thu, 29 May 2008 16:30:54 -0700 (PDT)
To: [e-mail], [e-mail]
Subject: RFC 5183 on Sieve Email Filtering: Environment Extension
From: [e-mail]
Message-Id: <[e-mail]>
Date: Thu, 29 May 2008 16:30:54 -0700 (PDT)
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Announcements <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:[e-mail]?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5183

        Title:      Sieve Email Filtering: Environment Extension 
        Author:     N. Freed
        Status:     Standards Track
        Date:       May 2008
        Mailbox:    [e-mail]
        Pages:      10
        Characters: 16950
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-freed-sieve-environment-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5183.txt

This document describes the "environment" extension to the Sieve
email filtering language.  The "environment" extension gives a Sieve
script access to information about the Sieve interpreter itself,
where it is running, and about any transport connection currently
involved in transferring the message.  [STANDARDS TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce

--------------090606060407060709080506--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4U1Ubuu028971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2008 18:30:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4U1UbBB028970; Thu, 29 May 2008 18:30:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4U1UZBK028953 for <[e-mail]>; Thu, 29 May 2008 18:30:36 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 29 May 2008 18:30:33 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 29 May 2008 18:30:29 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1212111032; h=Date:	 From:Subject:MIME-version:Content-type; b=Hk++iscxyF0wErmRTAdfXitnp qSCURhe26kwEtikRt28Ps0ijMiH64SeVmP9iA6gl+99VwiDAg6Trzl+TvJ0dg==
Date: Thu, 29 May 2008 17:32:10 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
In-reply-to: "Your message dated Fri, 30 May 2008 00:06:15 +0100" <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], Matthew Elvey <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Thu May 29 17:22:46 2008, Ned Freed wrote:
> > (1) is only appropriate if the MAIL FROM is emoty, NOTIFY=NEVER is
> > in effect,
> > the MAIL FROM Is somehow known to be forged. That leaves generating
> > a DSN as the only viable alternative in most cases.

> As a brief aside - I agree with both Matthew's aims here and Ned's
> conclusions - it did occur to me that a (possibly LMTP specific)
> response code of some form which indicated both that the mail was
> rejected as was strongly considered to be forged (or otherwise not
> worthwhile to send a DSN for) might be a possibility, although not
> for this document or even working group.

> I suspect that using a 2xx in this case might be best, since it would
> become a "discard", in effect, if the LMTP client didn't understand
> it, and the additional bandwidth and processing for LMTP connections
> is negligable. For SMTP, a 4xx might be more sensible, which would
> reduce the bandwidth, but not generate a DSN instantly.

I pretty much agree with all of this, but now let's take it to the logical
conclusion: If the script has determined that this is probable spam and doesn't
want a response sent, why why not use the guaranteed-to-be-present discard
instead rather than employing the optional-and-doesn't-do-what-you-want
ereject?

The main reason I can think of for wanting to use ereject is that in some sense
it offers a way to log *why* the message was thrown away. But if that's the
goal, surely an extension that allows a <reason> argument to be given to
discard is the better answer. In the LMTP server case this could translate
into sending back a "2yx 5.a.b message discarded because ..." sort of response.

This is why I suggested adding text to the draft saying that these actions are
seriously suboptimal as a means of dealing with spam. I think a little care in
the use of these actions will go a lot further than racketing up the compliance
language further and further. 

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4TN6eZC086515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2008 16:06:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4TN6ef4086514; Thu, 29 May 2008 16:06:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net ([IPv6:2001:838:378:0:211:9ff:fe2c:e28e]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4TN6bgC086489 for <[e-mail]>; Thu, 29 May 2008 16:06:38 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Fri, 30 May 2008 00:06:17 +0100
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 30 May 2008 00:06:15 +0100
From: Dave Cridland <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: <[e-mail]>, Matthew Elvey <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu May 29 17:22:46 2008, Ned Freed wrote:
> (1) is only appropriate if the MAIL FROM is emoty, NOTIFY=NEVER is  
> in effect,
> the MAIL FROM Is somehow known to be forged. That leaves generating  
> a DSN as the only viable alternative in most cases.

As a brief aside - I agree with both Matthew's aims here and Ned's  
conclusions - it did occur to me that a (possibly LMTP specific)  
response code of some form which indicated both that the mail was  
rejected as was strongly considered to be forged (or otherwise not  
worthwhile to send a DSN for) might be a possibility, although not  
for this document or even working group.

I suspect that using a 2xx in this case might be best, since it would  
become a "discard", in effect, if the LMTP client didn't understand  
it, and the additional bandwidth and processing for LMTP connections  
is negligable. For SMTP, a 4xx might be more sensible, which would  
reduce the bandwidth, but not generate a DSN instantly.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4TJwhTv031447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2008 12:58:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4TJwhl8031446; Thu, 29 May 2008 12:58:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4TJwfRq031427 for <[e-mail]>; Thu, 29 May 2008 12:58:42 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 29 May 2008 12:58:40 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 29 May 2008 12:58:37 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1212091120; h=Date:	 From:Subject:MIME-version:Content-type; b=kTx1mxhazcbjelTRLwu4QcY4J lCrHCxhPzsxvMfl6raiqnijmBQD+Su8wa1HoTdkokJwMZmByK76oaEmadbV9g==
Date: Thu, 29 May 2008 09:22:46 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: draft-ietf-sieve-refuse-reject-07.txt
In-reply-to: "Your message dated Wed, 28 May 2008 17:25:06 -0700" <[e-mail]>
To: Matthew Elvey <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> As I've said before:

> >  I strongly support ... requiring that all implementations implement the ability to do
> >  proper smtp-time (or lmtp-time) protocol-level refusals (other than
> >  MUA-based implementations). It's an important interoperability issue.

> Ned responded:

> >  Yes, but the current draft already does this.

> I disagree.  There is a loophole for an implementer to decide that what he or
> she feels is preferred is to not bother fulfilling this requirement. It needs
> to be closed.

Then you really need to provide better evidence that such a loophole exists -
because I'm not seeing it. In this particular case the text you propose
changing currently reads "Sieve implementations that are able to reject
messages at the SMTP/ LMTP level MUST do so and SHOULD use the 550 response
code." So where's the loophole? Any implementation that is invoked by an
SMTP/LMTP server and has the ability to control SMTP statuses is by definition
"able to reject messages ..." and therefore falls under this requirement.

> The latest language suggestion doesn't quite fix the loophole, so I suggest
> we clarify by making explicit what Ned states is already implicit.  I propose
> we add it thus:

> "It is REQUIRED that all implementations implement the ability to do
> proper SMTP-time (or LMTP-time) protocol-level refusals (other than
> MUA-based implementations).

Not only does this not strengthen any requirements over the previous text,  it
actually weakens them, since all an implementation now needs to do is claim it
is operating, to use the traditional phrase, "with UA authority' and it is free
to do whatever it pleases because now it has categorized itself as an MUA.

Howver, if this revised language makes you happier about the document I have no
objections to it. However, I must reject the notion it tightens things up. If
anything it does the opposite.

> It's an important interoperability issue.

This OTOH, I see as a bit problematic. Since this isn't an interop issue in the
usual sense we think about such things, I find this to be confusing and cannot
support its inclusion.

> They SHOULD use the 550 response code to do so."

This is fine, of course.

> This can replace the relatively vague first sentence of 2.1.1.

There's nothing vague about it IMO.

> We should use the latest language suggestion as well:
> >    The ereject action MUST NOT be available in environments that do not
> >      support protocol level rejection, e.g. an MUA, and MUST be available
> >      in all other environments that support the reject action"

As I said previously, I think this is OK.

> I also support the addition of the text Ned proposed:

> "the risk that these actions will generate blowback spam are
> minimized but cannot be eliminated completely even in the case of ereject, so
> caution is advised when using these actions to deal with messages determined to
> be spam."

> It can go at the end of 2.1.2.

2.1.2 discusses sending DSNs and is therefore entirely the wrong place for
this. It belongs at the end of 2.1.1, the section talking about SMTP/LMTP level
rejects.

> The loophole I described is why I suggested the language I did, including the phrase "user's choice".

> > >  To the sentence that begins:
> >
> > >  "The Sieve interpreter MUST carry out one of the following actions
> > >  (listed in order from most to least preferred),"
> > >  add something like:
> > >  "MUST support the user's choice to carry out the most preferable action
> > >  possible"

> Ned responded:

>  > I confess I haven't a clue what you mean by "user's choice" in this
> context, so I really cannot evaluate it.

> I meant that, e.g. if the user wants to do a protocol-level refusal, an
> implementation that's not an MUA must support that choice.

> I still strongly support requiring a change to the default behaviour,
> and feel that there is reluctance to change the current behaviour for
> what was presented as nothing more than an unwillingness to explain what
> we all agreed were net good reasons for the change.

I fail to see continuing to impugn the motives for the position I have taken is
in any way helpful here. But in the interests of keeping this civil I'm not
going to respond further.

> But this is a compromise.  (A change to the default behaviour would make
> the draft SIMPLER too.)

A simpler but unacceptably incompatible change is still not acceptable.

> Also I propose some changes to newer stuff:
>                      of a message. The refusal should happen as early
> should be
>                      of a message. The refusal MUST happen as early

This is in the IANA registration, which given that IANA lifts these things out
and puts them in the registry means it is for all intents and purposes a
separate document. I don't think it is in any way apppropriate to use
requirements langauge in this context and therefore oppose making this change.

> and I don't see why
>     Script generators SHOULD ensure that a rejection action being
> shouldn't be
>     Script generators MUST ensure that a rejection action being

This cannot be a MUST, if for no other reason that such generators could
easily be operating in an MUA content where ereject is not available.

> also, let's change
>     using the ereject action, as it is more suitable for such rejections.
> to
>     using the ereject action, as reject is unsuitable for such rejections.

The problem with such claims is that the bar they effectively set is so
high ereject cannot meet them either. I'm therefore opposed to this as well.

> also, let's change
>     support protocol level rejection, e.g. an MUA, and MUST be available
> to
>     support protocol level rejection, i.e. an MUA, and MUST be available

It is entirely possible for there to be critters in the email universe that act
at the UA level but which aren't thought of as UAs. So what you are doing
actually weakens the requirement by making it sound like it only applies to
MUAs specifically.

> And I'm not clear why this is needed; I don't think it's the case:
> (However, the LMTP client may then have no choice
>     but to generate a DSN to report the error, which may result in
>     blowback.)
> Where it appears to be the case, the LMTP client may just need to be
> fixed.

Fixed how? Suppose the LMTP client is on an ingress MTA. Messages come
in from the Internet using SMTP and are then sent on using LMTP to affect
final delivery.

Suppose the Sieve implementation is operating as part of the LMTP server. (This
isn't how I'd ever do it, but it is nevertheless a perfectly legitimate
implementation option.) A message comes in via SMTP and is queued for
delivery. The LMTP client sends it to the LMTP server, which then runs
the Sieve which then does an ereject. This is then translated into a
550 LMTP response.

What is the MTA supposed to do now? It has exactly two options available:

(1) Silently discard the message.
(2) Generate a DSN and send it to the MAIL FROM address.

(1) is only appropriate if the MAIL FROM is emoty, NOTIFY=NEVER is in effect,
the MAIL FROM Is somehow known to be forged. That leaves generating a DSN 
as the only viable alternative in most cases.

Returning a 550 SMTP response is not possible for the simple reason that the
SMTP connection is long gone - in fact it could have taken place hours or even
days earlier. 

I will also note that the behavior of such an MTA, which not only isn't the
agent with the Sieve implementation, it likely will not even be aware that
Sieve is involved, is entirely out of scope for this working group. We cannot
impose requirements here even if we wanted to.

> If there is indeed such a case, it needs to be specified.

Specify what? The unfortunate reality is that once a message has been accepted
by an ingress MTA the options for getting rid of it narrow down to 
discarding it, with or without sending a notification. 

Now, I have long been a proponent of turning away as many messages as possible
while the connection is still there for reporting errors. But neither this
document nor this workging group are the places to make the case for doing
things this way.

> Oh, and the acronyms MDA,  MTA and MUA are now used but not defined (as
> Mail Delivery, Transfer and User Agents, respectively)
> draft-crocker-email-arch-10.txt defines 'em, but it's been an I-D for as
> long as this I-D, so I suggest we just spell 'em out on initial use.

I agree the terms need to be defined but the right way to do is is by
referencing the architecture document. The Sieve environment draft did so and
this has not proved to be a barrier to publication.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4T0PBeb067226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2008 17:25:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4T0PBk8067224; Wed, 28 May 2008 17:25:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4T0PAAP067218 for <[e-mail]>; Wed, 28 May 2008 17:25:10 -0700 (MST) (envelope-from [e-mail])
Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 2E2A811014A for <[e-mail]>; Wed, 28 May 2008 20:25:09 -0400 (EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 28 May 2008 20:25:09 -0400
X-Sasl-enc: yB2sbXpIQaxtYWDab74yMJZ22GwCDM0XYMoEvH8rN+Vh 1212020708
Received: from [192.168.18.101] (c-67-169-60-252.hsd1.ca.comcast.net [67.169.60.252]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6DDDCAF5C; Wed, 28 May 2008 20:25:08 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 28 May 2008 17:25:06 -0700
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 3.0a1 (Macintosh/2008050714)
MIME-Version: 1.0
To: [e-mail]
Subject: draft-ietf-sieve-refuse-reject-07.txt
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As I've said before:

>  I strongly support ... requiring that all implementations implement the ability to do
>  proper smtp-time (or lmtp-time) protocol-level refusals (other than
>  MUA-based implementations). It's an important interoperability issue.

Ned responded:
>  Yes, but the current draft already does this.

I disagree.  There is a loophole for an implementer to decide that what he or she feels is preferred is to not bother fulfilling this requirement. It needs to be closed.

The latest language suggestion doesn't quite fix the loophole, so I suggest we clarify by making explicit what Ned states is already implicit.  I propose we add it thus:

"It is REQUIRED that all implementations implement the ability to do
proper SMTP-time (or LMTP-time) protocol-level refusals (other than
MUA-based implementations). It's an important interoperability issue. They SHOULD use the 550 response code to do so."

This can replace the relatively vague first sentence of 2.1.1.

We should use the latest language suggestion as well:
>    The ereject action MUST NOT be available in environments that do not
>      support protocol level rejection, e.g. an MUA, and MUST be available
>      in all other environments that support the reject action"

I also support the addition of the text Ned proposed:

"the risk that these actions will generate blowback spam are
minimized but cannot be eliminated completely even in the case of ereject, so
caution is advised when using these actions to deal with messages determined to
be spam."

It can go at the end of 2.1.2.

The loophole I described is why I suggested the language I did, including the phrase "user's choice".

> >  To the sentence that begins:
>    
> >  "The Sieve interpreter MUST carry out one of the following actions
> >  (listed in order from most to least preferred),"
> >  add something like:
> >  "MUST support the user's choice to carry out the most preferable action
> >  possible"
Ned responded:

 > I confess I haven't a clue what you mean by "user's choice" in this 
context, so I really cannot evaluate it.

I meant that, e.g. if the user wants to do a protocol-level refusal, an 
implementation that's not an MUA must support that choice.

I still strongly support requiring a change to the default behaviour, 
and feel that there is reluctance to change the current behaviour for 
what was presented as nothing more than an unwillingness to explain what 
we all agreed were net good reasons for the change.
But this is a compromise.  (A change to the default behaviour would make 
the draft SIMPLER too.)

Also I propose some changes to newer stuff:
                     of a message. The refusal should happen as early
should be
                     of a message. The refusal MUST happen as early

and I don't see why
    Script generators SHOULD ensure that a rejection action being
shouldn't be
    Script generators MUST ensure that a rejection action being

also, let's change
    using the ereject action, as it is more suitable for such rejections.
to
    using the ereject action, as reject is unsuitable for such rejections.

also, let's change
    support protocol level rejection, e.g. an MUA, and MUST be available
to
    support protocol level rejection, i.e. an MUA, and MUST be available
And I'm not clear why this is needed; I don't think it's the case:
(However, the LMTP client may then have no choice
    but to generate a DSN to report the error, which may result in
    blowback.)
Where it appears to be the case, the LMTP client may just need to be 
fixed.  If there is indeed such a case, it needs to be specified.


Oh, and the acronyms MDA,  MTA and MUA are now used but not defined (as 
Mail Delivery, Transfer and User Agents, respectively) 
draft-crocker-email-arch-10.txt defines 'em, but it's been an I-D for as 
long as this I-D, so I suggest we just spell 'em out on initial use.

-Matthew



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4SHnNUq049596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2008 10:49:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4SHnN5g049589; Wed, 28 May 2008 10:49:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4SHnMwY049573 for <[e-mail]>; Wed, 28 May 2008 10:49:22 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 28 May 2008 10:49:18 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 28 May 2008 10:49:10 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1211996957; h=Date:	 From:Subject:MIME-version:Content-type; b=ghouawu8Rvo5bIgwkRj2YYgr9 hrsyy/+hfhumYAHMeBGUJHxRyYvrncPTpmerAzG25YKRdDart3Rn2BHO4qNtg==
Date: Wed, 28 May 2008 10:48:01 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sieve-refuse-reject-07.txt
In-reply-to: "Your message dated Wed, 28 May 2008 12:07:39 +0400" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [e-mail] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.
> >
> >
> > 	Title           : Sieve Email Filtering: Reject and Extended Reject Extensions
> > 	Author(s)       : A. Stone, et al.
> > 	Filename        : draft-ietf-sieve-refuse-reject-07.txt
> > 	Pages           : 14
> > 	Date            : 2008-05-27
> >
> This version looks good to me.

> Some nitpicking about references:

> The draft header says:
>   Updates: 3028 (if approved)

> However RFC 5228 says:
>  Obsoletes: 3028

> So I think this document needs to do the same thing (that is, together
> RFC 5228 and this draft are obsoleting RFC 3028)

Sounds right to me.

> > 1.1.  Conventions Used in This Document
>  [...]
> >    Conventions for notations are as in RFC 3028 [SIEVE] Section 1.1.
> I suggest this is changed to reference RFC 5228 [SIEVEBIS] ...
> >    [SIEVE]    Showalter, T., "Sieve: A Mail Filtering Language",
> >               RFC 3028, January 2001.
> ... and this reference can be made Informational.

Also good.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4SGc196027329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2008 09:38:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4SGc1DR027328; Wed, 28 May 2008 09:38:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4SGbxcH027301 for <[e-mail]>; Wed, 28 May 2008 09:38:00 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 28 May 2008 09:37:43 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 28 May 2008 09:37:38 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1211992663; h=Date:	 From:Subject:MIME-version:Content-type; b=N1C5mn16xyIY4tw/KwRMglAto NpKq0KzCQN5dFBZocvbGrBvOCZux2xgR14MCKzFisFIDfsqamWuZOTYcehQgg==
Date: Wed, 28 May 2008 09:34:04 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Finishing draft-ietf-sieve-refuse-reject-06.txt
In-reply-to: "Your message dated Tue, 27 May 2008 21:14:29 -0700" <1211948070.5425.32.camel@localhost>
To: Aaron Stone <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail], Matthew Elvey <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <1211948070.5425.32.camel@localhost>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Thank you! I took on the document at a time when I had time to work on
> such things, and shortly thereafter a project at my day job expanded to
> absorb all waking hours for a few months. Apologies for the delay this
> caused; I look forward to finishing up the document as soon as possible.

> I've adopted all of the changes suggested, albeit some with editorial
> changes, with one exception:

>   The Sieve interpreter MUST carry out one of the
>   following actions (listed in order from most to least preferred),
>   SHOULD carry out the most preferable action, and
>   SHOULD fall back to lesser actions if a preferred action fails.

> If we change one of those SHOULDs to MUST then I think we have to change
> both. Note that it prevents people who have a good reason to take things
> slightly out of order to do so and remain compliant. I am of the mind
> that SHOULD makes more sense because it allows for wiggle room.

That's the issue I was getting at when I said that changing this to a MUST
requires additional qualification, e.g. add "possible" to the end so you have:

   The Sieve interpreter MUST carry out one of the
   following actions (listed in order from most to least preferred),
   MUST carry out the most preferable action possible, and
   MUST fall back to lesser actions if a preferred action fails.

You cannot say just "MUST carry out the most preferable action" because that
means you are required to carry out the first action on the list. That's
clearly nonsensical.

Again, I have no problem with making such a change if it makes people happier
but I think the text is fine as-is.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4S87LhB078453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2008 01:07:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4S87LLQ078452; Wed, 28 May 2008 01:07:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4S87JSp078438 for <[e-mail]>; Wed, 28 May 2008 01:07:21 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.11] (atomnet2.ttr.ru [195.245.249.86])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 28 May 2008 09:07:18 +0100
Message-ID: <[e-mail]>
Date: Wed, 28 May 2008 12:07:39 +0400
From: Alexey Melnikov <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-refuse-reject-07.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.
>
>
> 	Title           : Sieve Email Filtering: Reject and Extended Reject Extensions
> 	Author(s)       : A. Stone, et al.
> 	Filename        : draft-ietf-sieve-refuse-reject-07.txt
> 	Pages           : 14
> 	Date            : 2008-05-27
>   
This version looks good to me.

Some nitpicking about references:

The draft header says:
  Updates: 3028 (if approved)

However RFC 5228 says:
 Obsoletes: 3028

So I think this document needs to do the same thing (that is, together 
RFC 5228 and this draft are obsoleting RFC 3028)

> 1.1.  Conventions Used in This Document
 [...]
>    Conventions for notations are as in RFC 3028 [SIEVE] Section 1.1.
I suggest this is changed to reference RFC 5228 [SIEVEBIS] ...
>    [SIEVE]    Showalter, T., "Sieve: A Mail Filtering Language",
>               RFC 3028, January 2001.
... and this reference can be made Informational.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4S6VmOx047628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2008 23:31:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4S6VmPu047627; Tue, 27 May 2008 23:31:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4S6VlFI047621 for <[e-mail]>; Tue, 27 May 2008 23:31:48 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id A06393A6945; Tue, 27 May 2008 23:30:02 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-refuse-reject-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 27 May 2008 23:30:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.


	Title           : Sieve Email Filtering: Reject and Extended Reject Extensions
	Author(s)       : A. Stone, et al.
	Filename        : draft-ietf-sieve-refuse-reject-07.txt
	Pages           : 14
	Date            : 2008-05-27

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sieve-refuse-reject-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4S4F9oQ005887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2008 21:15:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4S4F97S005886; Tue, 27 May 2008 21:15:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4S4F7BT005870 for <[e-mail]>; Tue, 27 May 2008 21:15:08 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.146] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id C501545E1; Tue, 27 May 2008 21:27:17 -0700 (PDT)
Subject: Re: Finishing draft-ietf-sieve-refuse-reject-06.txt
From: Aaron Stone <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail], Matthew Elvey <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 27 May 2008 21:14:29 -0700
Message-Id: <1211948070.5425.32.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.1.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thank you! I took on the document at a time when I had time to work on
such things, and shortly thereafter a project at my day job expanded to
absorb all waking hours for a few months. Apologies for the delay this
caused; I look forward to finishing up the document as soon as possible.

I've adopted all of the changes suggested, albeit some with editorial
changes, with one exception:

  The Sieve interpreter MUST carry out one of the
  following actions (listed in order from most to least preferred),
  SHOULD carry out the most preferable action, and
  SHOULD fall back to lesser actions if a preferred action fails.

If we change one of those SHOULDs to MUST then I think we have to change
both. Note that it prevents people who have a good reason to take things
slightly out of order to do so and remain compliant. I am of the mind
that SHOULD makes more sense because it allows for wiggle room.

Aaron


On Wed, 2008-05-21 at 15:00 -0700, Ned Freed wrote:
> I think the time has come to reach closure on this draft and move it forward.
> I've therefore done a careful review. I think the draft is technically fine but
> I do have a number of suggestions for editorial improvements. I will also
> respond to the final comments Mathhew made on this back in January - I don't
> believe anyone else responded to him.
> 
> The third paragraph of the abstract says:
> 
>    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.
> 
> The last sentence here isn't quite right - ereject makes it possible for
> SMTP level refusal to occur but cannot guarantee it. I suggest changing
> this to read:
> 
>    This memo updates the definition of the "reject" action to allow
>    messages to be refused during the SMTP transaction, and defines the
>    "ereject" action, which unlike "reject" requires messages be
>    refused during the SMTP transaction whenever possible.
> 
> The second paragraph of the introduction has the same issue. I suggest
> adding "if possible" at the end:
> 
>    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.
> 
> Section 1.1, second paragraph, last sentence:
> 
>    Implementations are advised to follow best practices and
>    keep abreast of current research in these fields.
> 
> I think my implementation is pretty cool but I doubt it is capable of this.
> How about "implementors" rather than "implementations"?
> 
> Section 2.1. The section on reject has an example at the end, how about having
> one here? (I really want ereject to appear on a par with reject in every
> way.) A simple one showing rejecting all mail from a particular address would
> be good, so how about:
> 
>        require ["ereject"];
> 
>        if address "from" "[e-mail]" {
>          ereject "Sorry, I no longer accept mail from this address";
>        }
> 
> Section 2.1.2, first paragraph. What's here is fine, however, the text fails to
> know that while per-recipient rejection after DATA is possible in LMTP it may
> not help prevent blowback, because in most cases the LMTP server  is talking to
> an MTA's LMTP client and that MTA has already accepted the message. It has
> little choice but to turn an LMTP-level rejection into a DSN. I therefore
> suggest adding an additional parenthetical note:
> 
>    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.)
> 
> Section 2.2, numbered list. The formatting here is a little unclear,
> but maybe the best thing to do is leave it to the RFC Editor to
> deal with.
> 
> Additionally, I don't think of messages as "containing" recipients. I therefore
> suggest changing "message contains a single recipient" to "message has
> a single recipient".
> 
> Section 2.2, last two paragraphs before example. This text discusses
> the script generation issue and is of sufficient importance I suggest moving
> it to a separate section by itself.
> 
> Finally, the [SIEVEBIS] and [VACATION] references need to be updated. Thie
> [Joe-DOS] reference also looks a bit off to me.
> 
> THat's it!
> 
> And now a response to Matthew's comments.
> 
> > There is reluctance to change the current behaviour for what was
> > presented as nothing more than an unwillingness to explain what we all
> > agreed were net good reasons for the change to a customer!
> 
> It's customers  plural, and we're talking about organizations with millions of
> users. This is a much bigger issue than you seem to think.
> 
> > The push to
> > change the draft in a way that (unlike the versions I worked on - i.e.
> > from pre-00 to Change log entry 07) makes it significantly fail to
> > address the blowback issue that was my primary motivation for getting
> > involved is not an improvement; it changes a view that had on-list
> > consensus for a long time, through many revision changes.
> 
> > My last long post to the list to draw out views on this issue in order
> > to move forward was answered by the blocker, Ned, IIRC.
> 
> > I just reread the "Spam blowback from Sieve implementations." thread to
> > refresh my memory.
> 
> This was back in 2006, so I also went back and reread it just now.
> 
> >  I reread Ned's posts, which made it explicit that
> > he had no intention of directly responding to the question I posed to
> > him, but his view is clear.   Ned's answer to my question below is (an
> > implicit but clear) yes:
> 
> On the contrary, what I said back them was that my objection was essentially
> orthogonal to this issue. Specifically, my concern was and is that existing
> useage of reject (which to the extent we use it is NOT used as a means of
> dealing with spam) not be mucked with gratuitously. I never expressed or
> implied any preference for how some additional action should behave or what the
> requirements associated with it should be.
> 
> > > Do we want to have the spec allow implementers to not bother to
> > > implement the ability to do proper smtp-time refusals, even though all
> > > implementers at the meeting indicated that it was possible for the
> > > implementations to be changed so that they could do so, and not doing so
> > > produces and will continue to produce immense economic harm caused by
> > > spam blowback?
> 
> > We've discussed the issue pretty throughly in that thread and though Ned
> > and others have made notable points, we still disagree, or at least my
> > opinion remains the same.  My answer, after balancing the pros and cons,
> > is still no.
> 
> And so is mine - if we're talking about ereject rather than reject.
> 
> > I strongly support requiring a change to the default behaviour, and most
> > certainly requiring that all implementations implement the ability to do
> > proper smtp-time (or lmtp-time) protocol-level refusals (other than
> > MUA-based implementations).  It's an important interoperability issue.
> 
> Yes, but the current draft already does this.
> 
> > Given the current draft, the latter requires a small change:
> 
> > To the sentence that begins:
> 
> > "The Sieve interpreter MUST carry out one of the following actions
> > (listed in order from most to least preferred),"
> > add something like:
> > "MUST support the user's choice to carry out the most preferable action
> > possible"
> 
> But the draft already says "SHOULD carry out the most preferable action". RFC
> 2119 SHOULD means "MUST do it unless you have a really good reason not to". And
> since the possibility of multiple recipients means we cannot require SMTP level
> rejection, a SHOULD is the best we can do here.
> 
> Now, this can actually be phrased using MUST by adding an additional
> qualifier: "MUST carry out the most preferable action possible". I have
> no problem with such a change if it makes you happier.
> 
> As for your suggested text, I confess I haven't a clue what you mean by "user's
> choice" in this context, so I really cannot evaluate it.
> 
> > An alternate (perhaps clearer) way of accomplishing this would be to
> > require that all (but MUA-based) implementations supporting 'reject'
> > also support 'ereject': change
> > "   The ereject action MUST NOT be available in environments that do not
> >    support protocol level rejection, e.g. an MUA."
> > to
> > "   The ereject action MUST NOT be available in environments that do not
> >    support protocol level rejection, e.g. an MUA, but MUST be available
> >    in all other environments that support the reject action"
> 
> I would say "and MUST" instead of "but MUST", but aside from that I have no
> problem with requiring implementations that can support ereject offer it as an
> alternative to reject. So, if others agree, by all means add this.
> 
> 				Ned
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4Q6OFwN011567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 May 2008 23:24:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4Q6OFfq011565; Sun, 25 May 2008 23:24:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4Q6OCNb011525 for <[e-mail]>; Sun, 25 May 2008 23:24:14 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.4] ((unknown) [89.163.8.23])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 26 May 2008 07:24:11 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Mon, 26 May 2008 07:24:09 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>> > > I finally had a chance to look at this. Having done so, the 
>> question I really
>> > > want to ask is has anyone implemented this, and if they  did, how 
>> well did it
>> > > work? And if the answer to that is "no implementations yet", I'd 
>> then like to
>> > > hear if anyone is planning to implement this, and if so, when and 
>> for what
>> > > puropse?
>
>> > The whole thing just leaves me a quivering mess, whimpering in a
>> > corner and yearning for the good old days, when if one APPENDed
>> > message literal in a MULTAPPEND set was accepted, one could breathe a
>> > sigh of relief and use LITERAL+ to do heavy pipelining on the rest.
>
>> > I'm still not entirely sure how IMAP-SIEVE would signal *which*
>> > message failed in a MULTIAPPEND set, actually
>
>> Dave, I don't understand how is this different from MULTIAPPEND without
>> IMAP Sieve: an IMAP Sieve script can't "fail" append. It can only
>> discard message after it gets appended (see section 3.6).
>
> And as I said in my comments, I view this as a significant omission 
> that needs
> to be corrected.

Possibly (I haven't made my mind on this yet).
I would just point out that your change would create an extra failure 
case that isn't present in IMAP Sieve now.

> As for the MULTIAPPEND issue, well, I've already commented on
> what I view to be the inadequacy of IMAP error reporting in other 
> contexts.

This is solvable by defining a new response code (or a new response).

>> > - I did look, and Section 2.2.2's coverage of this particular problem
>> > is, well, exceedingly economic.
>> >
>> > But this is a specific issue, rather than the more general problem.
>>  [...]
>> > This ignores the interesting cases of whether an implementation
>> > ignores, for the purposes of Sieve, events caused by Sieve scripts,
>> > since otherwise two mailboxes could have conflicting scripts that
>> > cheerfully bounced an APPENDed message backwards and forwards for all
>> > eternity.
>
>> Sieve fileinto caused by IMAP Sieve is not the same as IMAP COPY, but in
>> order to avoid any doubts I agree that the Security Considerations
>> should also mention that.
>
> I agree with this as far it goes, but it caused me to review the text on
> fileinto in the base Sieve specification as well as in the IMAP sieve 
> document,
> and I'm afraid what turned up is another impedance mismatch that needs 
> to be
> addressed.
>
> The base spec basically says that
>
>   fileinto "foo";
>
> causes the message to be placed in a mailbox named "foo". It then goes 
> on to
> discuss the access control issues this can cause, especially in the 
> case where
> the mailbox doesn't already exist. Conspiciously absent from any of 
> this is
> discussion of mailbox hierarchy - what, say,
>
>   fileinto "foo/bar";
> means is entirely implementation dependent. And if this case is 
> interesting,
> something like
>
>   fileinto "/foo/bar";
>
> has even more interesting implications. The reason for not nailing any 
> of this
> down is of course that Sieve does not presuppose a particular store 
> backend of
> any kind.
>
> Also implicit in this discussion is that the sieve in question has an
> identifiable owner that has access rights to the store. Also, in 
> practice the
> argument of fileinto is also interpreted in the context of where the 
> user's
> default mailbox is located - foo is normally placed at the same level 
> in the
> hierarchy as their inbox.
>
> Now consider how this changes when Sieves are used in IMAP. Now we're 
> dealing
> with a specific sort of store with very specific semantics. So now these
> semantics can and should be nailed down, but the draft currently fails 
> to do
> so.

Maybe so. I am not entirely clear what needs to be written to clarify that.

Isode's implementation just treats the fileinto argument as an IMAP 
mailbox name. So if it contains a shared folder prefix, this would cause 
mail to be filed into the shared folder.

> And then there's the access control issue. Presumably if a script is 
> attached
> to a user mailbox is "owned" by that user and inherits his or her access
> rights. (If so, this also needs to be explicitly stated.)

Right.

> But what about scripts attached to public mailboxes, ones that have no 
> owner?
> Who owns them and what rights do such scripts have?
>
> And what about the server script? Who owns it and what rights does it 
> have?

These are all interesting questions. I agree that they should be discussed.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4PNnnIS084101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 May 2008 16:49:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4PNnnSZ084099; Sun, 25 May 2008 16:49:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4PNnmIO084083 for <[e-mail]>; Sun, 25 May 2008 16:49:48 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 25 May 2008 16:49:46 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 25 May 2008 16:49:43 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1211759385; h=Date:	 From:Subject:MIME-version:Content-type; b=UoQsvl1uZc7t2jH3/OntsTKf7 2Dk4hZWS8j0OTrG6mmIOaJKRQIpyN5NBuF6TAgGPm7Gn9oluGXKssLVEjQmLA==
Date: Sun, 25 May 2008 15:17:27 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
In-reply-to: "Your message dated Sat, 24 May 2008 11:24:35 +0400" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > > I finally had a chance to look at this. Having done so, the question I really
> > > want to ask is has anyone implemented this, and if they  did, how well did it
> > > work? And if the answer to that is "no implementations yet", I'd then like to
> > > hear if anyone is planning to implement this, and if so, when and for what
> > > puropse?

> > The whole thing just leaves me a quivering mess, whimpering in a
> > corner and yearning for the good old days, when if one APPENDed
> > message literal in a MULTAPPEND set was accepted, one could breathe a
> > sigh of relief and use LITERAL+ to do heavy pipelining on the rest.

> > I'm still not entirely sure how IMAP-SIEVE would signal *which*
> > message failed in a MULTIAPPEND set, actually

> Dave, I don't understand how is this different from MULTIAPPEND without
> IMAP Sieve: an IMAP Sieve script can't "fail" append. It can only
> discard message after it gets appended (see section 3.6).

And as I said in my comments, I view this as a significant omission that needs
to be corrected. As for the MULTIAPPEND issue, well, I've already commented on
what I view to be the inadequacy of IMAP error reporting in other contexts.

> > - I did look, and Section 2.2.2's coverage of this particular problem
> > is, well, exceedingly economic.
> >
> > But this is a specific issue, rather than the more general problem.
>  [...]
> > This ignores the interesting cases of whether an implementation
> > ignores, for the purposes of Sieve, events caused by Sieve scripts,
> > since otherwise two mailboxes could have conflicting scripts that
> > cheerfully bounced an APPENDed message backwards and forwards for all
> > eternity.

> Sieve fileinto caused by IMAP Sieve is not the same as IMAP COPY, but in
> order to avoid any doubts I agree that the Security Considerations
> should also mention that.

I agree with this as far it goes, but it caused me to review the text on
fileinto in the base Sieve specification as well as in the IMAP sieve document,
and I'm afraid what turned up is another impedance mismatch that needs to be
addressed.

The base spec basically says that

   fileinto "foo";

causes the message to be placed in a mailbox named "foo". It then goes on to
discuss the access control issues this can cause, especially in the case where
the mailbox doesn't already exist. Conspiciously absent from any of this is
discussion of mailbox hierarchy - what, say,

   fileinto "foo/bar"; 

means is entirely implementation dependent. And if this case is interesting,
something like

   fileinto "/foo/bar";

has even more interesting implications. The reason for not nailing any of this
down is of course that Sieve does not presuppose a particular store backend of
any kind.

Also implicit in this discussion is that the sieve in question has an
identifiable owner that has access rights to the store. Also, in practice the
argument of fileinto is also interpreted in the context of where the user's
default mailbox is located - foo is normally placed at the same level in the
hierarchy as their inbox.

Now consider how this changes when Sieves are used in IMAP. Now we're dealing
with a specific sort of store with very specific semantics. So now these
semantics can and should be nailed down, but the draft currently fails to do
so.

And then there's the access control issue. Presumably if a script is attached
to a user mailbox is "owned" by that user and inherits his or her access
rights. (If so, this also needs to be explicitly stated.)

But what about scripts attached to public mailboxes, ones that have no owner?
Who owns them and what rights do such scripts have?

And what about the server script? Who owns it and what rights does it have?

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4OE14VJ026187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 May 2008 07:01:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4OE14vL026180; Sat, 24 May 2008 07:01:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4OE11YB026125 for <[e-mail]>; Sat, 24 May 2008 07:01:02 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id EBEF84AC7C for <[e-mail]>; Sat, 24 May 2008 16:00:59 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1211637640-77748-2464; Sat, 24 May 2008 16:00:40 +0200
Message-Id: <[e-mail]>
Date: Sat, 24 May 2008 16:00:25 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <cDxp+XoeqfU8rEAvX/0/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> Can you elaborate why?

Dave summed it up better than I could.

I realise there are use cases for some, most or perhaps all of 
imap-sieve. But the use cases aren't all there is: there's also an 
apparently infinite number of nasty scary cases.

In case it's not obvious, I would prefer that lemonade profile-bis avoid 
any reference to imap-sieve.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4O9rt8i040019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 May 2008 02:53:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4O9rt00040018; Sat, 24 May 2008 02:53:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4O9rsXB040003 for <[e-mail]>; Sat, 24 May 2008 02:53:55 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.11] (atomnet2.ttr.ru [195.245.249.86])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 24 May 2008 10:53:54 +0100
Message-ID: <[e-mail]>
Date: Sat, 24 May 2008 13:53:56 +0400
From: Alexey Melnikov <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <cDxp+XoeqfU8rEAvX/0/[e-mail]>
In-Reply-To: <cDxp+XoeqfU8rEAvX/0/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:
> I looked at imap-sieve long ago and decided that I wanted no part of it.
>   
Can you elaborate why?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4O9TL3H030862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 May 2008 02:29:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4O9TLFp030857; Sat, 24 May 2008 02:29:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4O9TI1G030839 for <[e-mail]>; Sat, 24 May 2008 02:29:19 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id B0FFB4AC7B; Sat, 24 May 2008 11:29:12 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1211621343-77748-2401; Sat, 24 May 2008 11:29:03 +0200
Message-Id: <cDxp+XoeqfU8rEAvX/0/[e-mail]>
Date: Sat, 24 May 2008 11:28:43 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
Cc: Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>, Dave Cridland <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I looked at imap-sieve long ago and decided that I wanted no part of it.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4O7OZoT087727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 May 2008 00:24:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4O7OZMc087726; Sat, 24 May 2008 00:24:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4O7OXQo087699 for <[e-mail]>; Sat, 24 May 2008 00:24:34 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.11] (atomnet2.ttr.ru [195.245.249.86])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 24 May 2008 08:24:32 +0100
Message-ID: <[e-mail]>
Date: Sat, 24 May 2008 11:24:35 +0400
From: Alexey Melnikov <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
To: Dave Cridland <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland wrote:
> On Fri May 23 16:40:57 2008, Ned Freed wrote:
>>> Alexey Melnikov wrote:
>>> > While this is a Lemonade WG document, this document is of 
>>> relevance to
>>> > the Sieve WG mailing list and should be reviewed here.
>>> >
>>> > So please review
>>> > 
>>> <http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-05.txt> 
>>>
>>> > before May 5th.
>>> I haven't seen any reviews of this. Can you please send me a quick 
>>> "I've
>>> reviewed it and it looks fine" or "this needs more work" to me, if
>>> you've done a review.
>> I finally had a chance to look at this. Having done so, the question 
>> I really
>> want to ask is has anyone implemented this, and if they  did, how 
>> well did it
>> work? And if the answer to that is "no implementations yet", I'd then 
>> like to
>> hear if anyone is planning to implement this, and if so, when and for 
>> what
>> puropse?
> The whole thing just leaves me a quivering mess, whimpering in a 
> corner and yearning for the good old days, when if one APPENDed 
> message literal in a MULTAPPEND set was accepted, one could breathe a 
> sigh of relief and use LITERAL+ to do heavy pipelining on the rest.
>
> I'm still not entirely sure how IMAP-SIEVE would signal *which* 
> message failed in a MULTIAPPEND set, actually
Dave, I don't understand how is this different from MULTIAPPEND without 
IMAP Sieve: an IMAP Sieve script can't "fail" append. It can only 
discard message after it gets appended (see section 3.6).
> - I did look, and Section 2.2.2's coverage of this particular problem 
> is, well, exceedingly economic.
>
> But this is a specific issue, rather than the more general problem.
 [...]
> This ignores the interesting cases of whether an implementation 
> ignores, for the purposes of Sieve, events caused by Sieve scripts, 
> since otherwise two mailboxes could have conflicting scripts that 
> cheerfully bounced an APPENDed message backwards and forwards for all 
> eternity.
Sieve fileinto caused by IMAP Sieve is not the same as IMAP COPY, but in 
order to avoid any doubts I agree that the Security Considerations 
should also mention that.
> The Security Considerations section clearly states that 
> implementations might choose to do so, maybe, but only for flagchanges 
> on Tuesdays in Summer during non-leap years.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4NNY8uU032330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2008 16:34:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4NNY8hD032329; Fri, 23 May 2008 16:34:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net ([IPv6:2001:838:378:0:211:9ff:fe2c:e28e]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4NNY6xh032304 for <[e-mail]>; Fri, 23 May 2008 16:34:07 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Sat, 24 May 2008 00:33:51 +0100
Subject: Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Sat, 24 May 2008 00:33:49 +0100
From: Dave Cridland <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: <[e-mail]>, Alexey Melnikov <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri May 23 16:40:57 2008, Ned Freed wrote:
> 
> 
>> Alexey Melnikov wrote:
>> > While this is a Lemonade WG document, this document is of  
>> relevance to
>> > the Sieve WG mailing list and should be reviewed here.
>> >
>> > So please review
>> >  
>> <http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-05.txt>
>> > before May 5th.
> 
>> I haven't seen any reviews of this. Can you please send me a quick  
>> "I've
>> reviewed it and it looks fine" or "this needs more work" to me, if
>> you've done a review.
> 
> I finally had a chance to look at this. Having done so, the  
> question I really
> want to ask is has anyone implemented this, and if they  did, how  
> well did it
> work? And if the answer to that is "no implementations yet", I'd  
> then like to
> hear if anyone is planning to implement this, and if so, when and  
> for what
> puropse?
> 
> 
The whole thing just leaves me a quivering mess, whimpering in a  
corner and yearning for the good old days, when if one APPENDed  
message literal in a MULTAPPEND set was accepted, one could breathe a  
sigh of relief and use LITERAL+ to do heavy pipelining on the rest.

I'm still not entirely sure how IMAP-SIEVE would signal *which*  
message failed in a MULTIAPPEND set, actually - I did look, and  
Section 2.2.2's coverage of this particular problem is, well,  
exceedingly economic.

But this is a specific issue, rather than the more general problem.

> The general problem I see here is that Sieve is specified to  
> operate in a
> fairly narrow context: At or around the time of final delivery.  
> This has
> influenced Sieve design choices in subtle ways and, now that we  
> have such an
> extensive body of work on Sieve-related stuff, tracking down all of  
> the
> implicit assumptions of context and reworking them so that Sieve  
> can operate in
> the context of the message store is very difficult. There are  
> almost certainly
> going to be things we miss or get wrong, and I think implementation  
> experience
> is about the only way we're going to find all the impedance  
> mismatches.
> 
> 
I have to admit to having had some concern over the document since  
its inception, but I've really been unable to pin down exactly what  
was bothering me about it - but in general terms it was indeed the  
unspoken assumptions.

The scary thing is that what you describe is a whole class of  
assumption I hadn't even considered - I was merely considering the  
class of assumption that IMAP client authors - who are hard enough to  
persuade into doing any actual IMAP client authoring, frankly, at the  
best of times - might well have made, and probably will wish to  
continue making, over time. A halfway predictable message store would  
be one of them, speaking personally.

Another class of assumption is that IMAP server developers are used  
to the requirements that certain operations are atomic, and running  
an arbitrary SIEVE script atomically doesn't quite fit into this  
frame of thought. Still, there are worse things, such as repeatedly  
stabbing myself in the navel with a rusty fork, and I suppose I  
shouldn't complain, since in as much as I can see, there is no  
requirement for self-mutilation anywhere in the specification. Nor,  
though, is there any mention of this in, say, Section 2.2.2, where it  
talks about the MULTIAPPEND case. (I was looking for a discussion of  
atomicity, not fork-stabbing, in case that's not clear. I did have a  
quick scan for self-mutilation, but aside from a brief mention of  
ManageSIEVE, there's nothing).

Uploading viruses, or uploading messages over a certain size, are  
both sensible things to want to prevent - but I have to admit to  
struggling to understand why an administrator would prefer to use a  
complicated script instead of a simple configuration setting,  
especially given that the complicated script will get executed for  
every flag change, too. Yay, go efficiency.

This ignores the interesting cases of whether an implementation  
ignores, for the purposes of Sieve, events caused by Sieve scripts,  
since otherwise two mailboxes could have conflicting scripts that  
cheerfully bounced an APPENDed message backwards and forwards for all  
eternity. The Security Considerations section clearly states that  
implementations might choose to do so, maybe, but only for  
flagchanges on Tuesdays in Summer during non-leap years.

There may very well be useful cases for this extension, above and  
beyond bringing on nervous breakdowns in IMAP implementors, hence the  
reason I'm obviously trying to appear positive about it, but these  
are not only likely to be quite rare and uncommon, but if they're  
not, then better solutions are undoubtedly possible.

So, to get back to your original question, I have not yet implemented  
it, and I don't think we have any imminent plans to do so, but I  
cannot speak for my employer in this regard.

I hope this helps answer your question.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4NM7XD1005044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2008 15:07:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4NM7Xui005043; Fri, 23 May 2008 15:07:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4NM7W6R005028 for <[e-mail]>; Fri, 23 May 2008 15:07:32 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 23 May 2008 15:07:30 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 23 May 2008 15:07:28 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1211580449; h=Date:	 From:Subject:MIME-version:Content-type; b=xefVOWfxkuf+wERZbrqTfb+++ gqurYX5N5iUj4QsYVnCyU9Z9I+BnZ/NpZ36m9iJXmV63a2nCbJqs3Ufm7VbOQ==
Date: Fri, 23 May 2008 08:40:57 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
In-reply-to: "Your message dated Fri, 23 May 2008 17:14:51 +0400" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Alexey Melnikov wrote:
> > While this is a Lemonade WG document, this document is of relevance to
> > the Sieve WG mailing list and should be reviewed here.
> >
> > So please review
> > <http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-05.txt>
> > before May 5th.

> I haven't seen any reviews of this. Can you please send me a quick "I've
> reviewed it and it looks fine" or "this needs more work" to me, if
> you've done a review.

I finally had a chance to look at this. Having done so, the question I really
want to ask is has anyone implemented this, and if they  did, how well did it
work? And if the answer to that is "no implementations yet", I'd then like to
hear if anyone is planning to implement this, and if so, when and for what
puropse?

The general problem I see here is that Sieve is specified to operate in a
fairly narrow context: At or around the time of final delivery. This has
influenced Sieve design choices in subtle ways and, now that we have such an
extensive body of work on Sieve-related stuff, tracking down all of the
implicit assumptions of context and reworking them so that Sieve can operate in
the context of the message store is very difficult. There are almost certainly
going to be things we miss or get wrong, and I think implementation experience
is about the only way we're going to find all the impedance mismatches.

Having said all this, I don't know how it translates into a plan of action for
the document. The obvious thing is to do is approve it as experimental, but
this may have the opposite of the indended effect - it may cause the
specification to be ignored because it is "not ready' for standardization.
OTOH, if it approved as proposed but then requires substantive changes, we
could easily end up in a situation with large differences between
implementations. That's not good either.

Now, obviously if someone has implemented this without difficulty then these
concerns are baseless. But if they haven't, I'd like to know to what extent
there are plans to code this, so we have some idea of how to proceed.

Moving on to specifics... Overall the document seems basically OK. I don't see
fundamental problems that would invalidate the entire approach. That said,
there are quite a few details I think need a bit of work.

First up is the interactions with annotations. I can see the value of being
able to get at annotations through Sieve. The trouble is there seems to be a
missing piece: I don't believe a Sieve extension has been defined that get at
annotation data. GIven that that's the case I'm not sure I see the point of the
changedannotation environment item. All this is going to tell you is what
annotations changed - it doesn't tell you whether they were added, or deleted,
or modified, or what's in them if they are still there. Unless there's either
an extension in the works for getting at annotation information (in which case
it needs to be referenced) or there's a use-case for knowing what annotations
have changed (in which case there should be an exmaple of that usage
somewhere), I have to recommend removing the changedannotations environment
item. If need be it can be defined in a subsequent Sieve annotate extension
specification.

Next up is the imap4flags extension. Flag handling is such a key part of IMAP I
really have to wonder how useful this extension is without imap4flags support.
I wonder if it doesn't make more sense to simply require imap4flags support -
given the way imap4flags can be used without variables it isn't especially
difficult to implement. It would certainly simplify the document by removing
lots of qualifiers all over the place.

The imap4flags extension essentially provides two different ways to manipulate
flags: With variables or with the so-called default flag internal variable.
Given some of the examples it appears that the default flag internal variable
is supposed to be set to the current flags on the emssage before the script is
run. I don't believe this is explicitly stated in the document, and it needs to
be. (This document should also reiterate that changes to the default flags
attach to the messages produced by the actions the sieve performs and the final
state of the default flags apply to the implicit keep.)

I note in passing that RFC 5232 doesn't actually say what the initial setting
of the default flags is supposed to be. Empty seems like the only choice for
regular Sieve use and we should spell that out in the next update.

And now for one of those subtle issues: Flag value inspection and manipulation.
A fairly common thing for scripts to do is make copies of their inputs so they
can refer back to the original values independent of any modifications the
script makes. (This is especially common practice in large scripts built up
from various component pieces from different sources.) This is a nonissue
for the imap4flags extension in normal usage: The initial setting of the
default flag internal value is empty. But it isn't empty at startup in this
new usage context. And unless I've missed something, there's no way to capture
the state of this internal variable. The best you can do is grab the first
flag in the set:

    if hasflag :matches "*" {set "doof" "${0}";}

Nowhere near good enough. Or, if you know the names of all the flags you're
ever going to be interested in, you can do:

    setflag "initialflags" "";
    if hasflag :is "flag1" {addflag "initialflags" "flag1";}
    if hasflag :is "flag2" {addflag "initialflags" "flag1";}
    ...
    if hasflag :is "flagn" {addflag "initialflags" "flagn";}

But this is extremely fragile, not to mention verbose and tacky.

The obvious way to address this is to add an additional environment item:
initialflags. This makes it easy to, say, reset the default flags to their
initial settings:

    if environment :matches "initialflags" "*" {setflag "${0}";}

Moving on... redirect. Redirect assumes that the message in hand is suitable
for submission. This is a reasonable assumption in normal Sieve use because the
message is either in transit or has just been in transit. However, I don't
believe, say, IMAP APPEND imposes sufficient requirements on messages for them
to be considered ready for submission. The draft needs to deal with this issue,
but I'm not exactly sure how - perhaps an explicit reference to the SMTP submit
specification plus some statement that if the message is unsuitable for
submission a DSN SHOULD be generated.

Next up is editheader and another subtle but extremely important issue. The
draft quite correctly bans editheader modifications to the message at hand
because such modifications  would violate IMAP semantics. However, this ignores
the extremely important usage of editheader as a meanss of annotating
redirected messages, where no such semantics problem exists. For example, it is
quite common to use editheader to prevent redirection loops:

        /* Don't redirect if we already redirected */
        if not header :contains "X-Sieve-Filtered"
                ["<[e-mail]>", "<[e-mail]>"]
        {
                addheader "X-Sieve-Filtered" "<[e-mail]>";
                redirect "[e-mail]";
        }

(This example is straigth from the editheader draft itself.) Given the added
risks of loops created by this document I really don't want to lose this
capability.

For that matter I'm not sure I see the harm in allowing:

        keep;
        addheader "comment" "extra copy for posterity"
	fileinto "archive";

Unless I'm missing something there should be no reason why an additional
copy of the message created with fileinto has to be identical to the
original.

And there's also the use of editheader as a kind of variable surrogate:

	if <something nasty and complex>
	{ addheader "flag" "whatever";}
	...
	if header :is "flag" "whatever" ...
	...
	deleteheader "flag";

I think this is a bit screwy and of course unnecessary in any implementation
that support variables, but I've seen several customer scripts do it. (And yes,
we support variables.)

I therefore think the outright ban on editheader needs to be lifted and
replaced with someething more nuanced, e.g., editheader, if used, has no
effect on implicit or expliccit keep, but can affect other actions.

Next up is spamtest and virustest. Neither is mentioned in the draft, and IMO
this is a SERIOUS omission. I can say with absolute certainty that one of the
main things, if not the main thing, our customers are going to want to do in
sieves attached to mailboxes: Check appended messages for spam and viruses. And
since headers cannot be used to communicate spam status because of message
immuatability, that leves spamtest and virustest as the only games in town.

And that segres into the next to last item on my list: reject. I think I
understand the reasons for wanting to ban it outright, but this is another one
that just isn't going to play in Peoria. Like it or not, people are going to
want to use this facility to impose access restrictions on IMAP APPEND, and
they are going to be pissed if they can't do it. In fact this is one that
unless there's a fundamental reason we cannot implement this in our store by
havingt it turn a reject into a NO response to APPEND I will recommend that we
simply ignore this restriciton and allow reject.

One final subtle issue. Another thing I'm fairly confident people will want to
do with Sieve in IMAP is implement finer grained access control. (When you
think about it, access control is one of Sieve's main purposes.) But unlike
final delivery, where there's no identity associated with the entity performing
the delivery, there's always an identity associated with someone doing IMAP
stuff. Accordingly, Sievce in IMAP needs to have a way to access this
identity so it can use it as part of its access control checks. THe obvious
way to do it is through another environment item, e.g., user-identifier. So 
you could say stuff like:

    if allof(environment :is "cause" ["append", "copy"],
             not environment :is "user-identifier" "ned",
	     size :over 64K {
      reject "Sorry, I don't allow random bozos to append big messages to my mailbox";
    }

That's it for now, but if nothing else I hope this review has driven home how
easy it is for these impedance mismatch issues to creep in unobserved.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4NDEriI038249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2008 06:14:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4NDErrG038240; Fri, 23 May 2008 06:14:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4NDEpfr038226 for <[e-mail]>; Fri, 23 May 2008 06:14:52 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.11] (atomnet2.ttr.ru [195.245.249.86])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 23 May 2008 14:14:51 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 May 2008 17:14:51 +0400
From: Alexey Melnikov <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
To: [e-mail]
Subject: Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:
> While this is a Lemonade WG document, this document is of relevance to 
> the Sieve WG mailing list and should be reviewed here.
>
> So please review 
> <http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-05.txt> 
> before May 5th.
Folks,
I haven't seen any reviews of this. Can you please send me a quick "I've 
reviewed it and it looks fine" or "this needs more work" to me, if 
you've done a review.

Thanks,
Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4MFHdTA089111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2008 08:17:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4MFHdTI089109; Thu, 22 May 2008 08:17:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4MFHZxL089088 for <[e-mail]>; Thu, 22 May 2008 08:17:38 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 482CD4AC7B for <[e-mail]>; Thu, 22 May 2008 17:17:34 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1211469444-77748-1600; Thu, 22 May 2008 17:17:24 +0200
Message-Id: <[e-mail]>
Date: Thu, 22 May 2008 17:17:13 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Finishing draft-ietf-sieve-refuse-reject-06.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FWIW. My silence is because I don't greatly care. I don't recall much 
about the remaining issues, but I do recall reading the thread and 
thinking that I'd be happy no matter what. So +1 on everything, 
anything, that leads to RFC publication.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LNjXMn075266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2008 16:45:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4LNjXIJ075264; Wed, 21 May 2008 16:45:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LNjTAm075239 for <[e-mail]>; Wed, 21 May 2008 16:45:29 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 21 May 2008 16:45:24 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 21 May 2008 16:45:20 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1211413524; h=Date:	 From:Subject:MIME-version:Content-type; b=kJknWumZm8GFqglGCSjrP7M5Z TTPnkE/Yfru6OFfunAmejnFUQPmG8/7tErIcSXrcwsCMQktE+HyN8VAxLNHtQ==
Date: Wed, 21 May 2008 15:00:14 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Finishing draft-ietf-sieve-refuse-reject-06.txt
In-reply-to: "Your message dated Mon, 21 Jan 2008 11:59:46 -0800" <[e-mail]>
To: [e-mail]
Cc: Matthew Elvey <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think the time has come to reach closure on this draft and move it forward.
I've therefore done a careful review. I think the draft is technically fine but
I do have a number of suggestions for editorial improvements. I will also
respond to the final comments Mathhew made on this back in January - I don't
believe anyone else responded to him.

The third paragraph of the abstract says:

   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.

The last sentence here isn't quite right - ereject makes it possible for
SMTP level refusal to occur but cannot guarantee it. I suggest changing
this to read:

   This memo updates the definition of the "reject" action to allow
   messages to be refused during the SMTP transaction, and defines the
   "ereject" action, which unlike "reject" requires messages be
   refused during the SMTP transaction whenever possible.

The second paragraph of the introduction has the same issue. I suggest
adding "if possible" at the end:

   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.

Section 1.1, second paragraph, last sentence:

   Implementations are advised to follow best practices and
   keep abreast of current research in these fields.

I think my implementation is pretty cool but I doubt it is capable of this.
How about "implementors" rather than "implementations"?

Section 2.1. The section on reject has an example at the end, how about having
one here? (I really want ereject to appear on a par with reject in every
way.) A simple one showing rejecting all mail from a particular address would
be good, so how about:

       require ["ereject"];

       if address "from" "[e-mail]" {
         ereject "Sorry, I no longer accept mail from this address";
       }

Section 2.1.2, first paragraph. What's here is fine, however, the text fails to
know that while per-recipient rejection after DATA is possible in LMTP it may
not help prevent blowback, because in most cases the LMTP server  is talking to
an MTA's LMTP client and that MTA has already accepted the message. It has
little choice but to turn an LMTP-level rejection into a DSN. I therefore
suggest adding an additional parenthetical note:

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

Section 2.2, numbered list. The formatting here is a little unclear,
but maybe the best thing to do is leave it to the RFC Editor to
deal with.

Additionally, I don't think of messages as "containing" recipients. I therefore
suggest changing "message contains a single recipient" to "message has
a single recipient".

Section 2.2, last two paragraphs before example. This text discusses
the script generation issue and is of sufficient importance I suggest moving
it to a separate section by itself.

Finally, the [SIEVEBIS] and [VACATION] references need to be updated. Thie
[Joe-DOS] reference also looks a bit off to me.

THat's it!

And now a response to Matthew's comments.

> There is reluctance to change the current behaviour for what was
> presented as nothing more than an unwillingness to explain what we all
> agreed were net good reasons for the change to a customer!

It's customers  plural, and we're talking about organizations with millions of
users. This is a much bigger issue than you seem to think.

> The push to
> change the draft in a way that (unlike the versions I worked on - i.e.
> from pre-00 to Change log entry 07) makes it significantly fail to
> address the blowback issue that was my primary motivation for getting
> involved is not an improvement; it changes a view that had on-list
> consensus for a long time, through many revision changes.

> My last long post to the list to draw out views on this issue in order
> to move forward was answered by the blocker, Ned, IIRC.

> I just reread the "Spam blowback from Sieve implementations." thread to
> refresh my memory.

This was back in 2006, so I also went back and reread it just now.

>  I reread Ned's posts, which made it explicit that
> he had no intention of directly responding to the question I posed to
> him, but his view is clear.   Ned's answer to my question below is (an
> implicit but clear) yes:

On the contrary, what I said back them was that my objection was essentially
orthogonal to this issue. Specifically, my concern was and is that existing
useage of reject (which to the extent we use it is NOT used as a means of
dealing with spam) not be mucked with gratuitously. I never expressed or
implied any preference for how some additional action should behave or what the
requirements associated with it should be.

> > Do we want to have the spec allow implementers to not bother to
> > implement the ability to do proper smtp-time refusals, even though all
> > implementers at the meeting indicated that it was possible for the
> > implementations to be changed so that they could do so, and not doing so
> > produces and will continue to produce immense economic harm caused by
> > spam blowback?

> We've discussed the issue pretty throughly in that thread and though Ned
> and others have made notable points, we still disagree, or at least my
> opinion remains the same.  My answer, after balancing the pros and cons,
> is still no.

And so is mine - if we're talking about ereject rather than reject.

> I strongly support requiring a change to the default behaviour, and most
> certainly requiring that all implementations implement the ability to do
> proper smtp-time (or lmtp-time) protocol-level refusals (other than
> MUA-based implementations).  It's an important interoperability issue.

Yes, but the current draft already does this.

> Given the current draft, the latter requires a small change:

> To the sentence that begins:

> "The Sieve interpreter MUST carry out one of the following actions
> (listed in order from most to least preferred),"
> add something like:
> "MUST support the user's choice to carry out the most preferable action
> possible"

But the draft already says "SHOULD carry out the most preferable action". RFC
2119 SHOULD means "MUST do it unless you have a really good reason not to". And
since the possibility of multiple recipients means we cannot require SMTP level
rejection, a SHOULD is the best we can do here.

Now, this can actually be phrased using MUST by adding an additional
qualifier: "MUST carry out the most preferable action possible". I have
no problem with such a change if it makes you happier.

As for your suggested text, I confess I haven't a clue what you mean by "user's
choice" in this context, so I really cannot evaluate it.

> An alternate (perhaps clearer) way of accomplishing this would be to
> require that all (but MUA-based) implementations supporting 'reject'
> also support 'ereject': change
> "   The ereject action MUST NOT be available in environments that do not
>    support protocol level rejection, e.g. an MUA."
> to
> "   The ereject action MUST NOT be available in environments that do not
>    support protocol level rejection, e.g. an MUA, but MUST be available
>    in all other environments that support the reject action"

I would say "and MUST" instead of "but MUST", but aside from that I have no
problem with requiring implementations that can support ereject offer it as an
alternative to reject. So, if others agree, by all means add this.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4EB4Aog032046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2008 04:04:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4EB4Af4032045; Wed, 14 May 2008 04:04:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4EB3dlw031999 for <[e-mail]>; Wed, 14 May 2008 04:04:10 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 47B274AC8A; Wed, 14 May 2008 13:03:33 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1210763002-14631-292; Wed, 14 May 2008 13:03:22 +0200
Message-Id: <[e-mail]>
Date: Wed, 14 May 2008 13:03:12 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: 5233 gotcha, perhaps
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> If your system allow for subaddress, then yes, you need to test :user 
> and :domain separately.

A bit of a pain... I've seen more than one guide to writing sieve 
scripts with examples like
   if address :is :all "from" "[e-mail]" { ...
and I dislike it when examples don't apply to my code.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4EAdV6o029615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2008 03:39:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4EAdVxx029614; Wed, 14 May 2008 03:39:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4EAd0tk029529 for <[e-mail]>; Wed, 14 May 2008 03:39:30 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.2] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 14 May 2008 11:38:59 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Wed, 14 May 2008 11:38:58 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: 5233 gotcha, perhaps
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Arnt,

Arnt Gulbrandsen wrote:

> Maybe I'm just being dense. Does :all correspond to user@domain, or to 
> userseparatordetail@domain?

:all corresponds the whole email address as supplied, i.e. to either 
user@domain or user+detail@domain.

> Both seem to be desirable.
>
> If the latter, then the fairly common idiom
>    if envelope :is :all "[e-mail]" { ...
> is not compatible with using subaddresses.

If your system allow for subaddress, then yes, you need to test :user 
and :domain separately.

> Hm.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4E9VfiV021516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2008 02:31:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m4E9VfAO021515; Wed, 14 May 2008 02:31:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4E9V9JM021472 for <[e-mail]>; Wed, 14 May 2008 02:31:40 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id AC54B4AC22 for <[e-mail]>; Wed, 14 May 2008 11:31:08 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1210757457-14631-242; Wed, 14 May 2008 11:30:57 +0200
Message-Id: <[e-mail]>
Date: Wed, 14 May 2008 11:30:47 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: 5233 gotcha, perhaps
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Maybe I'm just being dense. Does :all correspond to user@domain, or to 
userseparatordetail@domain?

Both seem to be desirable.

If the latter, then the fairly common idiom
    if envelope :is :all "[e-mail]" { ...
is not compatible with using subaddresses.

Hm.

Arnt