From owner-ietf-mta-filters@mail.imc.org Mon Dec 3 16:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=4.0 tests=AWL,BAYES_50 autolearn=no version=3.2.3 X-mallorn-MailScanner-Watermark: 1197325666.56965@1HXwB+OMgrYml3DgjT5FSw X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 03 Dec 2007 16:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB3MRcLX032369 for ; Mon, 3 Dec 2007 17:27:43 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB3MEcV1018301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 15:14:38 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB3MEcBT018299; Mon, 3 Dec 2007 15:14:38 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB3MEbrb018293 for ; Mon, 3 Dec 2007 15:14:38 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOGFSLFGB4006Z3P@mauve.mrochek.com> for ietf-mta-filters@imc.org; Mon, 3 Dec 2007 14:14:29 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOGCK4QI4G00ISSF@mauve.mrochek.com> for ietf-mta-filters@imc.org; Mon, 03 Dec 2007 14:14:00 -0800 (PST) Message-id: <01MOGFRJ1PAW00ISSF@mauve.mrochek.com> Date: Mon, 03 Dec 2007 14:14:00 -0800 (PST) From: Ned Freed Subject: My message about notify looping issues and possible solutions MIME-version: 1.0 Content-type: message/rfc822 To: MTA filtering mailing list DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1196720068; h=Date: From:Subject:MIME-version:Content-type; b=lzFCySI9UpBlxsPYXTu0LX3/E 2OtzN7BveRXy8U0KGTcWXzAIiWPI6S/5V6ZyqDUbkkZA4bIN0eEqMlTcnh2CQ== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Return-path: Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MNBHBAEWZK00BDC1@mauve.mrochek.com> for ned@mauve.mrochek.com; Tue, 06 Nov 2007 12:15:46 -0800 (PST) Date: Tue, 06 Nov 2007 07:28:30 -0800 (PST) From: Ned Freed Subject: Re: Request for review of draft-ietf-sieve-notify-mailto In-reply-to: "Your message dated Tue, 06 Nov 2007 14:43:38 +0000" <47307D9A.2010906@isode.com> To: Alexey Melnikov Cc: Ned Freed , Cyrus Daboo , Barry Leiba , Michael Haardt , Keith Moore Message-id: <01MNELS447A600BDC1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed Message-hash: 66BB4143B8AAEAD5C2F3C59D7E3BBF4F References: <47307D9A.2010906@isode.com> Original-recipient: rfc822;ned.freed@mrochek.com > Can you please review the latest draft-ietf-sieve-notify-mailto, as Lisa > is about to issue IETF LC on it. > In particular I am looking for your feedback on 2 issues: > 1). Is the text of mail loop prevention sufficient? It has at least two bugs, one obvious, the other subtle. First the obvious bug: THe text currently says that any Auto-submitted: field prevents notifications from being generated. What about "Auto-submitted: No"? Mind you, I doubt very much that generation of this field with this value will occur often if at all (in fact one possibility is to simply deprecate the "no" value at this point), but this is nevertheless an issue that needs to be fixed. The obvious solution is to treat "no" and only "no" as the same as not having an auto-submitted field. I also have to wonder if it doesn't make sense to add a parameter to Auto-submitted: that can be used to identify the email address of the owner of the sieve generating the notification. Incidentally, given that this document established an auto-submitted registry Keith Moore probably should be alerted to this action and I'm cc'ing him on this response. I don't think he follows the Sieve WG regularly. Now the subtle bug: The current rules permit a case where an undetectable loop can occur. Suppose I create a sieve that says: require "notify"; notify :from "ned.freed@mrochek.com" :message "whatever" "mailto:nosuchuser@validdomainwithdelayedaddressvaliditychecking.org"; This causes a notification to be sent unconditionally to an invalid address whose validity cannot be checked immediately and with an envelope from pointing back to the sieve owner. So in comes a triggering message, out goes a notification. The notification then bounces and unless the DSN contains an auto-submitted field it will generate another notification. (Note that the current draft standard for DSNs, RFC 3464, preceeded RFC 3834 and hence does not require an Auto-submitted field be included in the DSN. In fact RFC 3834 goes out of its way not to impose requirements on DSNs and MDNs so an implementation can be RFC 3834 compliant without adding Auto-submitted to DSNs. Since we cannot retroactively impose a requirement that DSNs and MDNs contain an auto-submitted field (and even it would take too long to deploy) we have to solve this some other way. I see two possibiities, one tricky, cute, but unreliable, the other ugly but reliable: (1) Require that when the envelope from on the triggering message is blank that the message be checked to see if it is a DSN/MDN and if it is look at the third part to see if it contains an auto-submitted header. (2) Use the same trick we required on redirect: When the triggering message contains an empty envelope from require that any notifications it generates also have an empty envelope from. I mention (1) only because of its cuteness - IMO it isn't going to be reliable enough, if for no other reason than the widespread existance of DSNs and MDNs using nonstandard formats. (Thank you qmail...) That leaves (2). I don't like it much but I don't see any real alternative. > 2). Something I remember from a previous conversation with you: are you > happy with the requirement on the Notify action to preserve Received > headers from the original message? No I'm not. As currently defined it's quite simply wrong to do this. The original message is what garnered those trace field values, not the notification. Someone attempting to trace the message path using this information could easily end up being very confused. It is also bound to trip any loop detection logic that has been set to fairly tight tolerances. And there's also the spam filter issue - one check I've seen made is to compare the dates on the Received: fields with the Date: field. A Date: field that's in the future relative to the first Received: field could raise flags and cause problems. (Mind you, I don't see a reason to cater to broken filter criteria but that's not sufficient justification for ignoring the issue completely.) Unfortunately there are no really good ways to solve this problem. I see the following possibilities: (1) Rely on auto-submitted being preserved as a loop check and don't do the Received: line copy at all. (2) Classify the Auto-submitted: field as a trace field and require that it appear above the copied Received: fields as a sort of boundary between the old set of Received: fields and the new. (3) Same as (2) except make the trace field some newly defined thing. (4) Same as (2) except use a specially formatted Received: field as the boundary. (5) Make the Received: line copy a SHOULD rather than a MUST. Add some discussion that the separation between old and new Receieved: fields can usually be determined by comparing the dates with the those on the Date: field. (6) Add the discussion mentioned in (5) but ignore the problem otherwise. I think (2) is our best bet. It should not be hard for implementors to do and it deals with the tracing problem, albeit in a somewhat fragile way (header fields of different with different names can and do get reordered in some cases). And while it doesn't solve the tight tolerance loop counter it does offer various ways out, e.g., impose a loose limit on the total number of Received: lines but a tighter limit on the number above the Auto-submitted: line. (I already have some logic along these lines so this is the course of action I'll probably bursue.) The same is true of date checks - filters could limit their checks to the fields above the Auto-submitted: (of course this requires a change in those filters). (1) makes me somewhat nervous - people have had their hands slapped often enough about preserving Received: fields but there's no similar history to support Auto-submitted: field preservation. I also doubt it will make it past the present IESG - I'm sure you know why. (6) is unacceptable to me, so much so that if it is the path chosen I will be implementing notify with the Received: line copy action disabled by default, regardless of whether or not it is deemed to be mandatory in the document. (We have several sites that make heavy, heavy use of notify and at least a couple of them do a lot of messaging tracing that would be totally confused without a well-defined trace boundary. One of them also operates in a regime where it is likely that trying to sort things by time comparisons won't be reliable.) I can live with (3) or (4) but fail to see any advantage over (2). I can also live with (5), of course, but like (1) I doubt it will make it past the IESG. A few more comments on the present draft: THe text in section 2.7 about :from needs to say that security checks MAY be applied to the :from values users specify. I see nothing in the security considerations section or anywhere else about placing limits on the number of notify actions a sieve script can perform. Nor is there any discussion of this in the base notify draft. Based on our recent experience with the base specification, I'm pretty sure this is a mistake that is going to guarantee a discuss from you-know-who. The obvious way to address this is to add some text either in this document or in the base notify specification that's modelled on the discussion of redirect in the base specification. Finally, a nit: The example shows :importance being specified even though the specification assigns no significance to :importance when this method is used. I suggest removing it. Ned From owner-ietf-mta-filters@mail.imc.org Mon Dec 3 20:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=4.0 tests=AWL,BAYES_05 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1197343510.88943@pXxnGpLTe/A3cQDHCLTmqg X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Mon, 03 Dec 2007 20:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB43P447017089 for ; Mon, 3 Dec 2007 22:25:09 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB43Ftb9047720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 20:15:55 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB43Ftxb047719; Mon, 3 Dec 2007 20:15:55 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB43FqUK047710 for ; Mon, 3 Dec 2007 20:15:53 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from [130.129.81.92] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 74C4E3D2D; Mon, 3 Dec 2007 19:16:46 -0800 (PST) Subject: Re: Naming conventions for Sieve RFCs From: Aaron Stone To: Kjetil Torgrim Homme , Alexey Melnikov , Nigel Swinson , ietf-mta-filters In-Reply-To: <1187011668.15776.6.camel@oslhomkje> References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> Content-Type: text/plain Date: Mon, 03 Dec 2007 19:15:01 -0800 Message-Id: <1196738101.7545.157.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Reviving this thread from the last message (not necessarily replying to this one specifically)... I am converting refuse-reject to xml2rfc. I have this: Sieve Email Filtering: Reject Extension I like Nigel's suggestion not to imply the functionality via the possibly jargony extension name, but rather to state the purpose of the extension in the title. This may result in long titles. For example, "Sieve Email Filtering: Extensions for Message Rejection". I think we should use both Nigel's and Kjetil's suggestions: "Sieve Email Filtering: Extensions for Foo" on the front page. "Sieve Extension: Foo" on top of each inner page. Aaron On Mon, 2007-08-13 at 15:27 +0200, Kjetil Torgrim Homme wrote: > On Sun, 2007-08-12 at 11:13 +0100, Alexey Melnikov wrote: > > Nigel Swinson wrote: > > >RFC3894 Sieve Extension: Copying Without Side Effects. J. Degener. > > > October 2004. (Format: TXT=9018 bytes) (Status: PROPOSED STANDARD) > > > I can change the title, but I think that: > > SIEVE Email Filtering Extension: Notifications > > > > is slightly more informative than: > > > > SIEVE Email Filtering: Enotify Extension > > > > (who would know that enotify is about notifications?) > > > > Opinions? > > I don't think it is necessary to use the capability string in the title, > cf. RFC 3894 above, but you need to write it differently so as not to > imply it, e.g. "Sieve Email Filtering: Extension for Notifications" > > as previously stated, I prefer the title stays as "Sieve Extension: > Notifications". > From owner-ietf-mta-filters@mail.imc.org Tue Dec 4 02:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=4.0 tests=AWL,BAYES_50 autolearn=no version=3.2.3 X-mallorn-MailScanner-Watermark: 1197363472.76574@inI4tN8esXUcjXyH2Kya9Q X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 04 Dec 2007 02:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB48vjma000391 for ; Tue, 4 Dec 2007 03:57:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB48fJFK069047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 01:41:19 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB48fJYj069046; Tue, 4 Dec 2007 01:41:19 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mout2.freenet.de (mout2.freenet.de [195.4.92.92]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB48fHjh069038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Dec 2007 01:41:18 -0700 (MST) (envelope-from michael.haardt@freenet.ag) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.68) (envelope-from ) id 1IzTLA-0001Wv-7U for ietf-mta-filters@imc.org; Tue, 04 Dec 2007 09:41:16 +0100 Received: from nostromo.freenet-ag.de ([194.97.7.6]:37442) by 10.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.68 #1) id 1IzTLA-0005ZM-6K for ietf-mta-filters@imc.org; Tue, 04 Dec 2007 09:41:16 +0100 Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.68 #1) id 1IzTL9-0007CW-NB for ietf-mta-filters@imc.org; Tue, 04 Dec 2007 09:41:15 +0100 Date: Tue, 04 Dec 2007 09:41:15 +0100 To: ietf-mta-filters@imc.org Subject: Re: My message about notify looping issues and possible solutions References: <01MOGFRJ1PAW00ISSF@mauve.mrochek.com> In-Reply-To: <01MOGFRJ1PAW00ISSF@mauve.mrochek.com> User-Agent: Heirloom mailx 12.1 6/15/06 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Michael Haardt Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > [Sending a notification to an address that generates a bounce] > (1) Require that when the envelope from on the triggering message is blank > that the message be checked to see if it is a DSN/MDN and if it is look > at the third part to see if it contains an auto-submitted header. I'm afraid that's something for an ideal world. > (2) Use the same trick we required on redirect: When the triggering message > contains an empty envelope from require that any notifications it generates > also have an empty envelope from. > > I mention (1) only because of its cuteness - IMO it isn't going to be reliable > enough, if for no other reason than the widespread existance of DSNs and MDNs > using nonstandard formats. (Thank you qmail...) That leaves (2). I don't like > it much but I don't see any real alternative. Indeed. > > 2). Something I remember from a previous conversation with you: are you > > happy with the requirement on the Notify action to preserve Received > > headers from the original message? > > No I'm not. As currently defined it's quite simply wrong to do this. The > original message is what garnered those trace field values, not the > notification. Someone attempting to trace the message path using this > information could easily end up being very confused. Personally, I would be more confused on not having "Received:" from the triggering message, but that may just be me. > It is also bound to trip > any loop detection logic that has been set to fairly tight tolerances. And > there's also the spam filter issue - one check I've seen made is to compare the > dates on the Received: fields with the Date: field. A Date: field that's in the > future relative to the first Received: field could raise flags and cause > problems. (Mind you, I don't see a reason to cater to broken filter criteria > but that's not sufficient justification for ignoring the issue completely.) I never thought of the date issue, and although I don't use a check like that, "Date:" being in the future looks really ugly to me. > Unfortunately there are no really good ways to solve this problem. I see the > following possibilities: > > (1) Rely on auto-submitted being preserved as a loop check and don't do the > Received: line copy at all. I am less afraid of trouble in the real world, but if that choice is going to cause trouble with approval, it isn't one. > (2) Classify the Auto-submitted: field as a trace field and require that it > appear above the copied Received: fields as a sort of boundary between > the old set of Received: fields and the new. > > (3) Same as (2) except make the trace field some newly defined thing. Depending on the order of different fields relative to each other sounds like asking for real trouble to me. > (4) Same as (2) except use a specially formatted Received: field as the > boundary. I never saw "Received:" being reordered. It's ugly, but anything apart from (1) is, and to me it sounds best among all options. > (5) Make the Received: line copy a SHOULD rather than a MUST. Add some > discussion that the separation between old and new Receieved: fields > can usually be determined by comparing the dates with the those on the Date: > field. > > (6) Add the discussion mentioned in (5) but ignore the problem otherwise. It is bad enough "Date:" is sometimes being "fixed" or accepted although being wrong. Knowing that and trying to assign relevance to it is not an option to me. Notifications are really a new kind of message, an odd mix somewhere between redirected and vacation messages, so all this is not just relevant to Sieve. I consider it important to reach a consensus, no matter how much work it may still take, because anything we screw up now probably can't be fixed later. Thanks a lot for your review! Michael From owner-ietf-mta-filters@mail.imc.org Tue Dec 4 03:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1197366227.07754@V6VtZd/K5+/MXpQdSqgW9Q X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 04 Dec 2007 03:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB49hdZr014891 for ; Tue, 4 Dec 2007 04:43:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB49Zx9N072814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 02:35:59 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB49ZxWY072813; Tue, 4 Dec 2007 02:35:59 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB49Zwbq072807 for ; Tue, 4 Dec 2007 02:35:58 -0700 (MST) (envelope-from arnt@gulbrandsen.priv.no) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 896794AC6D for ; Tue, 4 Dec 2007 10:36:01 +0100 (CET) Message-Id: Date: Tue, 4 Dec 2007 10:35:15 +0100 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: My message about notify looping issues and possible solutions References: <01MOGFRJ1PAW00ISSF@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean FWIW, I tried something else entirely, namely using RFC 4865 to handle looping. Use HOLDFOR=120 if you've sent a notification in the same general direction in the recent past, and mail loops become annoyances rather than disasters. With a round-trip time of 2-4 minutes, it's difficult to pile up more than a three- or four-digit number of messages before the loop is discovered and fixed. A whole weekend is just 1000-2000 messages. Arnt From owner-ietf-mta-filters@mail.imc.org Tue Dec 4 13:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.3 X-mallorn-MailScanner-Watermark: 1197402911.44248@Uqlmn4SE+CM599n9yohftg X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 04 Dec 2007 13:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB4Jt2af017569 for ; Tue, 4 Dec 2007 14:55:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB4JgMLu031172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 12:42:22 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB4JgMrU031171; Tue, 4 Dec 2007 12:42:22 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB4JgHfK031157 for ; Tue, 4 Dec 2007 12:42:20 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [130.129.17.12] (dhcp-110c.ietf70.org [130.129.17.12]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 4 Dec 2007 19:42:15 +0000 Message-ID: <475560FA.3020405@isode.com> Date: Tue, 04 Dec 2007 14:15:22 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Aaron Stone CC: Kjetil Torgrim Homme , Nigel Swinson , ietf-mta-filters Subject: Re: Naming conventions for Sieve RFCs References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> <1196738101.7545.157.camel@localhost> In-Reply-To: <1196738101.7545.157.camel@localhost> MIME-Version: 1.0 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: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Aaron Stone wrote: >Reviving this thread from the last message (not necessarily replying to >this one specifically)... > >I am converting refuse-reject to xml2rfc. I have this: > > > > > Sieve Email Filtering: Reject Extension > > >I like Nigel's suggestion not to imply the functionality via the >possibly jargony extension name, but rather to state the purpose of the >extension in the title. This may result in long titles. > >For example, "Sieve Email Filtering: Extensions for Message Rejection". > >I think we should use both Nigel's and Kjetil's suggestions: >"Sieve Email Filtering: Extensions for Foo" on the front page. >"Sieve Extension: Foo" on top of each inner page. > > Fine with me. I've just updated sieve-notify to use the same convention. From owner-ietf-mta-filters@mail.imc.org Tue Dec 4 15:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1197408451.46358@pfKoc1tCebzRYIdxRzpj6A X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 04 Dec 2007 15:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB4LRPJU010092 for ; Tue, 4 Dec 2007 16:27:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB4L9RJu040523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 14:09:27 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB4L9Rk1040522; Tue, 4 Dec 2007 14:09:27 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB4L9QKU040511 for ; Tue, 4 Dec 2007 14:09:27 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOHRT9H87K00DDMU@mauve.mrochek.com> for ietf-mta-filters@imc.org; Tue, 4 Dec 2007 13:09:24 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOHFMRD7TS00BDC1@mauve.mrochek.com>; Tue, 04 Dec 2007 13:09:20 -0800 (PST) Cc: Aaron Stone , Kjetil Torgrim Homme , Nigel Swinson , ietf-mta-filters Message-id: <01MOHRT8949000BDC1@mauve.mrochek.com> Date: Tue, 04 Dec 2007 13:07:12 -0800 (PST) From: Ned Freed Subject: Re: Naming conventions for Sieve RFCs In-reply-to: "Your message dated Tue, 04 Dec 2007 14:15:22 +0000" <475560FA.3020405@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> <1196738101.7545.157.camel@localhost> <475560FA.3020405@isode.com> To: Alexey Melnikov DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1196802563; h=Date: From:Subject:MIME-version:Content-type; b=c4zp1bLfxKbl2QtC9/fQma8h7 lFM2AMGPVgOaFiL7pxBjtVhMDxP/EgR//OMlC7Fd2DOt30ncE5tfycTMMNysw== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > Aaron Stone wrote: > >Reviving this thread from the last message (not necessarily replying to > >this one specifically)... > > > >I am converting refuse-reject to xml2rfc. I have this: > > > > > > > > > > Sieve Email Filtering: Reject Extension > > > > > >I like Nigel's suggestion not to imply the functionality via the > >possibly jargony extension name, but rather to state the purpose of the > >extension in the title. This may result in long titles. > > > >For example, "Sieve Email Filtering: Extensions for Message Rejection". > > > >I think we should use both Nigel's and Kjetil's suggestions: > >"Sieve Email Filtering: Extensions for Foo" on the front page. > >"Sieve Extension: Foo" on top of each inner page. > > > > > Fine with me. > I've just updated sieve-notify to use the same convention. Vaction currently has: Sieve Email Filtering: Vacation Extension Should I send in an update that changes this to: Sieve Email Filtering: Vacation Extension Ned From owner-ietf-mta-filters@mail.imc.org Tue Dec 4 16:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1197412268.75456@AP9Z9HRASOnGZ7D28FT9rA X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 04 Dec 2007 16:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB4MV2PP022271 for ; Tue, 4 Dec 2007 17:31:08 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB4MIwbS046869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 15:18:58 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB4MIwql046868; Tue, 4 Dec 2007 15:18:58 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB4MIse4046857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Dec 2007 15:18:57 -0700 (MST) (envelope-from guenther+mtafilters@sendmail.com) Received: from dhcp-1792.ietf70.org (dhcp-1792.ietf70.org [130.129.23.146]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.0) with ESMTP id lB4MIoBD014350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 14:18:55 -0800 X-DKIM: Sendmail DKIM Filter v2.2.2 spork.sendmail.com lB4MIoBD014350 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1196806736; bh=6uFwshu/fC+mRtgYiojHoTwpioBj2T2okvlv v4YRno4=; h=Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type:X-MM-Ex-RefId; b=F omA/gf0jH8mTQuiZd6HLXh9oCN+S23k1mZ+kiFqw+R/sRL0qu2SSzq1hNErexF+tVE7 stHu5HDoL4oqVcxn5c0Oj4ry0Lu8nhR7gG4dMmhPFsnsAvBM2luGPPHPaVL0WidTmCi 86CV7BlqI2vfKkBR7ECbQB44ecyEpC/dx8eA= Date: Tue, 4 Dec 2007 14:18:45 -0800 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Ned Freed cc: Alexey Melnikov , ietf-mta-filters Subject: Re: Naming conventions for Sieve RFCs In-Reply-To: <01MOHRT8949000BDC1@mauve.mrochek.com> Message-ID: References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> <1196738101.7545.157.camel@localhost> <475560FA.3020405@isode.com> <01MOHRT8949000BDC1@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MM-Ex-RefId: 149371::071204141855-0AD4CB90-65B298D8/0-0/0-1 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Tue, 4 Dec 2007, Ned Freed wrote: ... > Vaction currently has: > > > Sieve Email Filtering: Vacation Extension > > > Should I send in an update that changes this to: > > > Sieve Email Filtering: Vacation Extension > For the drafts that's already in the RFC editor queue, I suspect this is best done by settling on the format, then Alexey swinging by the RFC editor table and asking them how they would like to get the request. Philip Guenther From owner-ietf-mta-filters@mail.imc.org Tue Dec 4 16:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1197414794.49703@ydIRIw8AwKgiXKWHdsx5tQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 04 Dec 2007 16:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB4ND7II030525 for ; Tue, 4 Dec 2007 18:13:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB4N27Ok050267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 16:02:07 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB4N277c050265; Tue, 4 Dec 2007 16:02:07 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB4N258o050256 for ; Tue, 4 Dec 2007 16:02:06 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [130.129.17.12] (dhcp-110c.ietf70.org [130.129.17.12]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 4 Dec 2007 23:02:04 +0000 Message-ID: <4755DC63.4010106@isode.com> Date: Tue, 04 Dec 2007 23:01:55 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Philip Guenther CC: Ned Freed , ietf-mta-filters Subject: Re: Naming conventions for Sieve RFCs References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> <1196738101.7545.157.camel@localhost> <475560FA.3020405@isode.com> <01MOHRT8949000BDC1@mauve.mrochek.com> In-Reply-To: MIME-Version: 1.0 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: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Philip Guenther wrote: > On Tue, 4 Dec 2007, Ned Freed wrote: > ... > >> Vaction currently has: >> >> >> Sieve Email Filtering: Vacation Extension >> >> >> Should I send in an update that changes this to: >> >> >> Sieve Email Filtering: Vacation Extension >> > > For the drafts that's already in the RFC editor queue, I suspect this > is best done by settling on the format, then Alexey swinging by the > RFC editor table and asking them how they would like to get the request. Agreed. Just pick a format. From owner-ietf-mta-filters@mail.imc.org Tue Dec 4 20:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1197426958.75714@jw/Q51SQFwNvHgBgM5Rl9A X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 04 Dec 2007 20:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB52ZqLC008956 for ; Tue, 4 Dec 2007 21:35:58 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB52Pb8W067231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 19:25:37 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB52Pb3u067230; Tue, 4 Dec 2007 19:25:37 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB52PaUq067223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Dec 2007 19:25:37 -0700 (MST) (envelope-from guenther+mtafilters@sendmail.com) Received: from dhcp-475c.ietf70.org (dhcp-475c.ietf70.org [130.129.71.92]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.0) with ESMTP id lB52PFC2015470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 18:25:37 -0800 X-DKIM: Sendmail DKIM Filter v2.2.2 spork.sendmail.com lB52PFC2015470 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1196821539; bh=psmZFL0HvYGhR/k5w+tkfORhp1JxGZbA+KMJ sVFwuAo=; h=Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type:X-MM-Ex-RefId; b=o Xf3CnFYuvXuuw69L/xrQlQOWev4LXNKMVRKxlKh1WlUnmTMMs9e2+GTcbuHljTfokRF jHeeeJq65GRxEkhGekwXwvRfEq6JWvhex9EqWOacG3v3S8J6JDSDWRH54VNo+HIBhFz v2AeMCBdF5ye9NB8aNUAywqjAyRgxWdlbNKo= Date: Tue, 4 Dec 2007 18:25:09 -0800 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Ned Freed cc: Alexey Melnikov , ietf-mta-filters Subject: Re: Naming conventions for Sieve RFCs In-Reply-To: Message-ID: References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> <1196738101.7545.157.camel@localhost> <475560FA.3020405@isode.com> <01MOHRT8949000BDC1@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MM-Ex-RefId: 149371::071204182538-0AD47B90-26BBF16F/0-0/0-1 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Tue, 4 Dec 2007, Philip Guenther wrote: > For the drafts that's already in the RFC editor queue, I suspect this is best > done by settling on the format, then Alexey swinging by the RFC editor table > and asking them how they would like to get the request. Alexey and I chatted with the RFC editor and they said "yes, please put all title updates in a single request and have your AD bless it". Philip Guenther From owner-ietf-mta-filters@mail.imc.org Wed Dec 5 12:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: * X-Spam-Status: No, score=1.9 required=4.0 tests=AWL,BAYES_50 autolearn=no version=3.2.3 X-mallorn-MailScanner-Watermark: 1197484768.39609@ulEp/InwkZ8UlUp1ta7ylw X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 05 Dec 2007 12:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB5IdJ00007613 for ; Wed, 5 Dec 2007 13:39:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5IU4Ce045645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 11:30:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5IU4qj045644; Wed, 5 Dec 2007 11:30:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5IU3lX045638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Dec 2007 11:30:04 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C7684175DE; Wed, 5 Dec 2007 18:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Izz0U-0003oW-8B; Wed, 05 Dec 2007 13:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-mta-filters@imc.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 05 Dec 2007 13:30:02 -0500 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be infected Subject: {Blocked Content} I-D Action:draft-ietf-sieve-notify-xmpp-07.txt --NextPart Warning: This message has had one or more attachments removed Warning: (not named). Warning: Please read the "mallorn-Attachment-Warning.txt" attachment(s) for more information. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF. Title : Sieve Notification Mechanism: xmpp Author(s) : P. Saint-Andre, A. Melnikov Filename : draft-ietf-sieve-notify-xmpp-07.txt Pages : 14 Date : 2007-12-05 This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-xmpp-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-sieve-notify-xmpp-07.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-ietf-sieve-notify-xmpp-07.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. --NextPart Content-type: multipart/mixed; boundary="OtherAccess" --OtherAccess Content-Type: text/plain; charset="us-ascii"; name="mallorn-Attachment-Warning.txt" Content-Disposition: inline; filename="mallorn-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Wed Dec 5 13:39:28 2007 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the mallorn MailScanner in /var/spool/quarantine= /20071205 (message lB5IdJ00007613). --=20 Postmaster Mallorn Computing, Inc. http://www.mallorn.com/ For all your IT requirements visit: http://www.transtec.co.uk --OtherAccess Content-Type: text/plain; charset="us-ascii"; name="mallorn-Attachment-Warning.txt" Content-Disposition: inline; filename="mallorn-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Wed Dec 5 13:39:28 2007 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the mallorn MailScanner in /var/spool/quarantine= /20071205 (message lB5IdJ00007613). --=20 Postmaster Mallorn Computing, Inc. http://www.mallorn.com/ For all your IT requirements visit: http://www.transtec.co.uk --OtherAccess-- --NextPart-- From owner-ietf-mta-filters@mail.imc.org Thu Dec 6 20:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: * X-Spam-Status: No, score=1.9 required=4.0 tests=AWL,BAYES_50 autolearn=no version=3.2.3 X-mallorn-MailScanner-Watermark: 1197602583.78891@fL5nzzr7cjj+2cM7hQ5TkQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Thu, 06 Dec 2007 20:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lB73Mwms031411 for ; Thu, 6 Dec 2007 22:23:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB73A4iM009197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2007 20:10:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB73A4VF009196; Thu, 6 Dec 2007 20:10:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB73A3Yi009189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Dec 2007 20:10:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A5C46175E7; Fri, 7 Dec 2007 03:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J0TbG-0003Qq-4d; Thu, 06 Dec 2007 22:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-mta-filters@imc.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Dec 2007 22:10:02 -0500 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be infected Subject: {Blocked Content} I-D Action:draft-ietf-sieve-notify-11.txt --NextPart Warning: This message has had one or more attachments removed Warning: (not named). Warning: Please read the "mallorn-Attachment-Warning.txt" attachment(s) for more information. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF. Title : SIEVE Email Filtering: Extension for Notifications Author(s) : A. Melnikov, et al. Filename : draft-ietf-sieve-notify-11.txt Pages : 21 Date : 2007-12-06 Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method but it is expected that using existing instant messaging infrastructure such as XMPP, or SMS messages will be popular. This draft describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-sieve-notify-11.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-ietf-sieve-notify-11.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. --NextPart Content-type: multipart/mixed; boundary="OtherAccess" --OtherAccess Content-Type: text/plain; charset="us-ascii"; name="mallorn-Attachment-Warning.txt" Content-Disposition: inline; filename="mallorn-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Thu Dec 6 22:23:03 2007 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the mallorn MailScanner in /var/spool/quarantine= /20071206 (message lB73Mwms031411). --=20 Postmaster Mallorn Computing, Inc. http://www.mallorn.com/ For all your IT requirements visit: http://www.transtec.co.uk --OtherAccess Content-Type: text/plain; charset="us-ascii"; name="mallorn-Attachment-Warning.txt" Content-Disposition: inline; filename="mallorn-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Thu Dec 6 22:23:03 2007 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the mallorn MailScanner in /var/spool/quarantine= /20071206 (message lB73Mwms031411). --=20 Postmaster Mallorn Computing, Inc. http://www.mallorn.com/ For all your IT requirements visit: http://www.transtec.co.uk --OtherAccess-- --NextPart-- From owner-ietf-mta-filters@mail.imc.org Tue Dec 11 12:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198004994.40868@gMdMVq8x2dsDueirLbUXmQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Tue, 11 Dec 2007 12:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBBJ9lfU024451 for ; Tue, 11 Dec 2007 14:09:53 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBBIsgGX041496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Dec 2007 11:54:42 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBBIsgZc041495; Tue, 11 Dec 2007 11:54:42 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBBIsf2k041488 for ; Tue, 11 Dec 2007 11:54:42 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 11 Dec 2007 18:54:40 +0000 Message-ID: <475EDCE8.7020602@isode.com> Date: Tue, 11 Dec 2007 18:54:32 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Philip Guenther CC: Ned Freed , ietf-mta-filters Subject: Re: Naming conventions for Sieve RFCs References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> <1196738101.7545.157.camel@localhost> <475560FA.3020405@isode.com> <01MOHRT8949000BDC1@mauve.mrochek.com> In-Reply-To: MIME-Version: 1.0 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: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Philip Guenther wrote: > On Tue, 4 Dec 2007, Philip Guenther wrote: > >> For the drafts that's already in the RFC editor queue, I suspect this >> is best done by settling on the format, then Alexey swinging by the >> RFC editor table and asking them how they would like to get the request. > > Alexey and I chatted with the RFC editor and they said "yes, please > put all title updates in a single request and have your AD bless it". Have we settled on the format? I just received a message from RFC editors saying that documents will go to AUTH48 shortly... From owner-ietf-mta-filters@mail.imc.org Wed Dec 12 03:27:01 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=4.0 tests=BAYES_20 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198058502.63241@USteUcv+3q4YLX2JsevMew X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 12 Dec 2007 03:27:01 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBCA1a0B018782 for ; Wed, 12 Dec 2007 05:01:41 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBC9o8Pa004492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2007 02:50:08 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBC9o8rV004491; Wed, 12 Dec 2007 02:50:08 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from cypress.ugent.be (cypress.ugent.be [157.193.71.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBC9o6wR004484 for ; Wed, 12 Dec 2007 02:50:07 -0700 (MST) (envelope-from Rudy.Gevaert@UGent.be) Received: from bonobo.ugent.be (HELO localhost) ([157.193.71.53]) by cypress.ugent.be with ESMTP; 12 Dec 2007 10:50:06 +0100 Received: from cypress.ugent.be ([157.193.71.48]) by localhost (bonobo.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 30436-10-2 for ; Wed, 12 Dec 2007 10:50:05 +0100 (CET) Received: from pimp.ugent.be (HELO [157.193.44.68]) ([157.193.44.68]) by cypress.ugent.be with ESMTP/TLS/AES256-SHA; 12 Dec 2007 10:50:05 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJQ9X0edwSxE/2dsb2JhbAA Message-ID: <475FADF9.3070306@UGent.be> Date: Wed, 12 Dec 2007 10:46:33 +0100 From: Rudy Gevaert Organization: Universiteit Gent User-Agent: Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: MTA Filters Subject: error reporting with run time errors Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by UGent DICT Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Hello, I have subscribed to this list to report a (possible) problem with error reporting. Please accept my apologies if this is not the correct place to report it or if I'm not following the list policy. RFC3028 and the latest draft of RFC3028bis state in section 2.10.6. 2.10.6. Errors ... When an error happens, implementations MUST notify the user that an error occurred, which actions (if any) were taken, and do an implicit keep. We are using Cyrus Imapd and their sieve implementation. I found out of the following problem last week. Our incoming mail relays accept email with a size limit of 12MB. We have users that have sieve redirect scripts on the backend mail stores. As you know to forward the email a sendmail forward is used (as stated in the RFC, but this is left out in the latest draft). Because of an unfortunate oversight the postfix that runs on the mail stores (and thus it is postfix providing the sendmail binary) did have its message size limit set to 10MB. Forwarding messages greater than 10MB didn't work. In my logs I saw that like this: Nov 22 17:29:40 manaslu postfix/postdrop[23167]: warning: uid=980: File too large Nov 22 17:29:40 manaslu postfix/sendmail[23166]: fatal: (...@...)(980): Message file too big Nov 22 17:29:41 manaslu mail6/lmtp[9186]: sieve runtime error for jeanmarie^noterdaeme@ugent.be id <4745AC91.30707@ugent.be>: Redirect: Sendmail process terminated normally, exit status 69 I understand that the RFC says the user needs to be notified, but this doesn't happen. I agree that the issue is implementation specific, but I want to raise the following questions. a) Who is the user? b) How must the user be notified? For (a) you would be assume it is the user who set the sieve script. But actually it should be (in this case) the sender that at least gets a message that the email could not be forwarded (it delivered, but not to the final destination). (b) I would say by email, but depending who the user is, there could be problems. E.g. if he is forwarding all incoming email to an other address, it depends if he will be notified (mail could be lost). If the forwarding mechanism is broken the mailadmin should be notified. Maybe the RFCbis could be clearer on some points? Thank you in advance, Rudy -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert Rudy.Gevaert@UGent.be tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur ICT Department, Infrastructure office Groep Systemen Systems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- From owner-ietf-mta-filters@mail.imc.org Wed Dec 12 05:27:01 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198067123.02649@Z/L71gTtDnk+R4paeQoAuA X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 12 Dec 2007 05:27:01 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBCCPDcj002693 for ; Wed, 12 Dec 2007 07:25:18 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCCBHdf014495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2007 05:11:17 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBCCBHI4014494; Wed, 12 Dec 2007 05:11:17 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (SMTP.andrew.cmu.edu [128.2.10.212]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCCBFsY014487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Dec 2007 05:11:16 -0700 (MST) (envelope-from murch@andrew.cmu.edu) Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id lBCCB9Yb001910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Dec 2007 07:11:14 -0500 Message-ID: <475FCFCD.2050702@andrew.cmu.edu> Date: Wed, 12 Dec 2007 07:10:53 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Alexey Melnikov CC: Philip Guenther , Ned Freed , ietf-mta-filters Subject: Re: Naming conventions for Sieve RFCs References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> <1196738101.7545.157.camel@localhost> <475560FA.3020405@isode.com> <01MOHRT8949000BDC1@mauve.mrochek.com> <475EDCE8.7020602@isode.com> In-Reply-To: <475EDCE8.7020602@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.212 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Alexey Melnikov wrote: > > Philip Guenther wrote: > >> On Tue, 4 Dec 2007, Philip Guenther wrote: >> >>> For the drafts that's already in the RFC editor queue, I suspect this >>> is best done by settling on the format, then Alexey swinging by the >>> RFC editor table and asking them how they would like to get the request. >> >> Alexey and I chatted with the RFC editor and they said "yes, please >> put all title updates in a single request and have your AD bless it". > > Have we settled on the format? > I just received a message from RFC editors saying that documents will go > to AUTH48 shortly... Indeed. If/when we decide on a format, am I supposed to send in the title change(s) myself, or will the chairs do so? I'm putting together some other changes as we speak. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From owner-ietf-mta-filters@mail.imc.org Wed Dec 12 06:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198068211.22058@/GHyGQMSnsPH5TRfqNUIvQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 12 Dec 2007 06:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBCChN9b004530 for ; Wed, 12 Dec 2007 07:43:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCCVQGs016110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2007 05:31:26 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBCCVQje016109; Wed, 12 Dec 2007 05:31:26 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCCVN3U016101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Dec 2007 05:31:25 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1J2QkF-0008EE-DB; Wed, 12 Dec 2007 13:31:23 +0100 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx3.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1J2QkE-0007R2-KN; Wed, 12 Dec 2007 13:31:22 +0100 Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.2.10]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J2QkE-0007QR-Eg; Wed, 12 Dec 2007 13:31:22 +0100 Subject: Re: error reporting with run time errors From: Kjetil Torgrim Homme To: Rudy Gevaert Cc: MTA Filters In-Reply-To: <475FADF9.3070306@UGent.be> References: <475FADF9.3070306@UGent.be> Content-Type: text/plain Date: Wed, 12 Dec 2007 13:31:32 +0100 Message-Id: <1197462692.25524.30.camel@oslhomkje> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, AWL=0.048) X-UiO-Scanned: EFC19A85A02F01DCD807C36FE66B7D9ED08A421E X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 890 total 5704950 max/h 8345 blacklist 0 greylist 0 ratelimit 0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Wed, 2007-12-12 at 10:46 +0100, Rudy Gevaert wrote: > RFC3028 and the latest draft of RFC3028bis state in section 2.10.6. > > 2.10.6. Errors > > ... > > When an error happens, implementations MUST notify the user that an > error occurred, which actions (if any) were taken, and do an implicit > keep. > > > We are using Cyrus Imapd and their sieve implementation. I found out of > the following problem last week. Our incoming mail relays accept email > with a size limit of 12MB. We have users that have sieve redirect > scripts on the backend mail stores. As you know to forward the email a > sendmail forward is used (as stated in the RFC, but this is left out in > the latest draft). Because of an unfortunate oversight the postfix that > runs on the mail stores (and thus it is postfix providing the sendmail > binary) did have its message size limit set to 10MB. Forwarding > messages greater than 10MB didn't work. [...] > > I understand that the RFC says the user needs to be notified, but this > doesn't happen. I'm not sure that the redirect action failed in this case. it successfully passed the message on to Sendmail. in general, you can't guarantee that the next hop will be successful. > I agree that the issue is implementation specific, but > I want to raise the following questions. > > a) Who is the user? > b) How must the user be notified? > > For (a) you would be assume it is the user who set the sieve script. yes. > But actually it should be (in this case) the sender that at least gets a > message that the email could not be forwarded (it delivered, but not to > the final destination). why? there's nothing wrong with notifying the sender as well (but please limit backscatter!), but it's the recipient (script owner) who needs to be notified that his filter failed so that he can fix it. I think it is too onerous to require the "redirect" delivery to be successful. if a "redirect" delivery failure causes the script to fail, the Sieve implementation can not rely on MDN to do the reporting, it has to keep track of delivery success or failure itself. this is a bit awkward, since it has to maintain its own queue, you can't just hand it off to your MTA via "Sendmail-API", since there is no back-channel to the submitter. what's worse -- the script can't terminate until the delivery is done, which can take days! what would happen to commands after the "redirect" in the script? should they be postponed? obviously not. the Cyrus implementation does not perform actions as it runs through the script, it collects a list of actions which should be taken, and performs these *after* the script has finished. I think this is a perfectly reasonable approach. BTW, in Cyrus (at least 2.2.x), a redirect is implemented as a message submitted with the cyrus system user as the envelope sender, so failed redirects go to the mail admin. this is not a Sendmail forward, since that keeps the envelope sender from the original message. it would probably be good to make Cyrus compliant here. > (b) I would say by email, but depending who the user is, there could be > problems. E.g. if he is forwarding all incoming email to an other > address, it depends if he will be notified (mail could be lost). If the > forwarding mechanism is broken the mailadmin should be notified. the implementation MUST be able to do a "keep". if it can't do that, it should not have accepted the message in the first place. > Maybe the RFCbis could be clearer on some points? publication of 3028bis as RFC 5228 is imminent, so it will almost certainly have to wait until 3028ter. some text to clarify success or failure of "redirect" might be a good idea. -- best wishes, Kjetil T. From owner-ietf-mta-filters@mail.imc.org Wed Dec 12 08:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198074439.00268@QunevhNJ+DMAI2w2VSggfA X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 12 Dec 2007 08:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBCERCi5010973 for ; Wed, 12 Dec 2007 09:27:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCEFUOP026422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2007 07:15:30 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBCEFUPi026421; Wed, 12 Dec 2007 07:15:30 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from cedar.ugent.be (cedar.ugent.be [157.193.49.14]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCEFSCg026410 for ; Wed, 12 Dec 2007 07:15:29 -0700 (MST) (envelope-from Rudy.Gevaert@UGent.be) Received: from bonobo.ugent.be (HELO localhost) ([157.193.71.53]) by cedar.ugent.be with ESMTP; 12 Dec 2007 15:15:28 +0100 Received: from cedar.ugent.be ([157.193.49.14]) by localhost (bonobo.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 27019-01-6 for ; Wed, 12 Dec 2007 15:15:28 +0100 (CET) Received: from pimp.ugent.be (HELO [157.193.44.68]) ([157.193.44.68]) by cedar.ugent.be with ESMTP/TLS/AES256-SHA; 12 Dec 2007 15:15:28 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACh8X0edwSxE/2dsb2JhbACRPw Message-ID: <475FEC28.6060908@UGent.be> Date: Wed, 12 Dec 2007 15:11:52 +0100 From: Rudy Gevaert Organization: Universiteit Gent User-Agent: Thunderbird 2.0.0.6 (X11/20071008) MIME-Version: 1.0 To: MTA Filters Subject: Re: error reporting with run time errors References: <475FADF9.3070306@UGent.be> <1197462692.25524.30.camel@oslhomkje> In-Reply-To: <1197462692.25524.30.camel@oslhomkje> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by UGent DICT Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Kjetil Torgrim Homme wrote: > I'm not sure that the redirect action failed in this case. it > successfully passed the message on to Sendmail. in general, you can't > guarantee that the next hop will be successful. I think it depends on what you see as 'failed' or 'succeeded'. :) Nov 22 17:29:41 manaslu mail6/lmtp[9186]: sieve runtime error for jeanmarie^noterdaeme@ugent.be id <4745AC91.30707@ugent.be>: Redirect: Sendmail process terminated normally, exit status 69 In this case it was given successfully to sendmail, but sendmail didn't forward it, it even exited with status 69. But that seems to be ok for the cyrus implementation. >> I want to raise the following questions. >> >> a) Who is the user? >> b) How must the user be notified? >> >> For (a) you would be assume it is the user who set the sieve script. > > yes. > >> But actually it should be (in this case) the sender that at least gets a >> message that the email could not be forwarded (it delivered, but not to >> the final destination). > > why? there's nothing wrong with notifying the sender as well (but > please limit backscatter!), but it's the recipient (script owner) who > needs to be notified that his filter failed so that he can fix it. Now that I gave it an other thought I think the user who set the forward should be notified. The notification should be put in his inbox. I'm saying this because: - you can't rely on the redirect action to actually work, so if the forward doesn't work the notification will be put in his inbox - the redirect action could be set up for a specific action The only problem that remains is that the user still has login to his mailbox to see the notification if the redirect action doesn't work (in that case). > I think it is too onerous to require the "redirect" delivery to be > successful. > if a "redirect" delivery failure causes the script to fail, the Sieve > implementation can not rely on MDN to do the reporting, it has to keep > track of delivery success or failure itself. this is a bit awkward, > since it has to maintain its own queue, you can't just hand it off to > your MTA via "Sendmail-API", since there is no back-channel to the > submitter. what's worse -- the script can't terminate until the > delivery is done, which can take days! what would happen to commands > after the "redirect" in the script? should they be postponed? > obviously not. Sorry, I don't understand what you are trying to say. > the Cyrus implementation does not perform actions as it runs through the > script, it collects a list of actions which should be taken, and > performs these *after* the script has finished. I think this is a > perfectly reasonable approach. I can't comment on this, I would have to look at the source. > BTW, in Cyrus (at least 2.2.x), a redirect is implemented as a message > submitted with the cyrus system user as the envelope sender, so failed > redirects go to the mail admin. this is not a Sendmail forward, since > that keeps the envelope sender from the original message. it would > probably be good to make Cyrus compliant here. This is already the case in 2.3.10 >> Maybe the RFCbis could be clearer on some points? > > publication of 3028bis as RFC 5228 is imminent, so it will almost > certainly have to wait until 3028ter. > > some text to clarify success or failure of "redirect" might be a good > idea. I would think so too. Rudy -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert Rudy.Gevaert@UGent.be tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur ICT Department, Infrastructure office Groep Systemen Systems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- From owner-ietf-mta-filters@mail.imc.org Wed Dec 12 12:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198089187.02196@RfmWsgqSBBDXnintl9PTVw X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 12 Dec 2007 12:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBCIWxWM010891 for ; Wed, 12 Dec 2007 13:33:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCILt0t049723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2007 11:21:56 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBCILtDM049722; Wed, 12 Dec 2007 11:21:55 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCILsgb049715 for ; Wed, 12 Dec 2007 11:21:55 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 12 Dec 2007 18:21:53 +0000 Message-ID: <476026C0.7080409@isode.com> Date: Wed, 12 Dec 2007 18:21:52 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ietf-mta-filters Subject: Re: Naming conventions for Sieve RFCs References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> <1196738101.7545.157.camel@localhost> <475560FA.3020405@isode.com> <01MOHRT8949000BDC1@mauve.mrochek.com> <475EDCE8.7020602@isode.com> <475FCFCD.2050702@andrew.cmu.edu> In-Reply-To: <475FCFCD.2050702@andrew.cmu.edu> MIME-Version: 1.0 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: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Ken Murchison wrote: > Alexey Melnikov wrote: > >> Philip Guenther wrote: >> >>> On Tue, 4 Dec 2007, Philip Guenther wrote: >>> >>>> For the drafts that's already in the RFC editor queue, I suspect >>>> this is best done by settling on the format, then Alexey swinging >>>> by the RFC editor table and asking them how they would like to get >>>> the request. >>> >>> Alexey and I chatted with the RFC editor and they said "yes, please >>> put all title updates in a single request and have your AD bless it". >> >> Have we settled on the format? >> I just received a message from RFC editors saying that documents will >> go to AUTH48 shortly... > > Indeed. If/when we decide on a format, am I supposed to send in the > title change(s) myself, or will the chairs do so? I'm putting > together some other changes as we speak. As nobody seems to be able to make a decision on this, chairs decided that all RFCs should use the following title: Sieve Email Filtering: Extension I will send RFC editor messages for each affected RFC-to-be. From owner-ietf-mta-filters@mail.imc.org Wed Dec 12 13:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198092685.88597@eUVvM5y2jY2sdVMnRqFEMg X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 12 Dec 2007 13:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBCJVJ9m018411 for ; Wed, 12 Dec 2007 14:31:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCJGgWD053835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2007 12:16:42 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBCJGg5S053834; Wed, 12 Dec 2007 12:16:42 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCJGdbM053825 for ; Wed, 12 Dec 2007 12:16:41 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from serendipity.palo-alto.ca.us (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with SMTP id 3B7893D2D; Wed, 12 Dec 2007 11:18:30 -0800 (PST) Date: Wed, 12 Dec 2007 19:18:30 -0000 To: "Alexey Melnikov" , "ietf-mta-filters" Subject: Re: Naming conventions for Sieve RFCs From: "Aaron Stone" X-Mailer: TWIG 2.8.3 Message-ID: In-Reply-To: <476026C0.7080409@isode.com> References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> <1187011668.15776.6.camel@oslhomkje> <1196738101.7545.157.camel@localhost> <475560FA.3020405@isode.com> <01MOHRT8949000BDC1@mauve.mrochek.com> <475EDCE8.7020602@isode.com> <475FCFCD.2050702@andrew.cmu.edu>, <475FCFCD.2050702@andrew.cmu.edu> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Wed, Dec 12, 2007, Alexey Melnikov said: > > Ken Murchison wrote: > >> Alexey Melnikov wrote: >> >>> Philip Guenther wrote: >>> >>>> On Tue, 4 Dec 2007, Philip Guenther wrote: >>>> >>>>> For the drafts that's already in the RFC editor queue, I suspect >>>>> this is best done by settling on the format, then Alexey swinging >>>>> by the RFC editor table and asking them how they would like to get >>>>> the request. >>>> >>>> Alexey and I chatted with the RFC editor and they said "yes, please >>>> put all title updates in a single request and have your AD bless it". >>> >>> Have we settled on the format? >>> I just received a message from RFC editors saying that documents will >>> go to AUTH48 shortly... >> >> Indeed. If/when we decide on a format, am I supposed to send in the >> title change(s) myself, or will the chairs do so? I'm putting >> together some other changes as we speak. > > As nobody seems to be able to make a decision on this, chairs decided > that all RFCs should use the following title: > > Sieve Email Filtering: Extension > > I will send RFC editor messages for each affected RFC-to-be. > Ok, so long as we've got all our ducks in a row :-) Aaron From owner-ietf-mta-filters@mail.imc.org Wed Dec 12 16:27:02 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198103767.2356@IgYqA2PGfnNdNA5LVgxo/A X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Wed, 12 Dec 2007 16:27:02 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBCMZwnT006303 for ; Wed, 12 Dec 2007 17:36:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCMN9IT070916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2007 15:23:09 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBCMN9KV070915; Wed, 12 Dec 2007 15:23:09 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBCMN8o3070907 for ; Wed, 12 Dec 2007 15:23:08 -0700 (MST) (envelope-from ned.freed@mrochek.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOT0QEXJTC00JG9Z@mauve.mrochek.com> for ietf-mta-filters@imc.org; Wed, 12 Dec 2007 14:23:06 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MOSTWOKPVK00BDC1@mauve.mrochek.com>; Wed, 12 Dec 2007 14:23:04 -0800 (PST) Cc: MTA Filters Message-id: <01MOT0QE8VNM00BDC1@mauve.mrochek.com> Date: Wed, 12 Dec 2007 13:44:38 -0800 (PST) From: Ned Freed Subject: Re: error reporting with run time errors In-reply-to: "Your message dated Wed, 12 Dec 2007 10:46:33 +0100" <475FADF9.3070306@UGent.be> References: <475FADF9.3070306@UGent.be> To: Rudy Gevaert DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1197498186; h=Date: From:Subject:MIME-version:Content-type; b=tzrivcxmA0leXcKvtpI9hosO9 UqtGxlCeO6pY5xO/Flr7V4hgaQQkUN/pIVuPxlG1fLNYIJ1u7YxIVQvWhDKvQ== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > Hello, > I have subscribed to this list to report a (possible) problem with error > reporting. Please accept my apologies if this is not the correct place > to report it or if I'm not following the list policy. > RFC3028 and the latest draft of RFC3028bis state in section 2.10.6. > 2.10.6. Errors > ... > When an error happens, implementations MUST notify the user that an > error occurred, which actions (if any) were taken, and do an implicit > keep. > We are using Cyrus Imapd and their sieve implementation. I found out of > the following problem last week. Our incoming mail relays accept email > with a size limit of 12MB. We have users that have sieve redirect > scripts on the backend mail stores. As you know to forward the email a > sendmail forward is used (as stated in the RFC, but this is left out in > the latest draft). Because of an unfortunate oversight the postfix that > runs on the mail stores (and thus it is postfix providing the sendmail > binary) did have its message size limit set to 10MB. Forwarding > messages greater than 10MB didn't work. > In my logs I saw that like this: > Nov 22 17:29:40 manaslu postfix/postdrop[23167]: warning: uid=980: File > too large > Nov 22 17:29:40 manaslu postfix/sendmail[23166]: fatal: (...@...)(980): > Message file too big > Nov 22 17:29:41 manaslu mail6/lmtp[9186]: sieve runtime error for > jeanmarie^noterdaeme@ugent.be id <4745AC91.30707@ugent.be>: Redirect: > Sendmail process terminated normally, exit status 69 I don't know the underlying architecture here, but it isn't obvious to me that this is a redirect error. Redirect reinjects a message into the transport infrastructure. That message can bounce at some subsequent point even though the redirect itself was succesful. FWIW, the way we handle redirect in our implementation is to put a copy of the message with new recipients in what amounts to a submission queue. The submission may fail at a later point but that doesn't prevent the redirect from completing succesfully in almost all cases. > I understand that the RFC says the user needs to be notified, but this > doesn't happen. I agree that the issue is implementation specific, but > I want to raise the following questions. > a) Who is the user? The owner of the sieve. > b) How must the user be notified? That's implementation-specific. Again FWIW, we do this by sending a special notification message to the sieve owner. > For (a) you would be assume it is the user who set the sieve script. Yes, but note that admins can and do set up sieves for users but in such a case it isn't clear they're the ones who should receive error notifications. > But actually it should be (in this case) the sender that at least gets a > message that the email could not be forwarded (it delivered, but not to > the final destination). Maybe, maybe not. It's a question of intent. If the redirect is to, say, a remote archive and the main copy of the message was delivered normally, notifying the sender about a copy they don't know and don't care about, may end up causing more problems than it solves. > (b) I would say by email, but depending who the user is, there could be > problems. E.g. if he is forwarding all incoming email to an other > address, it depends if he will be notified (mail could be lost). Remember that in the event of an error the sieve result is ignored and a keep is performed. This mitigates at least some of the issues of using email to make the report. > If the > forwarding mechanism is broken the mailadmin should be notified. It really depends on how it's problem. > Maybe the RFCbis could be clearer on some points? A bit late for that now that 3028bis is about to come out as an RFC. Ned From owner-ietf-mta-filters@mail.imc.org Thu Dec 13 09:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198165182.3518@KpZZ7H+BiywlhxrkVvM9ZA X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Thu, 13 Dec 2007 09:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBDFda9f011357 for ; Thu, 13 Dec 2007 10:39:41 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBDFMk8o047504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 08:22:46 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBDFMkmd047503; Thu, 13 Dec 2007 08:22:46 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBDFMhaj047491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Dec 2007 08:22:45 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1J2ptb-0007U2-3H; Thu, 13 Dec 2007 16:22:43 +0100 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx5.uio.no) by mail-mx5.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1J2pta-00081j-In; Thu, 13 Dec 2007 16:22:42 +0100 Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.2.10]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J2ptZ-00081W-Ra; Thu, 13 Dec 2007 16:22:42 +0100 Subject: Re: error reporting with run time errors From: Kjetil Torgrim Homme Reply-To: MTA Filters To: Rudy Gevaert Cc: MTA Filters In-Reply-To: <475FEC28.6060908@UGent.be> References: <475FADF9.3070306@UGent.be> <1197462692.25524.30.camel@oslhomkje> <475FEC28.6060908@UGent.be> Content-Type: text/plain Date: Thu, 13 Dec 2007 16:23:00 +0100 Message-Id: <1197559380.25524.91.camel@oslhomkje> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, AWL=0.047) X-UiO-Scanned: 4A56C313CF0B260C67EB74EF080A18A22BF282F0 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 520 total 5730675 max/h 8345 blacklist 0 greylist 0 ratelimit 0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Wed, 2007-12-12 at 15:11 +0100, Rudy Gevaert wrote: > Kjetil Torgrim Homme wrote: > > > I'm not sure that the redirect action failed in this case. it > > successfully passed the message on to Sendmail. in general, you can't > > guarantee that the next hop will be successful. > > I think it depends on what you see as 'failed' or 'succeeded'. :) > > Nov 22 17:29:41 manaslu mail6/lmtp[9186]: sieve runtime error for > jeanmarie^noterdaeme@ugent.be id <4745AC91.30707@ugent.be>: Redirect: > Sendmail process terminated normally, exit status 69 > > In this case it was given successfully to sendmail, but sendmail didn't > forward it, it even exited with status 69. But that seems to be ok for > the cyrus implementation. this is a quality of implementation issue, IMHO. as long as only *some* types of errors can be discovered, and the types depend on implementation strategy, I don't think it is appropriate for the Sieve spec to make a list. > The only problem that remains is that the user still has login to his > mailbox to see the notification if the redirect action doesn't work (in > that case). yes, this is unfortunate. a Sieve implementation is allowed to use other notification methods if they're available, though. (e.g. the user allows XMPP) > > I think it is too onerous to require the "redirect" delivery to be > > successful. > > > if a "redirect" delivery failure causes the script to fail, the Sieve > > implementation can not rely on MDN to do the reporting, it has to keep > > track of delivery success or failure itself. this is a bit awkward, > > since it has to maintain its own queue, you can't just hand it off to > > your MTA via "Sendmail-API", since there is no back-channel to the > > submitter. what's worse -- the script can't terminate until the > > delivery is done, which can take days! what would happen to commands > > after the "redirect" in the script? should they be postponed? > > obviously not. > > Sorry, I don't understand what you are trying to say. not sure if I'm able to state it more clearly, but I'll try. current status is (as I understand the spec) that a redirect action succeeds as long as it is syntactically correct. the Sieve implementation isn't even required to check the supplied address for syntax validity. if you want the success of the redirect action to depend on the success of the actual forwarding of the e-mail, you need a tight integration of the sending action in your Sieve implementation. the server you're redirecting to may be down, and then Sieve will have to queue the message, and postpone the remainder of the Sieve script until the redirect action returns with a definite answer. this is not workable, IMHO. -- regards, Kjetil T. From owner-ietf-mta-filters@mail.imc.org Thu Dec 13 09:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-3.0 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198166121.82493@eVePVR40+oRHLBx9ch1GBg X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Thu, 13 Dec 2007 09:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBDFtFGC013451 for ; Thu, 13 Dec 2007 10:55:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBDFjaNJ049379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 08:45:36 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBDFjaHF049378; Thu, 13 Dec 2007 08:45:36 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBDFjZZr049370 for ; Thu, 13 Dec 2007 08:45:36 -0700 (MST) (envelope-from arnt@gulbrandsen.priv.no) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id A58BF4AC48 for ; Thu, 13 Dec 2007 16:45:34 +0100 (CET) Message-Id: <6oxy8zf6M7DMWWZC4RKY1w.md5@libertango.oryx.com> Date: Thu, 13 Dec 2007 16:44:22 +0100 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: error reporting with run time errors References: <475FADF9.3070306@UGent.be> <1197462692.25524.30.camel@oslhomkje> <475FEC28.6060908@UGent.be> <1197559380.25524.91.camel@oslhomkje> In-Reply-To: <1197559380.25524.91.camel@oslhomkje> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Kjetil Torgrim Homme writes: > as long as only *some* types of errors can be discovered, and the > types depend on implementation strategy, I don't think it is > appropriate for the Sieve spec to make a list. I agree. That said, if the actual redirection has no possiblity of succeeding I don't think the redirect command should succeed. The details aren't IMO specifiable, but that simple statement is a useful rule. Not that it matters at this time - 3028bis has come too far and 3028ter is far away. Arnt From owner-ietf-mta-filters@mail.imc.org Fri Dec 14 07:27:05 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=4.0 tests=AWL,BAYES_40 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198247022.17807@c/zPRt0mJ7qXXv93DcPYfQ X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Fri, 14 Dec 2007 07:27:05 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBEENXFp010825 for ; Fri, 14 Dec 2007 09:23:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBEEA3uD058784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2007 07:10:03 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBEEA31j058783; Fri, 14 Dec 2007 07:10:03 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBEEA2Ue058776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 14 Dec 2007 07:10:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E058B26E65; Fri, 14 Dec 2007 14:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J3BEn-0004Qz-Qd; Fri, 14 Dec 2007 09:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-mta-filters@imc.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 14 Dec 2007 09:10:01 -0500 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be infected Subject: {Blocked Content} I-D Action:draft-ietf-sieve-refuse-reject-06.txt --NextPart Warning: This message has had one or more attachments removed Warning: (not named). Warning: Please read the "mallorn-Attachment-Warning.txt" attachment(s) for more information. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF. Title : Sieve Email Filtering: Extensions for Rejecting Messages Author(s) : A. Stone, et al. Filename : draft-ietf-sieve-refuse-reject-06.txt Pages : 13 Date : 2007-12-14 This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028. A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction. The "ereject" action is intended to replace the "reject" action wherever possible. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-sieve-refuse-reject-06.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-ietf-sieve-refuse-reject-06.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. --NextPart Content-type: multipart/mixed; boundary="OtherAccess" --OtherAccess Content-Type: text/plain; charset="us-ascii"; name="mallorn-Attachment-Warning.txt" Content-Disposition: inline; filename="mallorn-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Fri Dec 14 09:23:42 2007 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the mallorn MailScanner in /var/spool/quarantine= /20071214 (message lBEENXFp010825). --=20 Postmaster Mallorn Computing, Inc. http://www.mallorn.com/ For all your IT requirements visit: http://www.transtec.co.uk --OtherAccess Content-Type: text/plain; charset="us-ascii"; name="mallorn-Attachment-Warning.txt" Content-Disposition: inline; filename="mallorn-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Fri Dec 14 09:23:42 2007 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the mallorn MailScanner in /var/spool/quarantine= /20071214 (message lBEENXFp010825). --=20 Postmaster Mallorn Computing, Inc. http://www.mallorn.com/ For all your IT requirements visit: http://www.transtec.co.uk --OtherAccess-- --NextPart-- From owner-ietf-mta-filters@mail.imc.org Fri Dec 14 13:27:03 2007 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on lorien2.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 X-mallorn-MailScanner-Watermark: 1198265581.2576@Pk7MdxJ+TmFltkWNfRnhqw X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from lorien2.mallorn.com [208.78.102.2] by remote.mallorn.com with POP3 (fetchmail-6.3.8) for (single-drop); Fri, 14 Dec 2007 13:27:03 -0700 (MST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien2.mallorn.com (8.14.1/8.14.1) with ESMTP id lBEJWtSb024310 for ; Fri, 14 Dec 2007 14:33:00 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBEJF4Gr089703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2007 12:15:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBEJF48g089702; Fri, 14 Dec 2007 12:15:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBEJF3Jf089695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 14 Dec 2007 12:15:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 39AF3175C6; Fri, 14 Dec 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J3Fzx-0003i8-On; Fri, 14 Dec 2007 14:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-mta-filters@imc.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 14 Dec 2007 14:15:01 -0500 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be infected Subject: {Blocked Content} I-D ACTION:draft-ietf-sieve-body-07.txt --NextPart Warning: This message has had one or more attachments removed Warning: (not named). Warning: Please read the "mallorn-Attachment-Warning.txt" attachment(s) for more information. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF. Title : Sieve Email Filtering: Body Extension Author(s) : P. Guenther, J. Degener Filename : draft-ietf-sieve-body-07.txt Pages : 12 Date : 2007-12-14 This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-sieve-body-07.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-ietf-sieve-body-07.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. --NextPart Content-type: multipart/mixed; boundary="OtherAccess" --OtherAccess Content-Type: text/plain; charset="us-ascii"; name="mallorn-Attachment-Warning.txt" Content-Disposition: inline; filename="mallorn-Attachment-Warning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "not named" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Fri Dec 14 14:33:01 2007 the virus scanner said: External message bodies cannot be scanned and are removed Note to Help Desk: Look on the mallorn MailScanner in /var/spool/quarantine= /20071214 (message lBEJWtSb024310). --=20 Postmaster Mallorn Computing, Inc. http://www.mallorn.com/ For all your IT requirements visit: http://www.transtec.co.uk --OtherAccess Content-Type: text/plain; charset="us-ascii"; name="mallorn-Attachment-Warning.txt" Conte