Re: Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt, take 2

[Ned Freed <[e-mail]>]

> Ned Freed wrote:

> >> 2). Ned wrote in a separate email about # 2:
> >
> >> > Script analysis is one of those tri-state things. It can conclude
> >> that:
> >> >
> >> > (1) A script is harmless.
> >> > (2) A script is harmful.
> >> > (3) The script cannot be analyzed.
> >> >
> >> > Now, in practice the _overwhelming_ majority of actual scripts will
> >> fall into
> >> > one of the first two categories. This is especially true when
> >> scripts are
> >> > created by a GUI - GUIs tools tend to construct straightforward
> >> scripts without
> >> > any of the complexities that hinder analysis.
> >> >
> >> > And even when the conclusion is (3), that actually tells you
> >> something. A
> >> > really sophisticated system might even note the presence of a highly
> >> > complicated script and watch even more carefully for abuse.
> >> >
> >> > Heck, even a very naive analysis can be useful. For example, to the
> >> extent
> >> > redirect offers capabilities beyond those of a .forward file, they
> >> only arise
> >> > when the address redirect sends the message to can be controlled by
> >> the message
> >> > itself. For that you really need Sieve variables (and hence this is
> >> out of
> >> > scope for the Sieve base specification). So one very simple thing
> >> you can do is
> >> > look for the use of variables and the presence of ${} constructs in
> >> redirects.
> >> > A setup that allows users to configure arbitrary sieves might want
> >> to check for
> >> > this combination and either disallow or flag it in some way.
> >
> >> I don't think the discussion about looking for variables in the redirect
> >> address belongs to the 3028bis, because 3028bis itself has no variables.
> >> Apart from that something along the lines of Ned's text can be included.
> >
> > Agreed. I can work on a cut down version if you want.

> Yes please.

With all the back and forth on this I'm afraid I've lost track of the
current set of proposed revisions. If you could send them to me I'll see
about adding these points to them without getting into the issues Sieve
variables raises.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8UNkpel022076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Sep 2007 16:46:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8UNkpTj022075; Sun, 30 Sep 2007 16:46:51 -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.13.5/8.13.5) with ESMTP id l8UNkjYb022059 for <[e-mail]>; Sun, 30 Sep 2007 16:46:46 -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, 30 Sep 2007 16:46:37 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 30 Sep 2007 16:46:34 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail], Cullen Jennings <[e-mail]>, Lisa Dusseault <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Sun, 30 Sep 2007 16:45:40 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt, take 2
In-reply-to: "Your message dated Thu, 27 Sep 2007 12:08:08 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Alexey Melnikov <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1191195995; h=Date:	 From:Subject:MIME-version:Content-type; b=NJygjgOqjjnIt75Zue2+afSL8 lQFz1TWMd1LHtQF7pEsI2vgJ70TI5xiSsCyjeHkJpK2I4O/jFDtbu6r8y5CBA==
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:

> >> 2). Ned wrote in a separate email about # 2:
> >
> >> > Script analysis is one of those tri-state things. It can conclude
> >> that:
> >> >
> >> > (1) A script is harmless.
> >> > (2) A script is harmful.
> >> > (3) The script cannot be analyzed.
> >> >
> >> > Now, in practice the _overwhelming_ majority of actual scripts will
> >> fall into
> >> > one of the first two categories. This is especially true when
> >> scripts are
> >> > created by a GUI - GUIs tools tend to construct straightforward
> >> scripts without
> >> > any of the complexities that hinder analysis.
> >> >
> >> > And even when the conclusion is (3), that actually tells you
> >> something. A
> >> > really sophisticated system might even note the presence of a highly
> >> > complicated script and watch even more carefully for abuse.
> >> >
> >> > Heck, even a very naive analysis can be useful. For example, to the
> >> extent
> >> > redirect offers capabilities beyond those of a .forward file, they
> >> only arise
> >> > when the address redirect sends the message to can be controlled by
> >> the message
> >> > itself. For that you really need Sieve variables (and hence this is
> >> out of
> >> > scope for the Sieve base specification). So one very simple thing
> >> you can do is
> >> > look for the use of variables and the presence of ${} constructs in
> >> redirects.
> >> > A setup that allows users to configure arbitrary sieves might want
> >> to check for
> >> > this combination and either disallow or flag it in some way.
> >
> >> I don't think the discussion about looking for variables in the redirect
> >> address belongs to the 3028bis, because 3028bis itself has no variables.
> >> Apart from that something along the lines of Ned's text can be included.
> >
> > Agreed. I can work on a cut down version if you want.

> Yes please.

With all the back and forth on this I'm afraid I've lost track of the
current set of proposed revisions. If you could send them to me I'll see
about adding these points to them without getting into the issues Sieve
variables raises.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8SEegnV022855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 07:40:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8SEegx2022854; Fri, 28 Sep 2007 07:40:42 -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.13.5/8.13.5) with ESMTP id l8SEeffp022847 for <[e-mail]>; Fri, 28 Sep 2007 07:40:42 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <Rv0SZwBsKB=[e-mail]>; Fri, 28 Sep 2007 15:40:40 +0100
Message-ID: <[e-mail]>
Date: Fri, 28 Sep 2007 15:40:32 +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: Cyrus Daboo <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: notify-xmpp implementations?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; 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>

Cyrus Daboo wrote:

> Hi,
> Quick question does anyone have, or planning on doing, an 
> implementation of the notify-xmpp extension?

Isode will implement it.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8SEFbNq021202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 07:15:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8SEFbfA021196; Fri, 28 Sep 2007 07:15:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8SEFXWM021154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 28 Sep 2007 07:15:36 -0700 (MST) (envelope-from [e-mail])
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8SEFQBg005861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 28 Sep 2007 10:15:29 -0400
Date: Fri, 28 Sep 2007 10:15:21 -0400
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: notify-xmpp implementations?
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
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,
Quick question does anyone have, or planning on doing, an implementation of 
the notify-xmpp extension?

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8RB7m6n053247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 04:07:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8RB7mGv053245; Thu, 27 Sep 2007 04:07:48 -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.13.5/8.13.5) with ESMTP id l8RB7j8a053227 for <[e-mail]>; Thu, 27 Sep 2007 04:07:46 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 27 Sep 2007 12:07:39 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 Sep 2007 12:08:08 +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: [e-mail], Cullen Jennings <[e-mail]>, Lisa Dusseault <[e-mail]>, [e-mail]
Subject: Re: Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt, take 2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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=us-ascii; 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:

>> 2). Ned wrote in a separate email about # 2:
>
>> > Script analysis is one of those tri-state things. It can conclude 
>> that:
>> >
>> > (1) A script is harmless.
>> > (2) A script is harmful.
>> > (3) The script cannot be analyzed.
>> >
>> > Now, in practice the _overwhelming_ majority of actual scripts will 
>> fall into
>> > one of the first two categories. This is especially true when 
>> scripts are
>> > created by a GUI - GUIs tools tend to construct straightforward 
>> scripts without
>> > any of the complexities that hinder analysis.
>> >
>> > And even when the conclusion is (3), that actually tells you 
>> something. A
>> > really sophisticated system might even note the presence of a highly
>> > complicated script and watch even more carefully for abuse.
>> >
>> > Heck, even a very naive analysis can be useful. For example, to the 
>> extent
>> > redirect offers capabilities beyond those of a .forward file, they 
>> only arise
>> > when the address redirect sends the message to can be controlled by 
>> the message
>> > itself. For that you really need Sieve variables (and hence this is 
>> out of
>> > scope for the Sieve base specification). So one very simple thing 
>> you can do is
>> > look for the use of variables and the presence of ${} constructs in 
>> redirects.
>> > A setup that allows users to configure arbitrary sieves might want 
>> to check for
>> > this combination and either disallow or flag it in some way.
>
>> I don't think the discussion about looking for variables in the redirect
>> address belongs to the 3028bis, because 3028bis itself has no variables.
>> Apart from that something along the lines of Ned's text can be included.
>
> Agreed. I can work on a cut down version if you want.

Yes please.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8QIw9Q4064598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2007 11:58:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8QIw9AJ064597; Wed, 26 Sep 2007 11:58:09 -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.13.5/8.13.5) with ESMTP id l8QIw80Q064591 for <[e-mail]>; Wed, 26 Sep 2007 11:58:08 -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, 26 Sep 2007 11:58:05 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 26 Sep 2007 11:58:01 -0700 (PDT)
Cc: [e-mail], Cullen Jennings <[e-mail]>, Ned Freed <[e-mail]>, Lisa Dusseault <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 25 Sep 2007 13:19:50 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt, take 2
In-reply-to: "Your message dated Sat, 22 Sep 2007 23:16:48 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Alexey Melnikov <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190833083; h=Date:	 From:Subject:MIME-version:Content-type; b=YQkZseD9g48JCibGDCJz66sWE 27iwDtTDQEZIpafprb/0fece8KQqBX2wh7dCuCGK47B66j52JDYSK5ygfSrVw==
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>

> After talking to Cullen Lisa thinks that one or two of the following
> changes should address Cullen's DISCUSS (I assume that the text I've
> suggested earlier should be included in some form into 3028bis anyway,
> this is in addition to this):

> 1). Limit applicability of SIEVE, e.g. to deployments where
> administrators can disable accounts abusing scripts.
> 2). Add text with helpful guidance about script analysis or  forking
> detection.
> 3). Add requirements for use of mail headers to more reliably detect
> forking.

> =======
> So here is some background on the three choices and are my comments on
> them (strictly as an individual contributor).

> 1). This is really no brainer. Any deployed mail system should have a
> way to disable accounts.

Of course they do. It's an absolute requirement for any real world system for
many reasons having nothing to do with Sieve. And most systems provide more
than one way to do it - ours has well over a dozen. I can even recall
discussions of the best ways to disable incoming email for specific accounts,
or for that matter how to disable .forward files specifically, dating back to
the early 80s.

> I would suggest adding the following:

>   Sieve implementations MUST provide facilities to allow administrators
> to disable accounts abusing scripts.

I certainly have no problem with adding such a statement.

> 2). Ned wrote in a separate email about # 2:

> > Script analysis is one of those tri-state things. It can conclude that:
> >
> > (1) A script is harmless.
> > (2) A script is harmful.
> > (3) The script cannot be analyzed.
> >
> > Now, in practice the _overwhelming_ majority of actual scripts will fall into
> > one of the first two categories. This is especially true when scripts are
> > created by a GUI - GUIs tools tend to construct straightforward scripts without
> > any of the complexities that hinder analysis.
> >
> > And even when the conclusion is (3), that actually tells you something. A
> > really sophisticated system might even note the presence of a highly
> > complicated script and watch even more carefully for abuse.
> >
> > Heck, even a very naive analysis can be useful. For example, to the extent
> > redirect offers capabilities beyond those of a .forward file, they only arise
> > when the address redirect sends the message to can be controlled by the message
> > itself. For that you really need Sieve variables (and hence this is out of
> > scope for the Sieve base specification). So one very simple thing you can do is
> > look for the use of variables and the presence of ${} constructs in redirects.
> > A setup that allows users to configure arbitrary sieves might want to check for
> > this combination and either disallow or flag it in some way.

