From owner-ietf-mta-filters Mon Feb 2 10:35:54 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12IZsel031087; Mon, 2 Feb 2004 10:35:54 -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 i12IZs0B031086; Mon, 2 Feb 2004 10:35:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12IZrX4031078 for ; Mon, 2 Feb 2004 10:35:53 -0800 (PST) (envelope-from mganesh@india.hp.com) Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel12.hp.com (Postfix) with ESMTP id 766CF1C023CF; Mon, 2 Feb 2004 10:35:53 -0800 (PST) Received: from india.hp.com (nt23060.india.hp.com [15.42.230.60]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i12IIEZ12988; Mon, 2 Feb 2004 23:48:14 +0530 (IST) Message-ID: <401E9888.6020601@india.hp.com> Date: Tue, 03 Feb 2004 00:05:52 +0530 From: Madan Ganesh Velayudham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lyndon Nerenberg Cc: ietf-mta-filters@imc.org Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments References: <401963FA.60905@india.hp.com> <2147483647.1075381786@d154-5-112-162.bchsia.telus.net> In-Reply-To: <2147483647.1075381786@d154-5-112-162.bchsia.telus.net> 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: List-ID: List-Unsubscribe: Hi Lyndon, Thank you for your review comments. Please find my comments in line : > > Some comments based on a quick scan of the document ... > > Section 4: > > * "action" needs to be more clearly defined Sure. Shall refine it. > > Section 5: > > * Why two capabilities? Both commands are required, so there's no > point in advertising two capability strings. The capability should be > changed to something like "STATISTICS". Thats great. Yes, Both are required capability strings. I will update the Capability string to STATISTICS. > > Section 6: > > * What does a "zero valued action counter" mean? Surely '0' is a valid > counter value, meaning the action has never been triggered. I think what > you're implying here is that a '0' value means the counter for the > action isn't implemented. If that's the case, just don't return a > response for that action. My initial assumption was if the discarded mail count is 0, the implementation may return discard 0 or dont return discard action itself. But as you said, the client is no way differentiating whether the action is supported or not. > > * Presumably GETSTAT is only valid in authenticated state? (Section 7 > explicitly calls this out, so section 6 should as well.) I think it is already there. "This command MUST be given after the client is authenticated". Pls clarify if i'm wrong. > > Section 8: > > * The grammar (and semantic description) for the command responses is > missing. Thanks for pointing out. I shall include it some thing like command-getstat-resp = getstat-resp-list getstat-resp-list = [ supported-action integer-value ] * getstat-resp-list supported-action = "discard" / "divert" / "reject" command-resetstat=res = "OK" | "NO" > > Section 9: > > * Since there's no way (that I can see) to access another users counter > data (through the protocol), this text doesn't seem relevant. Yes, I agree. But to be expilicit. > > General: > > * How useful is the returned data? The fact that an action took place > doesn't really tell me anything. I would be much more interested in > seeing how often each rule fired, as that would allow me to optimize my > rulesets. > That is a interesting thought. I shall think of it and document it. Please let me know your comments. MG > --lyndon > -- _____________________________________________________________ ___ /___\ Madan ganesh Velayudham |/. .\| STSD, India ( ) ) +91 80 (2) 205 3108 \ = / _)_(_ There are no limitation in what you can do except the limitations of your own mind. _____________________________________________________________ From owner-ietf-mta-filters Wed Feb 4 06:08:34 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14E8YTv053452; Wed, 4 Feb 2004 06:08:34 -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 i14E8Yb1053451; Wed, 4 Feb 2004 06:08:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from vementry.enterprise.ucs.ed.ac.uk (vementry.enterprise.ucs.ed.ac.uk [129.215.200.96]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14E8WsK053432 for ; Wed, 4 Feb 2004 06:08:33 -0800 (PST) (envelope-from nigel.swinson@rockliffe.com) Received: from SCOTTY (unverified [129.215.188.53]) by vementry.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 6.0.9) with ESMTP id ; Wed, 4 Feb 2004 14:08:34 +0000 Message-ID: <032601c3eb28$5f8448f0$662c2a0a@rockliffe.com> From: "Nigel Swinson" To: "Madan Ganesh Velayudham" Cc: References: <401963FA.60905@india.hp.com> Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments Date: Wed, 4 Feb 2004 14:08:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > "SIEVE: Remove attachment(s)", Madan Velayudham, 23-Dec-03. (8185 bytes) " > > http://ietf.org/internet-drafts/draft-madanganeshv-sieve-remove-attach-00.txt > > > This draft introduces an action command 'fileinto-except' to [SIEVE] in > order to move a message to a folder without certain attachments of the > received message. I think it might be more useful to have an action that removes an attachment, and a test that tests for the prescence of a mime body part. So you'd say: if (message contains .exe attachment) { remove .exe attachment fileinto folder; stop; } We generically want a test that allows users to examine the prescense or absence of attachments of various kinds, so I think it would make sense to build upon that work. As it is, the extension you propose means that you can only neatly remove one style of attachment. What if you want to remove all .exe/.bat/.pif/.vbs attachments? You'd end up with long and nasty regex expressions that try to match filenames that contain any of the proposed extensions. Much better I think would be to have four remove attachment commands, one for each kind of extension. Having a remove-attachment extension will end up along the lines of the editheader extensions in the sense that they will modify the message. So it raises some of the issues that have already been discussed there, so I guess we'd have to say that tests examine the current state of the message. So if we say: remove .exe attachments if (message contains .exe attachment) { We'd never get here. } Cheers Nigel From owner-ietf-mta-filters Wed Feb 4 22:10:54 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i156Asoq017049; Wed, 4 Feb 2004 22:10:54 -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 i156ArCx017048; Wed, 4 Feb 2004 22:10:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i156Aq2s017009 for ; Wed, 4 Feb 2004 22:10:52 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-112-162.bchsia.telus.net (d154-5-112-162.bchsia.telus.net [154.5.112.162]) (authenticated bits=0) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id i156AiTi072320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2004 23:10:51 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 04 Feb 2004 22:10:38 -0800 From: Lyndon Nerenberg To: Madan Ganesh Velayudham cc: ietf-mta-filters@imc.org Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments Message-ID: <2147483647.1075932638@d154-5-112-162.bchsia.telus.net> In-Reply-To: <401E9888.6020601@india.hp.com> References: <401963FA.60905@india.hp.com> <2147483647.1075381786@d154-5-112-162.bchsia.telus.net> <401E9888.6020601@india.hp.com> X-Mailer: Mulberry/3.1.1 (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=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-2-3 12:05 AM +0530 Madan Ganesh Velayudham wrote: >> Section 9: >> >> * Since there's no way (that I can see) to access another users >> counter data (through the protocol), this text doesn't seem >> relevant. > > Yes, I agree. But to be expilicit. It is "explicit" by reason of the specification simply not specifying the facility. Having the security section talk about something that does not exist in the protocol is just going to confuse people. The text in question needs to be removed. From owner-ietf-mta-filters Thu Feb 5 00:46:28 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i158kSKc074700; Thu, 5 Feb 2004 00:46:28 -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 i158kSvE074699; Thu, 5 Feb 2004 00:46:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i158kR0c074687 for ; Thu, 5 Feb 2004 00:46:27 -0800 (PST) (envelope-from mganesh@india.hp.com) Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel6.hp.com (Postfix) with ESMTP id 04F541C0442C; Thu, 5 Feb 2004 03:46:34 -0500 (EST) Received: from india.hp.com (nt23060.india.hp.com [15.42.230.60]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i158QFZ03665; Thu, 5 Feb 2004 13:56:15 +0530 (IST) Message-ID: <402202E8.30206@india.hp.com> Date: Thu, 05 Feb 2004 14:16:32 +0530 From: Madan Ganesh Velayudham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lyndon Nerenberg Cc: ietf-mta-filters@imc.org Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments References: <401963FA.60905@india.hp.com> <2147483647.1075381786@d154-5-112-162.bchsia.telus.net> <401E9888.6020601@india.hp.com> <2147483647.1075932638@d154-5-112-162.bchsia.telus.net> In-Reply-To: <2147483647.1075932638@d154-5-112-162.bchsia.telus.net> 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: List-ID: List-Unsubscribe: Lyndon Nerenberg wrote: > --On 2004-2-3 12:05 AM +0530 Madan Ganesh Velayudham > wrote: > >>> Section 9: >>> >>> * Since there's no way (that I can see) to access another users >>> counter data (through the protocol), this text doesn't seem >>> relevant. >> >> >> Yes, I agree. But to be expilicit. > > > It is "explicit" by reason of the specification simply not specifying > the facility. Having the security section talk about something that does > not exist in the protocol is just going to confuse people. The text in > question needs to be removed. > > Yes, Lyndon. Thats a valid one. It is better not to confuse the people. The updated draft will not have this text. Thank You, MG -- _____________________________________________________________ ___ /___\ Madan ganesh Velayudham |/. .\| STSD, India ( ) ) +91 80 (2) 205 3108 \ = / _)_(_ There are no limitation in what you can do except the limitations of your own mind. _____________________________________________________________ From owner-ietf-mta-filters Thu Feb 5 19:44:15 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i161gqeG069366; Thu, 5 Feb 2004 17:42:52 -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 i161gqnk069365; Thu, 5 Feb 2004 17:42:52 -0800 (PST) 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.8) with ESMTP id i161go9b069351 for ; Thu, 5 Feb 2004 17:42:51 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (pool-141-151-144-199.pitt.east.verizon.net [141.151.144.199]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i161gYk3020774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Feb 2004 20:42:37 -0500 Date: Thu, 05 Feb 2004 20:42:55 -0500 From: Cyrus Daboo To: IETF MTA Filters List Subject: I-D ACTION:draft-daboo-sieve-mime-00.txt (fwd) Message-ID: <104800.1076013775@ninevah.cyrusoft.com> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI - the following is a draft for a new SIEVE operation for testing the content of MIME part headers. Comments welcome... ------------ Forwarded Message ----------- Date: Thursday, February 5, 2004 3:43 PM -0500 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-daboo-sieve-mime-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIEVE Email Filtering: MIME Extension Author(s) : C. Daboo Filename : draft-daboo-sieve-mime-00.txt Pages : 8 Date : 2004-2-5 This document describes the SIEVE Email Filtering 'mime' extension which adds a new test for testing the values of MIME headers in a message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daboo-sieve-mime-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-daboo-sieve-mime-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-daboo-sieve-mime-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- End Forwarded Message ---------- -- Cyrus Daboo From owner-ietf-mta-filters Thu Feb 12 12:03:08 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CK38G3060341; Thu, 12 Feb 2004 12:03:08 -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 i1CK38jI060340; Thu, 12 Feb 2004 12:03:08 -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.8) with ESMTP id i1CK36s2060328 for ; Thu, 12 Feb 2004 12:03:06 -0800 (PST) (envelope-from matthew@elvey.fastmail.fm) X-Sasl-enc: dw5UXec+0wrvv2yq48R9fA 1076616002 Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 7E40A4F4ED7 for ; Thu, 12 Feb 2004 15:00:02 -0500 (EST) Message-ID: <402BDB3F.1090808@elvey.fastmail.fm> Date: Thu, 12 Feb 2004 11:59:59 -0800 From: "Matthew Elvey (FM)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h 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 . 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: List-ID: List-Unsubscribe: Hello, folks. Please review and provide feedback on the "refuse" extension, designed to mostly replace Sieve's "reject" command. It's been accepted as an I-D (-00), but we've made some further changes to what's published, so please review and comment on what's at We welcome feedback, particularly - changes that include replacement text or - suggestions from Sieve implementers. Abstract With "refuse", Sieve gains the ability to simply not accept an email during the SMTP transaction (instead of accepting it and then sending an MDN [MDN] back to the alleged sender using "reject"). A Joe-job is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by the bounces, MDNs and messages with complaints. With "reject", MDNs contribute to the flood of Joe-job spam to victims of Joe-jobs; SMTP level refusals usually don't. So "refuse" provides users the latter method to handle unwanted email. The further changes were limited to Section 13 'Open Issues for Discussion' and a typo. -Matthew & Alexey From owner-ietf-mta-filters Fri Feb 13 02:28:39 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DASdo3084608; Fri, 13 Feb 2004 02:28:39 -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 i1DASc39084607; Fri, 13 Feb 2004 02:28:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DASW4o084599 for ; Fri, 13 Feb 2004 02:28:36 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 337781BDE5A; Fri, 13 Feb 2004 11:28:48 +0100 (CET) Message-Id: From: Arnt Gulbrandsen To: "Matthew Elvey (FM)" Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Cc: ietf-mta-filters@imc.org References: <402BDB3F.1090808@elvey.fastmail.fm> In-Reply-To: <402BDB3F.1090808@elvey.fastmail.fm> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 13 Feb 2004 11:28:09 +0100 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Matthew Elvey (FM) writes: > http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt I suggest adding a sentence saying that SMTP refusal may happen at the RCPT TO or DATA stages, depending on what's convenient to the implementation. (I suppose it might also happen at the MAIL FROM stage, if a systemwide sieve does the refusal.) The 550 result code is a fine thing, but shouldn't you also specify an extended result code (1893/2034)? 5.7.1, perhaps? Arnt From owner-ietf-mta-filters Fri Feb 13 07:37:27 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DFbRLk001074; Fri, 13 Feb 2004 07:37:27 -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 i1DFbQxa001073; Fri, 13 Feb 2004 07:37:26 -0800 (PST) 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.8) with ESMTP id i1DFbKiZ001066 for ; Fri, 13 Feb 2004 07:37:20 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.3] (pool-141-151-144-199.pitt.east.verizon.net [141.151.144.199]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i1DFa0k3006152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2004 10:36:02 -0500 Date: Fri, 13 Feb 2004 10:37:30 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen , "Matthew Elvey (FM)" cc: ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <6008.1076668650@ninevah.local> In-Reply-To: References: <402BDB3F.1090808@elvey.fastmail.fm> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Friday, February 13, 2004 11:28 AM +0100 Arnt Gulbrandsen wrote: | I suggest adding a sentence saying that SMTP refusal may happen at the | RCPT TO or DATA stages, depending on what's convenient to the | implementation. (I suppose it might also happen at the MAIL FROM stage, | if a systemwide sieve does the refusal.) But SIEVE has to operate on the message data - there isn't enough information before the DATA command to run SIEVE, unless you extend SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test). Frankly any system-wide script like that is better left to the SMTP implentation's own filtering/ruleset behaviour. -- Cyrus Daboo From owner-ietf-mta-filters Fri Feb 13 07:46:49 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DFknCM001539; Fri, 13 Feb 2004 07:46:49 -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 i1DFknXw001538; Fri, 13 Feb 2004 07:46:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DFkl8h001532 for ; Fri, 13 Feb 2004 07:46:47 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Cc: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org References: <402BDB3F.1090808@elvey.fastmail.fm> <6008.1076668650@ninevah.local> In-Reply-To: <6008.1076668650@ninevah.local> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 13 Feb 2004 16:47:14 +0100 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > But SIEVE has to operate on the message data - there isn't enough > information before the DATA command to run SIEVE, unless you extend > SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test). As I remember the draft I read, a spamtest implementation can legally arrive at a conclusion without considering the body, so if the script's first rule is a spam test, the body need not be considered. (I agree that the body will almost always be considered.) Anyway, I think the possibility of e.g. a future MAIL FROM test is reason enough to _permit_ the refusal to happen at any stage of the SMTP/LTMP process. > Frankly any system-wide script like that is better left to the SMTP > implentation's own filtering/ruleset behaviour. Sure, but that own filtering behaviour might just be sieve ;) Arnt From owner-ietf-mta-filters Fri Feb 13 08:01:05 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DG15NQ002516; Fri, 13 Feb 2004 08:01:05 -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 i1DG15m3002515; Fri, 13 Feb 2004 08:01:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from chiark.greenend.org.uk (mail@chiark.greenend.org.uk [193.201.200.170]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DG14nv002507 for ; Fri, 13 Feb 2004 08:01:04 -0800 (PST) (envelope-from fanf@chiark.greenend.org.uk) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-mta-filters@imc.org id 1Arfkr-0006VF-00; Fri, 13 Feb 2004 16:01:25 +0000 To: ietf-mta-filters@imc.org From: Tony Finch Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-Reply-To: References: <402BDB3F.1090808@elvey.fastmail.fm> <6008.1076668650@ninevah.local> <6008.1076668650@ninevah.local> Message-Id: Date: Fri, 13 Feb 2004 16:01:25 +0000 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > >Anyway, I think the possibility of e.g. a future MAIL FROM test is >reason enough to _permit_ the refusal to happen at any stage of the >SMTP/LTMP process. There's already an envelope from test in RFC 3028. Tony. -- f.a.n.finch http://dotat.at/ CROMARTY FORTH TYNE DOGGER: WESTERLY VEERING NORTHERLY 3 OR 4. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR IN DOGGER. From owner-ietf-mta-filters Fri Feb 13 07:58:47 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DFwln5002407; Fri, 13 Feb 2004 07:58:47 -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 i1DFwlDH002406; Fri, 13 Feb 2004 07:58:47 -0800 (PST) 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.8) with ESMTP id i1DFwkJm002398 for ; Fri, 13 Feb 2004 07:58:46 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.3] (pool-141-151-144-199.pitt.east.verizon.net [141.151.144.199]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i1DFvUk3006555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2004 10:57:34 -0500 Date: Fri, 13 Feb 2004 10:59:01 -0500 From: Cyrus Daboo To: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <9573.1076669941@ninevah.local> In-Reply-To: <402BDB3F.1090808@elvey.fastmail.fm> References: <402BDB3F.1090808@elvey.fastmail.fm> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Matthew, --On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey (FM)" wrote: | Hello, folks. Please review and provide feedback on the "refuse" | extension, designed to mostly replace Sieve's "reject" command. Question - is there any situation where you would want both reject and refuse available at the same time? i.e. couldn't we just get away with an extension that simply indicates that the existing reject command will actually run during the SMTP transaction and will generate an SMTP error instead of an MDN? Or, if modifying the base-spec reject behaviour is really not allowed in this way, how about having refuse do either SMTP error or MDN as appropriate for the system? That would mean that users can write one script using a single command and have it work on any SIEVE system, whether SIEVE runs at SMTP time or post-SMTP. I would hate to have to change reject<->refuse every time I moved or copied a script across different systems. -- Cyrus Daboo From owner-ietf-mta-filters Fri Feb 13 08:10:24 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DGAOpo003123; Fri, 13 Feb 2004 08:10:24 -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 i1DGAOk6003122; Fri, 13 Feb 2004 08:10:24 -0800 (PST) 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.8) with ESMTP id i1DGAIYC003105 for ; Fri, 13 Feb 2004 08:10:19 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.3] (pool-141-151-144-199.pitt.east.verizon.net [141.151.144.199]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i1DG8uk3006708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2004 11:09:00 -0500 Date: Fri, 13 Feb 2004 11:10:27 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen cc: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <11803.1076670627@ninevah.local> In-Reply-To: References: <402BDB3F.1090808@elvey.fastmail.fm> <6008.1076668650@ninevah.local> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Friday, February 13, 2004 4:47 PM +0100 Arnt Gulbrandsen wrote: |> But SIEVE has to operate on the message data - there isn't enough |> information before the DATA command to run SIEVE, unless you extend |> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test). | | As I remember the draft I read, a spamtest implementation can legally | arrive at a conclusion without considering the body, so if the script's | first rule is a spam test, the body need not be considered. (I agree that | the body will almost always be considered.) | | Anyway, I think the possibility of e.g. a future MAIL FROM test is reason | enough to _permit_ the refusal to happen at any stage of the SMTP/LTMP | process. If you are going to run a script before DATA then you are going to have to limit the set of available sieve tests to just those that make sense - in other words you need to define different 'profiles' of the sieve syntax that are valid for different phases of the message delivery process. I think it would be a mistake just to say that certain tests (e.g. for header addresses) become no-ops when run before DATA. As such I think that a document that defines such a profile would allow the refusal on MAIL FROM or RCPT TO without needing to define that in refuse. -- Cyrus Daboo From owner-ietf-mta-filters Fri Feb 13 11:38:44 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DJciKO015083; Fri, 13 Feb 2004 11:38:44 -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 i1DJcimq015082; Fri, 13 Feb 2004 11:38:44 -0800 (PST) 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.8) with ESMTP id i1DJchZa015075 for ; Fri, 13 Feb 2004 11:38:43 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust246.tnt30.lnd3.gbr.da.uu.net [62.188.122.246]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 13 Feb 2004 19:38:53 +0000 Message-ID: <402D018E.3060102@isode.com> Date: Fri, 13 Feb 2004 16:55:42 +0000 From: Alexey Melnikov 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: Arnt Gulbrandsen CC: Cyrus Daboo , "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402BDB3F.1090808@elvey.fastmail.fm> <6008.1076668650@ninevah.local> In-Reply-To: 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: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Cyrus Daboo writes: > >> But SIEVE has to operate on the message data - there isn't enough >> information before the DATA command to run SIEVE, unless you extend >> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test). > > As I remember the draft I read, a spamtest implementation can legally > arrive at a conclusion without considering the body, so if the > script's first rule is a spam test, the body need not be considered. > (I agree that the body will almost always be considered.) In theory any Sieve script that doesn't test message headers/body can be executed before DATA command. But the task of checking if a Sieve script doesn't require message content might not be a trivial task. Especially if the Sieve engine also supports variables. So I would rather ignore the issue of executing Sieve scripts before DATA command in the Sieve "refuse" extension. > Anyway, I think the possibility of e.g. a future MAIL FROM test is > reason enough to _permit_ the refusal to happen at any stage of the > SMTP/LTMP process. > >> Frankly any system-wide script like that is better left to the SMTP >> implentation's own filtering/ruleset behaviour. > > Sure, but that own filtering behaviour might just be sieve ;) Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-mta-filters Fri Feb 13 11:38:52 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DJcq8x015097; Fri, 13 Feb 2004 11:38:52 -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 i1DJcqek015096; Fri, 13 Feb 2004 11:38:52 -0800 (PST) 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.8) with ESMTP id i1DJconX015089 for ; Fri, 13 Feb 2004 11:38:51 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust246.tnt30.lnd3.gbr.da.uu.net [62.188.122.246]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 13 Feb 2004 19:39:08 +0000 Message-ID: <402D0276.40509@isode.com> Date: Fri, 13 Feb 2004 16:59:34 +0000 From: Alexey Melnikov 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: Arnt Gulbrandsen CC: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402BDB3F.1090808@elvey.fastmail.fm> In-Reply-To: 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: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Matthew Elvey (FM) writes: > >> http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt > > > I suggest adding a sentence saying that SMTP refusal may happen at the > RCPT TO or DATA stages, depending on what's convenient to the > implementation. (I suppose it might also happen at the MAIL FROM > stage, if a systemwide sieve does the refusal.) > > The 550 result code is a fine thing, but shouldn't you also specify an > extended result code (1893/2034)? 5.7.1, perhaps? This is an open issue in the document ;-). Matthew and I weren't sure what to do with enhanced status codes. Do you suggest that we mandate 5.7.1 or should we instead mention it and allow an MTA to select another enhanced status code if appropriate? Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-mta-filters Fri Feb 13 12:29:21 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DKTKb2017957; Fri, 13 Feb 2004 12:29:20 -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 i1DKTKcs017956; Fri, 13 Feb 2004 12:29:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1DKTIrX017948 for ; Fri, 13 Feb 2004 12:29:19 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 15872 invoked from network); 13 Feb 2004 15:29:39 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 13 Feb 2004 15:29:39 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 17778 invoked by uid 101); 13 Feb 2004 15:29:39 -0500 From: "Mark E. Mallett" Date: Fri, 13 Feb 2004 15:29:39 -0500 To: Cyrus Daboo Cc: "Matthew Elvey \(FM\)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <20040213202939.GB9805@iridium.mv.net> References: <402BDB3F.1090808@elvey.fastmail.fm> <9573.1076669941@ninevah.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9573.1076669941@ninevah.local> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Feb 13, 2004 at 10:59:01AM -0500, Cyrus Daboo wrote: > Hi Matthew, > > --On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey (FM)" > wrote: > > | Hello, folks. Please review and provide feedback on the "refuse" > | extension, designed to mostly replace Sieve's "reject" command. > > Question - is there any situation where you would want both reject and > refuse available at the same time? i.e. couldn't we just get away with an > extension that simply indicates that the existing reject command will > actually run during the SMTP transaction and will generate an SMTP error > instead of an MDN? Or, if modifying the base-spec reject behaviour is > really not allowed in this way, how about having refuse do either SMTP > error or MDN as appropriate for the system? That would mean that users can > write one script using a single command and have it work on any SIEVE > system, whether SIEVE runs at SMTP time or post-SMTP. I would hate to have > to change reject<->refuse every time I moved or copied a script across > different systems. This was my initial reaction too: rather than introduce a new action, introduce a new "smtp-time" operating mode where the existing "reject" action would have the desired effect. One might even add an option to "reject" to specify the SMTP response code and the extended result code, which could be used in the smtp-time mode and ignore otherwise. As I mentioned in another thread, this notion of operating mode could also be useful in other contexts. Re the draft text: why is it "test refuse" and not "action refuse" ? mm From owner-ietf-mta-filters Fri Feb 13 13:01:06 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DL1674019357; Fri, 13 Feb 2004 13:01:06 -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 i1DL164U019356; Fri, 13 Feb 2004 13:01:06 -0800 (PST) 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.8) with ESMTP id i1DL15q4019339 for ; Fri, 13 Feb 2004 13:01:05 -0800 (PST) (envelope-from kristin.hubner@Sun.COM) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1DL1KdO007610; Fri, 13 Feb 2004 13:01:20 -0800 (PST) Received: from we-gotmail.red.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id i1DL0gB04490; Fri, 13 Feb 2004 13:00:42 -0800 (PST) Received: from mars.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by we-gotmail.red.iplanet.com (Sun Java System Messaging Server 6.1 (built Feb 6 2004)) with ESMTP id <0HT1008ONJQ83640@we-gotmail.red.iplanet.com>; Fri, 13 Feb 2004 13:01:20 -0800 (PST) Received: from [129.153.12.63] by we-gotmail.red.iplanet.com (mshttpd); Fri, 13 Feb 2004 13:01:20 -0800 Date: Fri, 13 Feb 2004 13:01:20 -0800 From: kristin.hubner@Sun.COM Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h To: =?iso-8859-1?Q?Cyrus=A0Daboo=A0?= Cc: =?iso-8859-1?B?Ik1hdHRoZXegRWx2ZXmgKEZNKSKg?= , ietf-mta-filters@imc.org Message-id: <66e108b22ff.402ccaa0@mars.iplanet.com> MIME-version: 1.0 X-Mailer: Sun ONE Messenger Express 6.1 (built Feb 6 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I would argue that there is a need, or at least desire, to have both "reject" and "refuse". For one thing, you can't internationalize "refuse". We have people who want to ensure for some more "friendly" bounces that the original sender will see some "friendly" explanatory text. So they want to use "reject" so that they can: (a) ensure that their own text is presented to the original sending user (SMTP rejection text, in contrast, may or may not end up getting presented to the original sender), and possibly (b) use another language/charset (language-appropriate subset of UTF8) for their rejection text, possibly customizing the choice of language/characters based on characteristics of the message being rejected. But in other cases, with more "unfriendly" bounces, rejecting the message at the SMTP level is more desirable. When it's more important to limit load on or protect your own server vs. being "friendly" to the original sender, then "reject" can be more appealing. I can therefore envision cases of Sieve scripts that might wish to use both. Regards, Kristin kristin.hubner@sun.com ----- Original Message ----- From: Cyrus Daboo Date: Friday, February 13, 2004 7:59 am Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h > > Hi Matthew, > > --On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey > (FM)" > wrote: > > | Hello, folks. Please review and provide feedback on the "refuse" > | extension, designed to mostly replace Sieve's "reject" command. > > Question - is there any situation where you would want both reject > and > refuse available at the same time? i.e. couldn't we just get away > with an > extension that simply indicates that the existing reject command > will > actually run during the SMTP transaction and will generate an SMTP > error > instead of an MDN? Or, if modifying the base-spec reject behaviour > is > really not allowed in this way, how about having refuse do either > SMTP > error or MDN as appropriate for the system? That would mean that > users can > write one script using a single command and have it work on any > SIEVE > system, whether SIEVE runs at SMTP time or post-SMTP. I would hate > to have > to change reject<->refuse every time I moved or copied a script > across > different systems. > > -- > Cyrus Daboo > > From owner-ietf-mta-filters Fri Feb 13 14:34:22 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DMYM4B025283; Fri, 13 Feb 2004 14:34:22 -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 i1DMYM4t025281; Fri, 13 Feb 2004 14:34:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.lokitech.com (mail.lokitech.com [209.92.53.4]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1DMYJqs025249 for ; Fri, 13 Feb 2004 14:34:20 -0800 (PST) (envelope-from sergek@lokitech.com) Received: from 216.181.165.37 ([216.181.165.37]) by mail.lokitech.com (JAMES SMTP Server 2.1.3) with SMTP ID 866; Fri, 13 Feb 2004 17:34:39 -0500 (EST) Message-ID: <402D50FF.1060609@lokitech.com> Date: Fri, 13 Feb 2004 17:34:39 -0500 From: Serge Knystautas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kristin.hubner@Sun.COM CC: Cyrus Daboo , "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <66e108b22ff.402ccaa0@mars.iplanet.com> In-Reply-To: <66e108b22ff.402ccaa0@mars.iplanet.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: List-ID: List-Unsubscribe: kristin.hubner@Sun.COM wrote: > But in other cases, with more "unfriendly" bounces, rejecting the message at the SMTP level is more > desirable. When it's more important to limit load on or protect your own server vs. being "friendly" to > the original sender, then "reject" can be more appealing. > > I can therefore envision cases of Sieve scripts that might wish to use both. This isn't specific to just Kristin's comment, but if you're talking about using sieve in the SMTP transaction, when does this happen? After MAIL FROM? After each RCPT TO? After HELO? (the last is a bit far-fetched, but it can be used as a more structured way of rejecting servers on DNS RBL). -- Serge Knystautas President Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. sergek@lokitech.com From owner-ietf-mta-filters Fri Feb 13 15:22:49 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DNMnQB028289; Fri, 13 Feb 2004 15:22:49 -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 i1DNMnPM028288; Fri, 13 Feb 2004 15:22:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DNMmBp028281 for ; Fri, 13 Feb 2004 15:22:48 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L6JWNISZOW000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Fri, 13 Feb 2004 15:21:57 -0800 (PST) Date: Fri, 13 Feb 2004 15:18:42 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Fri, 13 Feb 2004 17:34:39 -0500" <402D50FF.1060609@lokitech.com> To: Serge Knystautas Cc: kristin.hubner@Sun.COM, Cyrus Daboo , "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Message-id: <01L6K3DJJ8CA000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <66e108b22ff.402ccaa0@mars.iplanet.com> <402D50FF.1060609@lokitech.com> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > kristin.hubner@Sun.COM wrote: > > But in other cases, with more "unfriendly" bounces, rejecting the message at the SMTP level is more > > desirable. When it's more important to limit load on or protect your own server vs. being "friendly" to > > the original sender, then "reject" can be more appealing. > > > > I can therefore envision cases of Sieve scripts that might wish to use both. > This isn't specific to just Kristin's comment, but if you're talking > about using sieve in the SMTP transaction, when does this happen? I suppose it could happen anywhere in the dialogue, but as a practical matter, any script that uses header tests (and the majority of them do) can only after the message has been transferred. Of course this runs into problems when there are multiple recipients. But remember: The majority of messages have a single recipient. And there's also LMTP to consider - a sieve implementation operating in the context of an LMTP server has no problem returning per-recipient failures after the data. Ned From owner-ietf-mta-filters Sat Feb 14 17:08:02 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1F182Fi071886; Sat, 14 Feb 2004 17:08:02 -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 i1F1828e071885; Sat, 14 Feb 2004 17:08:02 -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.8) with ESMTP id i1F17u9P071879 for ; Sat, 14 Feb 2004 17:07:57 -0800 (PST) (envelope-from matthew@elvey.fastmail.fm) X-Sasl-enc: tYXT/SgkIoR/xO6If+kkvw 1076807300 Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id CCCDF511583; Sat, 14 Feb 2004 20:08:15 -0500 (EST) Message-ID: <402EC67F.8060902@elvey.fastmail.fm> Date: Sat, 14 Feb 2004 17:08:15 -0800 From: "Matthew Elvey (FM)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Cc: "Arnt Gulbrandsen" , "Cyrus Daboo" , "Mark E. Mallett" , kristin.hubner@Sun.COM Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h 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 . 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: List-ID: List-Unsubscribe: Wow, lots of good feedback! Several replies follow: On 2/13/2004 7:47 AM, Arnt Gulbrandsen sent forth electrons to convey: > > > Anyway, I think the possibility of e.g. a future MAIL FROM test is > reason enough to __permit__ the refusal to happen at any stage of the > SMTP/LTMP process. I intend to remove the text "to an end of DATA command " so that in no case does the draft stand in the way of this. I think Sieve implementations supporting pre-DATA refuse is a desirable goal. For example, LMAP could well make pre-DATA refuse more even more useful than RBLs and envelope checks already do. And folks who want to receive all email addressed to them, completely "uncensored", can do so in a new way if there's a pre-DATA Sieve processing/operating mode. It's beyond the scope of this draft to explicitly facilitate it, so how 'bout a separate thread on a pre-DATA Sieve processing/operating mode? I prefer to not add excess verbiage explicitly allowing things that are already allowed, but we could (reluctantly) add: "SMTP refusal may happen at any stage of the SMTP/LTMP process, up to the end of DATA command." I like Cyrus' idea of the refuse extension simply changing the semantics of "reject" for several reasons. It's the best way to make mass search-and-replace unnecessary when switching from an MTA that can support "refuse" to an MUA that can't. It makes it easier for folks to switch to using "refuse". I can't think of a situation where you would want both reject and refuse available at the same time. Err, Arrgh - Kriskin Hubner came up with one: "reject" results in friendlier emails than "refuse". I find that many people don't understand even 'friendly' refuse messages - e.g. a doctor's and an economist's email to me were refused with a friendly refuse message, and yet they failed to act on it. Perhaps the format of "refuse" messages is actually MORE easily comprehended because it's less unique. (email |bugzilla3sd@matthewelvey.fastmail.fm to see my | 'friendly' refuse message|.)| (Regarding the other issues raised: I believe that anyone who would receive an email that was rejected would receive that email if it was refused as instead, unless they had weird email filters in place, so don't think that's an issue. Also, I can't recall seeing a bounce that didn't include the rejection text; what MTA's bounces don't ?) |3 of us like it. Kristin, further thoughts? Can you clarify whether SMTP rejection text can use another charset? I get email (spam) with Subjects in all sorts of charsets, imagine this would work too, but I'm (obviously) no expert. | On 2/13/2004 12:29 PM, Mark E. Mallett sent forth electrons to convey: >On Fri, Feb 13, 2004 at 10:59:01AM -0500, Cyrus Daboo wrote: > > >One might even add an option >to "reject" to specify the SMTP response code and the extended result code, >which could be used in the smtp-time mode and ignore otherwise. Alexey and I had considered this and decided that the added complexity of allowing the user to specify the SMTP response code was outweighed by the meager benefits of providing it. We even wrote (and later removed) a long text on how to allow user-specified __extended__ codes to be supported. "Experience with many protocols has shown that: protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity." - RFC 1651 Have a compelling argument for the option? In any case, I will s/5.7.0/5.7.1 in the draft (in the section that may or may not make it into the next revsion). >Re the draft text: why is it "test refuse" and not "action refuse" ? > > Because I made a mistake :). I will be mostly away from email next week. -- Matthew From owner-ietf-mta-filters Wed Feb 18 12:18:42 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IFtua6054807; Wed, 18 Feb 2004 07:55:56 -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 i1IFtuFb054806; Wed, 18 Feb 2004 07:55:56 -0800 (PST) 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.8) with ESMTP id i1IFtoYQ054795 for ; Wed, 18 Feb 2004 07:55:55 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 18 Feb 2004 15:55:45 +0000 Message-ID: <40338AFE.4010906@isode.com> Date: Wed, 18 Feb 2004 15:55:42 +0000 From: Alexey Melnikov 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: Tim Showalter CC: ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <4032BBAB.1000608@psaux.com> In-Reply-To: <4032BBAB.1000608@psaux.com> 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: List-ID: List-Unsubscribe: Tim Showalter wrote: > Alexey Melnikov wrote: > >> I don't remember now why the Seive RFC was written to use MDNs. > > I do. Reject originally (early spec, long time ago) said generate a > DSN, but MUAs can't do that--conceptually, anyway. An MUA can > generate a good forgery, but it was inappropriate for it to do so. > > The guarantee advertised by a DSN is supposed to be "this is what > happened". The guarantee advertised by an MDN is "this is what > happened, except that maybe then something else happened that negated > this event". My memory of the spec is that it doesn't exactly allow > outright lying, but you're allowed to state "deleted" and there is no > guarantee that the message wasn't immediately undeleted, for instance. > > So I guess the short version is that MDNs were chosen because we could > get away with so much more. Than my question is: is changing "reject" to generate DSNs in MTAs and MDN in MUAs acceptable? I personally have no problems with this, and I suspect most users will not probably care either. Alexey From owner-ietf-mta-filters Wed Feb 18 12:18:47 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IG3GMI055470; Wed, 18 Feb 2004 08:03:16 -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 i1IG3G2O055469; Wed, 18 Feb 2004 08:03:16 -0800 (PST) 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.8) with ESMTP id i1IG3ECE055462 for ; Wed, 18 Feb 2004 08:03:15 -0800 (PST) (envelope-from daboo@cyrusoft.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 i1IG0qk3027600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2004 11:00:52 -0500 Date: Wed, 18 Feb 2004 11:03:08 -0500 From: Cyrus Daboo To: "Matthew Elvey (FM)" , Arnt Gulbrandsen , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <4464.1077102188@ninevah.cyrusoft.com> In-Reply-To: <40337941.6020106@elvey.fastmail.fm> References: <402EC67F.8060902@elvey.fastmail.fm> <40337941.6020106@elvey.fastmail.fm> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Matthew, --On Wednesday, February 18, 2004 6:40 AM -0800 "Matthew Elvey (FM)" wrote: |> Anyway, you could punt and say that a refuse implementation should use |> SMTP/LMTP rejection _where_possible_, and allow an implementation to |> treat refuse as reject if the implementation can't do anything else. | | I very much want the user to be able to know as conclusively as possible | that if "refuse" is supported, then they will be refusing mail at SMTP | time. Frankly I doubt that the 'average' user will understand the distinction between refuse and reject - 'power' users will. I would likely expect that reject vs refuse is something that will be decided by site admins as a matter of policy and they would configure their sieve web-frontends (or other script generation tools) to use one or the other as appropriate with just a single UI widget representing a 'reject' type action that the user can pick. Perhaps the following would be better: A single new command 'refuse' that takes various arguments, the first of which can be one of: 'mdn' - send an mdn rejection with supplied descriptive text 'dsn' - send a dsn rejection with supplied descriptive text 'smtp5' - send an smtp permanent failure - ascii text provided is sent with smtp response 'smtp4' - send an smtp temporary failure - ascii text provided is sent with smtp response 'default' - one of the above as a defined by site policy. The only problem with this is knowing how to deal with the text for the 'default' argument - for mdn/dsn it can be utf8, but for smtp it can only be ascii. Perhaps 'default' should take two strings - one utf8 one ascii - but that is ugly! -- Cyrus Daboo From owner-ietf-mta-filters Wed Feb 18 12:43:12 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1FI5iJX093668; Sun, 15 Feb 2004 10:05:44 -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 i1FI5ikD093667; Sun, 15 Feb 2004 10:05:44 -0800 (PST) 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.8) with ESMTP id i1FI5be2093659 for ; Sun, 15 Feb 2004 10:05:39 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.253]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 15 Feb 2004 18:05:40 +0000 Message-ID: <402FB4E7.5010903@isode.com> Date: Sun, 15 Feb 2004 18:05:27 +0000 From: Alexey Melnikov 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: "Matthew Elvey (FM)" CC: ietf-mta-filters@imc.org, Cyrus Daboo Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402EC67F.8060902@elvey.fastmail.fm> In-Reply-To: <402EC67F.8060902@elvey.fastmail.fm> 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: List-ID: List-Unsubscribe: Matthew Elvey (FM) wrote: > I like Cyrus' idea of the refuse extension simply changing the semantics > of "reject" for several reasons. > It's the best way to make mass search-and-replace unnecessary when > switching from an MTA that can support "refuse" to an MUA that can't. > It makes it easier for folks to switch to using "refuse". We are basically in agreement. The only thing that concerns me is that currently "refuse" might generate a DSN, while "reject" is required to generate an MDN. Does it matter that the behavior changes when a Sieve script is moved between MTA and MUA or vice versa? I don't remember now why the Seive RFC was written to use MDNs. > I can't think of a situation where you would want both reject and refuse > available at the same time. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ From owner-ietf-mta-filters Fri Feb 20 07:51:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KFpVnl010100; Fri, 20 Feb 2004 07:51:31 -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 i1KFpVdk010099; Fri, 20 Feb 2004 07:51:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KFpOuI010090 for ; Fri, 20 Feb 2004 07:51:25 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L6SRNG66PS000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Fri, 20 Feb 2004 07:51:24 -0800 (PST) Date: Fri, 20 Feb 2004 07:41:24 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Sun, 15 Feb 2004 18:05:27 +0000" <402FB4E7.5010903@isode.com> To: Alexey Melnikov Cc: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org, Cyrus Daboo Message-id: <01L6TFODICFU000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Matthew Elvey (FM) wrote: > > I like Cyrus' idea of the refuse extension simply changing the semantics > > of "reject" for several reasons. > > It's the best way to make mass search-and-replace unnecessary when > > switching from an MTA that can support "refuse" to an MUA that can't. > > It makes it easier for folks to switch to using "refuse". > We are basically in agreement. > The only thing that concerns me is that currently "refuse" might > generate a DSN, while "reject" is required to generate an MDN. > Does it matter that the behavior changes when a Sieve script is moved > between MTA and MUA or vice versa? > I don't remember now why the Seive RFC was written to use MDNs. It is because MDNs are the only generally appropriate mechanism that both MTAs and MUAs can legitimately use. Remember that the place where sieves get applied is left intentionally fuzzy; it can be anything from just before the time of final delivery to much later. A DSN is not an appropriate construct to use after final delivery: The necessary information to construct the DSN may not be available, it looks bad if final delivery produced a success DSN only to be followed by a subsequent faileded DSN, etc. You can only get away with using DSNs for this if you restrict the time of application of the sieve to just before or during final delivery. > > I can't think of a situation where you would want both reject and refuse > > available at the same time. The main problem with the idea of relaxing the rules for reject to allow it to generate DSNs or a 5xy error when running on an MTA is that a script will behave in a fairly different way depending on whether you run it on an MUA or a MTA. I really don't like this. And if you use a require tag to mean "change the semantics of reject to refuse" and make it so the tag only works on MTAs, you're back to having to change the scripts when you move them around. Its just generally cleaner to have two different actions here and have one of them be MTA-only. Ned From owner-ietf-mta-filters Sun Feb 22 14:17:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1MMHDjL042479; Sun, 22 Feb 2004 14:17:13 -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 i1MMHD3c042478; Sun, 22 Feb 2004 14:17:13 -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.8) with ESMTP id i1MMHBgG042472 for ; Sun, 22 Feb 2004 14:17:12 -0800 (PST) (envelope-from matthew@elvey.fastmail.fm) X-Sasl-enc: hRESNxqRFDwZnAisJsjrtw 1077487815 Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id DA1295CAC8A; Sun, 22 Feb 2004 17:10:13 -0500 (EST) Message-ID: <403928C3.4080408@elvey.fastmail.fm> Date: Sun, 22 Feb 2004 16:10:11 -0600 From: "Matthew Elvey (FM)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ned.freed@mrochek.com Cc: Alexey Melnikov , ietf-mta-filters@imc.org, Cyrus Daboo Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> In-Reply-To: <01L6TFODICFU000051@mauve.mrochek.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 . 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: List-ID: List-Unsubscribe: On 2/20/2004 9:41 AM, ned.freed@mrochek.com sent forth electrons to convey: > > The main problem with the idea of relaxing the rules for reject to > allow it to > generate DSNs or a 5xy error when running on an MTA is that a script will > behave in a fairly different way depending on whether you run it on an > MUA or a > MTA. I really don't like this. And if you use a require tag to mean > "change the > semantics of reject to refuse" and make it so the tag only works on > MTAs, > you're back to having to change the scripts when you move them around. > Its just > generally cleaner to have two different actions here and have one of > them be > MTA-only. It's unavoidable for behavior to differ between an MUA and an MTA, if there is support for a "refuse" action. What solution do you suggest to avoid a script either behaving differently or having to be different ? You're almost saying you want both, but isn't that an impossibility? A require tag that means "change the semantics of reject to refuse" seems to have the fewest drawbacks. I think it's impossible for a script that uses a "refuse" action to be and behave the same on an MUA and an MTA. This is still a problem with Cyrus' proposal: what would happen if "refuse smtp5" was attempted in a script on a MUA? It still would require a change on a mail agent that couldn't do SMTP time refuses. Here's an idea! Perhaps "refuse" should have an "Am I an MTA capable of refusing?" test or constant? Then users wouldn't have to add/remove the string when moving a script between MUA and MTA. From owner-ietf-mta-filters Sun Feb 22 14:29:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1MMThVs042870; Sun, 22 Feb 2004 14:29:43 -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 i1MMThe7042869; Sun, 22 Feb 2004 14:29:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1MMTgEk042863 for ; Sun, 22 Feb 2004 14:29:42 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L6TMNRXDHC000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Sun, 22 Feb 2004 14:28:32 -0800 (PST) Date: Sun, 22 Feb 2004 14:23:02 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Sun, 22 Feb 2004 16:10:11 -0600" <403928C3.4080408@elvey.fastmail.fm> To: "Matthew Elvey (FM)" Cc: ned.freed@mrochek.com, Alexey Melnikov , ietf-mta-filters@imc.org, Cyrus Daboo Message-id: <01L6WM5F152U000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On 2/20/2004 9:41 AM, ned.freed@mrochek.com sent forth electrons to convey: > > > > The main problem with the idea of relaxing the rules for reject to > > allow it to > > generate DSNs or a 5xy error when running on an MTA is that a script will > > behave in a fairly different way depending on whether you run it on an > > MUA or a > > MTA. I really don't like this. And if you use a require tag to mean > > "change the > > semantics of reject to refuse" and make it so the tag only works on > > MTAs, > > you're back to having to change the scripts when you move them around. > > Its just > > generally cleaner to have two different actions here and have one of > > them be > > MTA-only. > It's unavoidable for behavior to differ between an MUA and an MTA, if > there is support for a "refuse" action. This presupposes that refuse is supportable on an MUA. I don't think it is or should be. > What solution do you suggest to avoid a script either behaving > differently or having to be different ? I suggest that if you want a portable script you use reject and live with its limitations. If, on the other hand, you are willing to live with an MTA-only script, you have the option of using refuse. > You're almost saying you want both, but isn't that an impossibility? No. See above. > A require tag that means "change the semantics of reject to refuse" > seems to have the fewest drawbacks. I disagree. There's only a small incremental cost of switching rejects to refuses throughout compared to the cost of switching just the require clause. And you lose the ability to have both behaviors, which is something a large, composite script might want. > I think it's impossible for a script that uses a "refuse" action to be > and behave the same on an MUA and an MTA. It is impossible to implement refuse on an MUA, period. > This is still a problem with Cyrus' proposal: what would happen if > "refuse smtp5" was attempted in a script on a MUA? It still would > require a change on a mail agent that couldn't do SMTP time refuses. > Here's an idea! > Perhaps "refuse" should have an "Am I an MTA capable of refusing?" test > or constant? > Then users wouldn't have to add/remove the string > when moving a script between MUA and MTA. A major wart like this is entirely unwarranted IMO. Ned From owner-ietf-mta-filters Tue Feb 24 08:44:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OGin8k057343; Tue, 24 Feb 2004 08:44:49 -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 i1OGinvM057341; Tue, 24 Feb 2004 08:44:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OGil7i057333 for ; Tue, 24 Feb 2004 08:44:48 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from LDAP4.andrew.cmu.edu (LDAP4.andrew.cmu.edu [128.2.10.233]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i1OGiokZ017536 for ; Tue, 24 Feb 2004 11:44:50 -0500 Date: Tue, 24 Feb 2004 11:44:50 -0500 (EST) From: Rob Siemborski To: ietf-mta-filters@imc.org Subject: imapflags -- backwards compatibility Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey, Ken, and I were discussing the new imapflags extension changes, and it should be possible to do this in a mostly backwards-compatible manner (excluding the :flags parameter to keep and fileinto). This would allow us to keep the old capability name. If the variable arguments to addflag and setflags optional, you can continue to have the old behavior (with the "global" flags variable). This avoids the need to add a full dependency on variables as well -- you would be unable to use the optional parameter unless "variables" is also required. Additionally, "hasflag" might also either require variables *or* you could make the variable list to hasflag optional as well (This is probably the most problematic aspect of doing this). Finally, if the :flags parameter is omitted to fileinto/keep, then the flags that are in the "global variable" would be applied to the message as it was stored. As an aside, it might make sense to move the "optional" arguments to the end of the parameter lists of these actions, but that is of lesser concern. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- From owner-ietf-mta-filters Tue Feb 24 19:11:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1P3BU2t092893; Tue, 24 Feb 2004 19:11:30 -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 i1P3BUJQ092892; Tue, 24 Feb 2004 19:11:30 -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.8) with ESMTP id i1P3BK4Z092868 for ; Tue, 24 Feb 2004 19:11:23 -0800 (PST) (envelope-from matthew@elvey.fastmail.fm) X-Sasl-enc: OdL0Q4YwhgZrp5PobyuQmw 1077678684 Received: from elvey.fastmail.fm (p131.n-chpop07.stsn.com [63.240.158.131]) by mail.messagingengine.com (Postfix) with ESMTP id 751D9608841; Tue, 24 Feb 2004 22:11:22 -0500 (EST) Message-ID: <403C1257.9000808@elvey.fastmail.fm> Date: Tue, 24 Feb 2004 21:11:19 -0600 From: "Matthew Elvey (FM)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ned.freed@mrochek.com Cc: "Matthew Elvey (FM)" , Alexey Melnikov , ietf-mta-filters@imc.org, Cyrus Daboo Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> <01L6WM5F152U000051@mauve.mrochek.com> In-Reply-To: <01L6WM5F152U000051@mauve.mrochek.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 . 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: List-ID: List-Unsubscribe: On 2/22/2004 4:23 PM, ned.freed@mrochek.com sent forth electrons to convey: >> On 2/20/2004 9:41 AM, ned.freed@mrochek.com sent forth electrons to >> convey: > > >> > >> > The main problem with the idea of relaxing the rules for reject to >> > allow it to >> > generate DSNs or a 5xy error when running on an MTA is that a >> script will >> > behave in a fairly different way depending on whether you run it on an >> > MUA or a >> > MTA. I really don't like this. And if you use a require tag to mean >> > "change the >> > semantics of reject to refuse" and make it so the tag only works on >> > MTAs, >> > you're back to having to change the scripts when you move them around. >> > Its just >> > generally cleaner to have two different actions here and have one of >> > them be >> > MTA-only. > > >> It's unavoidable for behavior to differ between an MUA and an MTA, if >> there is support for a "refuse" action. > > > This presupposes that refuse is supportable on an MUA. I didn't (mean to) communicate that. What I meant to communicate: It's unavoidable for behavior to differ between an MUA and an MTA, if there is support for a "refuse" action (in Sieve when not on an MUA). > I don't think it is or > should be. So I am correct in concluding that you support the draft (the version posted to the list, which is still the latest version) insofar as refuse should be a new action, and MUAs must not claim to support it? You argued: > And if you use a require tag to mean "change the > semantics of reject to refuse" and make it so the tag only works on > MTAs, > you're back to having to change the scripts when you move them around. Yes, you'd have to change scripts using 'refuse' when you move them around whether 'refuse' changes the semantics of reject or not. Here's an idea: an implementation supporting 'refuse' MUST refuse at smtp time whenever possible. In other words, we make being an MUA an acceptable exception allowing an implementation to fail to refuse with a 5xx reply code (and instead send an MDN). We make script changes unnecessary, and yet it's still clear that your sieve client is refusing at smtp time whenever possible. Anyone who cares is likely to understand that MUAs can't refuse at smtp time. From owner-ietf-mta-filters Wed Feb 25 11:19:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJJAs9027549; Wed, 25 Feb 2004 11:19:10 -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 i1PJJAAP027548; Wed, 25 Feb 2004 11:19:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJJ89D027539 for ; Wed, 25 Feb 2004 11:19:08 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L70K0F8Z80000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Wed, 25 Feb 2004 11:19:05 -0800 (PST) Date: Wed, 25 Feb 2004 11:18:16 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Tue, 24 Feb 2004 21:11:19 -0600" <403C1257.9000808@elvey.fastmail.fm> To: "Matthew Elvey (FM)" Cc: ned.freed@mrochek.com, "Matthew Elvey (FM)" , Alexey Melnikov , ietf-mta-filters@imc.org, Cyrus Daboo Message-id: <01L70MEK7C4A000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> <01L6WM5F152U000051@mauve.mrochek.com> <403C1257.9000808@elvey.fastmail.fm> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > So I am correct in concluding that you support the draft (the version > posted to the list, which is still the latest version) insofar as refuse > should be a new action, and MUAs must not claim to support it? Yes, I think the current draft gets this right. Ned From owner-ietf-mta-filters Fri Feb 27 08:18:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RGIqBg027483; Fri, 27 Feb 2004 08:18:52 -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 i1RGIqp6027482; Fri, 27 Feb 2004 08:18:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1RGIp3S027475 for ; Fri, 27 Feb 2004 08:18:51 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 27895 invoked from network); 27 Feb 2004 11:18:50 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 27 Feb 2004 11:18:50 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 29696 invoked by uid 101); 27 Feb 2004 11:18:49 -0500 From: "Mark E. Mallett" Date: Fri, 27 Feb 2004 11:18:49 -0500 To: ietf-mta-filters@imc.org Cc: "Mark E. Mallett" Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <20040227161849.GB6061@iridium.mv.net> References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> <01L6WM5F152U000051@mauve.mrochek.com> <403C1257.9000808@elvey.fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403C1257.9000808@elvey.fastmail.fm> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Feb 24, 2004 at 09:11:19PM -0600, Matthew Elvey (FM) wrote: > On 2/22/2004 4:23 PM, ned.freed@mrochek.com sent forth electrons to convey: > > > >>It's unavoidable for behavior to differ between an MUA and an MTA, if > >>there is support for a "refuse" action. > > > > > >This presupposes that refuse is supportable on an MUA. > > I didn't (mean to) communicate that. What I meant to communicate: > > It's unavoidable for behavior to differ between an MUA and an MTA, if > there is support for a "refuse" action (in Sieve when not on an MUA). There are at least two different concerns that are being mingled, I think: one of script operating context, and one of portability within a given context. A script running in a MUA is in an entirely different context than a script running on an SMTP server. I believe most portability issues only apply to scripts within a given context. Personally I would imagine that an MUA script is written and maintained differently than one that runs on an SMTP server-- which may or may not be an MTA script (it could be an MTA script or an LDA script). So I see no reason to want a particular script to run without edits if it is put into a different context (MUA vs MTA). The question is whether an end user can write a server-side script that will operate whether or not that user knows if the script will be invoked by the MTA (so that SMTP-time refusal is possible) or by an LDA after the message has already been accepted at SMTP time. I believe it's valuable to have this level of portability. Even within the same mail server (or server farm) the operating mode might change from time to time. It would be good if the script could accomodate such a change, and it would be good to minimize the amount of work necessary to refit a script when moving from one environment to another. This would benefit both script writers and system administrators. This is not the only situation where it would be useful to have a more than just the "require" facility. (I'd like to be able to have a script that can be conditionalized according to what extensions are available, or according to what mode or context the script is operating under.) Solving that is not appropriate here, however such a solution would be applicable to "refuse". Without this, I believe it makes sense to try to make "refuse" operate in a server context, whether or not the script is running at SMTP time. mm From owner-ietf-mta-filters Sat Feb 28 11:15:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1SJFIVr097763; Sat, 28 Feb 2004 11:15:18 -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 i1SJFISs097762; Sat, 28 Feb 2004 11:15:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1SJFC4P097738 for ; Sat, 28 Feb 2004 11:15:13 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L720KZYSCG000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Sat, 28 Feb 2004 11:15:13 -0800 (PST) Date: Sat, 28 Feb 2004 11:05:10 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Fri, 27 Feb 2004 11:18:49 -0500" <20040227161849.GB6061@iridium.mv.net> To: "Mark E. Mallett" Cc: ietf-mta-filters@imc.org, "Mark E. Mallett" Message-id: <01L74T4UGS3W000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> <01L6WM5F152U000051@mauve.mrochek.com> <403C1257.9000808@elvey.fastmail.fm> <20040227161849.GB6061@iridium.mv.net> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Tue, Feb 24, 2004 at 09:11:19PM -0600, Matthew Elvey (FM) wrote: > > On 2/22/2004 4:23 PM, ned.freed@mrochek.com sent forth electrons to convey: > > > > > >>It's unavoidable for behavior to differ between an MUA and an MTA, if > > >>there is support for a "refuse" action. > > > > > > > > >This presupposes that refuse is supportable on an MUA. > > > > I didn't (mean to) communicate that. What I meant to communicate: > > > > It's unavoidable for behavior to differ between an MUA and an MTA, if > > there is support for a "refuse" action (in Sieve when not on an MUA). > There are at least two different concerns that are being mingled, > I think: one of script operating context, and one of portability > within a given context. A script running in a MUA is in an entirely > different context than a script running on an SMTP server. Not really. In our use of sieve it is fairly common for users to construct scripts in their MUA and upload them to a server. And in some cases users may design a script and both upload it to one server they use that supports such things and run it locally on their MUA when dealing with another server that doesn't support sieve filtering. There can also be server-specific sieve scripts that apply server-wide or to specific groups of users, but this doesn't mean there's not substantial overlap. The way I look at it is that server-side sieve support has to cover all the things client-side scripts do plus some additional stuff. > I believe > most portability issues only apply to scripts within a given context. Yes, but since the contexts overlap... > Personally I would imagine that an MUA script is written and maintained > differently than one that runs on an SMTP server-- which may or may > not be an MTA script (it could be an MTA script or an LDA script). > So I see no reason to want a particular script to run without edits > if it is put into a different context (MUA vs MTA). Server-side scripts provided by server admins which apply server-wide or to groups of users do have this characteristic, if for no other reason than the fact that most GUI sieve construction tools do a poor job of constructing such scripts. (Hardly surprising given that this isn't what the interface is designed to do.) But saying it applies to all scrips that run server-side is incorrect. > The question is whether an end user can write a server-side script > that will operate whether or not that user knows if the script will > be invoked by the MTA (so that SMTP-time refusal is possible) or > by an LDA after the message has already been accepted at SMTP time. > I believe it's valuable to have this level of portability. Even within > the same mail server (or server farm) the operating mode might change > from time to time. It would be good if the script could accomodate > such a change, and it would be good to minimize the amount of work > necessary to refit a script when moving from one environment to another. > This would benefit both script writers and system administrators. Yes, which is why I believe keeping the truly universal commands separate from the server-specific ones is a good idea. Ned Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1SJFIVr097763; Sat, 28 Feb 2004 11:15:18 -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 i1SJFISs097762; Sat, 28 Feb 2004 11:15:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1SJFC4P097738 for ; Sat, 28 Feb 2004 11:15:13 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L720KZYSCG000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Sat, 28 Feb 2004 11:15:13 -0800 (PST) Date: Sat, 28 Feb 2004 11:05:10 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Fri, 27 Feb 2004 11:18:49 -0500" <20040227161849.GB6061@iridium.mv.net> To: "Mark E. Mallett" Cc: ietf-mta-filters@imc.org, "Mark E. Mallett" Message-id: <01L74T4UGS3W000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> <01L6WM5F152U000051@mauve.mrochek.com> <403C1257.9000808@elvey.fastmail.fm> <20040227161849.GB6061@iridium.mv.net> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Tue, Feb 24, 2004 at 09:11:19PM -0600, Matthew Elvey (FM) wrote: > > On 2/22/2004 4:23 PM, ned.freed@mrochek.com sent forth electrons to convey: > > > > > >>It's unavoidable for behavior to differ between an MUA and an MTA, if > > >>there is support for a "refuse" action. > > > > > > > > >This presupposes that refuse is supportable on an MUA. > > > > I didn't (mean to) communicate that. What I meant to communicate: > > > > It's unavoidable for behavior to differ between an MUA and an MTA, if > > there is support for a "refuse" action (in Sieve when not on an MUA). > There are at least two different concerns that are being mingled, > I think: one of script operating context, and one of portability > within a given context. A script running in a MUA is in an entirely > different context than a script running on an SMTP server. Not really. In our use of sieve it is fairly common for users to construct scripts in their MUA and upload them to a server. And in some cases users may design a script and both upload it to one server they use that supports such things and run it locally on their MUA when dealing with another server that doesn't support sieve filtering. There can also be server-specific sieve scripts that apply server-wide or to specific groups of users, but this doesn't mean there's not substantial overlap. The way I look at it is that server-side sieve support has to cover all the things client-side scripts do plus some additional stuff. > I believe > most portability issues only apply to scripts within a given context. Yes, but since the contexts overlap... > Personally I would imagine that an MUA script is written and maintained > differently than one that runs on an SMTP server-- which may or may > not be an MTA script (it could be an MTA script or an LDA script). > So I see no reason to want a particular script to run without edits > if it is put into a different context (MUA vs MTA). Server-side scripts provided by server admins which apply server-wide or to groups of users do have this characteristic, if for no other reason than the fact that most GUI sieve construction tools do a poor job of constructing such scripts. (Hardly surprising given that this isn't what the interface is designed to do.) But saying it applies to all scrips that run server-side is incorrect. > The question is whether an end user can write a server-side script > that will operate whether or not that user knows if the script will > be invoked by the MTA (so that SMTP-time refusal is possible) or > by an LDA after the message has already been accepted at SMTP time. > I believe it's valuable to have this level of portability. Even within > the same mail server (or server farm) the operating mode might change > from time to time. It would be good if the script could accomodate > such a change, and it would be good to minimize the amount of work > necessary to refit a script when moving from one environment to another. > This would benefit both script writers and system administrators. Yes, which is why I believe keeping the truly universal commands separate from the server-specific ones is a good idea. Ned Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1RGIqBg027483; Fri, 27 Feb 2004 08:18:52 -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 i1RGIqp6027482; Fri, 27 Feb 2004 08:18:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1RGIp3S027475 for ; Fri, 27 Feb 2004 08:18:51 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 27895 invoked from network); 27 Feb 2004 11:18:50 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 27 Feb 2004 11:18:50 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 29696 invoked by uid 101); 27 Feb 2004 11:18:49 -0500 From: "Mark E. Mallett" Date: Fri, 27 Feb 2004 11:18:49 -0500 To: ietf-mta-filters@imc.org Cc: "Mark E. Mallett" Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <20040227161849.GB6061@iridium.mv.net> References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> <01L6WM5F152U000051@mauve.mrochek.com> <403C1257.9000808@elvey.fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403C1257.9000808@elvey.fastmail.fm> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Feb 24, 2004 at 09:11:19PM -0600, Matthew Elvey (FM) wrote: > On 2/22/2004 4:23 PM, ned.freed@mrochek.com sent forth electrons to convey: > > > >>It's unavoidable for behavior to differ between an MUA and an MTA, if > >>there is support for a "refuse" action. > > > > > >This presupposes that refuse is supportable on an MUA. > > I didn't (mean to) communicate that. What I meant to communicate: > > It's unavoidable for behavior to differ between an MUA and an MTA, if > there is support for a "refuse" action (in Sieve when not on an MUA). There are at least two different concerns that are being mingled, I think: one of script operating context, and one of portability within a given context. A script running in a MUA is in an entirely different context than a script running on an SMTP server. I believe most portability issues only apply to scripts within a given context. Personally I would imagine that an MUA script is written and maintained differently than one that runs on an SMTP server-- which may or may not be an MTA script (it could be an MTA script or an LDA script). So I see no reason to want a particular script to run without edits if it is put into a different context (MUA vs MTA). The question is whether an end user can write a server-side script that will operate whether or not that user knows if the script will be invoked by the MTA (so that SMTP-time refusal is possible) or by an LDA after the message has already been accepted at SMTP time. I believe it's valuable to have this level of portability. Even within the same mail server (or server farm) the operating mode might change from time to time. It would be good if the script could accomodate such a change, and it would be good to minimize the amount of work necessary to refit a script when moving from one environment to another. This would benefit both script writers and system administrators. This is not the only situation where it would be useful to have a more than just the "require" facility. (I'd like to be able to have a script that can be conditionalized according to what extensions are available, or according to what mode or context the script is operating under.) Solving that is not appropriate here, however such a solution would be applicable to "refuse". Without this, I believe it makes sense to try to make "refuse" operate in a server context, whether or not the script is running at SMTP time. mm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJJAs9027549; Wed, 25 Feb 2004 11:19:10 -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 i1PJJAAP027548; Wed, 25 Feb 2004 11:19:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJJ89D027539 for ; Wed, 25 Feb 2004 11:19:08 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L70K0F8Z80000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Wed, 25 Feb 2004 11:19:05 -0800 (PST) Date: Wed, 25 Feb 2004 11:18:16 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Tue, 24 Feb 2004 21:11:19 -0600" <403C1257.9000808@elvey.fastmail.fm> To: "Matthew Elvey (FM)" Cc: ned.freed@mrochek.com, "Matthew Elvey (FM)" , Alexey Melnikov , ietf-mta-filters@imc.org, Cyrus Daboo Message-id: <01L70MEK7C4A000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> <01L6WM5F152U000051@mauve.mrochek.com> <403C1257.9000808@elvey.fastmail.fm> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > So I am correct in concluding that you support the draft (the version > posted to the list, which is still the latest version) insofar as refuse > should be a new action, and MUAs must not claim to support it? Yes, I think the current draft gets this right. Ned Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1P3BU2t092893; Tue, 24 Feb 2004 19:11:30 -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 i1P3BUJQ092892; Tue, 24 Feb 2004 19:11:30 -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.8) with ESMTP id i1P3BK4Z092868 for ; Tue, 24 Feb 2004 19:11:23 -0800 (PST) (envelope-from matthew@elvey.fastmail.fm) X-Sasl-enc: OdL0Q4YwhgZrp5PobyuQmw 1077678684 Received: from elvey.fastmail.fm (p131.n-chpop07.stsn.com [63.240.158.131]) by mail.messagingengine.com (Postfix) with ESMTP id 751D9608841; Tue, 24 Feb 2004 22:11:22 -0500 (EST) Message-ID: <403C1257.9000808@elvey.fastmail.fm> Date: Tue, 24 Feb 2004 21:11:19 -0600 From: "Matthew Elvey (FM)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ned.freed@mrochek.com Cc: "Matthew Elvey (FM)" , Alexey Melnikov , ietf-mta-filters@imc.org, Cyrus Daboo Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> <01L6WM5F152U000051@mauve.mrochek.com> In-Reply-To: <01L6WM5F152U000051@mauve.mrochek.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 . 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: List-ID: List-Unsubscribe: On 2/22/2004 4:23 PM, ned.freed@mrochek.com sent forth electrons to convey: >> On 2/20/2004 9:41 AM, ned.freed@mrochek.com sent forth electrons to >> convey: > > >> > >> > The main problem with the idea of relaxing the rules for reject to >> > allow it to >> > generate DSNs or a 5xy error when running on an MTA is that a >> script will >> > behave in a fairly different way depending on whether you run it on an >> > MUA or a >> > MTA. I really don't like this. And if you use a require tag to mean >> > "change the >> > semantics of reject to refuse" and make it so the tag only works on >> > MTAs, >> > you're back to having to change the scripts when you move them around. >> > Its just >> > generally cleaner to have two different actions here and have one of >> > them be >> > MTA-only. > > >> It's unavoidable for behavior to differ between an MUA and an MTA, if >> there is support for a "refuse" action. > > > This presupposes that refuse is supportable on an MUA. I didn't (mean to) communicate that. What I meant to communicate: It's unavoidable for behavior to differ between an MUA and an MTA, if there is support for a "refuse" action (in Sieve when not on an MUA). > I don't think it is or > should be. So I am correct in concluding that you support the draft (the version posted to the list, which is still the latest version) insofar as refuse should be a new action, and MUAs must not claim to support it? You argued: > And if you use a require tag to mean "change the > semantics of reject to refuse" and make it so the tag only works on > MTAs, > you're back to having to change the scripts when you move them around. Yes, you'd have to change scripts using 'refuse' when you move them around whether 'refuse' changes the semantics of reject or not. Here's an idea: an implementation supporting 'refuse' MUST refuse at smtp time whenever possible. In other words, we make being an MUA an acceptable exception allowing an implementation to fail to refuse with a 5xx reply code (and instead send an MDN). We make script changes unnecessary, and yet it's still clear that your sieve client is refusing at smtp time whenever possible. Anyone who cares is likely to understand that MUAs can't refuse at smtp time. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OGin8k057343; Tue, 24 Feb 2004 08:44:49 -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 i1OGinvM057341; Tue, 24 Feb 2004 08:44:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1OGil7i057333 for ; Tue, 24 Feb 2004 08:44:48 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from LDAP4.andrew.cmu.edu (LDAP4.andrew.cmu.edu [128.2.10.233]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i1OGiokZ017536 for ; Tue, 24 Feb 2004 11:44:50 -0500 Date: Tue, 24 Feb 2004 11:44:50 -0500 (EST) From: Rob Siemborski To: ietf-mta-filters@imc.org Subject: imapflags -- backwards compatibility Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey, Ken, and I were discussing the new imapflags extension changes, and it should be possible to do this in a mostly backwards-compatible manner (excluding the :flags parameter to keep and fileinto). This would allow us to keep the old capability name. If the variable arguments to addflag and setflags optional, you can continue to have the old behavior (with the "global" flags variable). This avoids the need to add a full dependency on variables as well -- you would be unable to use the optional parameter unless "variables" is also required. Additionally, "hasflag" might also either require variables *or* you could make the variable list to hasflag optional as well (This is probably the most problematic aspect of doing this). Finally, if the :flags parameter is omitted to fileinto/keep, then the flags that are in the "global variable" would be applied to the message as it was stored. As an aside, it might make sense to move the "optional" arguments to the end of the parameter lists of these actions, but that is of lesser concern. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1MMThVs042870; Sun, 22 Feb 2004 14:29:43 -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 i1MMThe7042869; Sun, 22 Feb 2004 14:29:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1MMTgEk042863 for ; Sun, 22 Feb 2004 14:29:42 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L6TMNRXDHC000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Sun, 22 Feb 2004 14:28:32 -0800 (PST) Date: Sun, 22 Feb 2004 14:23:02 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Sun, 22 Feb 2004 16:10:11 -0600" <403928C3.4080408@elvey.fastmail.fm> To: "Matthew Elvey (FM)" Cc: ned.freed@mrochek.com, Alexey Melnikov , ietf-mta-filters@imc.org, Cyrus Daboo Message-id: <01L6WM5F152U000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> <403928C3.4080408@elvey.fastmail.fm> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On 2/20/2004 9:41 AM, ned.freed@mrochek.com sent forth electrons to convey: > > > > The main problem with the idea of relaxing the rules for reject to > > allow it to > > generate DSNs or a 5xy error when running on an MTA is that a script will > > behave in a fairly different way depending on whether you run it on an > > MUA or a > > MTA. I really don't like this. And if you use a require tag to mean > > "change the > > semantics of reject to refuse" and make it so the tag only works on > > MTAs, > > you're back to having to change the scripts when you move them around. > > Its just > > generally cleaner to have two different actions here and have one of > > them be > > MTA-only. > It's unavoidable for behavior to differ between an MUA and an MTA, if > there is support for a "refuse" action. This presupposes that refuse is supportable on an MUA. I don't think it is or should be. > What solution do you suggest to avoid a script either behaving > differently or having to be different ? I suggest that if you want a portable script you use reject and live with its limitations. If, on the other hand, you are willing to live with an MTA-only script, you have the option of using refuse. > You're almost saying you want both, but isn't that an impossibility? No. See above. > A require tag that means "change the semantics of reject to refuse" > seems to have the fewest drawbacks. I disagree. There's only a small incremental cost of switching rejects to refuses throughout compared to the cost of switching just the require clause. And you lose the ability to have both behaviors, which is something a large, composite script might want. > I think it's impossible for a script that uses a "refuse" action to be > and behave the same on an MUA and an MTA. It is impossible to implement refuse on an MUA, period. > This is still a problem with Cyrus' proposal: what would happen if > "refuse smtp5" was attempted in a script on a MUA? It still would > require a change on a mail agent that couldn't do SMTP time refuses. > Here's an idea! > Perhaps "refuse" should have an "Am I an MTA capable of refusing?" test > or constant? > Then users wouldn't have to add/remove the string > when moving a script between MUA and MTA. A major wart like this is entirely unwarranted IMO. Ned Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1MMHDjL042479; Sun, 22 Feb 2004 14:17:13 -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 i1MMHD3c042478; Sun, 22 Feb 2004 14:17:13 -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.8) with ESMTP id i1MMHBgG042472 for ; Sun, 22 Feb 2004 14:17:12 -0800 (PST) (envelope-from matthew@elvey.fastmail.fm) X-Sasl-enc: hRESNxqRFDwZnAisJsjrtw 1077487815 Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id DA1295CAC8A; Sun, 22 Feb 2004 17:10:13 -0500 (EST) Message-ID: <403928C3.4080408@elvey.fastmail.fm> Date: Sun, 22 Feb 2004 16:10:11 -0600 From: "Matthew Elvey (FM)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ned.freed@mrochek.com Cc: Alexey Melnikov , ietf-mta-filters@imc.org, Cyrus Daboo Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <01L6TFODICFU000051@mauve.mrochek.com> In-Reply-To: <01L6TFODICFU000051@mauve.mrochek.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 . 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: List-ID: List-Unsubscribe: On 2/20/2004 9:41 AM, ned.freed@mrochek.com sent forth electrons to convey: > > The main problem with the idea of relaxing the rules for reject to > allow it to > generate DSNs or a 5xy error when running on an MTA is that a script will > behave in a fairly different way depending on whether you run it on an > MUA or a > MTA. I really don't like this. And if you use a require tag to mean > "change the > semantics of reject to refuse" and make it so the tag only works on > MTAs, > you're back to having to change the scripts when you move them around. > Its just > generally cleaner to have two different actions here and have one of > them be > MTA-only. It's unavoidable for behavior to differ between an MUA and an MTA, if there is support for a "refuse" action. What solution do you suggest to avoid a script either behaving differently or having to be different ? You're almost saying you want both, but isn't that an impossibility? A require tag that means "change the semantics of reject to refuse" seems to have the fewest drawbacks. I think it's impossible for a script that uses a "refuse" action to be and behave the same on an MUA and an MTA. This is still a problem with Cyrus' proposal: what would happen if "refuse smtp5" was attempted in a script on a MUA? It still would require a change on a mail agent that couldn't do SMTP time refuses. Here's an idea! Perhaps "refuse" should have an "Am I an MTA capable of refusing?" test or constant? Then users wouldn't have to add/remove the string when moving a script between MUA and MTA. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KFpVnl010100; Fri, 20 Feb 2004 07:51:31 -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 i1KFpVdk010099; Fri, 20 Feb 2004 07:51:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1KFpOuI010090 for ; Fri, 20 Feb 2004 07:51:25 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L6SRNG66PS000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Fri, 20 Feb 2004 07:51:24 -0800 (PST) Date: Fri, 20 Feb 2004 07:41:24 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Sun, 15 Feb 2004 18:05:27 +0000" <402FB4E7.5010903@isode.com> To: Alexey Melnikov Cc: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org, Cyrus Daboo Message-id: <01L6TFODICFU000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Matthew Elvey (FM) wrote: > > I like Cyrus' idea of the refuse extension simply changing the semantics > > of "reject" for several reasons. > > It's the best way to make mass search-and-replace unnecessary when > > switching from an MTA that can support "refuse" to an MUA that can't. > > It makes it easier for folks to switch to using "refuse". > We are basically in agreement. > The only thing that concerns me is that currently "refuse" might > generate a DSN, while "reject" is required to generate an MDN. > Does it matter that the behavior changes when a Sieve script is moved > between MTA and MUA or vice versa? > I don't remember now why the Seive RFC was written to use MDNs. It is because MDNs are the only generally appropriate mechanism that both MTAs and MUAs can legitimately use. Remember that the place where sieves get applied is left intentionally fuzzy; it can be anything from just before the time of final delivery to much later. A DSN is not an appropriate construct to use after final delivery: The necessary information to construct the DSN may not be available, it looks bad if final delivery produced a success DSN only to be followed by a subsequent faileded DSN, etc. You can only get away with using DSNs for this if you restrict the time of application of the sieve to just before or during final delivery. > > I can't think of a situation where you would want both reject and refuse > > available at the same time. The main problem with the idea of relaxing the rules for reject to allow it to generate DSNs or a 5xy error when running on an MTA is that a script will behave in a fairly different way depending on whether you run it on an MUA or a MTA. I really don't like this. And if you use a require tag to mean "change the semantics of reject to refuse" and make it so the tag only works on MTAs, you're back to having to change the scripts when you move them around. Its just generally cleaner to have two different actions here and have one of them be MTA-only. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1FI5iJX093668; Sun, 15 Feb 2004 10:05:44 -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 i1FI5ikD093667; Sun, 15 Feb 2004 10:05:44 -0800 (PST) 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.8) with ESMTP id i1FI5be2093659 for ; Sun, 15 Feb 2004 10:05:39 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com ([62.3.217.253]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 15 Feb 2004 18:05:40 +0000 Message-ID: <402FB4E7.5010903@isode.com> Date: Sun, 15 Feb 2004 18:05:27 +0000 From: Alexey Melnikov 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: "Matthew Elvey (FM)" CC: ietf-mta-filters@imc.org, Cyrus Daboo Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402EC67F.8060902@elvey.fastmail.fm> In-Reply-To: <402EC67F.8060902@elvey.fastmail.fm> 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: List-ID: List-Unsubscribe: Matthew Elvey (FM) wrote: > I like Cyrus' idea of the refuse extension simply changing the semantics > of "reject" for several reasons. > It's the best way to make mass search-and-replace unnecessary when > switching from an MTA that can support "refuse" to an MUA that can't. > It makes it easier for folks to switch to using "refuse". We are basically in agreement. The only thing that concerns me is that currently "refuse" might generate a DSN, while "reject" is required to generate an MDN. Does it matter that the behavior changes when a Sieve script is moved between MTA and MUA or vice versa? I don't remember now why the Seive RFC was written to use MDNs. > I can't think of a situation where you would want both reject and refuse > available at the same time. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IG3GMI055470; Wed, 18 Feb 2004 08:03:16 -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 i1IG3G2O055469; Wed, 18 Feb 2004 08:03:16 -0800 (PST) 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.8) with ESMTP id i1IG3ECE055462 for ; Wed, 18 Feb 2004 08:03:15 -0800 (PST) (envelope-from daboo@cyrusoft.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 i1IG0qk3027600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2004 11:00:52 -0500 Date: Wed, 18 Feb 2004 11:03:08 -0500 From: Cyrus Daboo To: "Matthew Elvey (FM)" , Arnt Gulbrandsen , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <4464.1077102188@ninevah.cyrusoft.com> In-Reply-To: <40337941.6020106@elvey.fastmail.fm> References: <402EC67F.8060902@elvey.fastmail.fm> <40337941.6020106@elvey.fastmail.fm> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Matthew, --On Wednesday, February 18, 2004 6:40 AM -0800 "Matthew Elvey (FM)" wrote: |> Anyway, you could punt and say that a refuse implementation should use |> SMTP/LMTP rejection _where_possible_, and allow an implementation to |> treat refuse as reject if the implementation can't do anything else. | | I very much want the user to be able to know as conclusively as possible | that if "refuse" is supported, then they will be refusing mail at SMTP | time. Frankly I doubt that the 'average' user will understand the distinction between refuse and reject - 'power' users will. I would likely expect that reject vs refuse is something that will be decided by site admins as a matter of policy and they would configure their sieve web-frontends (or other script generation tools) to use one or the other as appropriate with just a single UI widget representing a 'reject' type action that the user can pick. Perhaps the following would be better: A single new command 'refuse' that takes various arguments, the first of which can be one of: 'mdn' - send an mdn rejection with supplied descriptive text 'dsn' - send a dsn rejection with supplied descriptive text 'smtp5' - send an smtp permanent failure - ascii text provided is sent with smtp response 'smtp4' - send an smtp temporary failure - ascii text provided is sent with smtp response 'default' - one of the above as a defined by site policy. The only problem with this is knowing how to deal with the text for the 'default' argument - for mdn/dsn it can be utf8, but for smtp it can only be ascii. Perhaps 'default' should take two strings - one utf8 one ascii - but that is ugly! -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1IFtua6054807; Wed, 18 Feb 2004 07:55:56 -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 i1IFtuFb054806; Wed, 18 Feb 2004 07:55:56 -0800 (PST) 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.8) with ESMTP id i1IFtoYQ054795 for ; Wed, 18 Feb 2004 07:55:55 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 18 Feb 2004 15:55:45 +0000 Message-ID: <40338AFE.4010906@isode.com> Date: Wed, 18 Feb 2004 15:55:42 +0000 From: Alexey Melnikov 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: Tim Showalter CC: ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402EC67F.8060902@elvey.fastmail.fm> <402FB4E7.5010903@isode.com> <4032BBAB.1000608@psaux.com> In-Reply-To: <4032BBAB.1000608@psaux.com> 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: List-ID: List-Unsubscribe: Tim Showalter wrote: > Alexey Melnikov wrote: > >> I don't remember now why the Seive RFC was written to use MDNs. > > I do. Reject originally (early spec, long time ago) said generate a > DSN, but MUAs can't do that--conceptually, anyway. An MUA can > generate a good forgery, but it was inappropriate for it to do so. > > The guarantee advertised by a DSN is supposed to be "this is what > happened". The guarantee advertised by an MDN is "this is what > happened, except that maybe then something else happened that negated > this event". My memory of the spec is that it doesn't exactly allow > outright lying, but you're allowed to state "deleted" and there is no > guarantee that the message wasn't immediately undeleted, for instance. > > So I guess the short version is that MDNs were chosen because we could > get away with so much more. Than my question is: is changing "reject" to generate DSNs in MTAs and MDN in MUAs acceptable? I personally have no problems with this, and I suspect most users will not probably care either. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1F182Fi071886; Sat, 14 Feb 2004 17:08:02 -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 i1F1828e071885; Sat, 14 Feb 2004 17:08:02 -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.8) with ESMTP id i1F17u9P071879 for ; Sat, 14 Feb 2004 17:07:57 -0800 (PST) (envelope-from matthew@elvey.fastmail.fm) X-Sasl-enc: tYXT/SgkIoR/xO6If+kkvw 1076807300 Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id CCCDF511583; Sat, 14 Feb 2004 20:08:15 -0500 (EST) Message-ID: <402EC67F.8060902@elvey.fastmail.fm> Date: Sat, 14 Feb 2004 17:08:15 -0800 From: "Matthew Elvey (FM)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Cc: "Arnt Gulbrandsen" , "Cyrus Daboo" , "Mark E. Mallett" , kristin.hubner@Sun.COM Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h 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 . 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: List-ID: List-Unsubscribe: Wow, lots of good feedback! Several replies follow: On 2/13/2004 7:47 AM, Arnt Gulbrandsen sent forth electrons to convey: > > > Anyway, I think the possibility of e.g. a future MAIL FROM test is > reason enough to __permit__ the refusal to happen at any stage of the > SMTP/LTMP process. I intend to remove the text "to an end of DATA command " so that in no case does the draft stand in the way of this. I think Sieve implementations supporting pre-DATA refuse is a desirable goal. For example, LMAP could well make pre-DATA refuse more even more useful than RBLs and envelope checks already do. And folks who want to receive all email addressed to them, completely "uncensored", can do so in a new way if there's a pre-DATA Sieve processing/operating mode. It's beyond the scope of this draft to explicitly facilitate it, so how 'bout a separate thread on a pre-DATA Sieve processing/operating mode? I prefer to not add excess verbiage explicitly allowing things that are already allowed, but we could (reluctantly) add: "SMTP refusal may happen at any stage of the SMTP/LTMP process, up to the end of DATA command." I like Cyrus' idea of the refuse extension simply changing the semantics of "reject" for several reasons. It's the best way to make mass search-and-replace unnecessary when switching from an MTA that can support "refuse" to an MUA that can't. It makes it easier for folks to switch to using "refuse". I can't think of a situation where you would want both reject and refuse available at the same time. Err, Arrgh - Kriskin Hubner came up with one: "reject" results in friendlier emails than "refuse". I find that many people don't understand even 'friendly' refuse messages - e.g. a doctor's and an economist's email to me were refused with a friendly refuse message, and yet they failed to act on it. Perhaps the format of "refuse" messages is actually MORE easily comprehended because it's less unique. (email |bugzilla3sd@matthewelvey.fastmail.fm to see my | 'friendly' refuse message|.)| (Regarding the other issues raised: I believe that anyone who would receive an email that was rejected would receive that email if it was refused as instead, unless they had weird email filters in place, so don't think that's an issue. Also, I can't recall seeing a bounce that didn't include the rejection text; what MTA's bounces don't ?) |3 of us like it. Kristin, further thoughts? Can you clarify whether SMTP rejection text can use another charset? I get email (spam) with Subjects in all sorts of charsets, imagine this would work too, but I'm (obviously) no expert. | On 2/13/2004 12:29 PM, Mark E. Mallett sent forth electrons to convey: >On Fri, Feb 13, 2004 at 10:59:01AM -0500, Cyrus Daboo wrote: > > >One might even add an option >to "reject" to specify the SMTP response code and the extended result code, >which could be used in the smtp-time mode and ignore otherwise. Alexey and I had considered this and decided that the added complexity of allowing the user to specify the SMTP response code was outweighed by the meager benefits of providing it. We even wrote (and later removed) a long text on how to allow user-specified __extended__ codes to be supported. "Experience with many protocols has shown that: protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity." - RFC 1651 Have a compelling argument for the option? In any case, I will s/5.7.0/5.7.1 in the draft (in the section that may or may not make it into the next revsion). >Re the draft text: why is it "test refuse" and not "action refuse" ? > > Because I made a mistake :). I will be mostly away from email next week. -- Matthew Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DNMnQB028289; Fri, 13 Feb 2004 15:22:49 -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 i1DNMnPM028288; Fri, 13 Feb 2004 15:22:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DNMmBp028281 for ; Fri, 13 Feb 2004 15:22:48 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L6JWNISZOW000051@mauve.mrochek.com> for ietf-mta-filters@imc.org; Fri, 13 Feb 2004 15:21:57 -0800 (PST) Date: Fri, 13 Feb 2004 15:18:42 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-reply-to: "Your message dated Fri, 13 Feb 2004 17:34:39 -0500" <402D50FF.1060609@lokitech.com> To: Serge Knystautas Cc: kristin.hubner@Sun.COM, Cyrus Daboo , "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Message-id: <01L6K3DJJ8CA000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <66e108b22ff.402ccaa0@mars.iplanet.com> <402D50FF.1060609@lokitech.com> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > kristin.hubner@Sun.COM wrote: > > But in other cases, with more "unfriendly" bounces, rejecting the message at the SMTP level is more > > desirable. When it's more important to limit load on or protect your own server vs. being "friendly" to > > the original sender, then "reject" can be more appealing. > > > > I can therefore envision cases of Sieve scripts that might wish to use both. > This isn't specific to just Kristin's comment, but if you're talking > about using sieve in the SMTP transaction, when does this happen? I suppose it could happen anywhere in the dialogue, but as a practical matter, any script that uses header tests (and the majority of them do) can only after the message has been transferred. Of course this runs into problems when there are multiple recipients. But remember: The majority of messages have a single recipient. And there's also LMTP to consider - a sieve implementation operating in the context of an LMTP server has no problem returning per-recipient failures after the data. Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DMYM4B025283; Fri, 13 Feb 2004 14:34:22 -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 i1DMYM4t025281; Fri, 13 Feb 2004 14:34:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.lokitech.com (mail.lokitech.com [209.92.53.4]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1DMYJqs025249 for ; Fri, 13 Feb 2004 14:34:20 -0800 (PST) (envelope-from sergek@lokitech.com) Received: from 216.181.165.37 ([216.181.165.37]) by mail.lokitech.com (JAMES SMTP Server 2.1.3) with SMTP ID 866; Fri, 13 Feb 2004 17:34:39 -0500 (EST) Message-ID: <402D50FF.1060609@lokitech.com> Date: Fri, 13 Feb 2004 17:34:39 -0500 From: Serge Knystautas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kristin.hubner@Sun.COM CC: Cyrus Daboo , "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <66e108b22ff.402ccaa0@mars.iplanet.com> In-Reply-To: <66e108b22ff.402ccaa0@mars.iplanet.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: List-ID: List-Unsubscribe: kristin.hubner@Sun.COM wrote: > But in other cases, with more "unfriendly" bounces, rejecting the message at the SMTP level is more > desirable. When it's more important to limit load on or protect your own server vs. being "friendly" to > the original sender, then "reject" can be more appealing. > > I can therefore envision cases of Sieve scripts that might wish to use both. This isn't specific to just Kristin's comment, but if you're talking about using sieve in the SMTP transaction, when does this happen? After MAIL FROM? After each RCPT TO? After HELO? (the last is a bit far-fetched, but it can be used as a more structured way of rejecting servers on DNS RBL). -- Serge Knystautas President Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. sergek@lokitech.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DL1674019357; Fri, 13 Feb 2004 13:01:06 -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 i1DL164U019356; Fri, 13 Feb 2004 13:01:06 -0800 (PST) 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.8) with ESMTP id i1DL15q4019339 for ; Fri, 13 Feb 2004 13:01:05 -0800 (PST) (envelope-from kristin.hubner@Sun.COM) Received: from dm-usca19-13.red.iplanet.com (host-179-56-18-192.iplanet.com [192.18.56.179] (may be forged)) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1DL1KdO007610; Fri, 13 Feb 2004 13:01:20 -0800 (PST) Received: from we-gotmail.red.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by dm-usca19-13.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id i1DL0gB04490; Fri, 13 Feb 2004 13:00:42 -0800 (PST) Received: from mars.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by we-gotmail.red.iplanet.com (Sun Java System Messaging Server 6.1 (built Feb 6 2004)) with ESMTP id <0HT1008ONJQ83640@we-gotmail.red.iplanet.com>; Fri, 13 Feb 2004 13:01:20 -0800 (PST) Received: from [129.153.12.63] by we-gotmail.red.iplanet.com (mshttpd); Fri, 13 Feb 2004 13:01:20 -0800 Date: Fri, 13 Feb 2004 13:01:20 -0800 From: kristin.hubner@Sun.COM Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h To: =?iso-8859-1?Q?Cyrus=A0Daboo=A0?= Cc: =?iso-8859-1?B?Ik1hdHRoZXegRWx2ZXmgKEZNKSKg?= , ietf-mta-filters@imc.org Message-id: <66e108b22ff.402ccaa0@mars.iplanet.com> MIME-version: 1.0 X-Mailer: Sun ONE Messenger Express 6.1 (built Feb 6 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I would argue that there is a need, or at least desire, to have both "reject" and "refuse". For one thing, you can't internationalize "refuse". We have people who want to ensure for some more "friendly" bounces that the original sender will see some "friendly" explanatory text. So they want to use "reject" so that they can: (a) ensure that their own text is presented to the original sending user (SMTP rejection text, in contrast, may or may not end up getting presented to the original sender), and possibly (b) use another language/charset (language-appropriate subset of UTF8) for their rejection text, possibly customizing the choice of language/characters based on characteristics of the message being rejected. But in other cases, with more "unfriendly" bounces, rejecting the message at the SMTP level is more desirable. When it's more important to limit load on or protect your own server vs. being "friendly" to the original sender, then "reject" can be more appealing. I can therefore envision cases of Sieve scripts that might wish to use both. Regards, Kristin kristin.hubner@sun.com ----- Original Message ----- From: Cyrus Daboo Date: Friday, February 13, 2004 7:59 am Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h > > Hi Matthew, > > --On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey > (FM)" > wrote: > > | Hello, folks. Please review and provide feedback on the "refuse" > | extension, designed to mostly replace Sieve's "reject" command. > > Question - is there any situation where you would want both reject > and > refuse available at the same time? i.e. couldn't we just get away > with an > extension that simply indicates that the existing reject command > will > actually run during the SMTP transaction and will generate an SMTP > error > instead of an MDN? Or, if modifying the base-spec reject behaviour > is > really not allowed in this way, how about having refuse do either > SMTP > error or MDN as appropriate for the system? That would mean that > users can > write one script using a single command and have it work on any > SIEVE > system, whether SIEVE runs at SMTP time or post-SMTP. I would hate > to have > to change reject<->refuse every time I moved or copied a script > across > different systems. > > -- > Cyrus Daboo > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DKTKb2017957; Fri, 13 Feb 2004 12:29:20 -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 i1DKTKcs017956; Fri, 13 Feb 2004 12:29:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by above.proper.com (8.12.11/8.12.8) with SMTP id i1DKTIrX017948 for ; Fri, 13 Feb 2004 12:29:19 -0800 (PST) (envelope-from mem@mv.mv.com) Received: (qmail 15872 invoked from network); 13 Feb 2004 15:29:39 -0500 Received: from iridium.mv.net (HELO mv.mv.com) (199.125.85.17) by mercury.mv.net with SMTP; 13 Feb 2004 15:29:39 -0500 X-Peer-Info: remote-ip 199.125.85.17 local-ip 199.125.85.40 local-name mercury.mv.net Received: (qmail 17778 invoked by uid 101); 13 Feb 2004 15:29:39 -0500 From: "Mark E. Mallett" Date: Fri, 13 Feb 2004 15:29:39 -0500 To: Cyrus Daboo Cc: "Matthew Elvey \(FM\)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <20040213202939.GB9805@iridium.mv.net> References: <402BDB3F.1090808@elvey.fastmail.fm> <9573.1076669941@ninevah.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9573.1076669941@ninevah.local> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Feb 13, 2004 at 10:59:01AM -0500, Cyrus Daboo wrote: > Hi Matthew, > > --On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey (FM)" > wrote: > > | Hello, folks. Please review and provide feedback on the "refuse" > | extension, designed to mostly replace Sieve's "reject" command. > > Question - is there any situation where you would want both reject and > refuse available at the same time? i.e. couldn't we just get away with an > extension that simply indicates that the existing reject command will > actually run during the SMTP transaction and will generate an SMTP error > instead of an MDN? Or, if modifying the base-spec reject behaviour is > really not allowed in this way, how about having refuse do either SMTP > error or MDN as appropriate for the system? That would mean that users can > write one script using a single command and have it work on any SIEVE > system, whether SIEVE runs at SMTP time or post-SMTP. I would hate to have > to change reject<->refuse every time I moved or copied a script across > different systems. This was my initial reaction too: rather than introduce a new action, introduce a new "smtp-time" operating mode where the existing "reject" action would have the desired effect. One might even add an option to "reject" to specify the SMTP response code and the extended result code, which could be used in the smtp-time mode and ignore otherwise. As I mentioned in another thread, this notion of operating mode could also be useful in other contexts. Re the draft text: why is it "test refuse" and not "action refuse" ? mm Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DJcq8x015097; Fri, 13 Feb 2004 11:38:52 -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 i1DJcqek015096; Fri, 13 Feb 2004 11:38:52 -0800 (PST) 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.8) with ESMTP id i1DJconX015089 for ; Fri, 13 Feb 2004 11:38:51 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust246.tnt30.lnd3.gbr.da.uu.net [62.188.122.246]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 13 Feb 2004 19:39:08 +0000 Message-ID: <402D0276.40509@isode.com> Date: Fri, 13 Feb 2004 16:59:34 +0000 From: Alexey Melnikov 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: Arnt Gulbrandsen CC: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402BDB3F.1090808@elvey.fastmail.fm> In-Reply-To: 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: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Matthew Elvey (FM) writes: > >> http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt > > > I suggest adding a sentence saying that SMTP refusal may happen at the > RCPT TO or DATA stages, depending on what's convenient to the > implementation. (I suppose it might also happen at the MAIL FROM > stage, if a systemwide sieve does the refusal.) > > The 550 result code is a fine thing, but shouldn't you also specify an > extended result code (1893/2034)? 5.7.1, perhaps? This is an open issue in the document ;-). Matthew and I weren't sure what to do with enhanced status codes. Do you suggest that we mandate 5.7.1 or should we instead mention it and allow an MTA to select another enhanced status code if appropriate? Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DJciKO015083; Fri, 13 Feb 2004 11:38:44 -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 i1DJcimq015082; Fri, 13 Feb 2004 11:38:44 -0800 (PST) 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.8) with ESMTP id i1DJchZa015075 for ; Fri, 13 Feb 2004 11:38:43 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust246.tnt30.lnd3.gbr.da.uu.net [62.188.122.246]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Fri, 13 Feb 2004 19:38:53 +0000 Message-ID: <402D018E.3060102@isode.com> Date: Fri, 13 Feb 2004 16:55:42 +0000 From: Alexey Melnikov 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: Arnt Gulbrandsen CC: Cyrus Daboo , "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h References: <402BDB3F.1090808@elvey.fastmail.fm> <6008.1076668650@ninevah.local> In-Reply-To: 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: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Cyrus Daboo writes: > >> But SIEVE has to operate on the message data - there isn't enough >> information before the DATA command to run SIEVE, unless you extend >> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test). > > As I remember the draft I read, a spamtest implementation can legally > arrive at a conclusion without considering the body, so if the > script's first rule is a spam test, the body need not be considered. > (I agree that the body will almost always be considered.) In theory any Sieve script that doesn't test message headers/body can be executed before DATA command. But the task of checking if a Sieve script doesn't require message content might not be a trivial task. Especially if the Sieve engine also supports variables. So I would rather ignore the issue of executing Sieve scripts before DATA command in the Sieve "refuse" extension. > Anyway, I think the possibility of e.g. a future MAIL FROM test is > reason enough to _permit_ the refusal to happen at any stage of the > SMTP/LTMP process. > >> Frankly any system-wide script like that is better left to the SMTP >> implentation's own filtering/ruleset behaviour. > > Sure, but that own filtering behaviour might just be sieve ;) Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DGAOpo003123; Fri, 13 Feb 2004 08:10:24 -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 i1DGAOk6003122; Fri, 13 Feb 2004 08:10:24 -0800 (PST) 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.8) with ESMTP id i1DGAIYC003105 for ; Fri, 13 Feb 2004 08:10:19 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.3] (pool-141-151-144-199.pitt.east.verizon.net [141.151.144.199]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i1DG8uk3006708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2004 11:09:00 -0500 Date: Fri, 13 Feb 2004 11:10:27 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen cc: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <11803.1076670627@ninevah.local> In-Reply-To: References: <402BDB3F.1090808@elvey.fastmail.fm> <6008.1076668650@ninevah.local> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Friday, February 13, 2004 4:47 PM +0100 Arnt Gulbrandsen wrote: |> But SIEVE has to operate on the message data - there isn't enough |> information before the DATA command to run SIEVE, unless you extend |> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test). | | As I remember the draft I read, a spamtest implementation can legally | arrive at a conclusion without considering the body, so if the script's | first rule is a spam test, the body need not be considered. (I agree that | the body will almost always be considered.) | | Anyway, I think the possibility of e.g. a future MAIL FROM test is reason | enough to _permit_ the refusal to happen at any stage of the SMTP/LTMP | process. If you are going to run a script before DATA then you are going to have to limit the set of available sieve tests to just those that make sense - in other words you need to define different 'profiles' of the sieve syntax that are valid for different phases of the message delivery process. I think it would be a mistake just to say that certain tests (e.g. for header addresses) become no-ops when run before DATA. As such I think that a document that defines such a profile would allow the refusal on MAIL FROM or RCPT TO without needing to define that in refuse. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DG15NQ002516; Fri, 13 Feb 2004 08:01:05 -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 i1DG15m3002515; Fri, 13 Feb 2004 08:01:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from chiark.greenend.org.uk (mail@chiark.greenend.org.uk [193.201.200.170]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DG14nv002507 for ; Fri, 13 Feb 2004 08:01:04 -0800 (PST) (envelope-from fanf@chiark.greenend.org.uk) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-mta-filters@imc.org id 1Arfkr-0006VF-00; Fri, 13 Feb 2004 16:01:25 +0000 To: ietf-mta-filters@imc.org From: Tony Finch Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h In-Reply-To: References: <402BDB3F.1090808@elvey.fastmail.fm> <6008.1076668650@ninevah.local> <6008.1076668650@ninevah.local> Message-Id: Date: Fri, 13 Feb 2004 16:01:25 +0000 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > >Anyway, I think the possibility of e.g. a future MAIL FROM test is >reason enough to _permit_ the refusal to happen at any stage of the >SMTP/LTMP process. There's already an envelope from test in RFC 3028. Tony. -- f.a.n.finch http://dotat.at/ CROMARTY FORTH TYNE DOGGER: WESTERLY VEERING NORTHERLY 3 OR 4. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR IN DOGGER. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DFwln5002407; Fri, 13 Feb 2004 07:58:47 -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 i1DFwlDH002406; Fri, 13 Feb 2004 07:58:47 -0800 (PST) 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.8) with ESMTP id i1DFwkJm002398 for ; Fri, 13 Feb 2004 07:58:46 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.3] (pool-141-151-144-199.pitt.east.verizon.net [141.151.144.199]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i1DFvUk3006555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2004 10:57:34 -0500 Date: Fri, 13 Feb 2004 10:59:01 -0500 From: Cyrus Daboo To: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <9573.1076669941@ninevah.local> In-Reply-To: <402BDB3F.1090808@elvey.fastmail.fm> References: <402BDB3F.1090808@elvey.fastmail.fm> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Matthew, --On Thursday, February 12, 2004 11:59 AM -0800 "Matthew Elvey (FM)" wrote: | Hello, folks. Please review and provide feedback on the "refuse" | extension, designed to mostly replace Sieve's "reject" command. Question - is there any situation where you would want both reject and refuse available at the same time? i.e. couldn't we just get away with an extension that simply indicates that the existing reject command will actually run during the SMTP transaction and will generate an SMTP error instead of an MDN? Or, if modifying the base-spec reject behaviour is really not allowed in this way, how about having refuse do either SMTP error or MDN as appropriate for the system? That would mean that users can write one script using a single command and have it work on any SIEVE system, whether SIEVE runs at SMTP time or post-SMTP. I would hate to have to change reject<->refuse every time I moved or copied a script across different systems. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DFknCM001539; Fri, 13 Feb 2004 07:46:49 -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 i1DFknXw001538; Fri, 13 Feb 2004 07:46:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DFkl8h001532 for ; Fri, 13 Feb 2004 07:46:47 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Cc: "Matthew Elvey (FM)" , ietf-mta-filters@imc.org References: <402BDB3F.1090808@elvey.fastmail.fm> <6008.1076668650@ninevah.local> In-Reply-To: <6008.1076668650@ninevah.local> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 13 Feb 2004 16:47:14 +0100 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > But SIEVE has to operate on the message data - there isn't enough > information before the DATA command to run SIEVE, unless you extend > SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test). As I remember the draft I read, a spamtest implementation can legally arrive at a conclusion without considering the body, so if the script's first rule is a spam test, the body need not be considered. (I agree that the body will almost always be considered.) Anyway, I think the possibility of e.g. a future MAIL FROM test is reason enough to _permit_ the refusal to happen at any stage of the SMTP/LTMP process. > Frankly any system-wide script like that is better left to the SMTP > implentation's own filtering/ruleset behaviour. Sure, but that own filtering behaviour might just be sieve ;) Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DFbRLk001074; Fri, 13 Feb 2004 07:37:27 -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 i1DFbQxa001073; Fri, 13 Feb 2004 07:37:26 -0800 (PST) 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.8) with ESMTP id i1DFbKiZ001066 for ; Fri, 13 Feb 2004 07:37:20 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.3] (pool-141-151-144-199.pitt.east.verizon.net [141.151.144.199]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i1DFa0k3006152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2004 10:36:02 -0500 Date: Fri, 13 Feb 2004 10:37:30 -0500 From: Cyrus Daboo To: Arnt Gulbrandsen , "Matthew Elvey (FM)" cc: ietf-mta-filters@imc.org Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Message-ID: <6008.1076668650@ninevah.local> In-Reply-To: References: <402BDB3F.1090808@elvey.fastmail.fm> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Friday, February 13, 2004 11:28 AM +0100 Arnt Gulbrandsen wrote: | I suggest adding a sentence saying that SMTP refusal may happen at the | RCPT TO or DATA stages, depending on what's convenient to the | implementation. (I suppose it might also happen at the MAIL FROM stage, | if a systemwide sieve does the refusal.) But SIEVE has to operate on the message data - there isn't enough information before the DATA command to run SIEVE, unless you extend SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test). Frankly any system-wide script like that is better left to the SMTP implentation's own filtering/ruleset behaviour. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DASdo3084608; Fri, 13 Feb 2004 02:28:39 -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 i1DASc39084607; Fri, 13 Feb 2004 02:28:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1DASW4o084599 for ; Fri, 13 Feb 2004 02:28:36 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 337781BDE5A; Fri, 13 Feb 2004 11:28:48 +0100 (CET) Message-Id: From: Arnt Gulbrandsen To: "Matthew Elvey (FM)" Subject: Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h Cc: ietf-mta-filters@imc.org References: <402BDB3F.1090808@elvey.fastmail.fm> In-Reply-To: <402BDB3F.1090808@elvey.fastmail.fm> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 13 Feb 2004 11:28:09 +0100 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Matthew Elvey (FM) writes: > http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt I suggest adding a sentence saying that SMTP refusal may happen at the RCPT TO or DATA stages, depending on what's convenient to the implementation. (I suppose it might also happen at the MAIL FROM stage, if a systemwide sieve does the refusal.) The 550 result code is a fine thing, but shouldn't you also specify an extended result code (1893/2034)? 5.7.1, perhaps? Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1CK38G3060341; Thu, 12 Feb 2004 12:03:08 -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 i1CK38jI060340; Thu, 12 Feb 2004 12:03:08 -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.8) with ESMTP id i1CK36s2060328 for ; Thu, 12 Feb 2004 12:03:06 -0800 (PST) (envelope-from matthew@elvey.fastmail.fm) X-Sasl-enc: dw5UXec+0wrvv2yq48R9fA 1076616002 Received: from elvey.fastmail.fm (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 7E40A4F4ED7 for ; Thu, 12 Feb 2004 15:00:02 -0500 (EST) Message-ID: <402BDB3F.1090808@elvey.fastmail.fm> Date: Thu, 12 Feb 2004 11:59:59 -0800 From: "Matthew Elvey (FM)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h 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 . 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: List-ID: List-Unsubscribe: Hello, folks. Please review and provide feedback on the "refuse" extension, designed to mostly replace Sieve's "reject" command. It's been accepted as an I-D (-00), but we've made some further changes to what's published, so please review and comment on what's at We welcome feedback, particularly - changes that include replacement text or - suggestions from Sieve implementers. Abstract With "refuse", Sieve gains the ability to simply not accept an email during the SMTP transaction (instead of accepting it and then sending an MDN [MDN] back to the alleged sender using "reject"). A Joe-job is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by the bounces, MDNs and messages with complaints. With "reject", MDNs contribute to the flood of Joe-job spam to victims of Joe-jobs; SMTP level refusals usually don't. So "refuse" provides users the latter method to handle unwanted email. The further changes were limited to Section 13 'Open Issues for Discussion' and a typo. -Matthew & Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i161gqeG069366; Thu, 5 Feb 2004 17:42:52 -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 i161gqnk069365; Thu, 5 Feb 2004 17:42:52 -0800 (PST) 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.8) with ESMTP id i161go9b069351 for ; Thu, 5 Feb 2004 17:42:51 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (pool-141-151-144-199.pitt.east.verizon.net [141.151.144.199]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i161gYk3020774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Feb 2004 20:42:37 -0500 Date: Thu, 05 Feb 2004 20:42:55 -0500 From: Cyrus Daboo To: IETF MTA Filters List Subject: I-D ACTION:draft-daboo-sieve-mime-00.txt (fwd) Message-ID: <104800.1076013775@ninevah.cyrusoft.com> X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI - the following is a draft for a new SIEVE operation for testing the content of MIME part headers. Comments welcome... ------------ Forwarded Message ----------- Date: Thursday, February 5, 2004 3:43 PM -0500 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-daboo-sieve-mime-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIEVE Email Filtering: MIME Extension Author(s) : C. Daboo Filename : draft-daboo-sieve-mime-00.txt Pages : 8 Date : 2004-2-5 This document describes the SIEVE Email Filtering 'mime' extension which adds a new test for testing the values of MIME headers in a message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daboo-sieve-mime-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-daboo-sieve-mime-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-daboo-sieve-mime-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- End Forwarded Message ---------- -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i158kSKc074700; Thu, 5 Feb 2004 00:46:28 -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 i158kSvE074699; Thu, 5 Feb 2004 00:46:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i158kR0c074687 for ; Thu, 5 Feb 2004 00:46:27 -0800 (PST) (envelope-from mganesh@india.hp.com) Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel6.hp.com (Postfix) with ESMTP id 04F541C0442C; Thu, 5 Feb 2004 03:46:34 -0500 (EST) Received: from india.hp.com (nt23060.india.hp.com [15.42.230.60]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i158QFZ03665; Thu, 5 Feb 2004 13:56:15 +0530 (IST) Message-ID: <402202E8.30206@india.hp.com> Date: Thu, 05 Feb 2004 14:16:32 +0530 From: Madan Ganesh Velayudham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lyndon Nerenberg Cc: ietf-mta-filters@imc.org Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments References: <401963FA.60905@india.hp.com> <2147483647.1075381786@d154-5-112-162.bchsia.telus.net> <401E9888.6020601@india.hp.com> <2147483647.1075932638@d154-5-112-162.bchsia.telus.net> In-Reply-To: <2147483647.1075932638@d154-5-112-162.bchsia.telus.net> 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: List-ID: List-Unsubscribe: Lyndon Nerenberg wrote: > --On 2004-2-3 12:05 AM +0530 Madan Ganesh Velayudham > wrote: > >>> Section 9: >>> >>> * Since there's no way (that I can see) to access another users >>> counter data (through the protocol), this text doesn't seem >>> relevant. >> >> >> Yes, I agree. But to be expilicit. > > > It is "explicit" by reason of the specification simply not specifying > the facility. Having the security section talk about something that does > not exist in the protocol is just going to confuse people. The text in > question needs to be removed. > > Yes, Lyndon. Thats a valid one. It is better not to confuse the people. The updated draft will not have this text. Thank You, MG -- _____________________________________________________________ ___ /___\ Madan ganesh Velayudham |/. .\| STSD, India ( ) ) +91 80 (2) 205 3108 \ = / _)_(_ There are no limitation in what you can do except the limitations of your own mind. _____________________________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i156Asoq017049; Wed, 4 Feb 2004 22:10:54 -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 i156ArCx017048; Wed, 4 Feb 2004 22:10:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i156Aq2s017009 for ; Wed, 4 Feb 2004 22:10:52 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-112-162.bchsia.telus.net (d154-5-112-162.bchsia.telus.net [154.5.112.162]) (authenticated bits=0) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id i156AiTi072320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2004 23:10:51 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Wed, 04 Feb 2004 22:10:38 -0800 From: Lyndon Nerenberg To: Madan Ganesh Velayudham cc: ietf-mta-filters@imc.org Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments Message-ID: <2147483647.1075932638@d154-5-112-162.bchsia.telus.net> In-Reply-To: <401E9888.6020601@india.hp.com> References: <401963FA.60905@india.hp.com> <2147483647.1075381786@d154-5-112-162.bchsia.telus.net> <401E9888.6020601@india.hp.com> X-Mailer: Mulberry/3.1.1 (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=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-2-3 12:05 AM +0530 Madan Ganesh Velayudham wrote: >> Section 9: >> >> * Since there's no way (that I can see) to access another users >> counter data (through the protocol), this text doesn't seem >> relevant. > > Yes, I agree. But to be expilicit. It is "explicit" by reason of the specification simply not specifying the facility. Having the security section talk about something that does not exist in the protocol is just going to confuse people. The text in question needs to be removed. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14E8YTv053452; Wed, 4 Feb 2004 06:08:34 -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 i14E8Yb1053451; Wed, 4 Feb 2004 06:08:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from vementry.enterprise.ucs.ed.ac.uk (vementry.enterprise.ucs.ed.ac.uk [129.215.200.96]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14E8WsK053432 for ; Wed, 4 Feb 2004 06:08:33 -0800 (PST) (envelope-from nigel.swinson@rockliffe.com) Received: from SCOTTY (unverified [129.215.188.53]) by vementry.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 6.0.9) with ESMTP id ; Wed, 4 Feb 2004 14:08:34 +0000 Message-ID: <032601c3eb28$5f8448f0$662c2a0a@rockliffe.com> From: "Nigel Swinson" To: "Madan Ganesh Velayudham" Cc: References: <401963FA.60905@india.hp.com> Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments Date: Wed, 4 Feb 2004 14:08:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > "SIEVE: Remove attachment(s)", Madan Velayudham, 23-Dec-03. (8185 bytes) " > > http://ietf.org/internet-drafts/draft-madanganeshv-sieve-remove-attach-00.txt > > > This draft introduces an action command 'fileinto-except' to [SIEVE] in > order to move a message to a folder without certain attachments of the > received message. I think it might be more useful to have an action that removes an attachment, and a test that tests for the prescence of a mime body part. So you'd say: if (message contains .exe attachment) { remove .exe attachment fileinto folder; stop; } We generically want a test that allows users to examine the prescense or absence of attachments of various kinds, so I think it would make sense to build upon that work. As it is, the extension you propose means that you can only neatly remove one style of attachment. What if you want to remove all .exe/.bat/.pif/.vbs attachments? You'd end up with long and nasty regex expressions that try to match filenames that contain any of the proposed extensions. Much better I think would be to have four remove attachment commands, one for each kind of extension. Having a remove-attachment extension will end up along the lines of the editheader extensions in the sense that they will modify the message. So it raises some of the issues that have already been discussed there, so I guess we'd have to say that tests examine the current state of the message. So if we say: remove .exe attachments if (message contains .exe attachment) { We'd never get here. } Cheers Nigel Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12IZsel031087; Mon, 2 Feb 2004 10:35:54 -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 i12IZs0B031086; Mon, 2 Feb 2004 10:35:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i12IZrX4031078 for ; Mon, 2 Feb 2004 10:35:53 -0800 (PST) (envelope-from mganesh@india.hp.com) Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel12.hp.com (Postfix) with ESMTP id 766CF1C023CF; Mon, 2 Feb 2004 10:35:53 -0800 (PST) Received: from india.hp.com (nt23060.india.hp.com [15.42.230.60]) by iconsrv6.india.hp.com (8.11.1 (PHNE_29912)/8.9.3 SMKit7.02) with ESMTP id i12IIEZ12988; Mon, 2 Feb 2004 23:48:14 +0530 (IST) Message-ID: <401E9888.6020601@india.hp.com> Date: Tue, 03 Feb 2004 00:05:52 +0530 From: Madan Ganesh Velayudham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lyndon Nerenberg Cc: ietf-mta-filters@imc.org Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments References: <401963FA.60905@india.hp.com> <2147483647.1075381786@d154-5-112-162.bchsia.telus.net> In-Reply-To: <2147483647.1075381786@d154-5-112-162.bchsia.telus.net> 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: List-ID: List-Unsubscribe: Hi Lyndon, Thank you for your review comments. Please find my comments in line : > > Some comments based on a quick scan of the document ... > > Section 4: > > * "action" needs to be more clearly defined Sure. Shall refine it. > > Section 5: > > * Why two capabilities? Both commands are required, so there's no > point in advertising two capability strings. The capability should be > changed to something like "STATISTICS". Thats great. Yes, Both are required capability strings. I will update the Capability string to STATISTICS. > > Section 6: > > * What does a "zero valued action counter" mean? Surely '0' is a valid > counter value, meaning the action has never been triggered. I think what > you're implying here is that a '0' value means the counter for the > action isn't implemented. If that's the case, just don't return a > response for that action. My initial assumption was if the discarded mail count is 0, the implementation may return discard 0 or dont return discard action itself. But as you said, the client is no way differentiating whether the action is supported or not. > > * Presumably GETSTAT is only valid in authenticated state? (Section 7 > explicitly calls this out, so section 6 should as well.) I think it is already there. "This command MUST be given after the client is authenticated". Pls clarify if i'm wrong. > > Section 8: > > * The grammar (and semantic description) for the command responses is > missing. Thanks for pointing out. I shall include it some thing like command-getstat-resp = getstat-resp-list getstat-resp-list = [ supported-action integer-value ] * getstat-resp-list supported-action = "discard" / "divert" / "reject" command-resetstat=res = "OK" | "NO" > > Section 9: > > * Since there's no way (that I can see) to access another users counter > data (through the protocol), this text doesn't seem relevant. Yes, I agree. But to be expilicit. > > General: > > * How useful is the returned data? The fact that an action took place > doesn't really tell me anything. I would be much more interested in > seeing how often each rule fired, as that would allow me to optimize my > rulesets. > That is a interesting thought. I shall think of it and document it. Please let me know your comments. MG > --lyndon > -- _____________________________________________________________ ___ /___\ Madan ganesh Velayudham |/. .\| STSD, India ( ) ) +91 80 (2) 205 3108 \ = / _)_(_ There are no limitation in what you can do except the limitations of your own mind. _____________________________________________________________