From owner-ietf-mta-filters Wed Jan 3 07:23:18 2007 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 l03ENH9D005606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 07:23:18 -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 l03ENHRK005605; Wed, 3 Jan 2007 07:23: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 mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l03ENFGW005599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Jan 2007 07:23:17 -0700 (MST) (envelope-from michael@freenet-ag.de) Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1H271O-0005Tr-5R for ietf-mta-filters@imc.org; Wed, 03 Jan 2007 15:23:14 +0100 Received: from nostromo.freenet-ag.de ([194.97.7.6]:48812) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1H271O-0004tk-2o for ietf-mta-filters@imc.org; Wed, 03 Jan 2007 15:23:14 +0100 Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.65 #1) id 1H271N-0004ZO-CS for ietf-mta-filters@imc.org; Wed, 03 Jan 2007 15:23:13 +0100 Date: Wed, 03 Jan 2007 15:23:13 +0100 To: ietf-mta-filters@imc.org Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> In-Reply-To: <4589A03A.3040001@aegee.org> 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: Hello, happy new year to everybody! I don't want to let this discussion just stop without agreement. So let's get results. > It is true that some notify-gateways support subjects, and others don't, > but a subject is a property of a general message. IMHO: Messages in general - yes. Notification messages - no. A poll should answer what the majority thinks: ---------------------------------------------------------------------- Do you consider general notification messages (in the context of the notify extension) to have a property "subject"? [ ] yes [ ] no ---------------------------------------------------------------------- > If we want a common name in all derived classes, the name shall be > defined already in the interface. I agree to that. Should the majority vote for subjects being proporties of general notification messages, we absolutely should put ":subject" in the framework. > By the way, what do you think about adding an "expire: date", in order > to allow the mechanism to delte the notification, if it is not delivered > within a certain time. E.g. I might like to get jabber message when I > get a mail, but when on holiday, I don't want 100 notifications once I > am back. Instead the notification might wait three days to be read and > then be discarded. I think if you want a rolling message store, the recipient store and its associated delivery policy (e.g. a sieve filter:-) should care about that, not the sender. > "method:" If method: is a must to have, then it is redundant to > write "method:" when this can be avoided and I am in favour of removing > it. That makes two of us. Compatibility is no problem at this point, because the name of the extension changes anyway. Michael From owner-ietf-mta-filters Wed Jan 3 09:27:52 2007 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 l03GRpd7014569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 09:27:52 -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 l03GRpPP014568; Wed, 3 Jan 2007 09:27:51 -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.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l03GRpGt014559 for ; Wed, 3 Jan 2007 09:27:51 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 8f2fb5a3f76456a07e0c9c3f64b2318a X-Spam-Score-Summary: 2,0,0,4b3bcde9424ab7d2,17cb9f564c0fc456,nigel.swinson@rockliffe.com,,RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1540:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2194:2199:2393:2553:2559:2562:2828:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.5) with ESMTP id ; Wed, 3 Jan 2007 08:27:50 -0800 Message-ID: <017801c72f54$3f5fcdb0$0202fea9@nigelhome> From: "Nigel Swinson" To: "Michael Haardt" Cc: References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt Date: Wed, 3 Jan 2007 16:28:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l03GRpGt014560 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > It is true that some notify-gateways support subjects, and others don't, > > but a subject is a property of a general message. > > IMHO: Messages in general - yes. Notification messages - no. But then complex messages may also transport notifications. Perhaps an alternative question is of all the available messaging channels, how many support a subject+body, and how many support just a body. You probably then ought to weight the frequency of the messaging channel. Carrier Pigeon isn't going to be as popular a choice as sms or email for notifications. If there are several channels that support a subject, it is worth adding to the notify spec. What is the utility of using notify with email? Why not just use redirect (+keep?). I'm currently marginally against adding :subject to the notify spec. Nigel From owner-ietf-mta-filters Wed Jan 3 10:22:46 2007 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 l03HMk3g019501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 10: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 l03HMkgt019500; Wed, 3 Jan 2007 10: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 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 l03HMkgN019489 for ; Wed, 3 Jan 2007 10:22:46 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id 6EF606024E43; Wed, 3 Jan 2007 09:22:35 -0800 (PST) Date: Wed, 3 Jan 2007 17:22:35 -0000 To: "Nigel Swinson" Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt From: "Aaron Stone" X-Mailer: TWIG 2.8.2 Message-ID: In-Reply-To: <017801c72f54$3f5fcdb0$0202fea9@nigelhome> References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Cc: Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 3, 2007, Nigel Swinson said: > What is the utility of using notify with email? Why not just use redirect > (+keep?). In many cases, the email and the email store will be secure, but the notification mechanism will not. The use case I've thought of is a doctor's email, which will be be secured and is restricted by patient privacy laws, but the doctor's pager is an open broadcast. The notification to "Read your hospital email now!" contains no private information. A copy of the original message (or even its Received headers, hence the thorny issues with catching message loops) is private. Incidentally, "Read your hospital email now!" strikes me as the _subject_. The message might be blank on a pager, or it might include some details if it were an email. In a non-privacy-centric situation, perhaps a lot of detail. Aaron From owner-ietf-mta-filters Wed Jan 3 10:48:43 2007 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 l03HmhmK021647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 10:48:43 -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 l03HmhkB021646; Wed, 3 Jan 2007 10:48:43 -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.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l03Hmggq021638 for ; Wed, 3 Jan 2007 10:48:42 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 5e1332730d7713f67900a5e5ee7dd0eb X-Spam-Score-Summary: 2,0,0,79ff669a7154f3e6,17cb9f564c0fc456,nigel.swinson@rockliffe.com,,RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2194:2199:2393:2559:2562:2693:2828:2891:2892:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3874:4362:4552:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.5) with ESMTP id ; Wed, 3 Jan 2007 09:48:42 -0800 Message-ID: <002601c72f5f$76491c90$0202fea9@nigelhome> From: "Nigel Swinson" To: "Aaron Stone" Cc: References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt Date: Wed, 3 Jan 2007 17:49:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l03Hmhgq021641 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > What is the utility of using notify with email? Why not just use redirect > > (+keep?). > > In many cases, the email and the email store will be secure, but the > notification mechanism will not. > > The use case I've thought of is a doctor's email, which will be be secured > and is restricted by patient privacy laws, but the doctor's pager is an > open broadcast. The notification to "Read your hospital email now!" > contains no private information. A copy of the original message (or even > its Received headers, hence the thorny issues with catching message loops) > is private. Thanks for that, it's helpful to think about :o) > Incidentally, "Read your hospital email now!" strikes me as the _subject_. > The message might be blank on a pager, or it might include some details if > it were an email. In a non-privacy-centric situation, perhaps a lot of > detail. I think we run the risk of straying into message summaries that Ned warned about previously. So why can't the notification be just "Read your hospital email now!" and have no two part subject/body, or in a non-privacy-centric situation use redirect(+keep?). Nigel From owner-ietf-mta-filters Wed Jan 3 13:30:32 2007 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 l03KUWTI034184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 13:30:32 -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 l03KUWkl034183; Wed, 3 Jan 2007 13:30:32 -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 l03KUTZB034174 for ; Wed, 3 Jan 2007 13:30:31 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id B00CC6024E43; Wed, 3 Jan 2007 12:30:19 -0800 (PST) Date: Wed, 3 Jan 2007 20:30:19 -0000 To: "Nigel Swinson" , "Aaron Stone" Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt From: "Aaron Stone" X-Mailer: TWIG 2.8.2 Message-ID: In-Reply-To: <002601c72f5f$76491c90$0202fea9@nigelhome> References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Cc: Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 3, 2007, Nigel Swinson said: >> Incidentally, "Read your hospital email now!" strikes me as the _subject_. >> The message might be blank on a pager, or it might include some details if >> it were an email. In a non-privacy-centric situation, perhaps a lot of >> detail. > > I think we run the risk of straying into message summaries that Ned warned > about previously. So why can't the notification be just "Read your hospital > email now!" and have no two part subject/body, or in a non-privacy-centric > situation use redirect(+keep?). Ok, but the implementation specs (notify-xmpp and notify-mailto) each specify different and strange default subjects in their respective media. They even seem to suggest that the subject would be hardcoded in the implementation. Aaron From owner-ietf-mta-filters Wed Jan 3 17:00:19 2007 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 l0400JsE047419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 17:00: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 l0400JeU047418; Wed, 3 Jan 2007 17:00: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 mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0400Irq047411 for ; Wed, 3 Jan 2007 17:00:18 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 2840ecd498a18647bdfc1c57d27f4e9f X-Spam-Score-Summary: 2,0,0,a52e3ad2ff841928,17cb9f564c0fc456,nigel.swinson@rockliffe.com,,RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1537:1567:1587:1593:1594:1711:1714:1730:1747:1766:1792:2073:2075:2078:2393:2559:2562:2828:3027:3865:3867:3868:3869:3870:3874:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.5) with ESMTP id ; Wed, 3 Jan 2007 16:00:13 -0800 Message-ID: <009201c72f93$760ab660$0202fea9@nigelhome> From: "Nigel Swinson" To: "Aaron Stone" Cc: References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt Date: Thu, 4 Jan 2007 00:01:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0400Irq047413 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Ok, but the implementation specs (notify-xmpp and notify-mailto) each > specify different and strange default subjects in their respective media. > They even seem to suggest that the subject would be hardcoded in the > implementation. I'd say if the gateway supports subject+body, then the notification should be the subject, not the body. A hardcoded subject sounds dreadful! Nigel From owner-ietf-mta-filters Thu Jan 4 07:56:08 2007 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 l04Eu8IH002184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 07:56: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 l04Eu83p002183; Thu, 4 Jan 2007 07:56: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 mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l04Eu40i002176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Jan 2007 07:56:07 -0700 (MST) (envelope-from michael@freenet-ag.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1H2U0h-0000MQ-6S for ietf-mta-filters@imc.org; Thu, 04 Jan 2007 15:56:03 +0100 Received: from nostromo.freenet-ag.de ([194.97.7.6]:51987) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1H2U0g-0006xK-Vq for ietf-mta-filters@imc.org; Thu, 04 Jan 2007 15:56:03 +0100 Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.65 #1) id 1H2U0g-0005H9-Fw for ietf-mta-filters@imc.org; Thu, 04 Jan 2007 15:56:02 +0100 Date: Thu, 04 Jan 2007 15:56:02 +0100 To: ietf-mta-filters@imc.org Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> <009201c72f93$760ab660$0202fea9@nigelhome> In-Reply-To: <009201c72f93$760ab660$0202fea9@nigelhome> 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: > > Ok, but the implementation specs (notify-xmpp and notify-mailto) each > > specify different and strange default subjects in their respective media. > > They even seem to suggest that the subject would be hardcoded in the > > implementation. > > I'd say if the gateway supports subject+body, then the notification should be the subject, not the body. A hardcoded subject sounds dreadful! >From draft-ietf-sieve-notify-mailto-01: o The "Subject:" field of the notification message contains the value defined by the :message notify tag, as described in [Notify]. If there is no :message tag, the subject is retained from the triggering message. Note that Sieve [Variables] can be used to advantage here, as shown in the example in Section 3. [...] o If the mailto URI contains a "body" header, the value of that header is used as the body of the notification message. If there is no "body" header, the body of the notification message is empty. No fixed subject, and I can't remember that is was suggested to change that. Michael From owner-ietf-mta-filters Sun Jan 14 02:36:09 2007 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 l0E9a9IW011749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jan 2007 02:36: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 l0E9a9AS011748; Sun, 14 Jan 2007 02:36: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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0E9a7uX011742 for ; Sun, 14 Jan 2007 02:36:08 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.17.15.141] ((unknown) [81.253.46.19]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 14 Jan 2007 09:36:05 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <45A9F979.7000500@isode.com> Date: Sun, 14 Jan 2007 09:35:53 +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: Dilyan Palauzov CC: ietf-mta-filters@imc.org Subject: Re: sieve for spamfiltering and greylisting References: <20061213124135.ge5xkem1ggkk4wow@mail.aegee.org> <458717AA.8020103@isode.com> <20061219081939.vcylj71s84kgs0k4@mail.aegee.org> In-Reply-To: <20061219081939.vcylj71s84kgs0k4@mail.aegee.org> MIME-version: 1.0 Content-type: text/plain; charset="UTF-8"; format="flowed" Content-transfer-encoding: 8bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dilyan Palauzov wrote: > Hello, Hi Dilyan, > My idea was not to call external applications, but to provide > unified interface where different applications read the same sieve > script but interpret different parts of it. Can this be done using Ned's environment extension and/or Sieve include extension? > The aim is to minimize the amount of interfaces a user needs to work > with in order to configure the way of the mail from the MTA to his > mailbox. > > There are several user's preferences in spamassassin (tool saying > for each may how high the probability is, that a specific mail is > spam). Such an example is the whitelisting. Another option is > altering the scores per user, that matching specific test gives, thus > modifying the influence that a test has. rewrite_header > (http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#basic_message_tagging_options > ) modifies the header of the message, in case it is spam. Of course > this can be achieved by other means in sieve, Indeed. The editheader extension can be used for that. > but the latter fact is a sign that spamassassin and sieve do very > similar things (conditionally rewriting headers) and therefore shall > be configured from the same place. I am not yet convinced that Sieve is the proper place for storing this information. One possibility is to store such information externally (in LDAP, ACAP or IMAP METADATA) and access it using a Sieve extension. I've written a Sieve extension for accessing IMAP METADATA values. Another possibility is to make spamassasin Sieve-aware. But maybe this is a wishful thinking :-). > spam rewrite_header nanana, or rather spam rewrite_header subject > nanana is supposed to prefix the subject-header with +nanana+ in the > mails marked as spam. > > Greetings, > Дилян From owner-ietf-mta-filters Tue Jan 16 04:28:09 2007 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 l0GBS9OG041802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 04:28: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 l0GBS90m041801; Tue, 16 Jan 2007 04:28: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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0GBS8Qp041795 for ; Tue, 16 Jan 2007 04:28:09 -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, 16 Jan 2007 11:28:07 +0000 Message-ID: <45ACB6BA.2040803@isode.com> Date: Tue, 16 Jan 2007 11:27:54 +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 MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: WGLC for Sieve Notify has ended 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: I will post the summary of all issues raised later this week. I've only seen comments from Michael, Aaron and Dilyan. Has anybody else reviewed the document? From owner-ietf-mta-filters Tue Jan 16 09:29:15 2007 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 l0GGTFJ2070102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 09:29:15 -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 l0GGTFwV070101; Tue, 16 Jan 2007 09:29:15 -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 l0GGTEWD070086 for ; Tue, 16 Jan 2007 09:29:15 -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, 16 Jan 2007 16:29:13 +0000 Message-ID: <45ACFD4B.80803@isode.com> Date: Tue, 16 Jan 2007 16:28:59 +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@imc.org Subject: Updated milestones 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: Hi folks, Below is a proposal from chairs about updating our milestones (again): Jan 2007 Submit 3028bis to IESG Jan 2007 Submit editheader draft to IESG Jan 2007 Submit body test draft to IESG Feb 2007 Submit notification action draft to IESG Mar 2007 WG last call for loop draft Apr 2007 Submit loop draft to IESG Apr 2007 Submit revised regex draft May 2007 Submit refuse draft to IESG Jun 2007 WG last call of regex draft Aug 2007 Submit regex action draft to IESG Aug 2007 3028bis interop report framework/matrix Does this seem reasonable? From owner-ietf-mta-filters Tue Jan 16 10:19:02 2007 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 l0GHJ2bu074340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 10:19:02 -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 l0GHJ217074339; Tue, 16 Jan 2007 10:19:02 -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 shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0GHJ1Sb074331 for ; Tue, 16 Jan 2007 10:19:02 -0700 (MST) (envelope-from mem@mv.mv.com) Received: (qmail 86968 invoked by uid 101); 16 Jan 2007 12:19:00 -0500 From: "Mark E. Mallett" Date: Tue, 16 Jan 2007 12:19:00 -0500 To: Alexey Melnikov Cc: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended Message-ID: <20070116171900.GA83498@osmium.mv.net> References: <45ACB6BA.2040803@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45ACB6BA.2040803@isode.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jan 16, 2007 at 11:27:54AM +0000, Alexey Melnikov wrote: > > I will post the summary of all issues raised later this week. > > I've only seen comments from Michael, Aaron and Dilyan. Has anybody else > reviewed the document? Yes... but too late, I fear. mm From owner-ietf-mta-filters Tue Jan 16 13:19:48 2007 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 l0GKJmEq088117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 13:19:48 -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 l0GKJmEX088116; Tue, 16 Jan 2007 13:19:48 -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 shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0GKJko7088110 for ; Tue, 16 Jan 2007 13:19:47 -0700 (MST) (envelope-from mem@mv.mv.com) Received: (qmail 48008 invoked by uid 101); 16 Jan 2007 15:19:46 -0500 From: "Mark E. Mallett" Date: Tue, 16 Jan 2007 15:19:45 -0500 To: Alexey Melnikov Cc: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended Message-ID: <20070116201945.GA37066@osmium.mv.net> References: <45ACB6BA.2040803@isode.com> <20070116171900.GA83498@osmium.mv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070116171900.GA83498@osmium.mv.net> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jan 16, 2007 at 12:19:00PM -0500, Mark E. Mallett wrote: > > On Tue, Jan 16, 2007 at 11:27:54AM +0000, Alexey Melnikov wrote: > > > > I will post the summary of all issues raised later this week. > > > > I've only seen comments from Michael, Aaron and Dilyan. Has anybody else > > reviewed the document? > > Yes... but too late, I fear. Sorry for being abrupt. I just have some probably-inconsequential comments. > Usage: notify ":method" string > [":from" string] > [":importance" <"1" / "2" / "3">] > [":options" string-list] > [":message" string] If I interpret the past discussion correctly, this may be getting changed to remove ':method' and add a positional . I think that is a positive change, but I don't feel too strongly. > 4. Extract_text Action > > Usage: extract_text [MODIFIER] [":first" number] > I feel that this would be much better as a standalone extension, or at least as part of an extension where it is more relevant (e.g. "mime"). It has broader use than for just notify; users might want it when notify is not available; and it could be specified in a more general way. I also think that notify could easily proceed without it (though I don't know all the history, so maybe I'm wrong). Having it here has the same feel as a legislative earmark. This is the strongest I feel of the remarks that I have here :) There's also this: > The Extract_text action stores at most :first bytes of the first > text/* part in the variable identified by varname. If the :first > parameter is not present, the whole content of the first text/* part > is stored. Should something be said about the upper bound? If nothing else, that the "whole content" may not be stored because of the truncation that happens when the variables limit is exceeded. I also think it would help to say that implementation limits may apply. My implementation, for example, caches in memory some minimum number of bytes of each mime part, with any excess possibly being cached on disk. I'd happily make what's cached in memory available, but I might be disgruntled by having to fetch more from disk cache. (This would probably already exceed the variables limit, but it's just an example of why an implementation might want to have a limit.) > 5. Test valid_notif_method > > Usage: valid_notif_method This has the feel of "creat()". i.e., are we so short on space that we can't have the 'y' ? Guess that's it.. -mm- From owner-ietf-mta-filters Wed Jan 17 09:12:39 2007 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 l0HGCdU8071645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 09:12:39 -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 l0HGCdqp071644; Wed, 17 Jan 2007 09:12:39 -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 l0HGCcm2071638 for ; Wed, 17 Jan 2007 09:12:38 -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, 17 Jan 2007 16:12:37 +0000 Message-ID: <45AE4AE7.9090405@isode.com> Date: Wed, 17 Jan 2007 16:12:23 +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 MIME-Version: 1.0 To: Ken Murchison CC: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <45AE4591.8040009@andrew.cmu.edu> In-Reply-To: <45AE4591.8040009@andrew.cmu.edu> 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: Ken Murchison wrote: > Alexey Melnikov wrote: > >> I will post the summary of all issues raised later this week. >> >> I've only seen comments from Michael, Aaron and Dilyan. Has anybody >> else reviewed the document? > > I'm wondering if we shouldn't leverage the 'ihave' test from the > environment extension rather than creating the proposed > 'valid_notif_method' test. I think you mean the "environment" test, not the "ihave". valid_notif_method can validate the whole URI, not just the schema part of it. From owner-ietf-mta-filters Wed Jan 17 09:19:56 2007 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 l0HGJuqk072096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 09:19: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 l0HGJuFB072095; Wed, 17 Jan 2007 09:19:56 -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 mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HGJs0g072089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Jan 2007 09:19:55 -0700 (MST) (envelope-from michael@freenet-ag.de) Received: from [194.97.55.242] (helo=mx9.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.65) (envelope-from ) id 1H7DVv-0001rr-E5 for ietf-mta-filters@imc.org; Wed, 17 Jan 2007 17:19:51 +0100 Received: from nostromo.freenet-ag.de ([194.97.7.6]:39600) by mx9.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1H7DVv-0005bU-Ct for ietf-mta-filters@imc.org; Wed, 17 Jan 2007 17:19:51 +0100 Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.65 #6) id 1H7DVu-00038F-V9 for ietf-mta-filters@imc.org; Wed, 17 Jan 2007 17:19:50 +0100 Date: Wed, 17 Jan 2007 17:19:50 +0100 To: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <45AE4591.8040009@andrew.cmu.edu> In-Reply-To: <45AE4591.8040009@andrew.cmu.edu> 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: > I'm wondering if we shouldn't leverage the 'ihave' test from the > environment extension rather than creating the proposed > 'valid_notif_method' test. Does ihave address checking if a particular set of arguments to an extension is valid, or just if the extension exists at all? There was a discussion about all kinds of generic error handlers and no consensus, but unfortunately nobody has valid reasons against 'valid_notif_method', so it looks like that's what we will get. The test feels wrong to me, but that's hardly something to object a WGLC, and even if we agree to some error handling approach, it is just ugly to carry around, but not a problem really. Michael From owner-ietf-mta-filters Wed Jan 17 08:49:40 2007 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 l0HFnd7d070291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 08:49:40 -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 l0HFndXu070290; Wed, 17 Jan 2007 08:49:39 -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.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HFnck7070284 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 17 Jan 2007 08:49:39 -0700 (MST) (envelope-from murch@andrew.cmu.edu) Received: from [192.168.137.23] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id l0HFnbo3021895 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 17 Jan 2007 10:49:37 -0500 Message-ID: <45AE4591.8040009@andrew.cmu.edu> Date: Wed, 17 Jan 2007 10:49:37 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> In-Reply-To: <45ACB6BA.2040803@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > I will post the summary of all issues raised later this week. > > I've only seen comments from Michael, Aaron and Dilyan. Has anybody else > reviewed the document? I'm wondering if we shouldn't leverage the 'ihave' test from the environment extension rather than creating the proposed 'valid_notif_method' test. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From owner-ietf-mta-filters Wed Jan 17 10:10:39 2007 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 l0HHAdWD076524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 10:10:39 -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 l0HHAdw0076523; Wed, 17 Jan 2007 10:10:39 -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 l0HHAbQq076516 for ; Wed, 17 Jan 2007 10:10:38 -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 339A14ADCA; Wed, 17 Jan 2007 18:10:37 +0100 (CET) Message-Id: Date: Wed, 17 Jan 2007 18:12:59 +0100 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended Cc: Alexey Melnikov , Ken Murchison References: <45ACB6BA.2040803@isode.com> <45AE4591.8040009@andrew.cmu.edu> <45AE4AE7.9090405@isode.com> In-Reply-To: <45AE4AE7.9090405@isode.com> 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: Alexey Melnikov writes: > valid_notif_method can validate the whole URI, not just the schema > part of it. Shouldn't it then be named valid_notif_uri (or valid_notify_uri)? Arnt From owner-ietf-mta-filters Wed Jan 17 10:55:09 2007 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 l0HHt9AW079226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 10:55: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 l0HHt9n2079225; Wed, 17 Jan 2007 10:55: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 laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HHt881079219 for ; Wed, 17 Jan 2007 10:55:09 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6AB8614225A; Wed, 17 Jan 2007 09:55:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04614-06; Wed, 17 Jan 2007 09:55:08 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D448F142258; Wed, 17 Jan 2007 09:55:05 -0800 (PST) In-Reply-To: <45ACB6BA.2040803@isode.com> References: <45ACB6BA.2040803@isode.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-mta-filters@imc.org Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: WGLC for Sieve Notify has ended Date: Wed, 17 Jan 2007 09:55:01 -0800 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think we're going to need a bit more language in the sieve-notify draft about sending from authorized or unauthorized from addresses, as well as about sending to people who do not want to receive notifications, and throttling. I'm not sure exactly what needs to be said, however. - Something about how implementations SHOULD restrict the from address to allow only appropriate mailboxes? SHOULD restrict the from address so that other domains aren't caused to be spoofed? - If the recipient of a sieve notify mail doesn't want those notifications, what recourse do they have? Servers SHOULD add a "cancel" link to each notify mail... ? - If the notification frequency is high, servers SHOULD throttle notifications (and if so what error to produce)? Disable the rule? lisa On Jan 16, 2007, at 3:27 AM, Alexey Melnikov wrote: > > I will post the summary of all issues raised later this week. > > I've only seen comments from Michael, Aaron and Dilyan. Has anybody > else reviewed the document? > From owner-ietf-mta-filters Thu Jan 18 12:46:14 2007 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 l0IJkEtN090665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 12:46:14 -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 l0IJkE55090664; Thu, 18 Jan 2007 12:46:14 -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 l0IJkAQP090655 for ; Thu, 18 Jan 2007 12:46:11 -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 ; Thu, 18 Jan 2007 19:46:09 +0000 Message-ID: <45AFCE72.4060201@isode.com> Date: Thu, 18 Jan 2007 19:45:54 +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: Dilyan Palauzov CC: ietf-mta-filters@imc.org Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> , <4589A03A.3040001@aegee.org> In-Reply-To: <4589A03A.3040001@aegee.org> 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: Dilyan Palauzov wrote: > Hello, Hi Dilyan, > To what I understood, the issue with method: and subject: was not > cleared yet. Let me share what I think: > > 'subject:" for me the purpose of sieve-notify is to define a general > framework for sending notifications, in the most general way a message > can be defined. It is true that some notify-gateways support subjects, > and others don't, but a subject is a property of a general message. > Look on the discussion as an object-oriented programmer: the base > class/interface is notify, derived by notify-voip-phone, notify-xmpp, > notify-mailto. Suppose notify-voip-phone puts a message in the voice > box of the user and displays text on the device's display (voip phones > do have ascii display). > If we want a common name in all derived classes, the name shall be > defined already in the interface. Then notify-xmpp can ignore this > tag, in the same way notify-voip-phone can ignore importance. But if > there is a subject: to be overwritten, then notify-display-phone is > supposed to use this keyword for the text to be displayed. If there is > no subject: , they could use display: and even if totally correct, it > is not very practical: the user will be then forced to learn the > different words used to replace "subject:", except having subject and > relying on the notify-extension to interpret it correctly (as will be > described in the sieve-notify.. how to use subject. I guess it is > already there, but have now now wish to check). > So I am in favour of having subject: in sieve-notify. Maybe I didn't understand your comments correctly, but you haven't convinced me that we need both :message and :subject. And I haven't heard a good argument for why :message is not acceptable, while :subject would be. > By the way, what do you think about adding an "expire: date", in > order to allow the mechanism to delte the notification, if it is not > delivered within a certain time. E.g. I might like to get jabber > message when I get a mail, but when on holiday, I don't want 100 > notifications once I am back. Instead the notification might wait > three days to be read and then be discarded. I see some utility in this, but I would suggest that this be done as a separate extension to Sieve notify. If other people disagree, please speak up now! > "method:" If method: is a must to have, then it is redundant to > write "method:" when this can be avoided and I am in favour of > removing it. Now, the backward compatibility, there could be a > transitional clause, included or not in the final document, that if > "methond" is not mentioned, then the last string is considered to > describe the method; if it is mentioned, then what follows it is the > method. To what I understand from computer lang. grammars it is very > easy to define the method "so or so" and I do not imagine very-very > huge problems. Ok, I count your voice for replacing :method with a positional argument. From owner-ietf-mta-filters Thu Jan 18 13:40:17 2007 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 l0IKeGqg094408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 13:40: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 l0IKeGAf094407; Thu, 18 Jan 2007 13:40:16 -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 l0IKeFgI094401 for ; Thu, 18 Jan 2007 13:40:16 -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 ; Thu, 18 Jan 2007 20:40:15 +0000 Message-ID: <45AFDB20.2030703@isode.com> Date: Thu, 18 Jan 2007 20:40:00 +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 MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt 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: Issue #1: Make tagged "method" parameter positional. (Michael, Dylan are in favor of the change). I would welcome additional opinions on this issue. Issue #2: Michael has suggested some changes to the requirement on timestamps. I will discuss this offline with Michael and Barry and will suggest some new text. Issue #3: :subject versa :message. Aaron, Dilyan in favor of adding :subject. Michael wants to keep using :message. Issue #4: Dilyan suggested to add "expiration" parameter/option to the notify action. While I see some utility in this option, I am reluctant to extend the document so late in the game, unless there is strong support from the WG. I would recommend to add this option in a separate document. Opinions? Issue #5: Ken (in a private message) has suggested to extend "body" test instead of introducing a new "extract_text" test. Opinions? Issue #6: Arnt wants to be able to do "send notification over XMPP, if can be delivered immediately. Otherwise send it over SMS". This issue needs further discussion. Issue #7: Lisa: controlling who can receive notifications and throttling. Have I listed all issues raised so far? From owner-ietf-mta-filters Thu Jan 18 14:43:12 2007 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 l0ILhCo6099479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 14:43:12 -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 l0ILhCc3099478; Thu, 18 Jan 2007 14:43:12 -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 l0ILhBdl099472 for ; Thu, 18 Jan 2007 14:43:12 -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 ; Thu, 18 Jan 2007 21:43:10 +0000 Message-ID: <45AFE9DE.6040005@isode.com> Date: Thu, 18 Jan 2007 21:42:54 +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 MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <45AFDB20.2030703@isode.com> In-Reply-To: <45AFDB20.2030703@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Issue #1: > > Make tagged "method" parameter positional. (Michael, Dylan are in > favor of the change). Mark E. Mallett is also in favor of this change (doesn't feel strongly) > I would welcome additional opinions on this issue. > > Issue #2: > > Michael has suggested some changes to the requirement on timestamps. I > will discuss this offline with Michael and Barry and will suggest some > new text. > > Issue #3: > > :subject versa :message. Aaron, Dilyan in favor of adding :subject. > Michael wants to keep using :message. > > Issue #4: > > Dilyan suggested to add "expiration" parameter/option to the notify > action. While I see some utility in this option, I am reluctant to > extend the document so late in the game, unless there is strong > support from the WG. I would recommend to add this option in a > separate document. Opinions? > > Issue #5: > > Ken (in a private message) has suggested to extend "body" test instead > of introducing a new "extract_text" test. Opinions? Somewhat related to this: Mark (and I was thinking the same) has suggested to move "extract_text" to another document (e.g. MIME loops), as it has applicability beyond Sieve notify. > Issue #6: > > Arnt wants to be able to do "send notification over XMPP, if can be > delivered immediately. Otherwise send it over SMS". > This issue needs further discussion. > > Issue #7: > > Lisa: controlling who can receive notifications and throttling. > > > Have I listed all issues raised so far? Also, several people including Mark has suggested to rename "valid_notif_method" to "valid_notify_method". Unless I hear otherwise, I will do that in the next revision. From owner-ietf-mta-filters Thu Jan 18 15:19:13 2007 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 l0IMJCob001892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 15:19:12 -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 l0IMJCa1001891; Thu, 18 Jan 2007 15:19:12 -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.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0IMJAV7001884 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 18 Jan 2007 15:19:12 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1H7fbB-0005HA-Ex; Thu, 18 Jan 2007 23:19:09 +0100 Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l0IMJAAQ011980 for ; Thu, 18 Jan 2007 22:19:10 GMT Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l0IMJ99D011979 for ietf-mta-filters@imc.org; Thu, 18 Jan 2007 23:19:09 +0100 X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to Dilyan.Palauzov@aegee.org using -f Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Thu, 18 Jan 2007 23:19:09 +0100 Message-ID: <20070118231909.om84uctk6ccok04c@mail.aegee.org> Date: Thu, 18 Jan 2007 23:19:09 +0100 From: Dilyan Palauzov To: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Virus-Scanned: ClamAV 0.88.7/2462/Thu Jan 18 10:07:46 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0IMJCV6001886 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Reading Lisa's mail, a new problem arized in my head: For every generated notification, the system administrator shall be able to say how did it originate. Making "grep" on all scripts is not an option, since the user might have changed the script in the meantime, or two users might have identical scripts. Just imagine a user gets constantly notifications saying "you got an email at your example.com mailbox". But the user does not have an example.com mailbox, and moreover, he has not set up such a script-notification. Obviously this was made by another user and when the system administrator, on whose server the message was generated, is informed about it, s/he shall be able to track where the problem was. So I suggest to add something to section 3.8. Requirements on notification methods specifications * It is RECOMMENDED that a notification includes means to identify/track its origin. But this could be understood, that a notification shall say which server generated it, and not which user. Any ideas? In sec 3.8. one more sentance could be included * Where applicatiable, derived extensions shall support a subject: option. Greetings, Дилян From owner-ietf-mta-filters Thu Jan 18 15:32:56 2007 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 l0IMWut6003214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 15:32: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 l0IMWuC3003213; Thu, 18 Jan 2007 15:32:56 -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.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0IMWr2q003204 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 18 Jan 2007 15:32:55 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1H7foT-0002Pv-49; Thu, 18 Jan 2007 23:32:53 +0100 Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l0IMWsnc012608 for ; Thu, 18 Jan 2007 22:32:54 GMT Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l0IMWrQb012607 for ietf-mta-filters@imc.org; Thu, 18 Jan 2007 23:32:53 +0100 X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to Dilyan.Palauzov@aegee.org using -f Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Thu, 18 Jan 2007 23:32:53 +0100 Message-ID: <20070118233253.0a7pbji0sg80448o@mail.aegee.org> Date: Thu, 18 Jan 2007 23:32:53 +0100 From: Dilyan Palauzov To: ietf-mta-filters@imc.org Subject: Re: sieve for spamfiltering and greylisting References: <20061213124135.ge5xkem1ggkk4wow@mail.aegee.org> <458717AA.8020103@isode.com> <20061219081939.vcylj71s84kgs0k4@mail.aegee.org> <45A9F979.7000500@isode.com> In-Reply-To: <45A9F979.7000500@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Virus-Scanned: ClamAV 0.88.7/2462/Thu Jan 18 10:07:46 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0IMWt2p003207 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, > One idea worth considering is multiple Sieve engines, one running in > MTA and one running in delivery agent. This was what I tried to explain all the time. >> My idea was not to call external applications, but to provide >> unified interface where different applications read the same sieve >> script but interpret different parts of it. > > Can this be done using Ned's environment extension and/or Sieve include > extension? No. The spam filter needs the user preferences in form of input and delivers probability as output. The environment extension might contain the results from the spam evaluation, but at the moment the script is supposed to be read either before or after spam filtering, thus being used either as input to the filter, or as output. > >> The aim is to minimize the amount of interfaces a user needs to >> work with in order to configure the way of the mail from the MTA >> to his mailbox. >> >> There are several user's preferences in spamassassin (tool saying >> for each may how high the probability is, that a specific mail is >> spam). Such an example is the whitelisting. Another option is >> altering the scores per user, that matching specific test gives, >> thus modifying the influence that a test has. rewrite_header >> (http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#basic_message_tagging_options ) modifies the header of the message, in case it is spam. Of course this can be achieved by other means in >> sieve, > > Indeed. The editheader extension can be used for that. > >> but the latter fact is a sign that spamassassin and sieve do very >> similar things (conditionally rewriting headers) and therefore >> shall be configured from the same place. > > I am not yet convinced that Sieve is the proper place for storing this > information. > One possibility is to store such information externally (in LDAP, ACAP > or IMAP METADATA) and access it using a Sieve extension. I've written a > Sieve extension for accessing IMAP METADATA values. IMAP Metadata is not appropriate, since not every email address has assigned an imap mailbox. E.g. on my server I have 15000 mail aliases and I don't want to install for all the suers imap accounts in order to store the settings. LDAP is an option, as well ACAP, but this is practiced at the moment: In order to configure the incoming mail, a user has to write a sieve script, then to setup the greylisting, then to sfjust spamassassin, and then one more spam filter. It would be better for the user if there was only one itnerface. Needless to say, first the anti-spam tools shall agree on common settings, but sieve is the only one of the mentioned 3 interfaces that provides standard means to upload the settings. > Another possibility is to make spamassasin Sieve-aware. But maybe this > is a wishful thinking :-). It is not that impossible. Just a new module for reading preferences is needed and if there is a standard, I am sure the module will be written. (there is already managesieve in perl). I will contact, soon or late, different spam dev. teams and share later the common opinion. Greetings, Дилян From owner-ietf-mta-filters Mon Jan 22 04:37:45 2007 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 l0MBbjos004387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 04:37:45 -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 l0MBbj2W004386; Mon, 22 Jan 2007 04:37:45 -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 l0MBbi6u004377 for ; Mon, 22 Jan 2007 04:37:44 -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 ; Mon, 22 Jan 2007 11:37:43 +0000 Message-ID: <45B378EB.6050804@isode.com> Date: Sun, 21 Jan 2007 14:30:03 +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@imc.org Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <45AFDB20.2030703@isode.com> <45AFE9DE.6040005@isode.com> In-Reply-To: <45AFE9DE.6040005@isode.com> 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: Alexey Melnikov wrote: > Alexey Melnikov wrote: > >> Issue #1: >> >> Make tagged "method" parameter positional. (Michael, Dylan are in >> favor of the change). > > Mark E. Mallett is also in favor of this change (doesn't feel strongly) I've done this change now. >> I would welcome additional opinions on this issue. >> >> Issue #2: >> >> Michael has suggested some changes to the requirement on timestamps. >> I will discuss this offline with Michael and Barry and will suggest >> some new text. > The updated text reads: Notifications SHOULD include timestamps, if the notification method allows for their transmission outside of the textual message. Implementation methods which can only transmit timestamps in the textual message MAY include them in the textual message. [...] >> Issue #7: >> >> Lisa: controlling who can receive notifications and throttling. > I've sent some suggested text to the mailing list. >> Have I listed all issues raised so far? > > Also, several people including Mark has suggested to rename > "valid_notif_method" to "valid_notify_method". Unless I hear > otherwise, I will do that in the next revision. This change is done now. From owner-ietf-mta-filters Mon Jan 22 04:37:42 2007 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 l0MBbgl2004343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 04:37: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 l0MBbg6D004342; Mon, 22 Jan 2007 04:37: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 l0MBbfaW004318 for ; Mon, 22 Jan 2007 04:37: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 ; Mon, 22 Jan 2007 11:37:40 +0000 Message-ID: <45B35EAE.7090106@isode.com> Date: Sun, 21 Jan 2007 12:38:06 +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: "Mark E. Mallett" CC: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <20070116171900.GA83498@osmium.mv.net> <20070116201945.GA37066@osmium.mv.net> In-Reply-To: <20070116201945.GA37066@osmium.mv.net> 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: Mark E. Mallett wrote: >> The Extract_text action stores at most :first bytes of the first >> text/* part in the variable identified by varname. If the :first >> parameter is not present, the whole content of the first text/* part >> is stored. >> >> >Should something be said about the upper bound? If nothing else, that >the "whole content" may not be stored because of the truncation that >happens when the variables limit is exceeded. I also think it would >help to say that implementation limits may apply. My implementation, >for example, caches in memory some minimum number of bytes of each mime >part, with any excess possibly being cached on disk. I'd happily make >what's cached in memory available, but I might be disgruntled by having >to fetch more from disk cache. (This would probably already exceed the >variables limit, but it's just an example of why an implementation might >want to have a limit.) > > I've added: In either case the actually stored data MAY be truncated to conform to implementation specific limit on variable length and/or on MIME body part length. Is this sufficient? Should we encourage implementations to have some kind of limit on body part length? From owner-ietf-mta-filters Mon Jan 22 04:37:51 2007 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 l0MBbppK004403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 04:37:51 -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 l0MBbpas004402; Mon, 22 Jan 2007 04:37:51 -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 l0MBbhVP004358 for ; Mon, 22 Jan 2007 04:37:44 -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 ; Mon, 22 Jan 2007 11:37:42 +0000 Message-ID: <45B3773F.7000308@isode.com> Date: Sun, 21 Jan 2007 14:22: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: Dilyan Palauzov CC: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <20070118231909.om84uctk6ccok04c@mail.aegee.org> In-Reply-To: <20070118231909.om84uctk6ccok04c@mail.aegee.org> MIME-version: 1.0 Content-type: text/plain; charset="UTF-8"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dilyan Palauzov wrote: > Hello, > > Reading Lisa's mail, a new problem arized in my head: > > For every generated notification, the system administrator shall be > able to say how did it originate. Making "grep" on all scripts is not > an option, since the user might have changed the script in the > meantime, or two users might have identical scripts. > > Just imagine a user gets constantly notifications saying "you got > an email at your example.com mailbox". But the user does not have an > example.com mailbox, and moreover, he has not set up such a > script-notification. Obviously this was made by another user and when > the system administrator, on whose server the message was generated, > is informed about it, s/he shall be able to track where the problem was. > > So I suggest to add something to section > > 3.8. Requirements on notification methods specifications > > * It is RECOMMENDED that a notification includes means to > identify/track its origin. I've extended your sentence. See my reply to a Lisa's message. > But this could be understood, that a notification shall say which > server generated it, and not which user. Any ideas? Replace "origin" with "sender"? > In sec 3.8. one more sentance could be included > > * Where applicatiable, derived extensions shall support a subject: > option. This is somewhat related to the discussion about :subject versa :message. I think we need to get consensus on the subject/message issue first. From owner-ietf-mta-filters Mon Jan 22 04:37:43 2007 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 l0MBbhND004351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 04:37:43 -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 l0MBbhUc004350; Mon, 22 Jan 2007 04:37:43 -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 l0MBbfaX004318 for ; Mon, 22 Jan 2007 04:37: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 ; Mon, 22 Jan 2007 11:37:41 +0000 Message-ID: <45B3773B.6090201@isode.com> Date: Sun, 21 Jan 2007 14:22:51 +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: Lisa Dusseault CC: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> In-Reply-To: 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: Lisa Dusseault wrote: > I think we're going to need a bit more language in the sieve-notify > draft about sending from authorized or unauthorized from addresses, > as well as about sending to people who do not want to receive > notifications, and throttling. I'm not sure exactly what needs to be > said, however. > - Something about how implementations SHOULD restrict the from > address to allow only appropriate mailboxes? SHOULD restrict the > from address so that other domains aren't caused to be spoofed? Here is the text I've added (taken from the vacation draft and reworded): In order to minimize/prevent forgery of the author value, implementations MAY impose restrictions on what values can specified in a ":from" parameter; it is suggested that values which fail such a validity check simply be ignored rather than causing the notify action to fail. Do you want to upgrade the MAY to SHOULD? Also, if you feel that the two examples you gave above should be specifically mentioned, I can add them to the text. > - If the recipient of a sieve notify mail doesn't want those > notifications, what recourse do they have? I think this problem is already present in email. > Servers SHOULD add a "cancel" link to each notify mail... ? How about the following text (I've reworded and extended Dilyan's proposal): Notifications SHOULD includes means to identify/track its origin, in order to allow a recipient to stop notifications or find out how to contact the sender. This requirement is to help tracking a misconfigured or abusive origin of notifications. ? > - If the notification frequency is high, servers SHOULD throttle > notifications (and if so what error to produce)? Disable the rule? Considering there is already some text about "not retrying notification indefinitely", I think it would be Ok to just drop notifications silently. I also think that throttling should be a MAY. So how about the following text: If there are errors sending the notification, the Sieve interpreter SHOULD ignore the notification and not retry indefinitely. The Sieve interpreter MAY throttle notifications; if it does, a request to send a notification can be silently ignored. Documents describing notification methods SHOULD describe how retries, throttling, duplicate suppression (if any), etc. are to be handled by implementations. ? From owner-ietf-mta-filters Mon Jan 22 07:28:32 2007 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 l0MESVAh019165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 07:28:31 -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 l0MESV6H019164; Mon, 22 Jan 2007 07:28:31 -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.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0MEST5I019152 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jan 2007 07:28:31 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1H909n-0001ma-6Q; Mon, 22 Jan 2007 15:28:23 +0100 Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l0MESRpu011727; Mon, 22 Jan 2007 14:28:27 GMT Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l0MESQ1H011726; Mon, 22 Jan 2007 15:28:26 +0100 X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to Dilyan.Palauzov@aegee.org using -f Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Mon, 22 Jan 2007 15:28:26 +0100 Message-ID: <20070122152826.j1kjv56roso0wskg@mail.aegee.org> Date: Mon, 22 Jan 2007 15:28:26 +0100 From: Dilyan Palauzov To: Alexey Melnikov Cc: Lisa Dusseault , ietf-mta-filters@imc.org Subject: retrying to send notifications References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> In-Reply-To: <45B3773B.6090201@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Virus-Scanned: ClamAV 0.88.7/2476/Sun Jan 21 16:22:33 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0MESV5H019158 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, > SHOULD ignore the notification and not retry indefinitely. means that the notification service is unreliable: if an SMS is to be sentfrom the mail server to an sms gateway, and there is a temporary problem, the suggestion sais that it shall not be retired. But the user may rely on receiving the notifications. What about including expire: parameter and saying that the implementation shall not try after the message has expired (thus removing indefinetely)? Greetings, Дилян >> - If the notification frequency is high, servers SHOULD throttle >> notifications (and if so what error to produce)? Disable the rule? > > Considering there is already some text about "not retrying notification > indefinitely", I think it would be Ok to just drop notifications > silently. > I also think that throttling should be a MAY. So how about the > following text: > > If there are errors sending the notification, the Sieve interpreter > SHOULD ignore the notification and not retry indefinitely. > The Sieve interpreter MAY throttle notifications; if it does, > a request to send a notification can be silently ignored. > Documents describing notification methods SHOULD describe how > retries, throttling, duplicate suppression (if any), etc. are > to be handled by implementations. > > ? ----- End message from alexey.melnikov@isode.com ----- From owner-ietf-mta-filters Fri Jan 26 14:29:55 2007 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 l0QLTsSn045148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 14:29: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 l0QLTsl5045147; Fri, 26 Jan 2007 14:29:54 -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 laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0QLTrHV045141 for ; Fri, 26 Jan 2007 14:29:54 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0338B142254; Fri, 26 Jan 2007 13:29:53 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16438-04; Fri, 26 Jan 2007 13:29:52 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 25F72142253; Fri, 26 Jan 2007 13:29:52 -0800 (PST) In-Reply-To: <45B3773B.6090201@isode.com> References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2592D3D3-A9A3-4505-8FE3-857ADE1C542B@osafoundation.org> Cc: ietf-mta-filters@imc.org Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: WGLC for Sieve Notify has ended Date: Fri, 26 Jan 2007 13:29:50 -0800 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: responses in-line... On Jan 21, 2007, at 6:22 AM, Alexey Melnikov wrote: > Lisa Dusseault wrote: > >> I think we're going to need a bit more language in the sieve- >> notify draft about sending from authorized or unauthorized from >> addresses, as well as about sending to people who do not want to >> receive notifications, and throttling. I'm not sure exactly what >> needs to be said, however. >> - Something about how implementations SHOULD restrict the >> from address to allow only appropriate mailboxes? SHOULD >> restrict the from address so that other domains aren't caused to >> be spoofed? > > Here is the text I've added (taken from the vacation draft and > reworded): > > In order to minimize/prevent forgery of the author value, > implementations MAY impose restrictions on what values can > specified > in a ":from" parameter; it is suggested that values which fail > such a validity check simply be ignored rather than causing > the notify action to fail. > > Do you want to upgrade the MAY to SHOULD? My individual opinion would be for a SHOULD but I'm not sure what other considerations hold. > >> - If the recipient of a sieve notify mail doesn't want those >> notifications, what recourse do they have? > > I think this problem is already present in email. Yes, obviously. But I wonder how often notifications will be sent from a system address for simplicity. E.g. all notifications might come from "notification@example.com" for the IMAP server for example.com, regardless of whose SIEVE rule generated the notification. Then it becomes harder for the recipient to filter which notifications they do and don't want, and a little different from ordinary email. > >> Servers SHOULD add a "cancel" link to each notify mail... ? > > How about the following text (I've reworded and extended Dilyan's > proposal): > > Notifications SHOULD includes means to identify/track its > origin, in order > to allow a recipient to stop notifications or find out how to > contact the sender. > This requirement is to help tracking a misconfigured or abusive > origin of > notifications. > > ? Yes, and I think this addresses my above concern. > >> - If the notification frequency is high, servers SHOULD >> throttle notifications (and if so what error to produce)? Disable >> the rule? > > Considering there is already some text about "not retrying > notification indefinitely", I think it would be Ok to just drop > notifications silently. > I also think that throttling should be a MAY. So how about the > following text: > > If there are errors sending the notification, the Sieve interpreter > SHOULD ignore the notification and not retry indefinitely. > The Sieve interpreter MAY throttle notifications; if it does, > a request to send a notification can be silently ignored. > Documents describing notification methods SHOULD describe how > retries, throttling, duplicate suppression (if any), etc. are > to be handled by implementations. > > ? Ok. Lisa From owner-ietf-mta-filters Sat Jan 27 11:52:58 2007 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 l0RIqv8X020722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jan 2007 11:52:57 -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 l0RIqvxw020720; Sat, 27 Jan 2007 11:52:57 -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 l0RIqsnT020703 for ; Sat, 27 Jan 2007 11:52:57 -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 ; Sat, 27 Jan 2007 18:52:52 +0000 Message-ID: <45BB8AC8.1000600@isode.com> Date: Sat, 27 Jan 2007 17:24:24 +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@imc.org Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <45AFDB20.2030703@isode.com> <45AFE9DE.6040005@isode.com> In-Reply-To: <45AFE9DE.6040005@isode.com> 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: Alexey Melnikov wrote: >> Issue #3: >> >> :subject versa :message. Aaron, Dilyan in favor of adding :subject. >> Michael wants to keep using :message. > I need to poll people on this, as I don't hear a clear consensus on this. Please pick one of the following: 1). keep the existing :message (it may or may not map to email Subject:, this is a separate issue at this point) 2). rename existing :message to :subject 3). I don't care whether we have :message or :subject, but we should have only one of them. 4). notify should have both :message and :subject Let me know your opinion or if I've missed some choice. >> Issue #4: >> >> Dilyan suggested to add "expiration" parameter/option to the notify >> action. While I see some utility in this option, I am reluctant to >> extend the document so late in the game, unless there is strong >> support from the WG. I would recommend to add this option in a >> separate document. Opinions? > I've heard a couple of voices for this feature, but no rough consensus yet. Hint for people who want this functionality: please provide some text for inclusion into the document. This will improve your chances of winning the argument ;-). >> Issue #5: >> >> Ken (in a private message) has suggested to extend "body" test >> instead of introducing a new "extract_text" test. Opinions? > In order to make some progress on this issue, here is how the updated body test can look like: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM] [BODY-EXTRACT] where BODY-TRANSFORM is defined as (section 4 of draft-ietf-sieve-body-05.txt): ":raw" / ":content" / ":text" I've added BODY-EXTRACT: :extract_none / :extract_whole / :extract_first number :extract_none is the default, i.e. if the variables extension is present, then the match variables ${1}, ${2}, ... are not set as a side effect of successful matching; :extract_first will truncate the current body part after bytes and will set the match variables. :extract_whole will set the match variable, without performing any truncation. >> Issue #6: >> >> Arnt wants to be able to do "send notification over XMPP, if can be >> delivered immediately. Otherwise send it over SMS". >> This issue needs further discussion. > Aaron replied that he likes the idea. Anybody else? Arnt has suggested that the notify action should take multiple :method parameters. As tagged parameters can't be specified multiple times in the same test (3028bis, section 2.6), this will mean changing the :method parameter to be a string list. Other alternative are: 1). Add a test to check if a notification method (specified as an URI) can deliver the notification immediately. IMHO, I like this a bit better than Arnt's proposal, as it is easier to implement and the resulting script is going to be easier to read. 2). Keep the existing syntax. A new "stackable" notification method can be specified that will perform the desired functionality. Opinions? ======= + A new issues (# 8): the Sieve notify document needs to describe what should happen if a parameter specified in two ways in the same notify call: as a notify action parameter and as an URI parameter to the method parameter, for example: notify :method "xmpp:tim@example.com?message;subject=SIEVE" :message "You got mail"; (assume for a moment that the content of the :message gets translated into the subject of the resulting notification) Options suggested so far: 1). URI parameters are always ignored 2). URI parameters (if any) override the corresponding notify parameters 3). the notify parameters override the corresponding URI parameters 4). specify both the notify and the URI parameters is an error. Opinions? From owner-ietf-mta-filters Sat Jan 27 14:06:51 2007 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 l0RL6pO9031801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jan 2007 14:06:51 -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 l0RL6p9J031800; Sat, 27 Jan 2007 14:06:51 -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.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0RL6nal031789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 27 Jan 2007 14:06:51 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1HAul6-0005Et-8l; Sat, 27 Jan 2007 22:06:48 +0100 Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l0RL6mhx010883 for ; Sat, 27 Jan 2007 21:06:48 GMT Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l0RL6m4R010876 for ietf-mta-filters@imc.org; Sat, 27 Jan 2007 22:06:48 +0100 X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to Dilyan.Palauzov@aegee.org using -f Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Sat, 27 Jan 2007 22:06:48 +0100 Message-ID: <20070127220648.ufdeeeu4socwwgss@mail.aegee.org> Date: Sat, 27 Jan 2007 22:06:48 +0100 From: Dilyan Palauzov To: ietf-mta-filters@imc.org Subject: the notify issues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Virus-Scanned: ClamAV 0.88.7/2493/Fri Jan 26 12:00:46 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0RL6pak031795 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, > Issue #3: :message vs :subject I am for 4). notify should have both :message and :subject > Issue #6 > "send notification over XMPP, if can be delivered immediately. > Otherwise send it over SMS" I am in favour of: 1). Add a test to check if a notification method (specified as an URI) can deliver the notification immediately. 1) Add a test to check if a notification method (specified as an URI) HAS delieverED the notification immediately. Expanations: for sending an SMS, or mail it cannot be said if the message can be delivered immediately, as it depends on many things, and even if a notification can be delivered during the test, this does not mean that it is delivered delivered immediately at a later point, when the notification is send. On the other side, if an SMS of mail is send, an acknowledgement can be requested, that the notification is read/delivered. Naturally, this will mean that the interpreter has to stop for certain time, like 10s, and wait for the acknowledgement. 2). Keep the existing syntax. A new "stackable" notification method can be specified that will perform the desired functionality. I do not get what means "stackable notification". > Issue #4, expire: Let's add to Section 3 Notify Action Usage: notify ":method" string [":from" string] [":importance" <"1" / "2" / "3">] [":options" string-list] [":message" string] * [":expire" number] * Section 3.7 Notify tag ":expire" * * If there are errors sending the notification, the parameter of the :expire tag sets for how long in seconds shall it be retried to deliver the notification. If the notification cannot be delivered within the time, it can be discarded. Missing ":expire" leaves up to the implementation to set up some reasonable defaults. * A value of 0 (zero) means that delivering the message shall not be retried. And add an example to the current 3.7 -- Does somebody know a standard, or part of it, to specify time period, but not date? In this way the seconds can be replaced with something easier to write. # Issue #8, having both content in both :method and :message -- I like: 3). the notify parameters override the corresponding URI parameters Or 4). specify both the notify and the URI parameters is an error... ... if they lead to generation of different notification. (it is not an error, if the :message and ?message define the same ) But 3 is more fault-tolerant. And final suggestion: Notifications SHOULD includes means to identify/track its origin, in order ***Notifications SHOULD include means to track its origin, in order to allow a recipient to stop notifications or find out how to contact the sender. This requirement is to help tracking a misconfigured or abusive origin of notifications. Greetings, Dilian From owner-ietf-mta-filters Mon Jan 29 07:10:55 2007 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 l0TEAtpj063031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 07:10: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 l0TEAtBU063030; Mon, 29 Jan 2007 07:10: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.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0TEAsov063019 for ; Mon, 29 Jan 2007 07:10:55 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 32c7197bd748b7a45a4d9dbb8c597941 X-Spam-Score-Summary: 2,0,0,df2b949bc9de515b,0f86fb8d6d24f8a7,nigel.swinson@rockliffe.com,,RULES_HIT:355:379:481:539:540:541:542:543:567:599:601:945:946:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1542:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2196:2198:2199:2200:2379:2393:2559:2562:2693:2737:2828:3027:3355:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4605:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 29 Jan 2007 06:10:42 -0800 Message-ID: <00cb01c743af$5bac3a20$0202fea9@nigelhome> From: "Nigel Swinson" To: "Alexey Melnikov" Cc: References: <45AFDB20.2030703@isode.com> <45AFE9DE.6040005@isode.com> <45BB8AC8.1000600@isode.com> Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt Date: Mon, 29 Jan 2007 14:11:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0TEAtov063025 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >> :subject versa :message. Aaron, Dilyan in favor of adding :subject. > >> Michael wants to keep using :message. > > > I need to poll people on this, as I don't hear a clear consensus on > this. Please pick one of the following: > > 3). I don't care whether we have :message or :subject, but we should > have only one of them. Option 3, or better still, make it a positional argument, ie the last argument. :o) > >> Issue #4: > >> > >> Dilyan suggested to add "expiration" parameter/option to the notify > >> action. While I see some utility in this option, I am reluctant to > >> extend the document so late in the game, unless there is strong > >> support from the WG. I would recommend to add this option in a > >> separate document. Opinions? > > > I've heard a couple of voices for this feature, but no rough consensus yet. > > Hint for people who want this functionality: please provide some text > for inclusion into the document. This will improve your chances of > winning the argument ;-). I'm not interested in this, it sounds like an unnecessary layer of complexity based on the premise that the transport is frequently unreliable. It sounds to me like a feature more useful on the client that receives the notifications to filter (perhaps using sieve) out the "old" notifications and bin them. > >> Issue #5: > >> > >> Ken (in a private message) has suggested to extend "body" test > >> instead of introducing a new "extract_text" test. Opinions? I agree. > >> Issue #6: > >> > >> Arnt wants to be able to do "send notification over XMPP, if can be > >> delivered immediately. Otherwise send it over SMS". > >> This issue needs further discussion. > > > Aaron replied that he likes the idea. Anybody else? > > Other alternative are: > 1). Add a test to check if a notification method (specified as an URI) > can deliver the notification immediately. > > Opinions? I have a hesitant preference for a test to check the capabilites of a notification method. Perhaps a set of variables in a namespace. > ======= > + A new issues (# 8): the Sieve notify document needs to describe what > should happen if a parameter specified in two ways in the same notify > call: as a notify action parameter and as an URI parameter to the method > parameter, for example: > > notify :method "xmpp:tim@example.com?message;subject=SIEVE" > :message "You got mail"; > > (assume for a moment that the content of the :message gets translated > into the subject of the resulting notification) > > Options suggested so far: > 4). specify both the notify and the URI parameters is an error. Option 4. Preferably parse time error. Nigel From owner-ietf-mta-filters Mon Jan 29 07:14:05 2007 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 l0TEE5mK063523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 07:14:05 -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 l0TEE5KW063522; Mon, 29 Jan 2007 07:14:05 -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.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0TEE5Dd063516 for ; Mon, 29 Jan 2007 07:14:05 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 2e98e97b3366143eb06f93b6e6389f1f X-Spam-Score-Summary: 2,0,0,d403c76506bcdc09,cc0db37ab101e937,nigel.swinson@rockliffe.com,,RULES_HIT:152:355:379:539:540:541:542:543:567:599:601:945:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1537:1560:1587:1593:1594:1676:1711:1714:1730:1747:1766:1792:2073:2075:2078:2393:2525:2559:2563:2682:2685:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3865:3866:3867:3869:3870:3872:3934:3936:3938:3941:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: utf-8 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 29 Jan 2007 06:14:03 -0800 Message-ID: <00d301c743af$d4939cd0$0202fea9@nigelhome> From: "Nigel Swinson" To: "Dilyan Palauzov" Cc: References: <20070127220648.ufdeeeu4socwwgss@mail.aegee.org> Subject: Re: the notify issues Date: Mon, 29 Jan 2007 14:14:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0TEE5Dd063517 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -- Does somebody know a standard, or part of it, to specify time > period, but not date? In this way the seconds can be replaced with > something easier to write. See iCalendar: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.3.6 Nigel From owner-ietf-mta-filters Mon Jan 29 11:36:56 2007 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 l0TIau00084455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 11:36: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 l0TIauK2084454; Mon, 29 Jan 2007 11:36:56 -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 (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0TIaspY084448 for ; Mon, 29 Jan 2007 11:36:54 -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 <01MCHYGC2RY800A7NA@mauve.mrochek.com> for ietf-mta-filters@imc.org; Mon, 29 Jan 2007 10:36:49 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1170095807; h=Date: From:Subject:MIME-version:Content-type; b=m+PZIXaLUj/zxUc2cssUCdTLw X9Z93G33wBHA6kN4PwEenhXJ7QcyKgcA+6ON3QZL6tYouajqzIyRXCAe4q4fg== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MCFODIBWCW00005H@mauve.mrochek.com>; Mon, 29 Jan 2007 10:36:43 -0800 (PST) Cc: Alexey Melnikov , Lisa Dusseault , ietf-mta-filters@imc.org Message-id: <01MCHYG9BPY400005H@mauve.mrochek.com> Date: Mon, 29 Jan 2007 09:51:25 -0800 (PST) From: Ned Freed Subject: Re: retrying to send notifications In-reply-to: "Your message dated Mon, 22 Jan 2007 15:28:26 +0100" <20070122152826.j1kjv56roso0wskg@mail.aegee.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8; DelSp=Yes; format=flowed References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> <20070122152826.j1kjv56roso0wskg@mail.aegee.org> To: Dilyan Palauzov Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Hello, > > SHOULD ignore the notification and not retry indefinitely. > means that the notification service is unreliable: Not only are some notification services unreliable, some, including some SMS variants, provide no way to determine if the notification was ever delivered. > if an SMS is to be > sentfrom the mail server to an sms gateway, and there is a temporary > problem, the suggestion sais that it shall not be retired. But the > user may rely on receiving the notifications. If so the more fool they. I'm sorry, the issue of end users placing unwarranted faith in inherently unreliable services is not a problem we should, or can, be trying to solve here. I will also point out that no amount of retrying will get a notification through when the end device is switched off or otherwise unable to receive the notification. In fact retrying too often will in quite a few cases cause overall service reliability to drop precipitously. > What about including expire: parameter and saying that the > implementation shall not try after the message has expired (thus > removing indefinetely)? Exactly what is an implementation supposed to do with such a parameter? Even in the very restricted subcase of SMS, there are many possible implementation approaches. For example, an obvious way for an email system to send a notification to SMS is through an email gateway. This would presumably leverage the existing queuing capabilites of the email system. The expire parameter could in theory be respected by the email system, but once the notification is passed through the gateway to SMS there may or may not be a way to pass the parameter on to the other side. And if a receipt is requested (assuming the email gateway even supports making such a request), the task of coordinating that receipt to the original request goes far beyond anything most implementations are likely to want to do. As another example, suppose the sieve implementation is prepared to speak SMPP to an SMSC. For some types of messages you can specify stuff like number of retries or expiration date. But not for others, including what SMS calls notifications. (I'm actually not entirely sure whether it makes sense for a sieve notify to generate an SMS notification, but it certainly sounds reasonable.) You can also ask for a delivery receipt, but now you're back to the receipt correlation problem. (You can also poll using the SMS query primitive, but this is frowned upon.) The elephant in the corner in all this is the need for one or more additional queues. System admins don't like queues - every one we require implementations to have is another thing they have to continuously monitor, which in turn increases operational costs. Further exacerbating the problem is when the queue has a different format or interface than existing queues on the system, requiring different/additional tools, training, etc. (This last is why leveraging an existing email gateway to SMS, even one with limited capabilities, may prove to be a lot more popular than people might initially believe.) And this is just SMS. There are all sorts of other ways to send notifications, each with its own peculiarities. The bottom line is that while I would have no problem with defining such a parameter, we realistically cannot mandate that implementations actually support it if we define it. And this will be true even if the underlying notification service supports expiration dates, or retries, or whatever. And saying MUST or SHALL isn't going to help: All it will do is force some implementations into incomliance, which IMO is a bad thing. Ned P.S. I should also mention that since our implementation has full a SMPP implementation that leverages our existing queuing facilities we probably won't have a problem implementing this, in the SMS case at least. But I suspect we're an unusual case. From owner-ietf-mta-filters Mon Jan 29 13:43:38 2007 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 l0TKhbY1006692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 13:43: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 l0TKhbJE006691; Mon, 29 Jan 2007 13:43: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 mauve.mrochek.com (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0TKha6I006683 for ; Mon, 29 Jan 2007 13:43:37 -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 <01MCI2VHFMK0008JLT@mauve.mrochek.com> for ietf-mta-filters@imc.org; Mon, 29 Jan 2007 12:43:33 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1170103412; h=Date: From:Subject:MIME-version:Content-type; b=R8jm/XbWqaYl8R8cfSxFWOPVf 1rIo6uxXN1tmFmlR5zaKWTRNkPhzibYyFM6qV/TS0n4mI++QthC0VCUESrAGA== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MCFODIBWCW00005H@mauve.mrochek.com>; Mon, 29 Jan 2007 12:43:30 -0800 (PST) Cc: Alexey Melnikov , ietf-mta-filters@imc.org Message-id: <01MCI2VGBOBM00005H@mauve.mrochek.com> Date: Mon, 29 Jan 2007 12:04:05 -0800 (PST) From: Ned Freed Subject: Re: WGLC for Sieve Notify has ended In-reply-to: "Your message dated Fri, 26 Jan 2007 13:29:50 -0800" <2592D3D3-A9A3-4505-8FE3-857ADE1C542B@osafoundation.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; delsp=yes; format=flowed References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> <2592D3D3-A9A3-4505-8FE3-857ADE1C542B@osafoundation.org> To: Lisa Dusseault Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Here is the text I've added (taken from the vacation draft and > > reworded): > > In order to minimize/prevent forgery of the author value, > > implementations MAY impose restrictions on what values can specified > > in a ":from" parameter; it is suggested that values which fail > > such a validity check simply be ignored rather than causing > > the notify action to fail. > > Do you want to upgrade the MAY to SHOULD? > My individual opinion would be for a SHOULD but I'm not sure what > other considerations hold. It seems to me that SHOULD has the right semantics here. Of course there are plenty of other considerations, including situations where validity cannot be accessed, notification mechanisms that either don't have the concept of an author or which embody it as something other than an email address. But SHOULD provides enough leeway that such cases can be dealt with without incompliance. > > > - If the recipient of a sieve notify mail doesn't want those > > > notifications, what recourse do they have? > > I think this problem is already present in email. > Yes, obviously. But I wonder how often notifications will be sent > from a system address for simplicity. E.g. all notifications might > come from "notification@example.com" for the IMAP server for > example.com, regardless of whose SIEVE rule generated the > notification. Then it becomes harder for the recipient to filter > which notifications they do and don't want, and a little different > from ordinary email. Some time back we introduced the idea of an "owner email address" in our sieve implementation to deal with this and related issues. However, there are also cases where you cannot use such an address even if you have it: One such is when the notification relates to a message arriving inside of a highly secure environment. We have customers using notify in such cases to inform some outside address that they need to check their secure mail, and one of the rules is that the notification has to come from a generic address - not even the recipient's address can be exposed. (My assumption is that sometimes the address of a recipient conveys some information as to what the person does, and revealing that is a no-no. Or maybe they's no real risk and they're being paranoid. Whatever - rules is rules.) > > > Servers SHOULD add a "cancel" link to each notify mail... ? > > How about the following text (I've reworded and extended Dilyan's > > proposal): > > Notifications SHOULD includes means to identify/track its origin, in order > > to allow a recipient to stop notifications or find out how to contact the sender. > > This requirement is to help tracking a misconfigured or abusive origin of > > notifications. > > > > ? > Yes, and I think this addresses my above concern. This seems reasonable to me as well. Ned From owner-ietf-mta-filters Mon Jan 29 13:49:33 2007 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 l0TKnXau007304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 13:49:33 -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 l0TKnXwC007303; Mon, 29 Jan 2007 13:49:33 -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 l0TKnU8r007294 for ; Mon, 29 Jan 2007 13:49:32 -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 ; Mon, 29 Jan 2007 20:49:26 +0000 Message-ID: <45BE5DC2.6030103@isode.com> Date: Mon, 29 Jan 2007 20:49:06 +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: Ned Freed CC: Lisa Dusseault , ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> <2592D3D3-A9A3-4505-8FE3-857ADE1C542B@osafoundation.org> <01MCI2VGBOBM00005H@mauve.mrochek.com> In-Reply-To: <01MCI2VGBOBM00005H@mauve.mrochek.com> 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: Ned Freed wrote: >> > Here is the text I've added (taken from the vacation draft and >> > reworded): > >> > In order to minimize/prevent forgery of the author value, >> > implementations MAY impose restrictions on what values can >> specified >> > in a ":from" parameter; it is suggested that values which fail >> > such a validity check simply be ignored rather than causing >> > the notify action to fail. > >> > Do you want to upgrade the MAY to SHOULD? > >> My individual opinion would be for a SHOULD but I'm not sure what >> other considerations hold. > > It seems to me that SHOULD has the right semantics here. Of course > there are > plenty of other considerations, including situations where validity > cannot be > accessed, notification mechanisms that either don't have the concept > of an > author or which embody it as something other than an email address. > But SHOULD > provides enough leeway that such cases can be dealt with without > incompliance. Ok, I've changed MAY to SHOULD in my copy. 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 l0TKnXau007304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 13:49:33 -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 l0TKnXwC007303; Mon, 29 Jan 2007 13:49:33 -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 l0TKnU8r007294 for ; Mon, 29 Jan 2007 13:49:32 -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 ; Mon, 29 Jan 2007 20:49:26 +0000 Message-ID: <45BE5DC2.6030103@isode.com> Date: Mon, 29 Jan 2007 20:49:06 +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: Ned Freed CC: Lisa Dusseault , ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> <2592D3D3-A9A3-4505-8FE3-857ADE1C542B@osafoundation.org> <01MCI2VGBOBM00005H@mauve.mrochek.com> In-Reply-To: <01MCI2VGBOBM00005H@mauve.mrochek.com> 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: Ned Freed wrote: >> > Here is the text I've added (taken from the vacation draft and >> > reworded): > >> > In order to minimize/prevent forgery of the author value, >> > implementations MAY impose restrictions on what values can >> specified >> > in a ":from" parameter; it is suggested that values which fail >> > such a validity check simply be ignored rather than causing >> > the notify action to fail. > >> > Do you want to upgrade the MAY to SHOULD? > >> My individual opinion would be for a SHOULD but I'm not sure what >> other considerations hold. > > It seems to me that SHOULD has the right semantics here. Of course > there are > plenty of other considerations, including situations where validity > cannot be > accessed, notification mechanisms that either don't have the concept > of an > author or which embody it as something other than an email address. > But SHOULD > provides enough leeway that such cases can be dealt with without > incompliance. Ok, I've changed MAY to SHOULD in my copy. 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 l0TKhbY1006692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 13:43: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 l0TKhbJE006691; Mon, 29 Jan 2007 13:43: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 mauve.mrochek.com (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0TKha6I006683 for ; Mon, 29 Jan 2007 13:43:37 -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 <01MCI2VHFMK0008JLT@mauve.mrochek.com> for ietf-mta-filters@imc.org; Mon, 29 Jan 2007 12:43:33 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1170103412; h=Date: From:Subject:MIME-version:Content-type; b=R8jm/XbWqaYl8R8cfSxFWOPVf 1rIo6uxXN1tmFmlR5zaKWTRNkPhzibYyFM6qV/TS0n4mI++QthC0VCUESrAGA== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MCFODIBWCW00005H@mauve.mrochek.com>; Mon, 29 Jan 2007 12:43:30 -0800 (PST) Cc: Alexey Melnikov , ietf-mta-filters@imc.org Message-id: <01MCI2VGBOBM00005H@mauve.mrochek.com> Date: Mon, 29 Jan 2007 12:04:05 -0800 (PST) From: Ned Freed Subject: Re: WGLC for Sieve Notify has ended In-reply-to: "Your message dated Fri, 26 Jan 2007 13:29:50 -0800" <2592D3D3-A9A3-4505-8FE3-857ADE1C542B@osafoundation.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; delsp=yes; format=flowed References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> <2592D3D3-A9A3-4505-8FE3-857ADE1C542B@osafoundation.org> To: Lisa Dusseault Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Here is the text I've added (taken from the vacation draft and > > reworded): > > In order to minimize/prevent forgery of the author value, > > implementations MAY impose restrictions on what values can specified > > in a ":from" parameter; it is suggested that values which fail > > such a validity check simply be ignored rather than causing > > the notify action to fail. > > Do you want to upgrade the MAY to SHOULD? > My individual opinion would be for a SHOULD but I'm not sure what > other considerations hold. It seems to me that SHOULD has the right semantics here. Of course there are plenty of other considerations, including situations where validity cannot be accessed, notification mechanisms that either don't have the concept of an author or which embody it as something other than an email address. But SHOULD provides enough leeway that such cases can be dealt with without incompliance. > > > - If the recipient of a sieve notify mail doesn't want those > > > notifications, what recourse do they have? > > I think this problem is already present in email. > Yes, obviously. But I wonder how often notifications will be sent > from a system address for simplicity. E.g. all notifications might > come from "notification@example.com" for the IMAP server for > example.com, regardless of whose SIEVE rule generated the > notification. Then it becomes harder for the recipient to filter > which notifications they do and don't want, and a little different > from ordinary email. Some time back we introduced the idea of an "owner email address" in our sieve implementation to deal with this and related issues. However, there are also cases where you cannot use such an address even if you have it: One such is when the notification relates to a message arriving inside of a highly secure environment. We have customers using notify in such cases to inform some outside address that they need to check their secure mail, and one of the rules is that the notification has to come from a generic address - not even the recipient's address can be exposed. (My assumption is that sometimes the address of a recipient conveys some information as to what the person does, and revealing that is a no-no. Or maybe they's no real risk and they're being paranoid. Whatever - rules is rules.) > > > Servers SHOULD add a "cancel" link to each notify mail... ? > > How about the following text (I've reworded and extended Dilyan's > > proposal): > > Notifications SHOULD includes means to identify/track its origin, in order > > to allow a recipient to stop notifications or find out how to contact the sender. > > This requirement is to help tracking a misconfigured or abusive origin of > > notifications. > > > > ? > Yes, and I think this addresses my above concern. This seems reasonable to me as well. Ned 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 l0TIau00084455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 11:36: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 l0TIauK2084454; Mon, 29 Jan 2007 11:36:56 -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 (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0TIaspY084448 for ; Mon, 29 Jan 2007 11:36:54 -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 <01MCHYGC2RY800A7NA@mauve.mrochek.com> for ietf-mta-filters@imc.org; Mon, 29 Jan 2007 10:36:49 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1170095807; h=Date: From:Subject:MIME-version:Content-type; b=m+PZIXaLUj/zxUc2cssUCdTLw X9Z93G33wBHA6kN4PwEenhXJ7QcyKgcA+6ON3QZL6tYouajqzIyRXCAe4q4fg== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MCFODIBWCW00005H@mauve.mrochek.com>; Mon, 29 Jan 2007 10:36:43 -0800 (PST) Cc: Alexey Melnikov , Lisa Dusseault , ietf-mta-filters@imc.org Message-id: <01MCHYG9BPY400005H@mauve.mrochek.com> Date: Mon, 29 Jan 2007 09:51:25 -0800 (PST) From: Ned Freed Subject: Re: retrying to send notifications In-reply-to: "Your message dated Mon, 22 Jan 2007 15:28:26 +0100" <20070122152826.j1kjv56roso0wskg@mail.aegee.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8; DelSp=Yes; format=flowed References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> <20070122152826.j1kjv56roso0wskg@mail.aegee.org> To: Dilyan Palauzov Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Hello, > > SHOULD ignore the notification and not retry indefinitely. > means that the notification service is unreliable: Not only are some notification services unreliable, some, including some SMS variants, provide no way to determine if the notification was ever delivered. > if an SMS is to be > sentfrom the mail server to an sms gateway, and there is a temporary > problem, the suggestion sais that it shall not be retired. But the > user may rely on receiving the notifications. If so the more fool they. I'm sorry, the issue of end users placing unwarranted faith in inherently unreliable services is not a problem we should, or can, be trying to solve here. I will also point out that no amount of retrying will get a notification through when the end device is switched off or otherwise unable to receive the notification. In fact retrying too often will in quite a few cases cause overall service reliability to drop precipitously. > What about including expire: parameter and saying that the > implementation shall not try after the message has expired (thus > removing indefinetely)? Exactly what is an implementation supposed to do with such a parameter? Even in the very restricted subcase of SMS, there are many possible implementation approaches. For example, an obvious way for an email system to send a notification to SMS is through an email gateway. This would presumably leverage the existing queuing capabilites of the email system. The expire parameter could in theory be respected by the email system, but once the notification is passed through the gateway to SMS there may or may not be a way to pass the parameter on to the other side. And if a receipt is requested (assuming the email gateway even supports making such a request), the task of coordinating that receipt to the original request goes far beyond anything most implementations are likely to want to do. As another example, suppose the sieve implementation is prepared to speak SMPP to an SMSC. For some types of messages you can specify stuff like number of retries or expiration date. But not for others, including what SMS calls notifications. (I'm actually not entirely sure whether it makes sense for a sieve notify to generate an SMS notification, but it certainly sounds reasonable.) You can also ask for a delivery receipt, but now you're back to the receipt correlation problem. (You can also poll using the SMS query primitive, but this is frowned upon.) The elephant in the corner in all this is the need for one or more additional queues. System admins don't like queues - every one we require implementations to have is another thing they have to continuously monitor, which in turn increases operational costs. Further exacerbating the problem is when the queue has a different format or interface than existing queues on the system, requiring different/additional tools, training, etc. (This last is why leveraging an existing email gateway to SMS, even one with limited capabilities, may prove to be a lot more popular than people might initially believe.) And this is just SMS. There are all sorts of other ways to send notifications, each with its own peculiarities. The bottom line is that while I would have no problem with defining such a parameter, we realistically cannot mandate that implementations actually support it if we define it. And this will be true even if the underlying notification service supports expiration dates, or retries, or whatever. And saying MUST or SHALL isn't going to help: All it will do is force some implementations into incomliance, which IMO is a bad thing. Ned P.S. I should also mention that since our implementation has full a SMPP implementation that leverages our existing queuing facilities we probably won't have a problem implementing this, in the SMS case at least. But I suspect we're an unusual case. 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 l0TEE5mK063523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 07:14:05 -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 l0TEE5KW063522; Mon, 29 Jan 2007 07:14:05 -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.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0TEE5Dd063516 for ; Mon, 29 Jan 2007 07:14:05 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 2e98e97b3366143eb06f93b6e6389f1f X-Spam-Score-Summary: 2,0,0,d403c76506bcdc09,cc0db37ab101e937,nigel.swinson@rockliffe.com,,RULES_HIT:152:355:379:539:540:541:542:543:567:599:601:945:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1537:1560:1587:1593:1594:1676:1711:1714:1730:1747:1766:1792:2073:2075:2078:2393:2525:2559:2563:2682:2685:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3865:3866:3867:3869:3870:3872:3934:3936:3938:3941:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: utf-8 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 29 Jan 2007 06:14:03 -0800 Message-ID: <00d301c743af$d4939cd0$0202fea9@nigelhome> From: "Nigel Swinson" To: "Dilyan Palauzov" Cc: References: <20070127220648.ufdeeeu4socwwgss@mail.aegee.org> Subject: Re: the notify issues Date: Mon, 29 Jan 2007 14:14:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0TEE5Dd063517 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -- Does somebody know a standard, or part of it, to specify time > period, but not date? In this way the seconds can be replaced with > something easier to write. See iCalendar: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.3.6 Nigel 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 l0TEAtpj063031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 07:10: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 l0TEAtBU063030; Mon, 29 Jan 2007 07:10: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.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0TEAsov063019 for ; Mon, 29 Jan 2007 07:10:55 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 32c7197bd748b7a45a4d9dbb8c597941 X-Spam-Score-Summary: 2,0,0,df2b949bc9de515b,0f86fb8d6d24f8a7,nigel.swinson@rockliffe.com,,RULES_HIT:355:379:481:539:540:541:542:543:567:599:601:945:946:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1542:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2196:2198:2199:2200:2379:2393:2559:2562:2693:2737:2828:3027:3355:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4605:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 29 Jan 2007 06:10:42 -0800 Message-ID: <00cb01c743af$5bac3a20$0202fea9@nigelhome> From: "Nigel Swinson" To: "Alexey Melnikov" Cc: References: <45AFDB20.2030703@isode.com> <45AFE9DE.6040005@isode.com> <45BB8AC8.1000600@isode.com> Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt Date: Mon, 29 Jan 2007 14:11:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0TEAtov063025 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >> :subject versa :message. Aaron, Dilyan in favor of adding :subject. > >> Michael wants to keep using :message. > > > I need to poll people on this, as I don't hear a clear consensus on > this. Please pick one of the following: > > 3). I don't care whether we have :message or :subject, but we should > have only one of them. Option 3, or better still, make it a positional argument, ie the last argument. :o) > >> Issue #4: > >> > >> Dilyan suggested to add "expiration" parameter/option to the notify > >> action. While I see some utility in this option, I am reluctant to > >> extend the document so late in the game, unless there is strong > >> support from the WG. I would recommend to add this option in a > >> separate document. Opinions? > > > I've heard a couple of voices for this feature, but no rough consensus yet. > > Hint for people who want this functionality: please provide some text > for inclusion into the document. This will improve your chances of > winning the argument ;-). I'm not interested in this, it sounds like an unnecessary layer of complexity based on the premise that the transport is frequently unreliable. It sounds to me like a feature more useful on the client that receives the notifications to filter (perhaps using sieve) out the "old" notifications and bin them. > >> Issue #5: > >> > >> Ken (in a private message) has suggested to extend "body" test > >> instead of introducing a new "extract_text" test. Opinions? I agree. > >> Issue #6: > >> > >> Arnt wants to be able to do "send notification over XMPP, if can be > >> delivered immediately. Otherwise send it over SMS". > >> This issue needs further discussion. > > > Aaron replied that he likes the idea. Anybody else? > > Other alternative are: > 1). Add a test to check if a notification method (specified as an URI) > can deliver the notification immediately. > > Opinions? I have a hesitant preference for a test to check the capabilites of a notification method. Perhaps a set of variables in a namespace. > ======= > + A new issues (# 8): the Sieve notify document needs to describe what > should happen if a parameter specified in two ways in the same notify > call: as a notify action parameter and as an URI parameter to the method > parameter, for example: > > notify :method "xmpp:tim@example.com?message;subject=SIEVE" > :message "You got mail"; > > (assume for a moment that the content of the :message gets translated > into the subject of the resulting notification) > > Options suggested so far: > 4). specify both the notify and the URI parameters is an error. Option 4. Preferably parse time error. Nigel 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 l0RL6pO9031801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jan 2007 14:06:51 -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 l0RL6p9J031800; Sat, 27 Jan 2007 14:06:51 -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.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0RL6nal031789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 27 Jan 2007 14:06:51 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1HAul6-0005Et-8l; Sat, 27 Jan 2007 22:06:48 +0100 Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l0RL6mhx010883 for ; Sat, 27 Jan 2007 21:06:48 GMT Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l0RL6m4R010876 for ietf-mta-filters@imc.org; Sat, 27 Jan 2007 22:06:48 +0100 X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to Dilyan.Palauzov@aegee.org using -f Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Sat, 27 Jan 2007 22:06:48 +0100 Message-ID: <20070127220648.ufdeeeu4socwwgss@mail.aegee.org> Date: Sat, 27 Jan 2007 22:06:48 +0100 From: Dilyan Palauzov To: ietf-mta-filters@imc.org Subject: the notify issues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Virus-Scanned: ClamAV 0.88.7/2493/Fri Jan 26 12:00:46 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0RL6pak031795 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, > Issue #3: :message vs :subject I am for 4). notify should have both :message and :subject > Issue #6 > "send notification over XMPP, if can be delivered immediately. > Otherwise send it over SMS" I am in favour of: 1). Add a test to check if a notification method (specified as an URI) can deliver the notification immediately. 1) Add a test to check if a notification method (specified as an URI) HAS delieverED the notification immediately. Expanations: for sending an SMS, or mail it cannot be said if the message can be delivered immediately, as it depends on many things, and even if a notification can be delivered during the test, this does not mean that it is delivered delivered immediately at a later point, when the notification is send. On the other side, if an SMS of mail is send, an acknowledgement can be requested, that the notification is read/delivered. Naturally, this will mean that the interpreter has to stop for certain time, like 10s, and wait for the acknowledgement. 2). Keep the existing syntax. A new "stackable" notification method can be specified that will perform the desired functionality. I do not get what means "stackable notification". > Issue #4, expire: Let's add to Section 3 Notify Action Usage: notify ":method" string [":from" string] [":importance" <"1" / "2" / "3">] [":options" string-list] [":message" string] * [":expire" number] * Section 3.7 Notify tag ":expire" * * If there are errors sending the notification, the parameter of the :expire tag sets for how long in seconds shall it be retried to deliver the notification. If the notification cannot be delivered within the time, it can be discarded. Missing ":expire" leaves up to the implementation to set up some reasonable defaults. * A value of 0 (zero) means that delivering the message shall not be retried. And add an example to the current 3.7 -- Does somebody know a standard, or part of it, to specify time period, but not date? In this way the seconds can be replaced with something easier to write. # Issue #8, having both content in both :method and :message -- I like: 3). the notify parameters override the corresponding URI parameters Or 4). specify both the notify and the URI parameters is an error... ... if they lead to generation of different notification. (it is not an error, if the :message and ?message define the same ) But 3 is more fault-tolerant. And final suggestion: Notifications SHOULD includes means to identify/track its origin, in order ***Notifications SHOULD include means to track its origin, in order to allow a recipient to stop notifications or find out how to contact the sender. This requirement is to help tracking a misconfigured or abusive origin of notifications. Greetings, Dilian 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 l0RIqv8X020722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jan 2007 11:52:57 -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 l0RIqvxw020720; Sat, 27 Jan 2007 11:52:57 -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 l0RIqsnT020703 for ; Sat, 27 Jan 2007 11:52:57 -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 ; Sat, 27 Jan 2007 18:52:52 +0000 Message-ID: <45BB8AC8.1000600@isode.com> Date: Sat, 27 Jan 2007 17:24:24 +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@imc.org Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <45AFDB20.2030703@isode.com> <45AFE9DE.6040005@isode.com> In-Reply-To: <45AFE9DE.6040005@isode.com> 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: Alexey Melnikov wrote: >> Issue #3: >> >> :subject versa :message. Aaron, Dilyan in favor of adding :subject. >> Michael wants to keep using :message. > I need to poll people on this, as I don't hear a clear consensus on this. Please pick one of the following: 1). keep the existing :message (it may or may not map to email Subject:, this is a separate issue at this point) 2). rename existing :message to :subject 3). I don't care whether we have :message or :subject, but we should have only one of them. 4). notify should have both :message and :subject Let me know your opinion or if I've missed some choice. >> Issue #4: >> >> Dilyan suggested to add "expiration" parameter/option to the notify >> action. While I see some utility in this option, I am reluctant to >> extend the document so late in the game, unless there is strong >> support from the WG. I would recommend to add this option in a >> separate document. Opinions? > I've heard a couple of voices for this feature, but no rough consensus yet. Hint for people who want this functionality: please provide some text for inclusion into the document. This will improve your chances of winning the argument ;-). >> Issue #5: >> >> Ken (in a private message) has suggested to extend "body" test >> instead of introducing a new "extract_text" test. Opinions? > In order to make some progress on this issue, here is how the updated body test can look like: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM] [BODY-EXTRACT] where BODY-TRANSFORM is defined as (section 4 of draft-ietf-sieve-body-05.txt): ":raw" / ":content" / ":text" I've added BODY-EXTRACT: :extract_none / :extract_whole / :extract_first number :extract_none is the default, i.e. if the variables extension is present, then the match variables ${1}, ${2}, ... are not set as a side effect of successful matching; :extract_first will truncate the current body part after bytes and will set the match variables. :extract_whole will set the match variable, without performing any truncation. >> Issue #6: >> >> Arnt wants to be able to do "send notification over XMPP, if can be >> delivered immediately. Otherwise send it over SMS". >> This issue needs further discussion. > Aaron replied that he likes the idea. Anybody else? Arnt has suggested that the notify action should take multiple :method parameters. As tagged parameters can't be specified multiple times in the same test (3028bis, section 2.6), this will mean changing the :method parameter to be a string list. Other alternative are: 1). Add a test to check if a notification method (specified as an URI) can deliver the notification immediately. IMHO, I like this a bit better than Arnt's proposal, as it is easier to implement and the resulting script is going to be easier to read. 2). Keep the existing syntax. A new "stackable" notification method can be specified that will perform the desired functionality. Opinions? ======= + A new issues (# 8): the Sieve notify document needs to describe what should happen if a parameter specified in two ways in the same notify call: as a notify action parameter and as an URI parameter to the method parameter, for example: notify :method "xmpp:tim@example.com?message;subject=SIEVE" :message "You got mail"; (assume for a moment that the content of the :message gets translated into the subject of the resulting notification) Options suggested so far: 1). URI parameters are always ignored 2). URI parameters (if any) override the corresponding notify parameters 3). the notify parameters override the corresponding URI parameters 4). specify both the notify and the URI parameters is an error. Opinions? 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 l0QLTsSn045148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 14:29: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 l0QLTsl5045147; Fri, 26 Jan 2007 14:29:54 -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 laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0QLTrHV045141 for ; Fri, 26 Jan 2007 14:29:54 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0338B142254; Fri, 26 Jan 2007 13:29:53 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16438-04; Fri, 26 Jan 2007 13:29:52 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 25F72142253; Fri, 26 Jan 2007 13:29:52 -0800 (PST) In-Reply-To: <45B3773B.6090201@isode.com> References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2592D3D3-A9A3-4505-8FE3-857ADE1C542B@osafoundation.org> Cc: ietf-mta-filters@imc.org Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: WGLC for Sieve Notify has ended Date: Fri, 26 Jan 2007 13:29:50 -0800 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: responses in-line... On Jan 21, 2007, at 6:22 AM, Alexey Melnikov wrote: > Lisa Dusseault wrote: > >> I think we're going to need a bit more language in the sieve- >> notify draft about sending from authorized or unauthorized from >> addresses, as well as about sending to people who do not want to >> receive notifications, and throttling. I'm not sure exactly what >> needs to be said, however. >> - Something about how implementations SHOULD restrict the >> from address to allow only appropriate mailboxes? SHOULD >> restrict the from address so that other domains aren't caused to >> be spoofed? > > Here is the text I've added (taken from the vacation draft and > reworded): > > In order to minimize/prevent forgery of the author value, > implementations MAY impose restrictions on what values can > specified > in a ":from" parameter; it is suggested that values which fail > such a validity check simply be ignored rather than causing > the notify action to fail. > > Do you want to upgrade the MAY to SHOULD? My individual opinion would be for a SHOULD but I'm not sure what other considerations hold. > >> - If the recipient of a sieve notify mail doesn't want those >> notifications, what recourse do they have? > > I think this problem is already present in email. Yes, obviously. But I wonder how often notifications will be sent from a system address for simplicity. E.g. all notifications might come from "notification@example.com" for the IMAP server for example.com, regardless of whose SIEVE rule generated the notification. Then it becomes harder for the recipient to filter which notifications they do and don't want, and a little different from ordinary email. > >> Servers SHOULD add a "cancel" link to each notify mail... ? > > How about the following text (I've reworded and extended Dilyan's > proposal): > > Notifications SHOULD includes means to identify/track its > origin, in order > to allow a recipient to stop notifications or find out how to > contact the sender. > This requirement is to help tracking a misconfigured or abusive > origin of > notifications. > > ? Yes, and I think this addresses my above concern. > >> - If the notification frequency is high, servers SHOULD >> throttle notifications (and if so what error to produce)? Disable >> the rule? > > Considering there is already some text about "not retrying > notification indefinitely", I think it would be Ok to just drop > notifications silently. > I also think that throttling should be a MAY. So how about the > following text: > > If there are errors sending the notification, the Sieve interpreter > SHOULD ignore the notification and not retry indefinitely. > The Sieve interpreter MAY throttle notifications; if it does, > a request to send a notification can be silently ignored. > Documents describing notification methods SHOULD describe how > retries, throttling, duplicate suppression (if any), etc. are > to be handled by implementations. > > ? Ok. Lisa 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 l0MESVAh019165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 07:28:31 -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 l0MESV6H019164; Mon, 22 Jan 2007 07:28:31 -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.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0MEST5I019152 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jan 2007 07:28:31 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1H909n-0001ma-6Q; Mon, 22 Jan 2007 15:28:23 +0100 Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l0MESRpu011727; Mon, 22 Jan 2007 14:28:27 GMT Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l0MESQ1H011726; Mon, 22 Jan 2007 15:28:26 +0100 X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to Dilyan.Palauzov@aegee.org using -f Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Mon, 22 Jan 2007 15:28:26 +0100 Message-ID: <20070122152826.j1kjv56roso0wskg@mail.aegee.org> Date: Mon, 22 Jan 2007 15:28:26 +0100 From: Dilyan Palauzov To: Alexey Melnikov Cc: Lisa Dusseault , ietf-mta-filters@imc.org Subject: retrying to send notifications References: <45ACB6BA.2040803@isode.com> <45B3773B.6090201@isode.com> In-Reply-To: <45B3773B.6090201@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Virus-Scanned: ClamAV 0.88.7/2476/Sun Jan 21 16:22:33 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0MESV5H019158 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, > SHOULD ignore the notification and not retry indefinitely. means that the notification service is unreliable: if an SMS is to be sentfrom the mail server to an sms gateway, and there is a temporary problem, the suggestion sais that it shall not be retired. But the user may rely on receiving the notifications. What about including expire: parameter and saying that the implementation shall not try after the message has expired (thus removing indefinetely)? Greetings, Дилян >> - If the notification frequency is high, servers SHOULD throttle >> notifications (and if so what error to produce)? Disable the rule? > > Considering there is already some text about "not retrying notification > indefinitely", I think it would be Ok to just drop notifications > silently. > I also think that throttling should be a MAY. So how about the > following text: > > If there are errors sending the notification, the Sieve interpreter > SHOULD ignore the notification and not retry indefinitely. > The Sieve interpreter MAY throttle notifications; if it does, > a request to send a notification can be silently ignored. > Documents describing notification methods SHOULD describe how > retries, throttling, duplicate suppression (if any), etc. are > to be handled by implementations. > > ? ----- End message from alexey.melnikov@isode.com ----- 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 l0MBbppK004403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 04:37:51 -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 l0MBbpas004402; Mon, 22 Jan 2007 04:37:51 -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 l0MBbhVP004358 for ; Mon, 22 Jan 2007 04:37:44 -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 ; Mon, 22 Jan 2007 11:37:42 +0000 Message-ID: <45B3773F.7000308@isode.com> Date: Sun, 21 Jan 2007 14:22: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: Dilyan Palauzov CC: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <20070118231909.om84uctk6ccok04c@mail.aegee.org> In-Reply-To: <20070118231909.om84uctk6ccok04c@mail.aegee.org> MIME-version: 1.0 Content-type: text/plain; charset="UTF-8"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dilyan Palauzov wrote: > Hello, > > Reading Lisa's mail, a new problem arized in my head: > > For every generated notification, the system administrator shall be > able to say how did it originate. Making "grep" on all scripts is not > an option, since the user might have changed the script in the > meantime, or two users might have identical scripts. > > Just imagine a user gets constantly notifications saying "you got > an email at your example.com mailbox". But the user does not have an > example.com mailbox, and moreover, he has not set up such a > script-notification. Obviously this was made by another user and when > the system administrator, on whose server the message was generated, > is informed about it, s/he shall be able to track where the problem was. > > So I suggest to add something to section > > 3.8. Requirements on notification methods specifications > > * It is RECOMMENDED that a notification includes means to > identify/track its origin. I've extended your sentence. See my reply to a Lisa's message. > But this could be understood, that a notification shall say which > server generated it, and not which user. Any ideas? Replace "origin" with "sender"? > In sec 3.8. one more sentance could be included > > * Where applicatiable, derived extensions shall support a subject: > option. This is somewhat related to the discussion about :subject versa :message. I think we need to get consensus on the subject/message issue first. 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 l0MBbjos004387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 04:37:45 -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 l0MBbj2W004386; Mon, 22 Jan 2007 04:37:45 -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 l0MBbi6u004377 for ; Mon, 22 Jan 2007 04:37:44 -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 ; Mon, 22 Jan 2007 11:37:43 +0000 Message-ID: <45B378EB.6050804@isode.com> Date: Sun, 21 Jan 2007 14:30:03 +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@imc.org Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <45AFDB20.2030703@isode.com> <45AFE9DE.6040005@isode.com> In-Reply-To: <45AFE9DE.6040005@isode.com> 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: Alexey Melnikov wrote: > Alexey Melnikov wrote: > >> Issue #1: >> >> Make tagged "method" parameter positional. (Michael, Dylan are in >> favor of the change). > > Mark E. Mallett is also in favor of this change (doesn't feel strongly) I've done this change now. >> I would welcome additional opinions on this issue. >> >> Issue #2: >> >> Michael has suggested some changes to the requirement on timestamps. >> I will discuss this offline with Michael and Barry and will suggest >> some new text. > The updated text reads: Notifications SHOULD include timestamps, if the notification method allows for their transmission outside of the textual message. Implementation methods which can only transmit timestamps in the textual message MAY include them in the textual message. [...] >> Issue #7: >> >> Lisa: controlling who can receive notifications and throttling. > I've sent some suggested text to the mailing list. >> Have I listed all issues raised so far? > > Also, several people including Mark has suggested to rename > "valid_notif_method" to "valid_notify_method". Unless I hear > otherwise, I will do that in the next revision. This change is done now. 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 l0MBbhND004351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 04:37:43 -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 l0MBbhUc004350; Mon, 22 Jan 2007 04:37:43 -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 l0MBbfaX004318 for ; Mon, 22 Jan 2007 04:37: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 ; Mon, 22 Jan 2007 11:37:41 +0000 Message-ID: <45B3773B.6090201@isode.com> Date: Sun, 21 Jan 2007 14:22:51 +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: Lisa Dusseault CC: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> In-Reply-To: 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: Lisa Dusseault wrote: > I think we're going to need a bit more language in the sieve-notify > draft about sending from authorized or unauthorized from addresses, > as well as about sending to people who do not want to receive > notifications, and throttling. I'm not sure exactly what needs to be > said, however. > - Something about how implementations SHOULD restrict the from > address to allow only appropriate mailboxes? SHOULD restrict the > from address so that other domains aren't caused to be spoofed? Here is the text I've added (taken from the vacation draft and reworded): In order to minimize/prevent forgery of the author value, implementations MAY impose restrictions on what values can specified in a ":from" parameter; it is suggested that values which fail such a validity check simply be ignored rather than causing the notify action to fail. Do you want to upgrade the MAY to SHOULD? Also, if you feel that the two examples you gave above should be specifically mentioned, I can add them to the text. > - If the recipient of a sieve notify mail doesn't want those > notifications, what recourse do they have? I think this problem is already present in email. > Servers SHOULD add a "cancel" link to each notify mail... ? How about the following text (I've reworded and extended Dilyan's proposal): Notifications SHOULD includes means to identify/track its origin, in order to allow a recipient to stop notifications or find out how to contact the sender. This requirement is to help tracking a misconfigured or abusive origin of notifications. ? > - If the notification frequency is high, servers SHOULD throttle > notifications (and if so what error to produce)? Disable the rule? Considering there is already some text about "not retrying notification indefinitely", I think it would be Ok to just drop notifications silently. I also think that throttling should be a MAY. So how about the following text: If there are errors sending the notification, the Sieve interpreter SHOULD ignore the notification and not retry indefinitely. The Sieve interpreter MAY throttle notifications; if it does, a request to send a notification can be silently ignored. Documents describing notification methods SHOULD describe how retries, throttling, duplicate suppression (if any), etc. are to be handled by implementations. ? 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 l0MBbgl2004343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 04:37: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 l0MBbg6D004342; Mon, 22 Jan 2007 04:37: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 l0MBbfaW004318 for ; Mon, 22 Jan 2007 04:37: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 ; Mon, 22 Jan 2007 11:37:40 +0000 Message-ID: <45B35EAE.7090106@isode.com> Date: Sun, 21 Jan 2007 12:38:06 +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: "Mark E. Mallett" CC: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <20070116171900.GA83498@osmium.mv.net> <20070116201945.GA37066@osmium.mv.net> In-Reply-To: <20070116201945.GA37066@osmium.mv.net> 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: Mark E. Mallett wrote: >> The Extract_text action stores at most :first bytes of the first >> text/* part in the variable identified by varname. If the :first >> parameter is not present, the whole content of the first text/* part >> is stored. >> >> >Should something be said about the upper bound? If nothing else, that >the "whole content" may not be stored because of the truncation that >happens when the variables limit is exceeded. I also think it would >help to say that implementation limits may apply. My implementation, >for example, caches in memory some minimum number of bytes of each mime >part, with any excess possibly being cached on disk. I'd happily make >what's cached in memory available, but I might be disgruntled by having >to fetch more from disk cache. (This would probably already exceed the >variables limit, but it's just an example of why an implementation might >want to have a limit.) > > I've added: In either case the actually stored data MAY be truncated to conform to implementation specific limit on variable length and/or on MIME body part length. Is this sufficient? Should we encourage implementations to have some kind of limit on body part length? 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 l0IMWut6003214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 15:32: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 l0IMWuC3003213; Thu, 18 Jan 2007 15:32:56 -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.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0IMWr2q003204 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 18 Jan 2007 15:32:55 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1H7foT-0002Pv-49; Thu, 18 Jan 2007 23:32:53 +0100 Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l0IMWsnc012608 for ; Thu, 18 Jan 2007 22:32:54 GMT Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l0IMWrQb012607 for ietf-mta-filters@imc.org; Thu, 18 Jan 2007 23:32:53 +0100 X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to Dilyan.Palauzov@aegee.org using -f Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Thu, 18 Jan 2007 23:32:53 +0100 Message-ID: <20070118233253.0a7pbji0sg80448o@mail.aegee.org> Date: Thu, 18 Jan 2007 23:32:53 +0100 From: Dilyan Palauzov To: ietf-mta-filters@imc.org Subject: Re: sieve for spamfiltering and greylisting References: <20061213124135.ge5xkem1ggkk4wow@mail.aegee.org> <458717AA.8020103@isode.com> <20061219081939.vcylj71s84kgs0k4@mail.aegee.org> <45A9F979.7000500@isode.com> In-Reply-To: <45A9F979.7000500@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Virus-Scanned: ClamAV 0.88.7/2462/Thu Jan 18 10:07:46 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0IMWt2p003207 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, > One idea worth considering is multiple Sieve engines, one running in > MTA and one running in delivery agent. This was what I tried to explain all the time. >> My idea was not to call external applications, but to provide >> unified interface where different applications read the same sieve >> script but interpret different parts of it. > > Can this be done using Ned's environment extension and/or Sieve include > extension? No. The spam filter needs the user preferences in form of input and delivers probability as output. The environment extension might contain the results from the spam evaluation, but at the moment the script is supposed to be read either before or after spam filtering, thus being used either as input to the filter, or as output. > >> The aim is to minimize the amount of interfaces a user needs to >> work with in order to configure the way of the mail from the MTA >> to his mailbox. >> >> There are several user's preferences in spamassassin (tool saying >> for each may how high the probability is, that a specific mail is >> spam). Such an example is the whitelisting. Another option is >> altering the scores per user, that matching specific test gives, >> thus modifying the influence that a test has. rewrite_header >> (http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#basic_message_tagging_options ) modifies the header of the message, in case it is spam. Of course this can be achieved by other means in >> sieve, > > Indeed. The editheader extension can be used for that. > >> but the latter fact is a sign that spamassassin and sieve do very >> similar things (conditionally rewriting headers) and therefore >> shall be configured from the same place. > > I am not yet convinced that Sieve is the proper place for storing this > information. > One possibility is to store such information externally (in LDAP, ACAP > or IMAP METADATA) and access it using a Sieve extension. I've written a > Sieve extension for accessing IMAP METADATA values. IMAP Metadata is not appropriate, since not every email address has assigned an imap mailbox. E.g. on my server I have 15000 mail aliases and I don't want to install for all the suers imap accounts in order to store the settings. LDAP is an option, as well ACAP, but this is practiced at the moment: In order to configure the incoming mail, a user has to write a sieve script, then to setup the greylisting, then to sfjust spamassassin, and then one more spam filter. It would be better for the user if there was only one itnerface. Needless to say, first the anti-spam tools shall agree on common settings, but sieve is the only one of the mentioned 3 interfaces that provides standard means to upload the settings. > Another possibility is to make spamassasin Sieve-aware. But maybe this > is a wishful thinking :-). It is not that impossible. Just a new module for reading preferences is needed and if there is a standard, I am sure the module will be written. (there is already managesieve in perl). I will contact, soon or late, different spam dev. teams and share later the common opinion. Greetings, Дилян 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 l0IMJCob001892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 15:19:12 -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 l0IMJCa1001891; Thu, 18 Jan 2007 15:19:12 -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.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0IMJAV7001884 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 18 Jan 2007 15:19:12 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1H7fbB-0005HA-Ex; Thu, 18 Jan 2007 23:19:09 +0100 Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id l0IMJAAQ011980 for ; Thu, 18 Jan 2007 22:19:10 GMT Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l0IMJ99D011979 for ietf-mta-filters@imc.org; Thu, 18 Jan 2007 23:19:09 +0100 X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to Dilyan.Palauzov@aegee.org using -f Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Thu, 18 Jan 2007 23:19:09 +0100 Message-ID: <20070118231909.om84uctk6ccok04c@mail.aegee.org> Date: Thu, 18 Jan 2007 23:19:09 +0100 From: Dilyan Palauzov To: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Virus-Scanned: ClamAV 0.88.7/2462/Thu Jan 18 10:07:46 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0IMJCV6001886 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Reading Lisa's mail, a new problem arized in my head: For every generated notification, the system administrator shall be able to say how did it originate. Making "grep" on all scripts is not an option, since the user might have changed the script in the meantime, or two users might have identical scripts. Just imagine a user gets constantly notifications saying "you got an email at your example.com mailbox". But the user does not have an example.com mailbox, and moreover, he has not set up such a script-notification. Obviously this was made by another user and when the system administrator, on whose server the message was generated, is informed about it, s/he shall be able to track where the problem was. So I suggest to add something to section 3.8. Requirements on notification methods specifications * It is RECOMMENDED that a notification includes means to identify/track its origin. But this could be understood, that a notification shall say which server generated it, and not which user. Any ideas? In sec 3.8. one more sentance could be included * Where applicatiable, derived extensions shall support a subject: option. Greetings, Дилян 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 l0ILhCo6099479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 14:43:12 -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 l0ILhCc3099478; Thu, 18 Jan 2007 14:43:12 -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 l0ILhBdl099472 for ; Thu, 18 Jan 2007 14:43:12 -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 ; Thu, 18 Jan 2007 21:43:10 +0000 Message-ID: <45AFE9DE.6040005@isode.com> Date: Thu, 18 Jan 2007 21:42:54 +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 MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Re: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <45AFDB20.2030703@isode.com> In-Reply-To: <45AFDB20.2030703@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Issue #1: > > Make tagged "method" parameter positional. (Michael, Dylan are in > favor of the change). Mark E. Mallett is also in favor of this change (doesn't feel strongly) > I would welcome additional opinions on this issue. > > Issue #2: > > Michael has suggested some changes to the requirement on timestamps. I > will discuss this offline with Michael and Barry and will suggest some > new text. > > Issue #3: > > :subject versa :message. Aaron, Dilyan in favor of adding :subject. > Michael wants to keep using :message. > > Issue #4: > > Dilyan suggested to add "expiration" parameter/option to the notify > action. While I see some utility in this option, I am reluctant to > extend the document so late in the game, unless there is strong > support from the WG. I would recommend to add this option in a > separate document. Opinions? > > Issue #5: > > Ken (in a private message) has suggested to extend "body" test instead > of introducing a new "extract_text" test. Opinions? Somewhat related to this: Mark (and I was thinking the same) has suggested to move "extract_text" to another document (e.g. MIME loops), as it has applicability beyond Sieve notify. > Issue #6: > > Arnt wants to be able to do "send notification over XMPP, if can be > delivered immediately. Otherwise send it over SMS". > This issue needs further discussion. > > Issue #7: > > Lisa: controlling who can receive notifications and throttling. > > > Have I listed all issues raised so far? Also, several people including Mark has suggested to rename "valid_notif_method" to "valid_notify_method". Unless I hear otherwise, I will do that in the next revision. 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 l0IKeGqg094408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 13:40: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 l0IKeGAf094407; Thu, 18 Jan 2007 13:40:16 -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 l0IKeFgI094401 for ; Thu, 18 Jan 2007 13:40:16 -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 ; Thu, 18 Jan 2007 20:40:15 +0000 Message-ID: <45AFDB20.2030703@isode.com> Date: Thu, 18 Jan 2007 20:40:00 +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 MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt 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: Issue #1: Make tagged "method" parameter positional. (Michael, Dylan are in favor of the change). I would welcome additional opinions on this issue. Issue #2: Michael has suggested some changes to the requirement on timestamps. I will discuss this offline with Michael and Barry and will suggest some new text. Issue #3: :subject versa :message. Aaron, Dilyan in favor of adding :subject. Michael wants to keep using :message. Issue #4: Dilyan suggested to add "expiration" parameter/option to the notify action. While I see some utility in this option, I am reluctant to extend the document so late in the game, unless there is strong support from the WG. I would recommend to add this option in a separate document. Opinions? Issue #5: Ken (in a private message) has suggested to extend "body" test instead of introducing a new "extract_text" test. Opinions? Issue #6: Arnt wants to be able to do "send notification over XMPP, if can be delivered immediately. Otherwise send it over SMS". This issue needs further discussion. Issue #7: Lisa: controlling who can receive notifications and throttling. Have I listed all issues raised so far? 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 l0IJkEtN090665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jan 2007 12:46:14 -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 l0IJkE55090664; Thu, 18 Jan 2007 12:46:14 -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 l0IJkAQP090655 for ; Thu, 18 Jan 2007 12:46:11 -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 ; Thu, 18 Jan 2007 19:46:09 +0000 Message-ID: <45AFCE72.4060201@isode.com> Date: Thu, 18 Jan 2007 19:45:54 +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: Dilyan Palauzov CC: ietf-mta-filters@imc.org Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> , <4589A03A.3040001@aegee.org> In-Reply-To: <4589A03A.3040001@aegee.org> 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: Dilyan Palauzov wrote: > Hello, Hi Dilyan, > To what I understood, the issue with method: and subject: was not > cleared yet. Let me share what I think: > > 'subject:" for me the purpose of sieve-notify is to define a general > framework for sending notifications, in the most general way a message > can be defined. It is true that some notify-gateways support subjects, > and others don't, but a subject is a property of a general message. > Look on the discussion as an object-oriented programmer: the base > class/interface is notify, derived by notify-voip-phone, notify-xmpp, > notify-mailto. Suppose notify-voip-phone puts a message in the voice > box of the user and displays text on the device's display (voip phones > do have ascii display). > If we want a common name in all derived classes, the name shall be > defined already in the interface. Then notify-xmpp can ignore this > tag, in the same way notify-voip-phone can ignore importance. But if > there is a subject: to be overwritten, then notify-display-phone is > supposed to use this keyword for the text to be displayed. If there is > no subject: , they could use display: and even if totally correct, it > is not very practical: the user will be then forced to learn the > different words used to replace "subject:", except having subject and > relying on the notify-extension to interpret it correctly (as will be > described in the sieve-notify.. how to use subject. I guess it is > already there, but have now now wish to check). > So I am in favour of having subject: in sieve-notify. Maybe I didn't understand your comments correctly, but you haven't convinced me that we need both :message and :subject. And I haven't heard a good argument for why :message is not acceptable, while :subject would be. > By the way, what do you think about adding an "expire: date", in > order to allow the mechanism to delte the notification, if it is not > delivered within a certain time. E.g. I might like to get jabber > message when I get a mail, but when on holiday, I don't want 100 > notifications once I am back. Instead the notification might wait > three days to be read and then be discarded. I see some utility in this, but I would suggest that this be done as a separate extension to Sieve notify. If other people disagree, please speak up now! > "method:" If method: is a must to have, then it is redundant to > write "method:" when this can be avoided and I am in favour of > removing it. Now, the backward compatibility, there could be a > transitional clause, included or not in the final document, that if > "methond" is not mentioned, then the last string is considered to > describe the method; if it is mentioned, then what follows it is the > method. To what I understand from computer lang. grammars it is very > easy to define the method "so or so" and I do not imagine very-very > huge problems. Ok, I count your voice for replacing :method with a positional argument. 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 l0HHt9AW079226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 10:55: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 l0HHt9n2079225; Wed, 17 Jan 2007 10:55: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 laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HHt881079219 for ; Wed, 17 Jan 2007 10:55:09 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6AB8614225A; Wed, 17 Jan 2007 09:55:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04614-06; Wed, 17 Jan 2007 09:55:08 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D448F142258; Wed, 17 Jan 2007 09:55:05 -0800 (PST) In-Reply-To: <45ACB6BA.2040803@isode.com> References: <45ACB6BA.2040803@isode.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-mta-filters@imc.org Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: WGLC for Sieve Notify has ended Date: Wed, 17 Jan 2007 09:55:01 -0800 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think we're going to need a bit more language in the sieve-notify draft about sending from authorized or unauthorized from addresses, as well as about sending to people who do not want to receive notifications, and throttling. I'm not sure exactly what needs to be said, however. - Something about how implementations SHOULD restrict the from address to allow only appropriate mailboxes? SHOULD restrict the from address so that other domains aren't caused to be spoofed? - If the recipient of a sieve notify mail doesn't want those notifications, what recourse do they have? Servers SHOULD add a "cancel" link to each notify mail... ? - If the notification frequency is high, servers SHOULD throttle notifications (and if so what error to produce)? Disable the rule? lisa On Jan 16, 2007, at 3:27 AM, Alexey Melnikov wrote: > > I will post the summary of all issues raised later this week. > > I've only seen comments from Michael, Aaron and Dilyan. Has anybody > else reviewed the document? > 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 l0HHAdWD076524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 10:10:39 -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 l0HHAdw0076523; Wed, 17 Jan 2007 10:10:39 -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 l0HHAbQq076516 for ; Wed, 17 Jan 2007 10:10:38 -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 339A14ADCA; Wed, 17 Jan 2007 18:10:37 +0100 (CET) Message-Id: Date: Wed, 17 Jan 2007 18:12:59 +0100 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended Cc: Alexey Melnikov , Ken Murchison References: <45ACB6BA.2040803@isode.com> <45AE4591.8040009@andrew.cmu.edu> <45AE4AE7.9090405@isode.com> In-Reply-To: <45AE4AE7.9090405@isode.com> 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: Alexey Melnikov writes: > valid_notif_method can validate the whole URI, not just the schema > part of it. Shouldn't it then be named valid_notif_uri (or valid_notify_uri)? Arnt 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 l0HGJuqk072096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 09:19: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 l0HGJuFB072095; Wed, 17 Jan 2007 09:19:56 -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 mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HGJs0g072089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Jan 2007 09:19:55 -0700 (MST) (envelope-from michael@freenet-ag.de) Received: from [194.97.55.242] (helo=mx9.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.65) (envelope-from ) id 1H7DVv-0001rr-E5 for ietf-mta-filters@imc.org; Wed, 17 Jan 2007 17:19:51 +0100 Received: from nostromo.freenet-ag.de ([194.97.7.6]:39600) by mx9.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1H7DVv-0005bU-Ct for ietf-mta-filters@imc.org; Wed, 17 Jan 2007 17:19:51 +0100 Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.65 #6) id 1H7DVu-00038F-V9 for ietf-mta-filters@imc.org; Wed, 17 Jan 2007 17:19:50 +0100 Date: Wed, 17 Jan 2007 17:19:50 +0100 To: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <45AE4591.8040009@andrew.cmu.edu> In-Reply-To: <45AE4591.8040009@andrew.cmu.edu> 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: > I'm wondering if we shouldn't leverage the 'ihave' test from the > environment extension rather than creating the proposed > 'valid_notif_method' test. Does ihave address checking if a particular set of arguments to an extension is valid, or just if the extension exists at all? There was a discussion about all kinds of generic error handlers and no consensus, but unfortunately nobody has valid reasons against 'valid_notif_method', so it looks like that's what we will get. The test feels wrong to me, but that's hardly something to object a WGLC, and even if we agree to some error handling approach, it is just ugly to carry around, but not a problem really. Michael 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 l0HGCdU8071645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 09:12:39 -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 l0HGCdqp071644; Wed, 17 Jan 2007 09:12:39 -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 l0HGCcm2071638 for ; Wed, 17 Jan 2007 09:12:38 -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, 17 Jan 2007 16:12:37 +0000 Message-ID: <45AE4AE7.9090405@isode.com> Date: Wed, 17 Jan 2007 16:12:23 +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 MIME-Version: 1.0 To: Ken Murchison CC: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> <45AE4591.8040009@andrew.cmu.edu> In-Reply-To: <45AE4591.8040009@andrew.cmu.edu> 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: Ken Murchison wrote: > Alexey Melnikov wrote: > >> I will post the summary of all issues raised later this week. >> >> I've only seen comments from Michael, Aaron and Dilyan. Has anybody >> else reviewed the document? > > I'm wondering if we shouldn't leverage the 'ihave' test from the > environment extension rather than creating the proposed > 'valid_notif_method' test. I think you mean the "environment" test, not the "ihave". valid_notif_method can validate the whole URI, not just the schema part of it. 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 l0HFnd7d070291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 08:49:40 -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 l0HFndXu070290; Wed, 17 Jan 2007 08:49:39 -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.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HFnck7070284 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 17 Jan 2007 08:49:39 -0700 (MST) (envelope-from murch@andrew.cmu.edu) Received: from [192.168.137.23] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id l0HFnbo3021895 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 17 Jan 2007 10:49:37 -0500 Message-ID: <45AE4591.8040009@andrew.cmu.edu> Date: Wed, 17 Jan 2007 10:49:37 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended References: <45ACB6BA.2040803@isode.com> In-Reply-To: <45ACB6BA.2040803@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 128.2.10.81 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > I will post the summary of all issues raised later this week. > > I've only seen comments from Michael, Aaron and Dilyan. Has anybody else > reviewed the document? I'm wondering if we shouldn't leverage the 'ihave' test from the environment extension rather than creating the proposed 'valid_notif_method' test. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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 l0GKJmEq088117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 13:19:48 -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 l0GKJmEX088116; Tue, 16 Jan 2007 13:19:48 -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 shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0GKJko7088110 for ; Tue, 16 Jan 2007 13:19:47 -0700 (MST) (envelope-from mem@mv.mv.com) Received: (qmail 48008 invoked by uid 101); 16 Jan 2007 15:19:46 -0500 From: "Mark E. Mallett" Date: Tue, 16 Jan 2007 15:19:45 -0500 To: Alexey Melnikov Cc: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended Message-ID: <20070116201945.GA37066@osmium.mv.net> References: <45ACB6BA.2040803@isode.com> <20070116171900.GA83498@osmium.mv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070116171900.GA83498@osmium.mv.net> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jan 16, 2007 at 12:19:00PM -0500, Mark E. Mallett wrote: > > On Tue, Jan 16, 2007 at 11:27:54AM +0000, Alexey Melnikov wrote: > > > > I will post the summary of all issues raised later this week. > > > > I've only seen comments from Michael, Aaron and Dilyan. Has anybody else > > reviewed the document? > > Yes... but too late, I fear. Sorry for being abrupt. I just have some probably-inconsequential comments. > Usage: notify ":method" string > [":from" string] > [":importance" <"1" / "2" / "3">] > [":options" string-list] > [":message" string] If I interpret the past discussion correctly, this may be getting changed to remove ':method' and add a positional . I think that is a positive change, but I don't feel too strongly. > 4. Extract_text Action > > Usage: extract_text [MODIFIER] [":first" number] > I feel that this would be much better as a standalone extension, or at least as part of an extension where it is more relevant (e.g. "mime"). It has broader use than for just notify; users might want it when notify is not available; and it could be specified in a more general way. I also think that notify could easily proceed without it (though I don't know all the history, so maybe I'm wrong). Having it here has the same feel as a legislative earmark. This is the strongest I feel of the remarks that I have here :) There's also this: > The Extract_text action stores at most :first bytes of the first > text/* part in the variable identified by varname. If the :first > parameter is not present, the whole content of the first text/* part > is stored. Should something be said about the upper bound? If nothing else, that the "whole content" may not be stored because of the truncation that happens when the variables limit is exceeded. I also think it would help to say that implementation limits may apply. My implementation, for example, caches in memory some minimum number of bytes of each mime part, with any excess possibly being cached on disk. I'd happily make what's cached in memory available, but I might be disgruntled by having to fetch more from disk cache. (This would probably already exceed the variables limit, but it's just an example of why an implementation might want to have a limit.) > 5. Test valid_notif_method > > Usage: valid_notif_method This has the feel of "creat()". i.e., are we so short on space that we can't have the 'y' ? Guess that's it.. -mm- 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 l0GHJ2bu074340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 10:19:02 -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 l0GHJ217074339; Tue, 16 Jan 2007 10:19:02 -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 shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l0GHJ1Sb074331 for ; Tue, 16 Jan 2007 10:19:02 -0700 (MST) (envelope-from mem@mv.mv.com) Received: (qmail 86968 invoked by uid 101); 16 Jan 2007 12:19:00 -0500 From: "Mark E. Mallett" Date: Tue, 16 Jan 2007 12:19:00 -0500 To: Alexey Melnikov Cc: ietf-mta-filters@imc.org Subject: Re: WGLC for Sieve Notify has ended Message-ID: <20070116171900.GA83498@osmium.mv.net> References: <45ACB6BA.2040803@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45ACB6BA.2040803@isode.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Jan 16, 2007 at 11:27:54AM +0000, Alexey Melnikov wrote: > > I will post the summary of all issues raised later this week. > > I've only seen comments from Michael, Aaron and Dilyan. Has anybody else > reviewed the document? Yes... but too late, I fear. mm 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 l0GGTFJ2070102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 09:29:15 -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 l0GGTFwV070101; Tue, 16 Jan 2007 09:29:15 -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 l0GGTEWD070086 for ; Tue, 16 Jan 2007 09:29:15 -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, 16 Jan 2007 16:29:13 +0000 Message-ID: <45ACFD4B.80803@isode.com> Date: Tue, 16 Jan 2007 16:28:59 +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@imc.org Subject: Updated milestones 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: Hi folks, Below is a proposal from chairs about updating our milestones (again): Jan 2007 Submit 3028bis to IESG Jan 2007 Submit editheader draft to IESG Jan 2007 Submit body test draft to IESG Feb 2007 Submit notification action draft to IESG Mar 2007 WG last call for loop draft Apr 2007 Submit loop draft to IESG Apr 2007 Submit revised regex draft May 2007 Submit refuse draft to IESG Jun 2007 WG last call of regex draft Aug 2007 Submit regex action draft to IESG Aug 2007 3028bis interop report framework/matrix Does this seem reasonable? 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 l0GBS9OG041802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 04:28: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 l0GBS90m041801; Tue, 16 Jan 2007 04:28: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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0GBS8Qp041795 for ; Tue, 16 Jan 2007 04:28:09 -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, 16 Jan 2007 11:28:07 +0000 Message-ID: <45ACB6BA.2040803@isode.com> Date: Tue, 16 Jan 2007 11:27:54 +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 MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: WGLC for Sieve Notify has ended 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: I will post the summary of all issues raised later this week. I've only seen comments from Michael, Aaron and Dilyan. Has anybody else reviewed the document? 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 l0E9a9IW011749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jan 2007 02:36: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 l0E9a9AS011748; Sun, 14 Jan 2007 02:36: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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0E9a7uX011742 for ; Sun, 14 Jan 2007 02:36:08 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.17.15.141] ((unknown) [81.253.46.19]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 14 Jan 2007 09:36:05 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <45A9F979.7000500@isode.com> Date: Sun, 14 Jan 2007 09:35:53 +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: Dilyan Palauzov CC: ietf-mta-filters@imc.org Subject: Re: sieve for spamfiltering and greylisting References: <20061213124135.ge5xkem1ggkk4wow@mail.aegee.org> <458717AA.8020103@isode.com> <20061219081939.vcylj71s84kgs0k4@mail.aegee.org> In-Reply-To: <20061219081939.vcylj71s84kgs0k4@mail.aegee.org> MIME-version: 1.0 Content-type: text/plain; charset="UTF-8"; format="flowed" Content-transfer-encoding: 8bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dilyan Palauzov wrote: > Hello, Hi Dilyan, > My idea was not to call external applications, but to provide > unified interface where different applications read the same sieve > script but interpret different parts of it. Can this be done using Ned's environment extension and/or Sieve include extension? > The aim is to minimize the amount of interfaces a user needs to work > with in order to configure the way of the mail from the MTA to his > mailbox. > > There are several user's preferences in spamassassin (tool saying > for each may how high the probability is, that a specific mail is > spam). Such an example is the whitelisting. Another option is > altering the scores per user, that matching specific test gives, thus > modifying the influence that a test has. rewrite_header > (http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#basic_message_tagging_options > ) modifies the header of the message, in case it is spam. Of course > this can be achieved by other means in sieve, Indeed. The editheader extension can be used for that. > but the latter fact is a sign that spamassassin and sieve do very > similar things (conditionally rewriting headers) and therefore shall > be configured from the same place. I am not yet convinced that Sieve is the proper place for storing this information. One possibility is to store such information externally (in LDAP, ACAP or IMAP METADATA) and access it using a Sieve extension. I've written a Sieve extension for accessing IMAP METADATA values. Another possibility is to make spamassasin Sieve-aware. But maybe this is a wishful thinking :-). > spam rewrite_header nanana, or rather spam rewrite_header subject > nanana is supposed to prefix the subject-header with +nanana+ in the > mails marked as spam. > > Greetings, > Дилян 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 l04Eu8IH002184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jan 2007 07:56: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 l04Eu83p002183; Thu, 4 Jan 2007 07:56: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 mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l04Eu40i002176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Jan 2007 07:56:07 -0700 (MST) (envelope-from michael@freenet-ag.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1H2U0h-0000MQ-6S for ietf-mta-filters@imc.org; Thu, 04 Jan 2007 15:56:03 +0100 Received: from nostromo.freenet-ag.de ([194.97.7.6]:51987) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1H2U0g-0006xK-Vq for ietf-mta-filters@imc.org; Thu, 04 Jan 2007 15:56:03 +0100 Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.65 #1) id 1H2U0g-0005H9-Fw for ietf-mta-filters@imc.org; Thu, 04 Jan 2007 15:56:02 +0100 Date: Thu, 04 Jan 2007 15:56:02 +0100 To: ietf-mta-filters@imc.org Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> <009201c72f93$760ab660$0202fea9@nigelhome> In-Reply-To: <009201c72f93$760ab660$0202fea9@nigelhome> 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: > > Ok, but the implementation specs (notify-xmpp and notify-mailto) each > > specify different and strange default subjects in their respective media. > > They even seem to suggest that the subject would be hardcoded in the > > implementation. > > I'd say if the gateway supports subject+body, then the notification should be the subject, not the body. A hardcoded subject sounds dreadful! >From draft-ietf-sieve-notify-mailto-01: o The "Subject:" field of the notification message contains the value defined by the :message notify tag, as described in [Notify]. If there is no :message tag, the subject is retained from the triggering message. Note that Sieve [Variables] can be used to advantage here, as shown in the example in Section 3. [...] o If the mailto URI contains a "body" header, the value of that header is used as the body of the notification message. If there is no "body" header, the body of the notification message is empty. No fixed subject, and I can't remember that is was suggested to change that. Michael 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 l0400JsE047419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 17:00: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 l0400JeU047418; Wed, 3 Jan 2007 17:00: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 mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0400Irq047411 for ; Wed, 3 Jan 2007 17:00:18 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 2840ecd498a18647bdfc1c57d27f4e9f X-Spam-Score-Summary: 2,0,0,a52e3ad2ff841928,17cb9f564c0fc456,nigel.swinson@rockliffe.com,,RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1537:1567:1587:1593:1594:1711:1714:1730:1747:1766:1792:2073:2075:2078:2393:2559:2562:2828:3027:3865:3867:3868:3869:3870:3874:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.5) with ESMTP id ; Wed, 3 Jan 2007 16:00:13 -0800 Message-ID: <009201c72f93$760ab660$0202fea9@nigelhome> From: "Nigel Swinson" To: "Aaron Stone" Cc: References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt Date: Thu, 4 Jan 2007 00:01:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0400Irq047413 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Ok, but the implementation specs (notify-xmpp and notify-mailto) each > specify different and strange default subjects in their respective media. > They even seem to suggest that the subject would be hardcoded in the > implementation. I'd say if the gateway supports subject+body, then the notification should be the subject, not the body. A hardcoded subject sounds dreadful! Nigel 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 l03KUWTI034184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 13:30:32 -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 l03KUWkl034183; Wed, 3 Jan 2007 13:30:32 -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 l03KUTZB034174 for ; Wed, 3 Jan 2007 13:30:31 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id B00CC6024E43; Wed, 3 Jan 2007 12:30:19 -0800 (PST) Date: Wed, 3 Jan 2007 20:30:19 -0000 To: "Nigel Swinson" , "Aaron Stone" Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt From: "Aaron Stone" X-Mailer: TWIG 2.8.2 Message-ID: In-Reply-To: <002601c72f5f$76491c90$0202fea9@nigelhome> References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Cc: Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 3, 2007, Nigel Swinson said: >> Incidentally, "Read your hospital email now!" strikes me as the _subject_. >> The message might be blank on a pager, or it might include some details if >> it were an email. In a non-privacy-centric situation, perhaps a lot of >> detail. > > I think we run the risk of straying into message summaries that Ned warned > about previously. So why can't the notification be just "Read your hospital > email now!" and have no two part subject/body, or in a non-privacy-centric > situation use redirect(+keep?). Ok, but the implementation specs (notify-xmpp and notify-mailto) each specify different and strange default subjects in their respective media. They even seem to suggest that the subject would be hardcoded in the implementation. Aaron 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 l03HmhmK021647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 10:48:43 -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 l03HmhkB021646; Wed, 3 Jan 2007 10:48:43 -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.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l03Hmggq021638 for ; Wed, 3 Jan 2007 10:48:42 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 5e1332730d7713f67900a5e5ee7dd0eb X-Spam-Score-Summary: 2,0,0,79ff669a7154f3e6,17cb9f564c0fc456,nigel.swinson@rockliffe.com,,RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2194:2199:2393:2559:2562:2693:2828:2891:2892:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3874:4362:4552:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.5) with ESMTP id ; Wed, 3 Jan 2007 09:48:42 -0800 Message-ID: <002601c72f5f$76491c90$0202fea9@nigelhome> From: "Nigel Swinson" To: "Aaron Stone" Cc: References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt Date: Wed, 3 Jan 2007 17:49:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l03Hmhgq021641 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > What is the utility of using notify with email? Why not just use redirect > > (+keep?). > > In many cases, the email and the email store will be secure, but the > notification mechanism will not. > > The use case I've thought of is a doctor's email, which will be be secured > and is restricted by patient privacy laws, but the doctor's pager is an > open broadcast. The notification to "Read your hospital email now!" > contains no private information. A copy of the original message (or even > its Received headers, hence the thorny issues with catching message loops) > is private. Thanks for that, it's helpful to think about :o) > Incidentally, "Read your hospital email now!" strikes me as the _subject_. > The message might be blank on a pager, or it might include some details if > it were an email. In a non-privacy-centric situation, perhaps a lot of > detail. I think we run the risk of straying into message summaries that Ned warned about previously. So why can't the notification be just "Read your hospital email now!" and have no two part subject/body, or in a non-privacy-centric situation use redirect(+keep?). Nigel 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 l03HMk3g019501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 10: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 l03HMkgt019500; Wed, 3 Jan 2007 10: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 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 l03HMkgN019489 for ; Wed, 3 Jan 2007 10:22:46 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id 6EF606024E43; Wed, 3 Jan 2007 09:22:35 -0800 (PST) Date: Wed, 3 Jan 2007 17:22:35 -0000 To: "Nigel Swinson" Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt From: "Aaron Stone" X-Mailer: TWIG 2.8.2 Message-ID: In-Reply-To: <017801c72f54$3f5fcdb0$0202fea9@nigelhome> References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Cc: Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Jan 3, 2007, Nigel Swinson said: > What is the utility of using notify with email? Why not just use redirect > (+keep?). In many cases, the email and the email store will be secure, but the notification mechanism will not. The use case I've thought of is a doctor's email, which will be be secured and is restricted by patient privacy laws, but the doctor's pager is an open broadcast. The notification to "Read your hospital email now!" contains no private information. A copy of the original message (or even its Received headers, hence the thorny issues with catching message loops) is private. Incidentally, "Read your hospital email now!" strikes me as the _subject_. The message might be blank on a pager, or it might include some details if it were an email. In a non-privacy-centric situation, perhaps a lot of detail. Aaron 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 l03GRpd7014569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 09:27:52 -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 l03GRpPP014568; Wed, 3 Jan 2007 09:27:51 -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.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l03GRpGt014559 for ; Wed, 3 Jan 2007 09:27:51 -0700 (MST) (envelope-from Nigel.Swinson@rockliffe.com) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 8f2fb5a3f76456a07e0c9c3f64b2318a X-Spam-Score-Summary: 2,0,0,4b3bcde9424ab7d2,17cb9f564c0fc456,nigel.swinson@rockliffe.com,,RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1540:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2194:2199:2393:2553:2559:2562:2828:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:5007,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 X-Spam-Score: 1 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.5) with ESMTP id ; Wed, 3 Jan 2007 08:27:50 -0800 Message-ID: <017801c72f54$3f5fcdb0$0202fea9@nigelhome> From: "Nigel Swinson" To: "Michael Haardt" Cc: References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt Date: Wed, 3 Jan 2007 16:28:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l03GRpGt014560 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > It is true that some notify-gateways support subjects, and others don't, > > but a subject is a property of a general message. > > IMHO: Messages in general - yes. Notification messages - no. But then complex messages may also transport notifications. Perhaps an alternative question is of all the available messaging channels, how many support a subject+body, and how many support just a body. You probably then ought to weight the frequency of the messaging channel. Carrier Pigeon isn't going to be as popular a choice as sms or email for notifications. If there are several channels that support a subject, it is worth adding to the notify spec. What is the utility of using notify with email? Why not just use redirect (+keep?). I'm currently marginally against adding :subject to the notify spec. Nigel 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 l03ENH9D005606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jan 2007 07:23:18 -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 l03ENHRK005605; Wed, 3 Jan 2007 07:23: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 mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l03ENFGW005599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Jan 2007 07:23:17 -0700 (MST) (envelope-from michael@freenet-ag.de) Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1H271O-0005Tr-5R for ietf-mta-filters@imc.org; Wed, 03 Jan 2007 15:23:14 +0100 Received: from nostromo.freenet-ag.de ([194.97.7.6]:48812) by mx6.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1H271O-0004tk-2o for ietf-mta-filters@imc.org; Wed, 03 Jan 2007 15:23:14 +0100 Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.65 #1) id 1H271N-0004ZO-CS for ietf-mta-filters@imc.org; Wed, 03 Jan 2007 15:23:13 +0100 Date: Wed, 03 Jan 2007 15:23:13 +0100 To: ietf-mta-filters@imc.org Subject: Re: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt References: <456F4D43.2050700@isode.com> <20061214142507.GA4066@nostromo.freenet-ag.de> <4581B357.2030400@isode.com> <4589A03A.3040001@aegee.org> In-Reply-To: <4589A03A.3040001@aegee.org> 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: Hello, happy new year to everybody! I don't want to let this discussion just stop without agreement. So let's get results. > It is true that some notify-gateways support subjects, and others don't, > but a subject is a property of a general message. IMHO: Messages in general - yes. Notification messages - no. A poll should answer what the majority thinks: ---------------------------------------------------------------------- Do you consider general notification messages (in the context of the notify extension) to have a property "subject"? [ ] yes [ ] no ---------------------------------------------------------------------- > If we want a common name in all derived classes, the name shall be > defined already in the interface. I agree to that. Should the majority vote for subjects being proporties of general notification messages, we absolutely should put ":subject" in the framework. > By the way, what do you think about adding an "expire: date", in order > to allow the mechanism to delte the notification, if it is not delivered > within a certain time. E.g. I might like to get jabber message when I > get a mail, but when on holiday, I don't want 100 notifications once I > am back. Instead the notification might wait three days to be read and > then be discarded. I think if you want a rolling message store, the recipient store and its associated delivery policy (e.g. a sieve filter:-) should care about that, not the sender. > "method:" If method: is a must to have, then it is redundant to > write "method:" when this can be avoided and I am in favour of removing > it. That makes two of us. Compatibility is no problem at this point, because the name of the extension changes anyway. Michael