> I don't think the discussion about looking for variables in the redirect
> address belongs to the 3028bis, because 3028bis itself has no variables.
> Apart from that something along the lines of Ned's text can be included.

Agreed. I can work on a cut down version if you want.

> 3). [I hope that the following is not too cryptic for people to
> understand. If it is, I can try to provide a more detailed explanation
> later.] Lisa has suggested in a private email a new header field
> (Mail-Fork-Estimation) that can be used to convey the estimated total
> number of redirects that happened so far as estimated at the previous
> hop. The value of this header is multiplied by the number of redirects
> that happens at the current hop and if it is bigger than 100, the
> message is going to be dropped at the next hop. So this is similar to
> counting Received headers, but compensates for multiple redirects.

First, given the plethora of autoforwarding mechanisms in near-universal use
today, any such mechanism has to be defined as a general email requirement in
order to be in any way effective. Simply requiring Sieve implementations, which
despire being widely deployed nevertheless account for only a tiny fraction of
the autoforwarding capabilities available to end users, isn't going to cut it.

Now let me remind everyone that our purpose here is to work on Sieve, not to
define general mechanisms for email as a whoie. And even if defining this for
Sieve only made sense, here's what our charter says about 3028bis:

(1) Revise the base sieve specification, RFC 3028, with the intention
    of moving it to draft standard. Substantive additions or revisions to
    the base specification are out of scope of this working group. However,
    the need to loosen current restrictions on side effects of tests as well
    as the need for a normative reference to the newly-defined comparators
    registry may necessitate a recycle at proposed.

It is quite clear that this this would be substantive change to the base
specification and as such is clearly out of scope.

Now, as to the question of whether or not it makes sense to define this for
email in general: My main concern is that this mechanism deals with the
necessarily incomplete information a single autoforwarder has by trying figure
out an upper bound on the number of recipients that have been added. The
problem with this is that it is incredibly easy for the upper bound to end up
being much too large. For example, suppose you have one autoforwarder that
spits out 11 recipients, one of which is itself an autforwarder with 10
recipients. Despite the fact that the message is only going to be sent to 20
people at most this case is going to trip the detector and result in the loss
of messages.

The only way to address this is to bump or disable the limit, but the
multiplicative nature of the estimate means that the limit will have to be set
pretty darned high (likely well over 1000) before it ceases to cause trouble.
And at that point the limit is probably not going to be effective at stopping
actual abuse.

The multiplicative nature of the overestimate may even make it possible for
users to game the system to cause deliberate loss of message without themselves
being blamed. For example, suppose I need to send mail to A and B but
I want to insure that B's copy gets lost somewhere along the way. I happen
to know that B has autoforwarding in place to direct his mail to both his
real account and to his pager. All I have to do is set up an autoforwarder
with 50 dummy addresses in additiona to A and B's address. I send the mail
and B's copy exceeds the limit and is silently dropped.

Similar fun and games can actually be had with Received: line limits. The
difference is Received: line counts are additive, making the cutovers between
successful delivery and failure much harder to predict and control.
Multiplcative limits increase much more quickly and are therefore much easier
to target.

The mechanism as currently defined also fails to take into account the very
real case where complete information for multiple autoforwarding hops actually
is available. For example, large enterprises routinely employ complex
mutlilevel autoforwarders with a high degree of overlap between the various
recipient lists. They then depend on the fact that all levels are evalauted in
tandem so duplicate addresses can be eliminated. (I've seen real world cases
where a bug in duplicate elimination logic caused single recipients to receive
around a hundred copies of each message - that's how much overlap there can
be.)

So for this to work in such cases the count either has to be based on the
actual number of recipients that pop out of alias expansion, which is going to
be very difficult to get at in some implementations, or else there has to be a
way to "back out" some number of recipients from the total when it is
determined that they don't actually exist. This may argue for representing the
value as a series of separate fanout estimates you mulitply together to check
rather than collapsing it down to a single number. (Or it may not - I haven't
thought through all the implications and implementation issues fully.)

And there are also privacy implications to consider. Having this header in the
message unavoidably reveals information about the extent to which the message
has been forwarded/redirected. And since that information has to appear in all
copies at ang given point, it can reveal aspects of one recipient's forwarding
activities to another. As it happens I just got off a call regarding a large
customer of ours where exactly this issue came up - this exposure would be a
MAJOR no-no for them. One way to address this would be for this to be done with
an SMTP extension rather than a header field, but that brings along its own
deployment issues.

Another argument against having this as a header is that what's being  
proposed is actually a pretty serious layering violation. Headers are supposed
to be the province of user agents, and while MTAs routinely prepend header
fields to messages they aren't supposed to be mucking around with existing
headers. Of course this can be avoided by using the SMTP extensions approach,
but another way to do it would be to use multiple header fields. Each
autoforwarder would then add an additional fork-count field and the check
would be to multiply the values in all the fields together and see if they
exceed the limit.

And once you get to the idea of using multiple fields for this, this becomes a
variant of another idea that has been around for a long time: Something X.400
calls DLExpansionHistory. In fact if memory serves while the X.400 variant of
this didn't have a way to track the number of recipients added by each
expansion operation, the Message Router variant did have it. So another
question that really should be asked and answered is why there has been
essentially no interest in adapting this approach to Internet mail up to this
point.

The bottom line is what I suspect people are thinking of as a simple addition
to Sieve specifically is in fact a fairly complex matter with lots of
ramifications and implications for email in general. It is therefore totally
inappropriate to consider defining this in the present context.

> While I think this might be a neat research idea and should be published
> as a draft, I have a problem with mandating this in 3028bis:

As do I - see above.

> 1). If this is mandated in 3028bis, this would take some time to deploy.
> This would also render *all* existing implementations non-compliant,
> which is not a good thing. While I can see that this might help in the
> future, I don't think it is necessary and 2 other approaches (script
> analysis and abuse detection+script disabling) already work quite
> reasonably

Agreed.

> 2). This proposal changes how redirect has to be implemented by many
> implementations.

And not just redirect. Again, for this to be in any way effective it would have
to be part of every autoforwarder, not just Sieve.

> Currently for some implementations a redirect can be a
> fire-and-forget operation (after adding it to logs). The actual message
> submission is performed asynchronously. Your proposal will require that
> all redirects for all users (a single message can be destined to
> multiple recipients and all of them can have Sieve scripts) are to be
> performed by an MTA at one moment, because all of them will have to have
> the same Mail-Fork-Estimation header field. In Sieve WG we have many
> different implementations and we were trying vary carefully not to put
> unnecessary requirements on implementations.

I actually don't think this objection is valid as stated. The entire point of
using the multiplicative overestimate is to deal with the fact that scripts
unavoidably operate in isolation and cannot see what is going on elsewhere.
Even if couple the results of multiple sieves on the same system, this does
nothign to address the case where the sieves are evaluated on different
systems.

The one exception here is the case where autoforwarders are intentionally
operated in tandome in order to get proper duplicate elimination between
recipient lists with high degrees of overlap. In such cases the the estimate
has to reflect the results of duplicate elimiantion as I discussed above. But
this really isn't a Sieve redirect issue, if for no other reason than it isn't
practical to use Sieve redirect to build such setups - redirect's definition is
sufficiently loose that it allows changes to be made to messages that would
preclude duplicate elimation.

> ====
> To summarize: I personally disagree that # 3 is a solution suitable for
> 3028bis. I agree that some combination of 1 and 2 is reasonable. I would
> need some help to come up with text covering # 2.

