Re: draft-elvey-refuse-sieve-02.txt (multi-reply)

Cyrus Daboo <daboo@isamet.com> Thu, 12 August 2004 19:26 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 i7CJQJFK018690; Thu, 12 Aug 2004 12:26:19 -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 i7CJQJvX018689; Thu, 12 Aug 2004 12:26:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CJQICP018678 for <ietf-mta-filters@imc.org>; Thu, 12 Aug 2004 12:26:18 -0700 (PDT) (envelope-from daboo@isamet.com)
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7CJBBo3022682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 15:11:12 -0400
Date: Thu, 12 Aug 2004 15:26:19 -0400
From: Cyrus Daboo <daboo@isamet.com>
To: Matthew Elvey <matthew@elvey.com>, ietf-mta-filters@imc.org
Subject: Re: draft-elvey-refuse-sieve-02.txt (multi-reply)
Message-ID: <F4A682911CC9FE88AE37B506@ninevah.cyrusoft.com>
In-Reply-To: <411AABFC.7080508@elvey.com>
References: <41186140.2010708@elvey.com> <EACA30731845B29364DE4D95@plato.cyrusoft.com> <411915C4.70406@elvey.com> <CD470B9182495A90577DABAE@ninevah.cyrusoft.com> <59E96938-EB0A-11D8-852C-000A95AF6E0A@sun.com> <411AABFC.7080508@elvey.com>
X-Mailer: Mulberry/4.0.0d1 (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, hits=0.0 tests=none
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>

Hi Matthew,

--On Wednesday, August 11, 2004 4:30 PM -0700 Matthew Elvey 
<matthew@elvey.com> wrote:

> Allowing the user to specify the response code is a bad idea -
> featuritits.  It provides very little to no benefit, violates KISS, and
> introduces complications.
> What if the user specifies 200 as the response code?  :)
> I want refuse to have all the features it must have, and no more.

Actually we are talking about enhanced error codes here, so the user cannot 
touch the response code (i.e. it will always be a 5xx response).

If you want to really apply KISS then I would argue that the sieve script 
shouldn't even have a way to set the SMTP error text, let alone the 
response or enhanced codes. Why not leave the SMTP error message to the 
SMTP server implementation? That eliminates the need to have two text 
parameters for ascii and non-ascii - you just need the one for 'non-ascii' 
which only gets used for DSN/MDN.

I also strongly dislike the idea of changing the behaviour of the command 
based on whether non-ascii text is present in the reason string or not.

Here is my suggestion in a little bit more detail:

Relax the behaviour of the reject command to allow it to also be used for 
SMTP errors and to allow generation of DSNs in addition to MDNs as needed. 
New syntax would be:

	reject [":auto" / ":dsn" / ":mdn"] <reason: string>
	
	optional arguments:
	
	":auto" - the sieve implementation decides which of SMTP error, DSN
	or MDN is appropriate to use when the action is executed. This is
	also the default behaviour if none of the optional tags is
	specified. The 'reason' string is used in a DSN or MDN if one of
	those is generated. The 'reason' string is not used in any SMTP error.
	
	":dsn" - a DSN is always generated when the reject action is
	executed. The 'reason' string is used in the DSN.
	
	":mdn" - a MDN is always generated when the reject action is
	executed. The 'reason' string is used in the MDN.

This deals with the KISS issue and having the command do different things 
based on ascii/non-ascii in reason. A user has the option to explicitly 
require a DSN or MDN if they know they always want the reason string to get 
back to the sender, bypassing the possibility of a meaningless SMTP error.

-- 
Cyrus Daboo