Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
Kristin Hubner <kristin.hubner@sun.com> Tue, 10 August 2004 20:18 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 i7AKI7V0064138; Tue, 10 Aug 2004 13:18:07 -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 i7AKI7I5064137; Tue, 10 Aug 2004 13:18:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AKI7bE064128 for <ietf-mta-filters@imc.org>; Tue, 10 Aug 2004 13:18:07 -0700 (PDT) (envelope-from kristin.hubner@sun.com)
Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7AKI40R028637; Tue, 10 Aug 2004 13:18:05 -0700 (PDT)
Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id i7AKI4E06185; Tue, 10 Aug 2004 13:18:04 -0700 (PDT)
Received: from [129.153.12.231] (dhcp-uwcv01-12-231.West.Sun.COM [129.153.12.231]) by we-gotmail.red.iplanet.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Jul 26 2004)) with ESMTPSA id <0I2800A2ZZ23G300@we-gotmail.red.iplanet.com>; Tue, 10 Aug 2004 13:18:04 -0700 (PDT)
Date: Tue, 10 Aug 2004 13:17:49 -0700
From: Kristin Hubner <kristin.hubner@sun.com>
Subject: Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
In-reply-to: <CD470B9182495A90577DABAE@ninevah.cyrusoft.com>
To: Cyrus Daboo <daboo@isamet.com>
Cc: Matthew Elvey <matthew@elvey.com>, ietf-mta-filters@imc.org
Message-id: <59E96938-EB0A-11D8-852C-000A95AF6E0A@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Content-transfer-encoding: 7bit
References: <41186140.2010708@elvey.com> <EACA30731845B29364DE4D95@plato.cyrusoft.com> <411915C4.70406@elvey.com> <CD470B9182495A90577DABAE@ninevah.cyrusoft.com>
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 Aug 10, 2004, at 12:16 PM, Cyrus Daboo wrote: > > Hi Matthew, > > --On Tuesday, August 10, 2004 11:36 AM -0700 Matthew Elvey > <matthew@elvey.com> wrote: > >>> There was some discussion at the lunch BOF last week about the >>> utility >>> of refuse. >> >> Cool; wish I coulda been there/participated. Anyone take minutes? >> (edit: I just heard that Alexey has notes he may share.) > > The Jabber log is here: > > <http://www.xmpp.org/ietf-logs/sieve@ietf.xmpp.org/2004-08-04.txt> > > I will also attempt to write up a brief summary and post to the list > in the next day or so. > >>> 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? >> >> So the idea is just a syntax change, yes? > > A syntax change and also a relaxation of the requirement that 'reject' > must generate an MDN. i.e. if 'reject' occurs in an implementation > that runs SIEVE during SMTP then that implementation is allowed to do > either an SMTP error code, DSN or MDN as it feels appropriate. The > 'reject' text specified by the user would be used for DSN or MDN text, > and we would add a new optional parameter for the SMTP error code and > descriptive error text. I'm sorry I missed the discussion, as perhaps the issues I will repeat below have been already discussed. If done as a relaxation of "reject", then one will need to be able to handle the DNS and MDN cases differently due to the issue of character sets and non-ASCII text in the reason text. The SMTP text has to be ASCII only. The MDN text can potentially contain non-ASCII text. Being able to provide a reason in their "own" language (a language that needs a non-ASCII charset for proper representation) is very important to some users. I can hardly stress enough how important this is to some users and user communities! So either: (1) A "relaxed" reject action would need another parameter specifying whether SMTP level rejection vs. later MDN should be performed, and then the value of that parameter would need to affect what sorts of characters are allowed in the reason string, or else (2) A "relaxed" reject action would need two parameters, one being the SMTP rejection text (ASCII only) and a second parameter would be the MDN text which would allow non-ASCII text. Or maybe some third approach I haven't thought of, as long as it allows non-ASCII text when non-ASCII text is legal, and uses ASCII text when ASCII text is required. To me, such approaches, complicating the reason text in a single action ("relaxed" reject) seems uglier than adding a new action refuse that does the SMTP rejection case and leaving reject alone as the MDN rejection case. And I think that the necessity for scripts to be aware of the difference between SMTP rejection and MDN rejection means that they might as well be coded with different actions -- I think that there is no real simplicity benefit to using a single action. >> What's the gist of the argument for the change? I can't think of any >> strong arguments against the change; here are some less strong >> arguments: > >> 1)A normal extension (the current 'refuse') is a cleaner >> implementation >> in the sense that it's a standard extension - something that's well >> understood, instead of something that makes the base Sieve RFC >> 'wrong' by >> changing it. > > My argument against a new command is that it makes scripts less > portable. By relaxing the restriction on reject the same script can > run efficiently on an implementation that runs at SMTP time and one > that runs at final delivery/LMTP time. It will also make switching > between such implementations easier as scripts will not have to be > changed to gain the benefits of SMTP time rejection. The "portable script" argument only works for sites that are supporting English-only (or at best, Western-European-languages-that-can-be-adequately-represented-in-ASCII- only) user communities. For other sites that are already using reject with MDN text that is not ASCII-only, their script already isn't suitable for SMTP reject time interpretation. Such sites are going to have to care, in their scripts, about the different requirements for reason text for SMTP rejections vs. MDNs. Regards, Kristin > > The question is whether there is ever a case where you would care what > type of reject behaviour is carried out: SMTP error, DSN or MDN. If > there is a requirement to allow users to explicitly state the type of > error that can easily be done as a parameter. > >> 2)It's already written and debugged. > > True, but I don't think switching to 'relaxed' reject would be a > significant change. I suspect the integration with SMTP is the biggest > issue. > >> Arguments for the change: >> 1)A change won't break anything, according to the URL below. >> >> Have we done something like this (e.g. modify an action to accept a >> special parameter flag) before? > > Yes - the copy extension adds a :copy parameter to fileinto and > redirect. imapflags also extends fileinto and also keep. > > > -- > Cyrus Daboo >
- draft-elvey-refuse-sieve-02.txt; http://wiki.fast… Matthew Elvey
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Cyrus Daboo
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Matthew Elvey
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Alexey Melnikov
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Cyrus Daboo
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Philip Guenther
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Kristin Hubner
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Simon Josefsson
- Re: managesieve Kjetil Torgrim Homme
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Philip Guenther
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Kjetil Torgrim Homme
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Kjetil Torgrim Homme
- Re: draft-elvey-refuse-sieve-02.txt Cyrus Daboo
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Cyrus Daboo
- Re: draft-elvey-refuse-sieve-02.txt Kjetil Torgrim Homme
- Re: draft-elvey-refuse-sieve-02.txt Cyrus Daboo
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Kristin Hubner
- Re: draft-elvey-refuse-sieve-02.txt Kjetil Torgrim Homme
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… ned.freed
- Re: draft-elvey-refuse-sieve-02.txt (multi-reply) Matthew Elvey
- Re: draft-elvey-refuse-sieve-02.txt (multi-reply) Kjetil Torgrim Homme
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Alexey Melnikov
- Re: draft-elvey-refuse-sieve-02.txt (multi-reply) Cyrus Daboo
- Re: draft-elvey-refuse-sieve-02.txt (multi-reply) Kjetil Torgrim Homme
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Matthew Elvey
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… ned.freed
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Matthew Elvey
- Re: draft-elvey-refuse-sieve-02.txt; http://wiki.… Mark E. Mallett