I agree with this assessment as well and would be happu to help with text
for 2.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8QAukCm013164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2007 03:56:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8QAuk7B013163; Wed, 26 Sep 2007 03:56:46 -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.13.5/8.13.5) with ESMTP id l8QAujUg013155 for <[e-mail]>; Wed, 26 Sep 2007 03:56:46 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id C0AC84ACF8; Wed, 26 Sep 2007 12:56:44 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Wed, 26 Sep 2007 12:58:45 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: a conflict between 3598(bis) and the base specification
Cc: Alexey Melnikov <[e-mail]>, Ken Murchison <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Alexey Melnikov writes:
> Ken Murchison wrote:
>> Proposed text 2:
>>
>> If the address is not encoded to contain a detail sub-part, then the 
>> address fails to match any of the specified keys.
>
> Either one is fine, I slightly prefer choice 1 (on the other hand 2 is 
> more readable. So I guess I can't really decide in this case :-)).

Either is fine with me as well. 2 slightly better.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8QAkcak012205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2007 03:46:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8QAkcuv012204; Wed, 26 Sep 2007 03:46:38 -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.13.5/8.13.5) with ESMTP id l8QAkbOE012197 for <[e-mail]>; Wed, 26 Sep 2007 03:46:38 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 26 Sep 2007 11:46:36 +0100
Message-ID: <[e-mail]>
Date: Wed, 26 Sep 2007 11:47:10 +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: Ken Murchison <[e-mail]>
CC: [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: a conflict between 3598(bis) and the base specification
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=us-ascii; 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>

Ken Murchison wrote:

> How about this?
>
> Original text:
>
> If the address is not encoded to contain a detail sub-part, then the 
> test evaluates to false.
>
>
> Proposed text 1:
>
> If the address is not encoded to contain a detail sub-part, then the 
> address fails to match any of the key-list arguments.
>
>
> Proposed text 2:
>
> If the address is not encoded to contain a detail sub-part, then the 
> address fails to match any of the specified keys.

Either one is fine, I slightly prefer choice 1 (on the other hand 2 is 
more readable. So I guess I can't really decide in this case :-)).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8QATtsH009841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2007 03:29:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8QATtrP009840; Wed, 26 Sep 2007 03:29: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.13.5/8.13.5) with ESMTP id l8QATsrf009833 for <[e-mail]>; Wed, 26 Sep 2007 03:29:55 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 26 Sep 2007 11:29:51 +0100
Message-ID: <[e-mail]>
Date: Wed, 26 Sep 2007 10:16:30 +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: Ken Murchison <[e-mail]>, [e-mail]
Subject: Re: a conflict between 3598(bis) and the base specification
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; 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:

>> Arnt Gulbrandsen wrote:
>> > Ken Murchison writes:
>> >> True, the test against the Cc field fails, but when given a list of
>> >> headers/strings, a logical OR is applied, so matching against To is
>> >> sufficient for the test to succeed.
>> >
>> > Ah, now I see what you're saying. But 3028 consistently talks about
>> > "address" as a single test with multiple arguments, not as a 
>> collection
>> > of single-argument tests, so "the test evaluates to false" is less 
>> than
>> > ideal phrasing.
>> >
>> > 3598bis is in the RFC-Editor's queue, isn't it? Too late to change
>> > anything substantive. I suppose a minor rephrasing could be done 
>> during
>> > auth48. Perhaps ", then the :detail doesn't match anything" or 
>> something
>> > like that. Not terribly important. Change it if you think that's both
>> > appropriate and permissible.
>
>> Anyone want to second this suggestion?
>
> Changing it to say "fails to match" or something similar seems fine to 
> me.

+1.

I don't think this change is very controversial, so it can be done in 
AUTH48.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PL94pB025077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 14:09:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PL94CE025076; Tue, 25 Sep 2007 14:09:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PL93mv025069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Sep 2007 14:09:04 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id l8PL91G4013802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 17:09:02 -0400
Message-ID: <[e-mail]>
Date: Tue, 25 Sep 2007 17:08:55 -0400
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail]
CC: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
Subject: Re: a conflict between 3598(bis) and the base specification
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.60 on 128.2.10.83
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:
> 
>> Arnt Gulbrandsen wrote:
>> > Ken Murchison writes:
>> >> True, the test against the Cc field fails, but when given a list of
>> >> headers/strings, a logical OR is applied, so matching against To is
>> >> sufficient for the test to succeed.
>> >
>> > Ah, now I see what you're saying. But 3028 consistently talks about
>> > "address" as a single test with multiple arguments, not as a collection
>> > of single-argument tests, so "the test evaluates to false" is less than
>> > ideal phrasing.
>> >
>> > 3598bis is in the RFC-Editor's queue, isn't it? Too late to change
>> > anything substantive. I suppose a minor rephrasing could be done during
>> > auth48. Perhaps ", then the :detail doesn't match anything" or 
>> something
>> > like that. Not terribly important. Change it if you think that's both
>> > appropriate and permissible.
> 
>> Anyone want to second this suggestion?
> 
> Changing it to say "fails to match" or something similar seems fine to me.

How about this?

Original text:

If the address is not encoded to contain a detail sub-part, then the 
test evaluates to false.


Proposed text 1:

If the address is not encoded to contain a detail sub-part, then the 
address fails to match any of the key-list arguments.


Proposed text 2:

If the address is not encoded to contain a detail sub-part, then the 
address fails to match any of the specified keys.


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PKkr9X023253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 13:46:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PKkrie023252; Tue, 25 Sep 2007 13:46:53 -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.13.5/8.13.5) with ESMTP id l8PKkqE3023246 for <[e-mail]>; Tue, 25 Sep 2007 13:46:53 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id ABBFF4AC44; Tue, 25 Sep 2007 22:46:51 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 25 Sep 2007 22:48:51 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: sieve vacation draft, :mime
Cc: Ned Freed <[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>

Ned Freed writes:
> MIME entities are only supposed to contain MIME headers,

The definition in 2045 contains this sentence:

    Any sort of field may be present in the header of an entity,
    but only those fields whose names begin with "content-" actually have
    any MIME-related meaning.

> so this is actually changing and extending what the document currently 
> allows. Absent a really compelling case for adding this functionality 
> I don't think now is the time to revisit this decision.

I agree that once a document is in the queue, the threshold for 
attempting a change should be high. Higher than e.g. the threshold for 
issuing an erratum.

The reason I'm unhappy today is that I just discovered lots of test 
cases. (I wasn't an implementer two years ago, I'm afraid.) I don't 
want to have to write code and tests for e.g. Subject being present in 
both :mime and :subject.

In fact, if your intention as document editor was that only MIME header 
fields should be present, I think I'll be quiet now and write some code 
to discard all other header fields. That's simple to implement and it's 
always possible to write more complicated code if someone complains.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PKI428020368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 13:18:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PKI4ix020367; Tue, 25 Sep 2007 13:18:04 -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.13.5/8.13.5) with ESMTP id l8PKI1Ma020361 for <[e-mail]>; Tue, 25 Sep 2007 13:18:04 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with SMTP id 4F50C3D06; Tue, 25 Sep 2007 13:19:47 -0700 (PDT)
Date: Tue, 25 Sep 2007 20:19:46 -0000
To: "Ned Freed" <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1190651039.11509.39.camel@localhost>, 
Cc: "Alexey Melnikov" <[e-mail]>, <[e-mail]>, "Ned Freed" <[e-mail]>, "Cullen Jennings" <[e-mail]>, "Lisa Dusseault" <[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 Tue, Sep 25, 2007, Ned Freed <[e-mail]> said:

> 
>> On Sat, 2007-09-22 at 22:13 +0100, Alexey Melnikov wrote:
>> > Ned Freed wrote:
>> >
>> > >> When I mentioned months ago
>> > >> I could imagine many ways to solve this, coupling this type of thing
>> > >> to the ability to do more than one redirect was one of the things
>> > >> that seemed like a possible solution (and corresponds to my
>> > >> understanding of at least some current deployments).
>> > >
>> > > In conclusion, Alexey has proposed new text in a separate messagage which
>> > > I find completely acceptable. Please take a look at that and let's see
>> > > where we are.
>> >
>> > Here is the proposal Ned was referring to:
>> >
>> > In section 4.2, add a sentence to the end of 3rd paragraph:
>> > OLD:
>> >   The envelope sender address on the outgoing message is chosen by the
>> >   sieve implementation.  It MAY be copied from the message being
>> >   processed.
>> > NEW:
>> >  The envelope sender address on the outgoing message is chosen by the
>> >  sieve implementation. It MAY be copied from the message being
>> >  processed. However, if the message being processed has an empty
>> >  envelope sender address the outgoing message MUST also have an
>> >  empty envelope sender address.
> 
>> If this is correct behavior (thinking back again to the original
>> reference to .forward files), then my implementation is incorrect (it
>> tries to construct an envelope sender when one is not already present).
> 
> I understand that some implementations will have to change, but I'm prety
> confident we need this requirement. I cannot cite problematic behavior
> with Sieve redirect to back it up, but I have seen several cases of
> bounce loops occur with other sorts of autoforwarding that does this.
> 
> This is less an issue with intentional attacks than it is with unintentional
> loop creation. The common problematic case is where someone redirects their
> mail unconditionally to some remote place while filling in their own address
> in the envelope. Now suppose that remote address becomes invalid. The
> DSN goes back and is redirected, but now it has a nonempty envelope from
> so a loop forms.

I think by the time we're done with this section, we'll have written the
best practices document for forwarding mail :-)  It's one of those things
where very specific guidance on edge cases is really important.

[snip]
>> >   (1) MUST implement facilities to detect and break message loops. See
>> >       RFC 2821 section 6.2 for additional information on basic loop
>> >       detection strategies.
>> >
>> >   (2) MUST provide the means for administrators to limit the ability of
>> >       users to abuse redirect. In particular, it MUST be possible to
>> >       limit the number of redirects a script can perform. Additionally,
>> >       if no use cases exist for using redirect to multiple destinations,
>> >       this limit SHOULD be set to 1. Additional limits, such
>> >       as the ability to restrict redirect to local users MAY also be
>> >       implemented.
>> >
>> >   (3) MUST provide facilities to log use of redirect in order to facilitate
>> >       tracking down abuse.
> 
>> +1. (2) is a rather stern new requirement. It provides clarity on what
>> was meant by "Site- or implementation-defined limits on actions are
>> useful for this" in the original text. I don't see any problems with
>> this text myself, unless it precludes some other mechanisms that I
>> haven't thought about.
> 
> I see it as setting a minimum that has to be there. I don't see how it could
> prevent some mechanism we haven't thought of from being used.

To clarify what I wrote above ('this text' had the wrong antecedent), I
see no problems myself with the new text and I definitely appreciate the
guidance and direct statement of what was alluded to by the original text.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PJ4pNK013254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 12:04:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PJ4pER013252; Tue, 25 Sep 2007 12:04:51 -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.13.5/8.13.5) with ESMTP id l8PJ4lqF013242 for <[e-mail]>; Tue, 25 Sep 2007 12:04: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]; Tue, 25 Sep 2007 12:04:39 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 25 Sep 2007 12:04:36 -0700 (PDT)
Cc: Alexey Melnikov <[e-mail]>, [e-mail], Ned Freed <[e-mail]>, Cullen Jennings <[e-mail]>, Lisa Dusseault <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 25 Sep 2007 11:55:19 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
In-reply-to: "Your message dated Mon, 24 Sep 2007 09:23:58 -0700" <1190651039.11509.39.camel@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1190651039.11509.39.camel@localhost>
To: Aaron Stone <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190747078; h=Date:	 From:Subject:MIME-version:Content-type; b=JOtUDeUrWv8wVxz0KePtSDMP5 UW1JtQDgkuGg8eMmqAk7mxz/rMFgh7hlLC0q+FNZwnDpF6y9B7QYG/08Pus8g==
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 Sat, 2007-09-22 at 22:13 +0100, Alexey Melnikov wrote:
> > Ned Freed wrote:
> >
> > >> When I mentioned months ago
> > >> I could imagine many ways to solve this, coupling this type of thing
> > >> to the ability to do more than one redirect was one of the things
> > >> that seemed like a possible solution (and corresponds to my
> > >> understanding of at least some current deployments).
> > >
> > > In conclusion, Alexey has proposed new text in a separate messagage which
> > > I find completely acceptable. Please take a look at that and let's see
> > > where we are.
> >
> > Here is the proposal Ned was referring to:
> >
> > In section 4.2, add a sentence to the end of 3rd paragraph:
> > OLD:
> >   The envelope sender address on the outgoing message is chosen by the
> >   sieve implementation.  It MAY be copied from the message being
> >   processed.
> > NEW:
> >  The envelope sender address on the outgoing message is chosen by the
> >  sieve implementation. It MAY be copied from the message being
> >  processed. However, if the message being processed has an empty
> >  envelope sender address the outgoing message MUST also have an
> >  empty envelope sender address.

> If this is correct behavior (thinking back again to the original
> reference to .forward files), then my implementation is incorrect (it
> tries to construct an envelope sender when one is not already present).

I understand that some implementations will have to change, but I'm prety
confident we need this requirement. I cannot cite problematic behavior
with Sieve redirect to back it up, but I have seen several cases of
bounce loops occur with other sorts of autoforwarding that does this.

This is less an issue with intentional attacks than it is with unintentional
loop creation. The common problematic case is where someone redirects their
mail unconditionally to some remote place while filling in their own address
in the envelope. Now suppose that remote address becomes invalid. The
DSN goes back and is redirected, but now it has a nonempty envelope from
so a loop forms.

> > In section 4.2, last paragraph:
> >
> > OLD:
> > Implementations SHOULD take measures to implement loop control,
> >                 ^^^^^^
> > possibly including adding headers to the message or counting Received
> > headers.  If an implementation detects a loop, it causes an error.
> > NEW:
> > Implementations MUST take measures to implement loop control,
> >                 ^^^^
> > possibly including adding headers to the message or counting Received
> > headers as specified in section 6.2 of [SMTP].  If an implementation
> >         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > detects a loop, it causes an error.

