Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix

Alexey Melnikov <Alexey.Melnikov@isode.com> Tue, 10 August 2004 19:09 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 i7AJ9X0C057427; Tue, 10 Aug 2004 12:09:33 -0700 (PDT) (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 i7AJ9XbP057426; Tue, 10 Aug 2004 12:09:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AJ9Wsg057418 for <ietf-mta-filters@imc.org>; Tue, 10 Aug 2004 12:09:33 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from isode.com (1Cust30.tnt5.lnd4.gbr.da.uu.net [62.188.134.30]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 10 Aug 2004 20:13:21 +0100
Message-ID: <41191256.7050604@isode.com>
Date: Tue, 10 Aug 2004 19:22:14 +0100
From: Alexey Melnikov <Alexey.Melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <daboo@isamet.com>
CC: Matthew Elvey <matthew@elvey.com>, ietf-mta-filters@imc.org
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
References: <41186140.2010708@elvey.com> <EACA30731845B29364DE4D95@plato.cyrusoft.com>
In-Reply-To: <EACA30731845B29364DE4D95@plato.cyrusoft.com>
Content-Type: text/plain; charset="us-ascii"; 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>

Cyrus Daboo wrote:

> There was some discussion at the lunch BOF last week about the utility 
> of refuse. There was general consensus among the participants that it 
> would be better to extend reject to allow for SMTP refusal and DSN 
> generation rather than add a new command. Personally I prefer that 
> approach - but the issue needs more discussion on the list.
>
> We've probably been over this before, but can you explain in detail 
> why you think a new command is better than extending the behaviour of 
> reject?

I personally don't care, this is just syntax. I think somebody has 
objected to this before.

Alexey