Re: implementation issues

Matthew Elvey <matthew@elvey.com> Sat, 02 April 2005 18:48 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32Imjxx027754; Sat, 2 Apr 2005 10:48:45 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32Imj0S027753; Sat, 2 Apr 2005 10:48:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32ImhbB027745 for <ietf-mta-filters@imc.org>; Sat, 2 Apr 2005 10:48:44 -0800 (PST) (envelope-from matthew@elvey.com)
Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 424BBC6A288; Sat, 2 Apr 2005 13:48:42 -0500 (EST)
X-Sasl-enc: yvr/uMEoRpoumXCcqNnvAA 1112467722
Received: from [192.168.2.98] (adsl-67-123-77-234.dsl.snfc21.pacbell.net [67.123.77.234]) by frontend3.messagingengine.com (Postfix) with ESMTP id A6FC525535; Sat, 2 Apr 2005 13:48:41 -0500 (EST)
Message-ID: <424EE67B.4000002@elvey.com>
Date: Sat, 02 Apr 2005 10:37:47 -0800
From: Matthew Elvey <matthew@elvey.com>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sorin Suciu <sorin.suciu@gecadtech.com>
Subject: Re: implementation issues
References: <424BB1E5.8060803@gecadtech.com>
In-Reply-To: <424BB1E5.8060803@gecadtech.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>

On 3/31/05 12:16 AM, Sorin Suciu sent forth electrons to convey:

>
> so, if i understand this correctly we have the following receipe for a 
> perfect implementation:
> - reject can only be by itself and only once (eventualy with stop)

I disagree.  From 
http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-02.txt:

>4.2  "refuse" compatibility with other actions
>   
>   "Refuse" cancels the implicit keep, and is incompatible with
>   "reject" and "discard". "Refuse" is also incompatible with
>   "vacation" extension [VACATION]. (It should be compatible and
>   incompatible with the same actions as "reject", but [SIEVE] states
>   "Implementations SHOULD prohibit reject when used with other
>   actions." However we feel that "refuse" should be permitted when
>   used with other actions such as "fileinto" and "redirect".  This
>   could be useful for analyzing, tracking or reporting spam.  Also,
>   users can use tricks (such as multiple redirects back to their own
>   email addresses) to get around such a prohibition anyway.)
>
IIRC, there was support for such behavior.
(I wonder if the interactions of SIEVE actions would be most clearly and 
concisely described with if-then-else pseudocode (and a definition of 
when that code runs))