> +1

> > Add to the end of section 4.2 two new paragraphs:
> >
> > Implementations MUST provide means of limiting the number of redirects a
> > Sieve script can perform. See Section 10 for more details.
> >
> > Implementations MAY ignore a redirect action silently due to policy
> > reasons.
> > For example, an implementation MAY choose not to redirect to an address
> > that
> > is known to be undeliverable. An ignored redirect MUST NOT cancel the
> > implicit keep.
> >
> >
> > In section 10, replace 2nd paragraph:
> >
> > OLD:
> > It is equally important that implementations sanity-check the user's
> > scripts, and not allow users to create on-demand mailbombs.  For
> > instance, an implementation that allows a user to redirect a message
> > multiple times might also allow a user to create a mailbomb triggered
> > by mail from a specific user.  Site- or implementation-defined limits
> > on actions are useful for this.
> >
> > NEW:
> >   Allowing a single script to redirect to multiple destinations can be
> >   used as a means of amplifying the number of messages in an attack.
> >   Moreover, if loop detection is not properly implemented it may be
> >   possible to set up exponentially growing message loops. According,
> >   Sieve implementations:

> Accordingly,
>          ^^
> >   (1) MUST implement facilities to detect and break message loops. See
> >       RFC 2821 section 6.2 for additional information on basic loop
> >       detection strategies.
> >
> >   (2) MUST provide the means for administrators to limit the ability of
> >       users to abuse redirect. In particular, it MUST be possible to
> >       limit the number of redirects a script can perform. Additionally,
> >       if no use cases exist for using redirect to multiple destinations,
> >       this limit SHOULD be set to 1. Additional limits, such
> >       as the ability to restrict redirect to local users MAY also be
> >       implemented.
> >
> >   (3) MUST provide facilities to log use of redirect in order to facilitate
> >       tracking down abuse.

> +1. (2) is a rather stern new requirement. It provides clarity on what
> was meant by "Site- or implementation-defined limits on actions are
> useful for this" in the original text. I don't see any problems with
> this text myself, unless it precludes some other mechanisms that I
> haven't thought about.

I see it as setting a minimum that has to be there. I don't see how it could
prevent some mechanism we haven't thought of from being used.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PHM6ij099730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 10:22:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PHM6ip099729; Tue, 25 Sep 2007 10:22:06 -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.13.5/8.13.5) with ESMTP id l8PHM40C099721 for <[e-mail]>; Tue, 25 Sep 2007 10:22:05 -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]; Tue, 25 Sep 2007 10:22:01 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 25 Sep 2007 10:21:58 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 25 Sep 2007 10:21:25 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: sieve vacation draft, :mime
In-reply-to: "Your message dated Tue, 25 Sep 2007 13:51:41 +0200" <[e-mail]>
MIME-version: 1.0
References: <[e-mail]> <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190740921; h=Date:	 From:Subject:MIME-version; b=XIlzl84NU/+TAkW+3E6D8f1TYt2+LRkRWVuu/p vHPT0MtuKrvGkQ3kqfm9z1h0XUrPWUT2YT2Xyn/JHiwcHwcA==
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>

> Oops.

> Arnt Gulbrandsen writes:
> > I suggest that
> > ...

>   e) MIME-Version MUST NOT be included

MIME-Version isn't an entity header, so this is already covered as well.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PGJURY088898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 09:19:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PGJUAt088897; Tue, 25 Sep 2007 09:19:30 -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.13.5/8.13.5) with ESMTP id l8PGJTla088885 for <[e-mail]>; Tue, 25 Sep 2007 09:19: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]; Tue, 25 Sep 2007 09:19:25 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 25 Sep 2007 09:19:19 -0700 (PDT)
Cc: [e-mail], Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
Date: Tue, 25 Sep 2007 09:16:24 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: a conflict between 3598(bis) and the base specification
In-reply-to: "Your message dated Tue, 25 Sep 2007 10:36:49 -0400" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Ken Murchison <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190737165; h=Date:	 From:Subject:MIME-version:Content-type; b=on1CuIKDhMAYIhhbuSsEbzIXg g9uyqYdJC7czQeGRglatNpQLydtksUOoGlLIfIWM4Wlle9O3ngKJ2nN6tV6Vw==
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:
> > Ken Murchison writes:
> >> True, the test against the Cc field fails, but when given a list of
> >> headers/strings, a logical OR is applied, so matching against To is
> >> sufficient for the test to succeed.
> >
> > Ah, now I see what you're saying. But 3028 consistently talks about
> > "address" as a single test with multiple arguments, not as a collection
> > of single-argument tests, so "the test evaluates to false" is less than
> > ideal phrasing.
> >
> > 3598bis is in the RFC-Editor's queue, isn't it? Too late to change
> > anything substantive. I suppose a minor rephrasing could be done during
> > auth48. Perhaps ", then the :detail doesn't match anything" or something
> > like that. Not terribly important. Change it if you think that's both
> > appropriate and permissible.

> Anyone want to second this suggestion?

Changing it to say "fails to match" or something similar seems fine to me.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PGCTW2087678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 09:12:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PGCTxT087677; Tue, 25 Sep 2007 09:12:29 -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.13.5/8.13.5) with ESMTP id l8PGCSXA087671 for <[e-mail]>; Tue, 25 Sep 2007 09:12:28 -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]; Tue, 25 Sep 2007 09:11:53 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 25 Sep 2007 09:11:49 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 25 Sep 2007 09:08:49 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: sieve vacation draft and 3834
In-reply-to: "Your message dated Tue, 25 Sep 2007 13:49:03 +0200" </4/[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: </4/[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190736712; h=Date:	 From:Subject:MIME-version:Content-type; b=IVcjQfpBxXR9l/VrX6kpSmiqy seKFfe+s3nBs5HI+ZKim8Etk1kBbw/PfkD7UandPgm1smG2PkXBp2kOLloZdA==
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 section 4.6 is good, but it would be even better if it referred
> to RFC 3834 section 2, perhaps at the end of the first paragraph. Some
> of the later paragraphs could be deleted since 3834 says the same
> things.

Again, it is far too late to be considering such changes for this version of
the document. And even if that weren't the case I would object since RFC 3834
only provides, in its own words, "broad guidelines". IMO the point of RFC 3834
is to provide guidance as to what restrictions need to be in other documents
that define various types of autoforwarders. It isn't really intended to
provide the definition of the one true sort of autoforwwarder.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PG8e7D086833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 09:08:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PG8ecZ086832; Tue, 25 Sep 2007 09:08:40 -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.13.5/8.13.5) with ESMTP id l8PG8cB3086826 for <[e-mail]>; Tue, 25 Sep 2007 09:08:39 -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]; Tue, 25 Sep 2007 09:08:07 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 25 Sep 2007 09:07:57 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 25 Sep 2007 08:53:37 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: sieve vacation draft, :mime
In-reply-to: "Your message dated Tue, 25 Sep 2007 13:29:59 +0200" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1190736482; h=Date:	 From:Subject:MIME-version:Content-type; b=uah5i52Mu51COQazmK+RzWYtF bCEYXHPELs5qsCNhEloX6DkzZ1U9IBEZEEaOk2CKIEonAKEFeqaA6BZGBVrWA==
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>

> The sieve vacation draft doesn't say as much about :mime as it should.
> IMO, it should specify precisely which header fields must, may and must
> not be included in the :mime response.

First of all, as far as the current draft goes this discussion is happening
almost two years too late. Sieve vacation is in the RFC Editor queue  - it is
currently blocked on the base specification. The only changes that have been
made to vacation since it was approved have been ones to align stuff like IANA
registrations with current publication requirements.

> I suggest that
>    a) content-type MUST be included (since if it's not included, what's
> the point of :mime?)

Strongly disagree. The point of :mime could have been to specify a text/plain
part in the US-ASCII charset that also includes content-description or
content-id fields. In such a case the content-type would be optional according
to MIME and I see no reason why Sieve vacation should impose additional
requiremens on the MIME entities it allows people to construct.

>    b) content-transfer-encoding MAY be included, and if it's not
> included, the c-t-e is 7bit

This is already implicit in the definition of a MIME entity and IMO does not
need to be restated.

>    c) header fields defined in 2822 MUST NOT be included (e.g. received,
> to, subject)

This is also implicit in the definition of a MIME entity and while I can see
some merit in restating this particular restriction I don't think it rises to
the level of revising a draft in the RFC Editor queue.

>    d) other header fields MAY be included (e.g. x-loop, x-message-flag,
> content-disposition)

MIME entities are only supposed to contain MIME headers, so this is actually
changing and extending what the document currently allows. Absent a really
compelling case for adding this functionality I don't think now is the time
to revisit this decision.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PEawjH074470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 07:36:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PEaw1Z074469; Tue, 25 Sep 2007 07:36:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP.andrew.cmu.edu [128.2.10.212]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PEauXX074463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Sep 2007 07:36:57 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id l8PEatxN018679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 10:36:55 -0400
Message-ID: <[e-mail]>
Date: Tue, 25 Sep 2007 10:36:49 -0400
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail]
CC: Alexey Melnikov <[e-mail]>
Subject: Re: a conflict between 3598(bis) and the base specification
References: <[e-mail]>  <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.60 on 128.2.10.212
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:
> Ken Murchison writes:
>> True, the test against the Cc field fails, but when given a list of 
>> headers/strings, a logical OR is applied, so matching against To is 
>> sufficient for the test to succeed.
> 
> Ah, now I see what you're saying. But 3028 consistently talks about 
> "address" as a single test with multiple arguments, not as a collection 
> of single-argument tests, so "the test evaluates to false" is less than 
> ideal phrasing.
> 
> 3598bis is in the RFC-Editor's queue, isn't it? Too late to change 
> anything substantive. I suppose a minor rephrasing could be done during 
> auth48. Perhaps ", then the :detail doesn't match anything" or something 
> like that. Not terribly important. Change it if you think that's both 
> appropriate and permissible.

Anyone want to second this suggestion?

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PCTFmR058565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 05:29:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PCTFRi058564; Tue, 25 Sep 2007 05:29:15 -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.13.5/8.13.5) with ESMTP id l8PCTDEB058526 for <[e-mail]>; Tue, 25 Sep 2007 05:29:14 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id F0B754ACA3; Tue, 25 Sep 2007 14:29:12 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 25 Sep 2007 14:31:12 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: a conflict between 3598(bis) and the base specification
Cc: Ken Murchison <[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>

Ken Murchison writes:
> True, the test against the Cc field fails, but when given a list of 
> headers/strings, a logical OR is applied, so matching against To is 
> sufficient for the test to succeed.

Ah, now I see what you're saying. But 3028 consistently talks about 
"address" as a single test with multiple arguments, not as a collection 
of single-argument tests, so "the test evaluates to false" is less than 
ideal phrasing.

3598bis is in the RFC-Editor's queue, isn't it? Too late to change 
anything substantive. I suppose a minor rephrasing could be done during 
auth48. Perhaps ", then the :detail doesn't match anything" or 
something like that. Not terribly important. Change it if you think 
that's both appropriate and permissible.

> In fact, the implementation SHOULD short-circuit the test after the 
> To, and never test against Cc.

That's irrelevant. If the example test were address :detail ["cc", "to"] 
or the example header's Cc field were before its To field, this 
argument would not apply. Much too fragile to matter.

Arnt
(noncompliant implementer)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PButSU054927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 04:56:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PButRU054926; Tue, 25 Sep 2007 04:56:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (SMTP.andrew.cmu.edu [128.2.10.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBurwc054919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Sep 2007 04:56:54 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id l8PBupPO023335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 07:56:51 -0400
Message-ID: <[e-mail]>
Date: Tue, 25 Sep 2007 07:56:45 -0400
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: a conflict between 3598(bis) and the base specification
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.60 on 128.2.10.85
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:
> 
> Hi,
> 
> 3598 and 3598bis contain this (which I apologise for not spotting while 
> reviewing 3598bis):
> 
>    The ":detail" argument specifies that sub-part of the local-part
>    which lies to the right of the separator character (e.g., "sieve" in
>    "[e-mail]").  If no separator character exists, the test
>    evaluates to false.  If nothing lies to the right of the separator
>    character, then ":detail" ":is" the null key ("").  Otherwise, the
>    ":detail" sub-part contains the null key.
> 
> Why is the second sentence there? It seems to add a new value or throw 
> an exception which aborts the surrounding test and attempts to override 
> its result.
> 
> Consider this test and header fragment:
> 
>     if address :detail ["to", "cc"] "sieve" {
>         fileinto "sieve";
>     }
> 
>     From: [e-mail]
>     To: [e-mail]
>     Cc: [e-mail]
> 
> The specification for the "address" test lead me to think that since I'm 
> addressed as arnt+sieve, the test should hit. But no separator character 
> exists on the Cc field, so the second sentence quoted above says the 
> address test fails.

True, the test against the Cc field fails, but when given a list of 
headers/strings, a logical OR is applied, so matching against To is 
sufficient for the test to succeed.  In fact, the implementation SHOULD 
short-circuit the test after the To, and never test against Cc.


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBniuB054128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 04:49:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PBniXB054126; Tue, 25 Sep 2007 04:49:44 -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.13.5/8.13.5) with ESMTP id l8PBnhPr054118 for <[e-mail]>; Tue, 25 Sep 2007 04:49:43 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 8435C4ACE0; Tue, 25 Sep 2007 13:49:42 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 25 Sep 2007 13:51:41 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: Ned Freed <[e-mail]>
Subject: Re: sieve vacation draft, :mime
Cc: [e-mail]
References: <[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>

Oops.

Arnt Gulbrandsen writes:
> I suggest that
> ...

  e) MIME-Version MUST NOT be included

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBl6Uj053714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 04:47:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PBl6wi053713; Tue, 25 Sep 2007 04:47:06 -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.13.5/8.13.5) with ESMTP id l8PBl4Dd053707 for <[e-mail]>; Tue, 25 Sep 2007 04:47:05 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 57C3D4ACE2; Tue, 25 Sep 2007 13:47:04 +0200 (CEST)
Message-Id: </4/[e-mail]>
Date: Tue, 25 Sep 2007 13:49:03 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: Ned Freed <[e-mail]>
Subject: sieve vacation draft and 3834
Cc: [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>

Hi,

I think section 4.6 is good, but it would be even better if it referred 
to RFC 3834 section 2, perhaps at the end of the first paragraph. Some 
of the later paragraphs could be deleted since 3834 says the same 
things.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8PBS3KV050664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 04:28:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8PBS3jx050663; Tue, 25 Sep 2007 04:28:03 -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.13.5/8.13.5) with ESMTP id l8PBS11Y050656 for <[e-mail]>; Tue, 25 Sep 2007 04:28:02 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id C84524AC94; Tue, 25 Sep 2007 13:28:00 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 25 Sep 2007 13:29:59 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: Ned Freed <[e-mail]>
Subject: sieve vacation draft, :mime
Cc: [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>

Hi,

The sieve vacation draft doesn't say as much about :mime as it should. 
IMO, it should specify precisely which header fields must, may and must 
not be included in the :mime response.

I suggest that
   a) content-type MUST be included (since if it's not included, what's 
the point of :mime?)
   b) content-transfer-encoding MAY be included, and if it's not 
included, the c-t-e is 7bit
   c) header fields defined in 2822 MUST NOT be included (e.g. received, 
to, subject)
   d) other header fields MAY be included (e.g. x-loop, x-message-flag, 
content-disposition)

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8P9mtQQ035946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 02:48:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8P9mtpH035944; Tue, 25 Sep 2007 02:48:55 -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.13.5/8.13.5) with ESMTP id l8P9mr63035936 for <[e-mail]>; Tue, 25 Sep 2007 02:48:54 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D63D44AC96; Tue, 25 Sep 2007 11:48:52 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Tue, 25 Sep 2007 11:50:51 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: a conflict between 3598(bis) and the base specification
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>

Hi,

3598 and 3598bis contain this (which I apologise for not spotting while 
reviewing 3598bis):

    The ":detail" argument specifies that sub-part of the local-part
    which lies to the right of the separator character (e.g., "sieve" in
    "[e-mail]").  If no separator character exists, the test
    evaluates to false.  If nothing lies to the right of the separator
    character, then ":detail" ":is" the null key ("").  Otherwise, the
    ":detail" sub-part contains the null key.

Why is the second sentence there? It seems to add a new value or throw 
an exception which aborts the surrounding test and attempts to override 
its result.

Consider this test and header fragment:

     if address :detail ["to", "cc"] "sieve" {
         fileinto "sieve";
     }

     From: [e-mail]
     To: [e-mail]
     Cc: [e-mail]

The specification for the "address" test lead me to think that since I'm 
addressed as arnt+sieve, the test should hit. But no separator 
character exists on the Cc field, so the second sentence quoted above 
says the address test fails.

I don't like the way the address and :detail specifications conflict in 
this case.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8P5UqEi009853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2007 22:30:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8P5Uqjv009852; Mon, 24 Sep 2007 22:30:52 -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.13.5/8.13.5) with ESMTP id l8P5UnFl009836 for <[e-mail]>; Mon, 24 Sep 2007 22:30:51 -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 4D8383D06; Mon, 24 Sep 2007 22:32:29 -0700 (PDT)
Subject: Re: Suggested changes to address Cullen's DISCUSS on         draft-ietf-sieve-3028bis-12.txt
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail], Ned Freed <[e-mail]>, Cullen Jennings <[e-mail]>, Lisa Dusseault <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 24 Sep 2007 09:23:58 -0700
Message-Id: <1190651039.11509.39.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.3 
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>

On Sat, 2007-09-22 at 22:13 +0100, Alexey Melnikov wrote:
> Ned Freed wrote:
> 
> >> When I mentioned months ago
> >> I could imagine many ways to solve this, coupling this type of thing
> >> to the ability to do more than one redirect was one of the things
> >> that seemed like a possible solution (and corresponds to my
> >> understanding of at least some current deployments).
> >
> > In conclusion, Alexey has proposed new text in a separate messagage which
> > I find completely acceptable. Please take a look at that and let's see
> > where we are.
> 
> Here is the proposal Ned was referring to:
> 
> In section 4.2, add a sentence to the end of 3rd paragraph:
> OLD:
>   The envelope sender address on the outgoing message is chosen by the
>   sieve implementation.  It MAY be copied from the message being
>   processed.
> NEW:
>  The envelope sender address on the outgoing message is chosen by the
>  sieve implementation. It MAY be copied from the message being
>  processed. However, if the message being processed has an empty
>  envelope sender address the outgoing message MUST also have an
>  empty envelope sender address.

If this is correct behavior (thinking back again to the original
reference to .forward files), then my implementation is incorrect (it
tries to construct an envelope sender when one is not already present).

> In section 4.2, last paragraph:
> 
> OLD:
> Implementations SHOULD take measures to implement loop control,
>                 ^^^^^^
> possibly including adding headers to the message or counting Received
> headers.  If an implementation detects a loop, it causes an error.
> NEW:
> Implementations MUST take measures to implement loop control,
>                 ^^^^
> possibly including adding headers to the message or counting Received
> headers as specified in section 6.2 of [SMTP].  If an implementation
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> detects a loop, it causes an error.

+1

> Add to the end of section 4.2 two new paragraphs:
> 
> Implementations MUST provide means of limiting the number of redirects a
> Sieve script can perform. See Section 10 for more details.
> 
> Implementations MAY ignore a redirect action silently due to policy 
> reasons.
> For example, an implementation MAY choose not to redirect to an address 
> that
> is known to be undeliverable. An ignored redirect MUST NOT cancel the 
> implicit keep.
> 
> 
> In section 10, replace 2nd paragraph:
> 
> OLD:
> It is equally important that implementations sanity-check the user's
> scripts, and not allow users to create on-demand mailbombs.  For
> instance, an implementation that allows a user to redirect a message
> multiple times might also allow a user to create a mailbomb triggered
> by mail from a specific user.  Site- or implementation-defined limits
> on actions are useful for this.
> 
> NEW:
>   Allowing a single script to redirect to multiple destinations can be
>   used as a means of amplifying the number of messages in an attack.
>   Moreover, if loop detection is not properly implemented it may be
>   possible to set up exponentially growing message loops. According,
>   Sieve implementations:

Accordingly,
         ^^
>   (1) MUST implement facilities to detect and break message loops. See
>       RFC 2821 section 6.2 for additional information on basic loop
>       detection strategies.
> 
>   (2) MUST provide the means for administrators to limit the ability of
>       users to abuse redirect. In particular, it MUST be possible to
>       limit the number of redirects a script can perform. Additionally,
>       if no use cases exist for using redirect to multiple destinations,
>       this limit SHOULD be set to 1. Additional limits, such
>       as the ability to restrict redirect to local users MAY also be
>       implemented.
> 
>   (3) MUST provide facilities to log use of redirect in order to facilitate
>       tracking down abuse.

+1. (2) is a rather stern new requirement. It provides clarity on what
was meant by "Site- or implementation-defined limits on actions are
useful for this" in the original text. I don't see any problems with
this text myself, unless it precludes some other mechanisms that I
haven't thought about.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8NDhaZl065232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2007 06:43:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8NDhafw065231; Sun, 23 Sep 2007 06:43:36 -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.13.5/8.13.5) with ESMTP id l8NDhZGY065225 for <[e-mail]>; Sun, 23 Sep 2007 06:43:36 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 23 Sep 2007 14:43:33 +0100
Message-ID: <[e-mail]>
Date: Sat, 22 Sep 2007 23:16:48 +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: [e-mail]
CC: Cullen Jennings <[e-mail]>, Ned Freed <[e-mail]>, Lisa Dusseault <[e-mail]>, [e-mail]
Subject: Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt, take 2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

After talking to Cullen Lisa thinks that one or two of the following 
changes should address Cullen's DISCUSS (I assume that the text I've 
suggested earlier should be included in some form into 3028bis anyway, 
this is in addition to this):

1). Limit applicability of SIEVE, e.g. to deployments where 
administrators can disable accounts abusing scripts.
2). Add text with helpful guidance about script analysis or  forking  
detection.
3). Add requirements for use of mail headers to more reliably detect 
forking.

=======
So here is some background on the three choices and are my comments on 
them (strictly as an individual contributor).

1). This is really no brainer. Any deployed mail system should have a 
way to disable accounts. I would suggest adding the following:

  Sieve implementations MUST provide facilities to allow administrators 
to disable accounts abusing scripts.

Cullen, does this satisfy you?

2). Ned wrote in a separate email about # 2:

> Script analysis is one of those tri-state things. It can conclude that:
>
> (1) A script is harmless.
> (2) A script is harmful.
> (3) The script cannot be analyzed.
>
> Now, in practice the _overwhelming_ majority of actual scripts will 
> fall into
> one of the first two categories. This is especially true when scripts are
> created by a GUI - GUIs tools tend to construct straightforward 
> scripts without
> any of the complexities that hinder analysis.
>
> And even when the conclusion is (3), that actually tells you something. A
> really sophisticated system might even note the presence of a highly
> complicated script and watch even more carefully for abuse.
>
> Heck, even a very naive analysis can be useful. For example, to the 
> extent
> redirect offers capabilities beyond those of a .forward file, they 
> only arise
> when the address redirect sends the message to can be controlled by 
> the message
> itself. For that you really need Sieve variables (and hence this is 
> out of
> scope for the Sieve base specification). So one very simple thing you 
> can do is
> look for the use of variables and the presence of ${} constructs in 
> redirects.
> A setup that allows users to configure arbitrary sieves might want to 
> check for
> this combination and either disallow or flag it in some way.

I don't think the discussion about looking for variables in the redirect 
address belongs to the 3028bis, because 3028bis itself has no variables.
Apart from that something along the lines of Ned's text can be included.

3). [I hope that the following is not too cryptic for people to 
understand. If it is, I can try to provide a more detailed explanation 
later.] Lisa has suggested in a private email a new header field 
(Mail-Fork-Estimation) that can be used to convey the estimated total 
number of redirects that happened so far as estimated at the previous 
hop. The value of this header is multiplied by the number of redirects 
that happens at the current hop and if it is bigger than 100, the 
message is going to be dropped at the next hop. So this is similar to 
counting Received headers, but compensates for multiple redirects.

While I think this might be a neat research idea and should be published 
as a draft, I have a problem with mandating this in 3028bis:

1). If this is mandated in 3028bis, this would take some time to deploy. 
This would also render *all* existing implementations non-compliant, 
which is not a good thing. While I can see that this might help in the 
future, I don't think it is necessary and 2 other approaches (script 
analysis and abuse detection+script disabling) already work quite 
reasonably
2). This proposal changes how redirect has to be implemented by many 
implementations. Currently for some implementations a redirect can be a 
fire-and-forget operation (after adding it to logs). The actual message 
submission is performed asynchronously. Your proposal will require that 
all redirects for all users (a single message can be destined to 
multiple recipients and all of them can have Sieve scripts) are to be 
performed by an MTA at one moment, because all of them will have to have 
the same Mail-Fork-Estimation header field. In Sieve WG we have many 
different implementations and we were trying vary carefully not to put 
unnecessary requirements on implementations.

====
To summarize: I personally disagree that # 3 is a solution suitable for 
3028bis. I agree that some combination of 1 and 2 is reasonable. I would 
need some help to come up with text covering # 2.

Regards,
Alexey




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8NDh7aE065197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2007 06:43:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8NDh7Q3065196; Sun, 23 Sep 2007 06:43:07 -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.13.5/8.13.5) with ESMTP id l8NDh6qT065188 for <[e-mail]>; Sun, 23 Sep 2007 06:43:06 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 23 Sep 2007 14:43:00 +0100
Message-ID: <[e-mail]>
Date: Sat, 22 Sep 2007 22:22:42 +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: [e-mail], Cullen Jennings <[e-mail]>
CC: Ned Freed <[e-mail]>, Lisa Dusseault <[e-mail]>, [e-mail]
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
References: <[e-mail]> <[e-mail]> <[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>

Alexey Melnikov wrote:

> Ned Freed wrote:
>
>> In conclusion, Alexey has proposed new text in a separate messagage 
>> which
>> I find completely acceptable. Please take a look at that and let's see
>> where we are.
>
> Here is the proposal Ned was referring to:

And considering that the issue about Turing-completeness keep coming 
back, I suggest one more additional change:

In Section 1, 2nd paragraph, replace last sentence:
OLD:
   The base language is intentionally not Turing-complete: it provides 
no way to
   write a loop or a function and variables are not provided.
NEW:
  The base language was not designed to be Turing-complete: it does not have
  a loop command or function syntax.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8NDgxNx065176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2007 06:42:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8NDgxOo065175; Sun, 23 Sep 2007 06:42:59 -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.13.5/8.13.5) with ESMTP id l8NDgvhj065168 for <[e-mail]>; Sun, 23 Sep 2007 06:42:58 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 23 Sep 2007 14:42:53 +0100
Message-ID: <[e-mail]>
Date: Sat, 22 Sep 2007 22:13:29 +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: [e-mail]
CC: Ned Freed <[e-mail]>, Cullen Jennings <[e-mail]>, Lisa Dusseault <[e-mail]>, [e-mail]
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
References: <[e-mail]> <[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:

>> When I mentioned months ago
>> I could imagine many ways to solve this, coupling this type of thing
>> to the ability to do more than one redirect was one of the things
>> that seemed like a possible solution (and corresponds to my
>> understanding of at least some current deployments).
>
> In conclusion, Alexey has proposed new text in a separate messagage which
> I find completely acceptable. Please take a look at that and let's see
> where we are.

Here is the proposal Ned was referring to:

In section 4.2, add a sentence to the end of 3rd paragraph:
OLD:
  The envelope sender address on the outgoing message is chosen by the
  sieve implementation.  It MAY be copied from the message being
  processed.
NEW:
 The envelope sender address on the outgoing message is chosen by the
 sieve implementation. It MAY be copied from the message being
 processed. However, if the message being processed has an empty
 envelope sender address the outgoing message MUST also have an
 empty envelope sender address.

In section 4.2, last paragraph:

OLD:
Implementations SHOULD take measures to implement loop control,
                ^^^^^^
possibly including adding headers to the message or counting Received
headers.  If an implementation detects a loop, it causes an error.
NEW:
Implementations MUST take measures to implement loop control,
                ^^^^
possibly including adding headers to the message or counting Received
headers as specified in section 6.2 of [SMTP].  If an implementation
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
detects a loop, it causes an error.


Add to the end of section 4.2 two new paragraphs:

Implementations MUST provide means of limiting the number of redirects a
Sieve script can perform. See Section 10 for more details.

Implementations MAY ignore a redirect action silently due to policy 
reasons.
For example, an implementation MAY choose not to redirect to an address 
that
is known to be undeliverable. An ignored redirect MUST NOT cancel the 
implicit keep.


In section 10, replace 2nd paragraph:

OLD:
It is equally important that implementations sanity-check the user's
scripts, and not allow users to create on-demand mailbombs.  For
instance, an implementation that allows a user to redirect a message
multiple times might also allow a user to create a mailbomb triggered
by mail from a specific user.  Site- or implementation-defined limits
on actions are useful for this.

NEW:
  Allowing a single script to redirect to multiple destinations can be
  used as a means of amplifying the number of messages in an attack.
  Moreover, if loop detection is not properly implemented it may be
  possible to set up exponentially growing message loops. According,
  Sieve implementations:

  (1) MUST implement facilities to detect and break message loops. See
      RFC 2821 section 6.2 for additional information on basic loop
      detection strategies.

  (2) MUST provide the means for administrators to limit the ability of
      users to abuse redirect. In particular, it MUST be possible to
      limit the number of redirects a script can perform. Additionally,
      if no use cases exist for using redirect to multiple destinations,
      this limit SHOULD be set to 1. Additional limits, such
      as the ability to restrict redirect to local users MAY also be
      implemented.

  (3) MUST provide facilities to log use of redirect in order to facilitate
      tracking down abuse.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l880sOWE036019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2007 17:54:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l880sOu6036018; Fri, 7 Sep 2007 17:54:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l880sLcj036012 for <[e-mail]>; Fri, 7 Sep 2007 17:54:22 -0700 (MST) (envelope-from [e-mail])
Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l880sLA1004089 for <[e-mail]>; Sat, 8 Sep 2007 00:54:21 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 07 Sep 2007 18:54:21 -0600 (MDT)
Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) with ESMTPSA id <[e-mail]>; Fri, 07 Sep 2007 18:54:21 -0600 (MDT)
Date: Fri, 07 Sep 2007 17:55:14 -0700
From: Chris Newman <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
In-reply-to: <[e-mail]>
To: Cullen Jennings <[e-mail]>, Ned Freed <[e-mail]>
Cc: [e-mail], Alexey Melnikov <[e-mail]>, Lisa Dusseault <[e-mail]>, [e-mail], Philip Guenther <[e-mail]>
Message-id: <EAE0C6FB6AD32F419B7D15FD@[10.1.110.5]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Cullen Jennings wrote on 9/5/07 18:03 -0700:
> I think we are talking past each other  a bit so it might be very  helpful to
> have a phone call at some point. Let me make sure that I  got what you are
> saying here at the high level - I think your  position is roughly the
> following:
>
> If implementors follow the advice that Lisa put in the RFC Ed note  (what
> Alexey and you had sent), then it is still possible to have  massive mail
> bomb style attacks using SIEVE but in practice this is  not an issues because
> of a few things including 1) it is not the  weakest link of the email
> infrastructure and other things are  attacked first 2) it is no worse than
> currently deployed things 3)  logging can help with removing the the
> offending accounts after the  fact. By massive here I mean something more
> like 2^100 not 100 messages.
>
> Do I have that about right?

[speaking as a technical contributor, not an AD]

I believe you have that about right.  Indeed if you delete the first phrase and 
the text "using SIEVE" it states the present and historical behavior of the 
email system with .forward files, procmail and various other MTA-level 
forwarding/filtering mechanisms that have existed for decades and continue to 
be widely deployed and widely used.

This is one of the many cases where customers demand power tools that can be 
used to cause harm.  Quick and dirty attempts to make those tools harmless will 
also make them unacceptable to customers.  If our security considerations make 
unrealistic recommendations that vendors must ignore, that makes vendors that 
much more likely to ignore all the security considerations we write.  I 
consider our specifications higher quality if we limit ourselves to realistic 
recommendations and avoid the impractical ones.

For now, we have years of real world experience demonstrating that received 
counting and logging are sufficient mitigation for this threat in today's world.

Here's an analogy:

Cars are very dangerous.  It would save thousands of lives if we banned cars 
from driving on highways.  Is that a good mitigation for the threat?

                - Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8615hjZ071950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2007 18:05:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8615hA9071949; Wed, 5 Sep 2007 18:05:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8615f0t071943 for <[e-mail]>; Wed, 5 Sep 2007 18:05:42 -0700 (MST) (envelope-from [e-mail])
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 05 Sep 2007 18:05:40 -0700
X-IronPort-AV: i="4.20,213,1186383600";  d="scan'208"; a="520924253:sNHT109719220"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8615fVx008244; Wed, 5 Sep 2007 18:05:41 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l8615JxK001625; Thu, 6 Sep 2007 01:05:23 GMT
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Impp: xmpp:[e-mail]
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: [e-mail], Lisa Dusseault <[e-mail]>, [e-mail], Alexey Melnikov <[e-mail]>, Philip Guenther <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
Date: Wed, 5 Sep 2007 18:03:50 -0700
To: Ned Freed <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23464; t=1189040741; x=1189904741; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Cullen=20Jennings=20<[e-mail]> |Subject:=20Re=3A=20Suggested=20changes=20to=20address=20Cullen's=20DISCU SS=20on=20draft-ietf-sieve-3028bis-12.txt |Sender:=20; bh=dQf96CS5PIF62ntxU3SwwTRaKS2FWsSk6GGKhMzWN8c=; b=oj6GWsMLcL8fSENktGXDWiwdvygtjLo53W71uRtjKl7zSwo1HApBuwZ+qM/ARd4CmMtxncmH IpFUnIjz47Z0jA8uhSjHRD3onKsCoJzmzP3iuq2rn+ucgVxcEfP8oUt9v5729ntAiHAw8kp/zk EtbRZNi1mC9zTXWUx65uTlB7k=;
Authentication-Results: sj-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
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 we are talking past each other  a bit so it might be very  
helpful to have a phone call at some point. Let me make sure that I  
got what you are saying here at the high level - I think your  
position is roughly the following:

If implementors follow the advice that Lisa put in the RFC Ed note  
(what Alexey and you had sent), then it is still possible to have  
massive mail bomb style attacks using SIEVE but in practice this is  
not an issues because of a few things including 1) it is not the  
weakest link of the email infrastructure and other things are  
attacked first 2) it is no worse than currently deployed things 3)  
logging can help with removing the the offending accounts after the  
fact. By massive here I mean something more like 2^100 not 100 messages.

Do I have that about right?


On Aug 30, 2007, at 7:37 PM, Ned Freed wrote:

>> > As a specific example, I have
>> > email accounts at Sun, on my home systems, Gmail, and a bunch of
>> > other places.
>> > All, I repeat _all_, of these services allow me to easily configure
>> > autoforwarding to multiple destinations.
>
>> Uh - you sure.
>
> Yes, as a matter of fact I am sure. I try very hard not to make  
> assertions
> without the facts to back them up.
>
>> I'm not aware how to make gmail go to multiple system
>
> It's trivial. Hit the settings tab at the top right and then create  
> two
> filters. Use whatever critera you like and have one that forwards  
> to address A
> and the other to address B.  Before I included gmail in my response  
> I tested
> this with two non-gmail accounts I have elsewhere and gmail happily  
> forwarded a
> test message to both. No warnings, no problems, just two copies of  
> the mail. I
> just checked my account again just now and the both forwards are  
> still in place
> and working. Here's approximately what my settings page has to say  
> about it:
>
>  The following filters are applied to all incoming mail:		
>  Matches: subject: vvv
>  Do this: Forward to [e-mail]
>
>  Matches: subject: vvv www
>  Do this: Forward to [e-mail]
>
> I can't really talk about the specific ISPs we have as customers  
> and their
> policies, but I can assure you gmail is not alone in offering this  
> capability
> to their users. To the extent offerings differ, the difference  
> seems to be
> whether or not users are allowed to configure custom filters at  
> all, not
> whether or not setups that allow custom filtering configuration can  
> forward.
> Hotmail, for example, effectively doesn't offer custom filter  
> settings, so it
> is hardly surprising that they don't offer forwarding.
>
>> which is of course the important one because the others systems have
>> relationships with you and other ways to secure things by causing bad
>> consequences for you if you abuse the system.
>
> I don't believe this is as much of a difference as you seem to  
> think. Quite a
> few of the cases of mailbombing I've seen have been disgruntled  
> employees and
> the like attacking their own company's systems. (AFAIK none of them  
> involved
> the use of sieve redirect, but that's really beside the point.)  
> Apparently
> nothing says "I quit" quite like a mailbox with 10 million pieces  
> of hate mail
> in it.
>
>> > If memory serves, your suggested way to prevent it was to allow at
>> > most one redirect operation to be done during the execution of a  
>> sieve
>> > script.
>
>> Well, what I have in my notes from the prague meeting was "Told them
>> I was OK with SHOULD not redirect to more than one location outside
>> the domain".
>
> And I responded that I think that goes too far and isn't  
> reasonable. In
> particular, a SHOULD that fails to take into account that there are  
> legitimate
> use-cases for mutlple redirects makes the entire specification look  
> incompetent
> and serves to weaken the effectiveness of all the other advice we  
> give.
>
>> We may have different ideas about what domain means but
>> roughly I would mean administrative domain - certainly I would call
>> an enterprise or large bank one domain even thought they might have
>> separate DNS domain names for different locations or something. You
>> might use the term "onsite" where I used domain.
>
> I don't think the restriction to a single domain, regardless of  
> what domain
> means, accomplishes nearly as much as you seem to think it does.  
> Again, to the
> extent mailbombing is an issue, in my experience it's as much of  
> one within an
> ADMD as outside of it. Perhaps more.
>
>> > And you've been told that this is simply not acceptable - there  
>> are too
>> > many use cases for forwarding email to two different places at  
>> once.
>
>> Actually, I have received very little comment on if this is
>> acceptable or not. I have mostly recieved something that loosely
>> translated to "the WG disagrees with your discuss". I would be very
>> happy to talk what my concerns are and have folks figure out if their
>> is a solution that addresses them and still meets the bulk of users
>> needs.
>
> Then there has been a disconnect getting WG comments back to you.  
> Several
> comments were in fact made, including but not limited to one from me.
>
>> > In fact this is an
>> > incredibly common thing for people to do for all sorts of
>> > legitimate reasons,
>> > including but not limited to:
>
>> I suspect what I had proposed meets all these use case but don't
>> claim to really know. Glad to be educated.
>
> OK, let's go down the list and see how ADMD restrictions fare:
>
>> > (1) Making messages accessible in multiple ways, e.g. send one  
>> copy to
>> >    my email account and another to my pager. Or voice mail. Or  
>> printer.
>> >    Or FAX.
>
> A very common case is for pager, fax, or voice mail services to be  
> outsourced
> to an external service provider. Often as not different people in  
> the org will
> use different providers for this stuff. This is especially true if  
> we're
> talking about a hosted setup. ADMD restriction cannot possibly work  
> here.
>
>> > (2) Secretaries who need copies of their boss's email.
>
> ADMD restriction are mostly compatible with this use-case.
>
>> > (3) Maintaining multiple mailboxes during a service transition
>> > period. Or two pagers.
>
> This would depend on the nature of the transition. I've seen  
> transitions to
> another ADMD as well as transitions within an ADMD. Domain  
> restrictions are
> problematic in this case.
>
>> > (4) Making backup copies of mail to address reliability issues (IMO
>> > this is not the best way to solve this problem but it is  
>> commonly done
>> > this way regardless of what I think).
>
> In many cases the entire point of doing this sort of thing,  
> especially at the
> user level, is to get a copy of your mail to a place that has separate
> administative controls. ADMD restrictions would be hugely problematic
> for this use-case.
>
>> > (5) Making copies of stuff for law enforcement use (garden variety
>> >    forwarding is a piss-poor way to implement this but it is  
>> nevertheless
>> >    something people do fairly often).
>
>> (uh, yah, laughing about how well this will meet some US Law
>> enforcement requirements :-)
>
> I can't get into details, but the truly amazing thing is that I've  
> seen
> situations where law enforcement _insisted_ on it being done this  
> way  even
> when a technically superior solution was available. (I'm actually  
> writing a
> response to a proposal that's basically a variant of this idea in   
> another
> window.)
>
> I don't actually know if the cases where this has been done involve  
> forwarding
> outside the ADMD or not. (To be honest, I try very hard to learn as  
> little
> about the operational details of interception activities as I  
> possibly can.)
> But given the complete lack of clue needed to even consider using  
> this approach
> I would not be at all surprised if such forwarding has been done in  
> this case.
>
>> > (6) Vacation-time forwarding of important messages to the "next
>> > tier" of handlers.
>
> This is usually done inside the ADMD but not always.
>
> Tallying up, restricting autforwarding by domain didn't fare so  
> well against
> this list of use-cases. So we're talking about a mechanism that is  
> ineffective
> against a significant subset of actual attacks as well as being  
> incompatible
> with a lot of completely legitimate things people like to do.
>
> Yet another problem with domain restrictions is that it is easy for  
> them to
> turn into a violation of the least astonishment principle. ADMD  
> boundaries can
> be complex - I've seen setups that consider thousands or tens of  
> thousands of
> domains as local - and asking users to understand complex  
> boundaries is in
> effect asking for a lot of support calls. And SPs will do almost  
> anything to
> lessen the number of support calls they get.
>
>> ...
>
>> I'm not surprised - this all seems very consistent with my
>> discussions to these types of folks. I assume you also have the
>> discussions with the people like Yahoo, MSN, gmail, around the
>> policies they put in place to stop their servers from being used in
>> DOS attacks?
>
> The people I talk to tend to be large ISPs rather than these sorts  
> of SPs, but
> yes, we talk about DOS attacks a fair amount. However, the issue of  
> the ISPs
> own infrastructure being used in the ways you envision for DOS  
> attacks has
> almsot never come up, for the simple reason that it is not a  
> significant issue
> for them.
>
>> I know I have been dragged into a few theses - can  you
>> provide some insight around policies there?
>
> OK, let's look at email DOS attacks in a bit more detail. Let's  
> start with what
> sounds like a silly question: What does an MTA do? The answer, of  
> course, is
> that it transfers messages around. It follows that if an MTA is  
> good at its job
> it has to be able to accept and process messages fairly quickly.  
> And this is in
> fact the case: It isn't at all difficult to get performance of 50
> messages/second on a single box. With a little more effort you can  
> kick things
> up into the 500 messages/second realm (the main issue at this point  
> is spam and
> virus scanning performance) and MTAs have been built that can  
> handle well over
> 2000 messages/second (at this point threads and filesystem  
> performance become
> the bottleneck, requiring a bunch of exotic tricks to deal with).
>
> MTAs are also built defensively, and the primary defensive stategy  
> is to try
> and stop the bad stuff as close to the security perimeter as  
> possible. The
> further in stuff gets the more resources have to be expended  
> dealing with it.
> For example, when a user goes seriously over quota the best thing  
> to do is turn
> back mail with a 4yz (temporary) error, not accept it and hold it  
> until they go
> under quota again. Various rate limiting strategies are useful here  
> as well and
> in practice are widely deployed. So unless your attack has both a  
> distributed
> source and destination there's a very good chance it will be  
> quickly detected
> and blocked.
>
> The bottom line is that modern MTAs are very good at handling lots  
> legitimate
> SMTP transactions and take all sorts of steps to prevent themselves  
> from being
> overwhelmed by too many of them. So attacking the email  
> infrastructure by
> performing lots of real transactions is in effect a frontal attack  
> against the
> most heavily fortified part of the entire system. This is not a  
> recipe for
> success.
>
> So if frontal attacks don't work very well, what does? What we  
> commonly see are
> attacks on various server resources: Connections, threads,  
> processes, memory
> and disk. If an attacker can consume enough of some resource they  
> can bring the
> servers down or at least make them very slow. For example, one  
> attack we saw a
> while back was to send an infinitely long message - some MTAs  
> buffer messages
> in memory and done right this could consume all available swap  
> space and hang
> the server. Or there's the trick of opening lots of connections but  
> never
> sending any data. Or stopping in the middle of the transaction.  
> (This one is
> apparently popular right now - I have no idea why.) Or sending  
> commands R E A L
> L Y  S L O W L Y. Or attacking the network stack with malformed  
> packets,
> incomplete TCP exchanges, and so on. Or simply overwhelming the  
> network itself
> with data. Or causing the MTA to overlaod some  other service, e.g.  
> kill the
> directory server by sending lots of RCPT TOs and forcing lots of  
> lookups. Or
> exploiting some known flaw in a particular implementation, e.g.  
> blowing a vital
> cache by doing something to invalidate its content. The list is  
> long, and if
> the attacker is highly distributed some of these are very difficult  
> to defend
> against.
>
> But now let's consider where autoforwarders fit into this attack  
> tree. First of
> all, since email is store and forward you cannot get an  
> autoforwarder to
> perform anything but an actual transaction, corresponding to a  
> direct frontal
> attack - exactly the attack MTAs are best at preventing. Even worse  
> (for the
> attacker), autforwarders don't provide an attacker with much  
> flexibility in
> terms of either distributing either the source or destination of  
> the attack:
> Automating account and filter creation is in most cases difficult  
> if not
> impossible, making the task of getting enough autoforwarders in  
> place very time
> consuming and error prone, and most autoforwarders, including Sieve  
> redirect,
> can only forward to a fixed set of destinations - the redirection  
> cannot go to
> an address that's pulled out of the message itself. (The sieve  
> variables
> extension changes this, but the topic at hand is what's possible in  
> the Sieve
> base specification, not what some extension allows.) Finally, the  
> people who
> offer autoforwarding as part of their service are as a general rule  
> not morons
> and will probably notice if a large volume of email starts coming  
> in only to be
> forwarded right back out.
>
> The bottom line is that, your beliefs to the contrary notwithstanding,
> autoforwarders just aren't that interesting of a tool for  
> attackers. This has
> been largely true throughout the history of email, and in the  
> present world of
> botnets it is more true than ever. The folks at Cloudmark (who know  
> far more
> about the attack landscape than I do) told me a couple of weeks ago  
> that the
> botnets out there are now so large that devastating results can be  
> had even if
> each infected system only sends out 5-6 messages a day. Given this  
> why would
> any attacker even bother making autoforwarders part of their attack  
> toolkit?
>
>> >> I believe that
>> >> the IETF has clear consensus that it does not want to deploy
>> >> technology that could trivially be used for large scale DOS and
>> >> message amplification attacks with very little safeguards or
>> >> traceable ways of dealing with this.
>> >
>> > This presupposes that there's a real risk here and that the  
>> necessary
>> > safeguards are not in place. I don't believe either of these are  
>> true.
>
>> So far no one as sent me any information arguing these are not true.
>
> Say what? My responses have contained exactly this sort of  
> information and
> argument. And AFAICT you have yet to effectively refute a single  
> point I have
> made.
>
>> > > Now my current judgement call is
>> > > that this is in that category and could cause harm to the  
>> internet.
>
>> > But we're not dealing with a new protocol with zero operational  
>> experience here
>> > where such judgement calls are our only means of assessing  
>> possible risk.
>> > Rather, we're not only dealing with a protocol that has  
>> signifcant deployment
>> > and operational experience, we're talking about a particular  
>> feature that's
>> > been an integrall part of email for decades and is accessible in  
>> all sorts of
>> > ways besides Sieve.
>
>> Sure - and clearly if it is not a problem, it is stopped somehow, I'm
>> asking the Security section to provide some advice about how this is
>> all stopped.
>
> Leaving aside that this is a fairly significant change in position  
> on your
> part, the problem with this is that your reasoning rests on an  
> unwarranted
> assumption: That the reason it is not a problem is because people  
> have taken
> specific steps to prevent autoforwarder abuse. The fact of the  
> matter is they
> haven't done this. What has happened instead is that the myriad of  
> other
> measures people have taken to prevent attacks on the email  
> infrastructure have
> collectively managed to make autoforwarders a fairly uninteresting  
> tool for
> attackers.
>
>> > First, nobody is claiming that autoforwarders cannot be used as  
>> an amplifying
>> > component in various sorts of attacks. They can be used this  
>> way. This was true
>> > for email decades before Sieve came along and it will continue  
>> to be true no
>> > matter what we do in this document.
>
>> yet somehow widespread message amplification attacks from email are
>> mitigated to an currently acceptable level.
>
> Yes, because the measures people take to defend against other, far  
> more
> pernicious attacks end up defending against autoforwarders  
> vicariously.
> Defending against mail loops, for example, does more to limit the  
> effectiveness
> of autoforwarders as an attack mechanism than any other step you  
> can take. But
> if you don't have reasonable loop detection in place you will  
> quickly find that
> autoforwarders are the least of your problems.
>
>> > Second, nobody is claiming that script analysis can be used to  
>> prevent people
>> > from abusing Sieve as part of such attacks. It simply cannot be  
>> done.
>
>> agreed - let's make sure the draft does not suggest people do it
>
> I have no problem with that.
>
>> >    More generally, the days where email systems can get away  
>> without producing
>> >    comprehensive logs and audit trails ended a long time ago. I  
>> have no idea
>> >    what you're basing your assertions that such attacks would  
>> not be tracable
>> >    in modern email systems, but it runs absolutely contrary to  
>> all of my
>> >    recent experience.
>
>> Certainly agree with you in enterprise case but in  a public provider
>> such as yahoo, sure they have logs but they may not have any way to
>> tying that to an actually human associated with the account.
>
> But even if they had the information they still aren't going to go  
> after most
> abusers - law enforcement could not care less about this stuff and  
> a civil suit
> is way too much trouble for way too little gain. All they're going  
> to do  is
> shut down the account.
>
> BTW, the same is often true in the enterprise case: If some guy  
> uses a mailbomb
> to say "I quit" the odds are pretty good the company will simply  
> clean up the
> mess and move on.
>
> In any case, the point of having good logs is to be able to  
> identify and stop
> bad behavior. Catching and punishing the person responsible is a whole
> different matter.
>
>> This is great - few bits inline below...
>
>> >    Allowing a single script to redirect to multiple destinations  
>> can be
>> >    used as a means of amplifying the number of messages in an  
>> attack.
>> >    Moreover, if loop detection is not properly implemented it  
>> may be possible
>> >    to set up expontentially growing message loops. Acording, Sieve
>> >    implementations:
>> >
>> >    (1) MUST implement facilities to detect and break message  
>> loops. See
>> >        RFC 2821 section 6.2 for additional information on basic  
>> loop
>> >        detection strategies.
>
>> My discuss did not ask for this but it certainly seems like a good  
>> idea.
>
> Alexey already pointed out that you did in fact ask for this.
>
>> >
>> >    (2) MUST provide the means for administrators to limit the  
>> ability of
>> >        users to abuse redirect. In particular, it MUST be  
>> possible to
>> >        limit the number of redirects a script can perform.  
>> Additionally,
>> >        if no use cases exists for using redirect to to multiple  
>> destinations,
>> >        this limit SHOULD be set to 1. Additional limits, such
>> >        as the ability to restrict redirect to local users MAY  
>> also be
>> >        implemented.
>
>> We are very close here. If you changed the  "Additionally if no use
>> cases exists for using redirect to to multiple destinations this
>> limit SHOULD be set to 1." to "Scripts SHOULD be limited to at most
>> one redirect that is not 'onsite'". And define onsite somewhere. I'd
>> point out that this is a SHOULD not a MUST and that it could be
>> ignored if people understood the security implications of what they
>> were about to do. This could also possibly be coupled with idea after
>> next point to explicitly allow multiple redirects in some cases.
>
> My problem with this is that "onsite" or "within the domain" or  
> whatever should
> not be conflated with limiting the extent to which users are  
> allowed to use
> redirect. I actually think you have substantially weakened the  
> impact of this
> guidance by over-emphasizing domain restrictions.
>
>> >    (3) MUST provide facilities to log use of redirect in order  
>> to facilitate
>> >        tracking down abuse.
>
>> I would ask if this mean that they MUST know what human the script
>> was associated with. If yes, it is way beyond what I am asking for
>> and if no then hard to see how it helps.
>
> On the contrary, this is arguably the most useful advice we have to  
> offer. Real
> time as well as offline analysis of logs is in practice one of the  
> primary
> tools that's used to find and eliminate email abuse. We actually  
> spend at least
> as much time advising our large ISP customers on how to do this more
> effectively than we do on how to set up rate limiting or any other  
> sort of
> defense. (And as I mentioned previously, our ISP customers have  
> demonstrated no
> interest whatsoever in administrative limits on redirect. And we'd  
> know because
> it turns out the limit option wasn't documented.)
>
>> When I mentioned months ago
>> I could imagine many ways to solve this, coupling this type of thing
>> to the ability to do more than one redirect was one of the things
>> that seemed like a possible solution (and corresponds to my
>> understanding of at least some current deployments).
>
> In conclusion, Alexey has proposed new text in a separate messagage  
> which
> I find completely acceptable. Please take a look at that and let's see
> where we are.
>
> 				Ned