Re: vacation and SMTP
Ned Freed <ned.freed@mrochek.com> Thu, 19 July 2007 15:06 UTC
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 l6JF6guM026076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 08:06: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 l6JF6gIG026074; Thu, 19 Jul 2007 08:06: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 mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6JF6eW6026066 for <ietf-mta-filters@imc.org>; Thu, 19 Jul 2007 08:06:41 -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 <01MJ4P17APTS004P7N@mauve.mrochek.com> for ietf-mta-filters@imc.org; Thu, 19 Jul 2007 08:06:37 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MJ4LYYVHM800005E@mauve.mrochek.com>; Thu, 19 Jul 2007 08:06:34 -0700 (PDT)
Cc: IETF Sieve <ietf-mta-filters@imc.org>
Message-id: <01MJ4P16AEJO00005E@mauve.mrochek.com>
Date: Thu, 19 Jul 2007 07:37:50 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: vacation and SMTP
In-reply-to: "Your message dated Thu, 19 Jul 2007 15:49:21 +0200" <20070719154921.ismxus1hc0400g8o@mail.aegee.org>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset="UTF-8"; DelSp="Yes"; format="flowed"
References: <20070719154921.ismxus1hc0400g8o@mail.aegee.org>
To: Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1184857596; h=Date: From:Subject:MIME-version:Content-type; b=Jiy2c3qkXEI9ByiNHZGnW2QX0 0d7nrzyTJFx4KRZ8YePaRb65obi8epKITMwUJ6ftu2PqgrIDjqlZsNnY8Vq3w==
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>
> On my last mail, how to apply sieve's reject towards a mail > envelope, containing more than 1 recipients, the very right approach > is to use PRDR - Per Recipient Delivery Response, > http://www.ietf.org/internet-drafts/draft-hall-prdr-00.txt. As I have stated previously, that remains to be seen. In the best possible case PRDR deployment is going to be very challening. Worst case it won't even see the light of day as a standard, let alone see any deployment whatsoever. > The next > option is to do what Arnt suggested (first RCPT TO: -> 250 OK, > consequent RCPT TO: -> 4xx temporary error). No, the next option is to accept the message and send back nondelivery notifications for the recipients who are determined to have failed after the message has been transferred. 4xy responses to all but the first recipient is an extremely drastic measure with all sorts of potentially very serious side effects. Again, all of this has been discussed previously. > And now I would like to ask for your opinion about providing a > standard way to send vacations over smtp and reflecting this standard > way on the design of sieve-vacation. Although it has not yet been published as an RFC due to normative dependencies on other drafts, sieve vacation is already approved as a proposed standard. You are well over a year too late to make any sort of major change to it. > The idea is similar to DNS: when the recipient will not get the > message (immediately), an error message is sent - first during the > SMTP dialog, later in form of bounce. The problem with the bounces is > that they might end in spamtrap, blacklisting the server, which sent > them. Out office messages are a kind of bounces, and moreover they > shall not be sent in response to mails coming from , -owner@, > listserv@, etc, and shall go to the one who actually sent the message, > not the one that are in the envelope's From: (read faked by spammer). > In this similar case the reject approach was extended to react > even during SMTP dialog, thus abolishing the (non-existent, but cool) > possibility to generate MIME/html messag bounces for rejected mails > already in sieve. > What about inventing a new SMTP extension, new response SMTP code > and giving back as response during the SMTP dialog, that the recipient > is on holiday? In this way the sender's MUA will have a standard way > to interpret the message, incl. translation to the local language. I don't see how that could possibly work. At most you could get the the fact that the message isn't going to be seen for some period of time out of a structure response of some kind. However, the nature of vacation responses is that they necessarily contain textual information about why the recipient is unavailable, who to contact as an alternative, and various other critical stuff that cannot possibly be coded in a structured way. So like it or not, useful localization of vacation responses has to be done by the person or agent generating the response. This is sharp contrast to nondelivery notifications, where the semantics associated with the reason for nondelivery can be categorized to some extent, making remote translation workable in most cases. Moreover, existing vacation mechanisms, including but not limited to sieve vacation, already provide fairly elaborate internationalization and localization facilities. For example, I can easily code a sieve to perform a test on the original message and send, say, a response in English to one set of users and a response in Spanish to another. It is simply not possible to duplicate these facilities, many of which depend on examination of the content of the original message, in a mechanism that operates at RCPT TO time. So PRDR or something similar is a necessary prerequisite for anything along these lines. Even worse, since SMTP responses are currently limited to US-ASCII, in order for this to work at all well it will depend on the deployment of an SMTP extension. But let's suppose all the necessary prerequisites for this extension are present, making it possible for a post-DATA response to present a properly localized vacation response. Now what? In many cases this will be happening on a relay hop, not a submission hop. So now an MTA has this information, not an MUA. The only way the MTA can provide this information to the user is to put it in a message and send it, and the minute it does that you've just reintroduced all the problems with notification filtering this mechanism was intended to avoid. So what you're talking about here is an extension that necessarily depends on at least two other extensions, neither of which are even standardized at this point and which may never be standadized, let alone deployed. And even if all this stuff deploys it doesn't really solve the original problem in many cases. I conclude that this would require a huge deployment effort with marginal benefits at best. In other words, IMO this is a complete nonstarter. 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 l6JF6guM026076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 08:06: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 l6JF6gIG026074; Thu, 19 Jul 2007 08:06: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 mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6JF6eW6026066 for <ietf-mta-filters@imc.org>; Thu, 19 Jul 2007 08:06:41 -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 <01MJ4P17APTS004P7N@mauve.mrochek.com> for ietf-mta-filters@imc.org; Thu, 19 Jul 2007 08:06:37 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MJ4LYYVHM800005E@mauve.mrochek.com>; Thu, 19 Jul 2007 08:06:34 -0700 (PDT) Cc: IETF Sieve <ietf-mta-filters@imc.org> Message-id: <01MJ4P16AEJO00005E@mauve.mrochek.com> Date: Thu, 19 Jul 2007 07:37:50 -0700 (PDT) From: Ned Freed <ned.freed@mrochek.com> Subject: Re: vacation and SMTP In-reply-to: "Your message dated Thu, 19 Jul 2007 15:49:21 +0200" <20070719154921.ismxus1hc0400g8o@mail.aegee.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8; DelSp=Yes; format=flowed References: <20070719154921.ismxus1hc0400g8o@mail.aegee.org> To: Dilyan Palauzov <Dilyan.Palauzov@aegee.org> DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1184857596; h=Date: From:Subject:MIME-version:Content-type; b=Jiy2c3qkXEI9ByiNHZGnW2QX0 0d7nrzyTJFx4KRZ8YePaRb65obi8epKITMwUJ6ftu2PqgrIDjqlZsNnY8Vq3w== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> > On my last mail, how to apply sieve's reject towards a mail > envelope, containing more than 1 recipients, the very right approach > is to use PRDR - Per Recipient Delivery Response, > http://www.ietf.org/internet-drafts/draft-hall-prdr-00.txt. As I have stated previously, that remains to be seen. In the best possible case PRDR deployment is going to be very challening. Worst case it won't even see the light of day as a standard, let alone see any deployment whatsoever. > The next > option is to do what Arnt suggested (first RCPT TO: -> 250 OK, > consequent RCPT TO: -> 4xx temporary error). No, the next option is to accept the message and send back nondelivery notifications for the recipients who are determined to have failed after the message has been transferred. 4xy responses to all but the first recipient is an extremely drastic measure with all sorts of potentially very serious side effects. Again, all of this has been discussed previously. > And now I would like to ask for your opinion about providing a > standard way to send vacations over smtp and reflecting this standard > way on the design of sieve-vacation. Although it has not yet been published as an RFC due to normative dependencies on other drafts, sieve vacation is already approved as a proposed standard. You are well over a year too late to make any sort of major change to it. > The idea is similar to DNS: when the recipient will not get the > message (immediately), an error message is sent - first during the > SMTP dialog, later in form of bounce. The problem with the bounces is > that they might end in spamtrap, blacklisting the server, which sent > them. Out office messages are a kind of bounces, and moreover they > shall not be sent in response to mails coming from , -owner@, > listserv@, etc, and shall go to the one who actually sent the message, > not the one that are in the envelope's From: (read faked by spammer). > In this similar case the reject approach was extended to react > even during SMTP dialog, thus abolishing the (non-existent, but cool) > possibility to generate MIME/html messag bounces for rejected mails > already in sieve. > What about inventing a new SMTP extension, new response SMTP code > and giving back as response during the SMTP dialog, that the recipient > is on holiday? In this way the sender's MUA will have a standard way > to interpret the message, incl. translation to the local language. I don't see how that could possibly work. At most you could get the the fact that the message isn't going to be seen for some period of time out of a structure response of some kind. However, the nature of vacation responses is that they necessarily contain textual information about why the recipient is unavailable, who to contact as an alternative, and various other critical stuff that cannot possibly be coded in a structured way. So like it or not, useful localization of vacation responses has to be done by the person or agent generating the response. This is sharp contrast to nondelivery notifications, where the semantics associated with the reason for nondelivery can be categorized to some extent, making remote translation workable in most cases. Moreover, existing vacation mechanisms, including but not limited to sieve vacation, already provide fairly elaborate internationalization and localization facilities. For example, I can easily code a sieve to perform a test on the original message and send, say, a response in English to one set of users and a response in Spanish to another. It is simply not possible to duplicate these facilities, many of which depend on examination of the content of the original message, in a mechanism that operates at RCPT TO time. So PRDR or something similar is a necessary prerequisite for anything along these lines. Even worse, since SMTP responses are currently limited to US-ASCII, in order for this to work at all well it will depend on the deployment of an SMTP extension. But let's suppose all the necessary prerequisites for this extension are present, making it possible for a post-DATA response to present a properly localized vacation response. Now what? In many cases this will be happening on a relay hop, not a submission hop. So now an MTA has this information, not an MUA. The only way the MTA can provide this information to the user is to put it in a message and send it, and the minute it does that you've just reintroduced all the problems with notification filtering this mechanism was intended to avoid. So what you're talking about here is an extension that necessarily depends on at least two other extensions, neither of which are even standardized at this point and which may never be standadized, let alone deployed. And even if all this stuff deploys it doesn't really solve the original problem in many cases. I conclude that this would require a huge deployment effort with marginal benefits at best. In other words, IMO this is a complete nonstarter. 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 l6JDnM1C019050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 06:49:22 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6JDnMO5019049; Thu, 19 Jul 2007 06:49:22 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from 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 l6JDnKIJ019040 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-mta-filters@imc.org>; Thu, 19 Jul 2007 06:49:22 -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 1IBWNb-00063D-CP; Thu, 19 Jul 2007 15:49:19 +0200 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 l6JDnNti022881 for <ietf-mta-filters@imc.org>; Thu, 19 Jul 2007 13:49:23 GMT Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id l6JDnMbk022873 for ietf-mta-filters@imc.org; Thu, 19 Jul 2007 15:49:22 +0200 X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to Dilyan.Palauzov@aegee.org using -f Received: from i71pc90a.cm-tm.uni-karlsruhe.de (i71pc90a.cm-tm.uni-karlsruhe.de [141.3.28.190]) by mail.aegee.org (Horde MIME library) with HTTP; Thu, 19 Jul 2007 15:49:21 +0200 Message-ID: <20070719154921.ismxus1hc0400g8o@mail.aegee.org> Date: Thu, 19 Jul 2007 15:49:21 +0200 From: Dilyan Palauzov <Dilyan.Palauzov@aegee.org> To: IETF Sieve <ietf-mta-filters@imc.org> Subject: vacation and SMTP 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.4) X-Virus-Scanned: ClamAV 0.90.3/3697/Thu Jul 19 00:18:47 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 l6JDnMII019043 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Hello, On my last mail, how to apply sieve's reject towards a mail envelope, containing more than 1 recipients, the very right approach is to use PRDR - Per Recipient Delivery Response, http://www.ietf.org/internet-drafts/draft-hall-prdr-00.txt . The next option is to do what Arnt suggested (first RCPT TO: -> 250 OK, consequent RCPT TO: -> 4xx temporary error). And now I would like to ask for your opinion about providing a standard way to send vacations over smtp and reflecting this standard way on the design of sieve-vacation. The idea is similar to DNS: when the recipient will not get the message (immediately), an error message is sent - first during the SMTP dialog, later in form of bounce. The problem with the bounces is that they might end in spamtrap, blacklisting the server, which sent them. Out office messages are a kind of bounces, and moreover they shall not be sent in response to mails coming from , -owner@, listserv@, etc, and shall go to the one who actually sent the message, not the one that are in the envelope's From: (read faked by spammer). In this similar case the reject approach was extended to react even during SMTP dialog, thus abolishing the (non-existent, but cool) possibility to generate MIME/html messag bounces for rejected mails already in sieve. What about inventing a new SMTP extension, new response SMTP code and giving back as response during the SMTP dialog, that the recipient is on holiday? In this way the sender's MUA will have a standard way to interpret the message, incl. translation to the local language. My suggestion is to include in sieve-vacation a tag for "valid till" and "alternative ways" (URLs, like tel:+123, or mailto:my-secretary)to contact the sender (and possibly a tag for "valid from"). Then this response is interpreted somehow and the original sender sees in her language till when the person is not available. A side effect there will be no :mime option applicatable, but giving a smtp response "550 I don't want this mail" doesn't offer it neither. Imagine something like this: EHLO 250 OK MAIL FROM:<Petra> 250 OK RCPT TO:<Carsten> 299-unavailable-till"Wed, 18 Jul 2007 19:21:55 -0400" 299-reachable-at "tel:+123456789" 299-reachable-at "sms:+987654321" 299 I am out of office, but will come to your mail once I am back DATA If you don't react today, we'll miss the contract. . 250 OK optionally with 299-unavailable-since"Wed, 11 Jul 2007 19:21:55 -0400" in between. Extending vacation with "valid till" will enable to automatically turn off the responses on Friday 17.00, even if one will be unavaileble till Sunday. And mailing lists will be able to recognize one is unavailable and not-unsubscribe her if the respecive mailbox is unfunctional (full) in the meantime. Greetings, Dilyan 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 l6FCtuJC068543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2007 05:55: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 l6FCttYO068542; Sun, 15 Jul 2007 05:55: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 kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6FCts06068533 for <ietf-mta-filters@imc.org>; Sun, 15 Jul 2007 05:55:55 -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 57C094AC91; Sun, 15 Jul 2007 14:55:53 +0200 (CEST) Message-Id: <X2vZBFef2lTN37wOhd3KGg.md5@libertango.oryx.com> Date: Sun, 15 Jul 2007 14:55:53 +0200 From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> To: ietf-mta-filters@imc.org Subject: Re: "reject" and SMTP Cc: Aaron Stone <aaron@serendipity.cx>, Dilyan Palauzov <Dilyan.Palauzov@aegee.org> References: <46992282.3070201@aegee.org> <1184465509.7894.24.camel@localhost> In-Reply-To: <1184465509.7894.24.camel@localhost> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Aaron Stone writes: > I don't know how you'd do this in SMTP since there is only one > response to the DATA command regardless of how many RCPT TO's were > given. If you're an absolute so-and-so, you answer 4xx and temporarily allow only one recipient for mail from that envelope sender. I don't know what reasonable implementer ought to do. 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 l6F2A1Wo033628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2007 19:10:01 -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 l6F2A136033626; Sat, 14 Jul 2007 19:10:01 -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 l6F29wYf033605 for <ietf-mta-filters@imc.org>; Sat, 14 Jul 2007 19:10:00 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from [192.168.1.146] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 40FEC6DDE; Sat, 14 Jul 2007 19:10:28 -0700 (PDT) Subject: Re: "reject" and SMTP From: Aaron Stone <aaron@serendipity.cx> To: Dilyan Palauzov <Dilyan.Palauzov@aegee.org> Cc: IETF Sieve WG <ietf-mta-filters@imc.org> In-Reply-To: <46992282.3070201@aegee.org> References: <46992282.3070201@aegee.org> Content-Type: text/plain; charset=utf8 Date: Sat, 14 Jul 2007 19:11:48 -0700 Message-Id: <1184465509.7894.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> On Sat, 2007-07-14 at 21:22 +0200, Dilyan Palauzov wrote: > Hello, > I have a question concerning section 3.1.1 (Rejecting messages at the > SMTP/LMTP protocol level ) of draft-ietf-sieve-refuse-reject-04: > > Imagine a mail envelope is sent to more than one recipients, one of > which accepts the mail, and the other makes sieve's refuse: [protocol snippet below] > What shall the server answer, when 1@example.org accepts the message and > 2@example.org does not (=makes sieve's refuse)? > > Greetings, > Дилян Following the end of the DATA command, there is a response for each recipient, per this modification to SMTP by RFC 2033: 4.2. The DATA command In the LMTP protocol, there is one additional restriction placed on the DATA command, and one change to how replies to the final "." are sent. The additional restriction is that when there have been no successful RCPT commands in the mail transaction, the DATA command MUST fail with a 503 reply code. The change is that after the final ".", the server returns one reply for each previously successful RCPT command in the mail transaction, in the order that the RCPT commands were issued. Even if there were multiple successful RCPT commands giving the same forward-path, there must be one reply for each successful RCPT command. So let's say that 1@example.org accepts the message while 2@example.org rejects it. I would imagine that your example would conclude like this: > C: mail from: 1@example.com > S: 2.1.0 1@example.com... Sender ok > C: rcpt to: 1@example.org > S: 2.1.5 1@example.org... Recipient ok > C: rcpt to: 1@example.org > S: 2.1.5 2@example.org... Recipient ok > C: DATA > C: That's all > C: . S: 250 OK S: 215 Recipient <1@example.org> OK S: 571 Recipient <2@example.org> Delivery not authorized, message refused C: QUIT S: 221 BYE I don't know how you'd do this in SMTP since there is only one response to the DATA command regardless of how many RCPT TO's were given. 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 l6EJMlr8083331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2007 12:22:47 -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 l6EJMlH5083330; Sat, 14 Jul 2007 12:22:47 -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 l6EJMiLx083322 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-mta-filters@imc.org>; Sat, 14 Jul 2007 12:22:46 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1I9nCV-0004ZX-5y; Sat, 14 Jul 2007 21:22:43 +0200 X-Mail-Sent-By-AEGEE.org-Account: Dilyan Palauzov@aegee.org Received: from [172.20.21.213] (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) (authenticated bits=0) by smtp.aegee.org (8.13.8/8.13.6) with ESMTP id l6EJMdKo005191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-mta-filters@imc.org>; Sat, 14 Jul 2007 19:22:42 GMT Message-ID: <46992282.3070201@aegee.org> Date: Sat, 14 Jul 2007 21:22:42 +0200 From: Dilyan Palauzov <Dilyan.Palauzov@aegee.org> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF Sieve WG <ietf-mta-filters@imc.org> Subject: "reject" and SMTP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.90.3/3669/Sat Jul 14 03:15:39 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Hello, I have a question concerning section 3.1.1 (Rejecting messages at the SMTP/LMTP protocol level ) of draft-ietf-sieve-refuse-reject-04: Imagine a mail envelope is sent to more than one recipients, one of which accepts the mail, and the other makes sieve's refuse: C: mail from: 1@example.com S: 2.1.0 1@example.com... Sender ok C: rcpt to: 1@example.org S: 2.1.5 1@example.org... Recipient ok C: rcpt to: 1@example.org S: 2.1.5 2@example.org... Recipient ok C: DATA C: That's all C: . S: ??? What shall the server answer, when 1@example.org accepts the message and 2@example.org does not (=makes sieve's refuse)? 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 l6CJF35i064728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2007 12:15:03 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6CJF3i8064727; Thu, 12 Jul 2007 12:15:03 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6CJF229064721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-mta-filters@imc.org>; Thu, 12 Jul 2007 12:15:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 1D29532A10; Thu, 12 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I947x-0005xh-Tx; Thu, 12 Jul 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-mta-filters@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sieve-notify-mailto-04.txt Message-Id: <E1I947x-0005xh-Tx@stiedprstage1.ietf.org> Date: Thu, 12 Jul 2007 15:15:01 -0400 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF. Title : Sieve Notification Mechanism: mailto Author(s) : B. Leiba, M. Haardt Filename : draft-ietf-sieve-notify-mailto-04.txt Pages : 14 Date : 2007-7-12 This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sieve-notify-mailto-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sieve-notify-mailto-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12144811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sieve-notify-mailto-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sieve-notify-mailto-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12144811.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 l6BJF7Pw026249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2007 12:15: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 l6BJF7Xe026248; Wed, 11 Jul 2007 12:15:07 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6BJF62C026231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-mta-filters@imc.org>; Wed, 11 Jul 2007 12:15:07 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 50F6F32A10; Wed, 11 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8heQ-0006p7-7U; Wed, 11 Jul 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-mta-filters@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sieve-editheader-09.txt Message-Id: <E1I8heQ-0006p7-7U@stiedprstage1.ietf.org> Date: Wed, 11 Jul 2007 15:15:02 -0400 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF. Title : Sieve Email Filtering: Editheader Extension Author(s) : P. Guenther, J. Degener Filename : draft-ietf-sieve-editheader-09.txt Pages : 11 Date : 2007-7-11 Email header fields are a flexible and easy to understand means of communication between email processors. This extension enables sieve scripts to interact with other components that consume or produce header fields by allowing the script to delete and add header fields. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sieve-editheader-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sieve-editheader-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-11143253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sieve-editheader-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sieve-editheader-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11143253.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 l696K3Ss051380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 23:20:03 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l696K3XE051379; Sun, 8 Jul 2007 23:20:03 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l696K2Rf051370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-mta-filters@imc.org>; Sun, 8 Jul 2007 23:20:02 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BCD07328DA; Mon, 9 Jul 2007 06:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7mbJ-0003JS-Lu; Mon, 09 Jul 2007 02:20:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-mta-filters@imc.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-sieve-mime-loop-03.txt Message-Id: <E1I7mbJ-0003JS-Lu@stiedprstage1.ietf.org> Date: Mon, 09 Jul 2007 02:20:01 -0400 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF. Title : Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure Author(s) : T. Hansen, C. Daboo Filename : draft-ietf-sieve-mime-loop-03.txt Pages : 17 Date : 2007-07-08 The Sieve email filtering language has no way to examine individual MIME parts or any way to manipulate those individual parts. However, being able to filter based on MIME content is important. This document defines extensions for these needs. Note This document is being discussed on the MTA-FILTERS mailing list, ietf-mta-filters@imc.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sieve-mime-loop-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sieve-mime-loop-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-07-09021139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sieve-mime-loop-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sieve-mime-loop-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-09021139.I-D\@ietf.org> --OtherAccess-- --NextPart-- 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 l68LFJ5l004069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 14:15: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 l68LFJ9h004068; Sun, 8 Jul 2007 14:15: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 ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l68LFIaJ004060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-mta-filters@imc.org>; Sun, 8 Jul 2007 14:15:18 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A58E92ACA7; Sun, 8 Jul 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7e5u-0006xu-DN; Sun, 08 Jul 2007 17:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-mta-filters@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sieve-notify-mailto-03.txt Message-Id: <E1I7e5u-0006xu-DN@stiedprstage1.ietf.org> Date: Sun, 08 Jul 2007 17:15:02 -0400 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF. Title : Sieve Notification Mechanism: mailto Author(s) : B. Leiba, M. Haardt Filename : draft-ietf-sieve-notify-mailto-03.txt Pages : 13 Date : 2007-7-8 This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sieve-notify-mailto-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sieve-notify-mailto-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-8163456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sieve-notify-mailto-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sieve-notify-mailto-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-8163456.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 l66GUpma015865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 09:30: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 l66GUp6p015864; Fri, 6 Jul 2007 09:30: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 l66GUnQX015856 for <ietf-mta-filters@imc.org>; Fri, 6 Jul 2007 09:30:50 -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 <Ro5uNgBIZTwc@rufus.isode.com>; Fri, 6 Jul 2007 17:30:47 +0100 Message-ID: <468E6DD8.2020200@isode.com> Date: Fri, 06 Jul 2007 17:29:12 +0100 From: Alexey Melnikov <alexey.melnikov@isode.com> 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: Peter Saint-Andre <stpeter@jabber.org> CC: ietf-mta-filters@imc.org Subject: Re: I-D Action:draft-ietf-sieve-notify-08.txt References: <E1I6q4H-0000le-A1@stiedprstage1.ietf.org> <468E688A.3040700@jabber.org> In-Reply-To: <468E688A.3040700@jabber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Peter Saint-Andre wrote: >Internet-Drafts@ietf.org wrote: > > >>http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-08.txt >> >> >What is the changelog from -07? > > Hi Peter, In the draft you can find: Changes since draft-ietf-sieve-notify-07 o Added a new "set" modifier for URL percent-encoding. o Clarified that notification methods must address notification loops. o Added an implementation consideration for implementations that use URIs internally. ;-) [Plus a couple of minor editorial changes from Barry] Or do you want to see a more detailed list of changes? 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 l66G4rqQ012271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 09:04:53 -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 l66G4rTK012270; Fri, 6 Jul 2007 09:04:53 -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 roundabout.local (dencfw1.jabber.com [207.182.164.5]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l66G4ptf012260 for <ietf-mta-filters@imc.org>; Fri, 6 Jul 2007 09:04:52 -0700 (MST) (envelope-from stpeter@jabber.org) Received: from roundabout.local (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id C748F625BB8 for <ietf-mta-filters@imc.org>; Fri, 6 Jul 2007 10:06:34 -0600 (MDT) Message-ID: <468E688A.3040700@jabber.org> Date: Fri, 06 Jul 2007 10:06:34 -0600 From: Peter Saint-Andre <stpeter@jabber.org> Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Re: I-D Action:draft-ietf-sieve-notify-08.txt References: <E1I6q4H-0000le-A1@stiedprstage1.ietf.org> In-Reply-To: <E1I6q4H-0000le-A1@stiedprstage1.ietf.org> Jabber-ID: stpeter@jabber.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050408060103040601010605" Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> This is a cryptographically signed message in MIME format. --------------ms050408060103040601010605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-08.txt What is the changelog from -07? Peter --------------ms050408060103040601010605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGowggdSoAMCAQICAwFotjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwNzA1MTYxODMyWhcNMDgwNzA0MTYxODMyWjCBwjELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxIjAgBgNVBAoTGVhN UFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2Vy dGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3 DQEJARYSc3RwZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAoRCp9cymHb9V1L04LWCmN2wQEbHFWrmgFnAPxRVQpMsB4ifl5iYSDICmBkLINum2inq9 /+0Fz6ScCEONYC/CDOkkmLPItEDNZ0gdUd+kl+5wMPI+567ttt85ResrUAN0B/gcp+prQKxS 7uM6JcSxC0PdwrWK9pWwxPR+LveLgX9/oE9jSSy5BIQnZVgH8nhjlNMcfkTw/hVuGD/8HJFX 1MVySNt7Qy38Kc3CALmuR3ulGUkYeepGUHXj3gdITJ1CKSKCTq6hqzjTZ4m2BDAdIV4LVVlZ pH8AFs7zcl6HuQ2jLAXqBH97iSHjm5bziC9PaNmAbQkLYIPqSK46YdnSmwIDAQABo4IEeDCC BHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBS08ly4gUAQeznlzuQXQlnPQN0HMTCB3QYDVR0jBIHVMIHSgBQE rNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz cmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsT EUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0g BIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20g THRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZh aWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRd MFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4 MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3Vz ZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3Mz LnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRD b20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAL7ynZiQ7FHEMcQsQetYQwDHKql1d2dBtPtW YjPvU62LyZHbqFKVc2oA6rKaGBqpUKVYUyoBkfJkyAz5/YgrFufw5mnrqysjctDMKTsjdtvu NnL0pIGnvZsQhlL/sTUV/hDOBv00ypsbHXpv5YrVKpCw4Vs9rwSo/5o8f2K8dMHbNB4dv3GX JfMGQUHR/UDTiMqMOxSRAXQ6xGBwNr3zmfDys7qtgoSqy9nBy3er12WRN10jUjdJsFv11Syh 1qyRr+RH0z3Yz6gfd0tq1S9sdzDZ+hFAai3eyjKU6kNLneumEu0w1jeL9EiDRioFsEqCYTuu +c4/cvqC+T/dP89QbGowgghqMIIHUqADAgECAgMBaLYwDQYJKoZIhvcNAQEFBQAwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnMB4XDTA3MDcwNTE2MTgzMloXDTA4MDcwNDE2MTgzMlowgcIxCzAJBgNVBAYT AlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQ IFN0YW5kYXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRp ZmljYXRlIE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0B CQEWEnN0cGV0ZXJAamFiYmVyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKEQqfXMph2/VdS9OC1gpjdsEBGxxVq5oBZwD8UVUKTLAeIn5eYmEgyApgZCyDbptop6vf/t Bc+knAhDjWAvwgzpJJizyLRAzWdIHVHfpJfucDDyPueu7bbfOUXrK1ADdAf4HKfqa0CsUu7j OiXEsQtD3cK1ivaVsMT0fi73i4F/f6BPY0ksuQSEJ2VYB/J4Y5TTHH5E8P4Vbhg//ByRV9TF ckjbe0Mt/CnNwgC5rkd7pRlJGHnqRlB1494HSEydQikigk6uoas402eJtgQwHSFeC1VZWaR/ ABbO83Jeh7kNoywF6gR/e4kh45uW84gvT2jZgG0JC2CD6kiuOmHZ0psCAwEAAaOCBHgwggR0 MAwGA1UdEwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAdBgNVHQ4EFgQUtPJcuIFAEHs55c7kF0JZz0DdBzEwgd0GA1UdIwSB1TCB0oAUBKzb JHdTRkaWXxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3Jh ZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFD QSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASC ATcwggEzMIIBLwYLKwYBBAGBtTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBb MCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4Yl aHR0cDovL2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2 MDcGCCsGAQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2Vy L2NhMDsGCCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51 c2VyLmNhLmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29t IFRydXN0ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC+8p2YkOxRxDHELEHrWEMAxyqpdXdnQbT7VmIz 71Oti8mR26hSlXNqAOqymhgaqVClWFMqAZHyZMgM+f2IKxbn8OZp66srI3LQzCk7I3bb7jZy 9KSBp72bEIZS/7E1Ff4Qzgb9NMqbGx16b+WK1SqQsOFbPa8EqP+aPH9ivHTB2zQeHb9xlyXz BkFB0f1A04jKjDsUkQF0OsRgcDa985nw8rO6rYKEqsvZwct3q9dlkTddI1I3SbBb9dUsodas ka/kR9M92M+oH3dLatUvbHcw2foRQGot3soylOpDS53rphLtMNY3i/RIg0YqBbBKgmE7rvnO P3L6gvk/3T/PUGxqMYIELDCCBCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJ c3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZp Y2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwg RnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYwCQYFKw4D AhoFAKCCAkkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcw NzA2MTYwNjM0WjAjBgkqhkiG9w0BCQQxFgQULJkSJtZpDvQZ+0qjby6Bzcnm/fQwUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UE BhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UE CxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNz IDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNv bS5vcmcCAwFotjCBygYLKoZIhvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYD VQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBD ZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkg RW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYw DQYJKoZIhvcNAQEBBQAEggEAB3w2ETATWV3+Dmol6YtF+0gOcK9di+t7rMSfYqFbA1rrmGch MmVzFuWi2V754qxlfMNKo78Sk40bz06d/EZRJZGDKx99rFJgxa701krXoGF3NBf499onLALR R5ctiojitjQegR+7/7yTCpX4YagVW64mVxOfQb/qouZllKxqmwDWSz4ni/KIofWUlifX36C9 MejS+pfjYmkcEcIFzPFPMkfA5JsbdQ9/O8S5Ba4hqtxiTT8PKKKRA2MZn1fOhcER5ihvvB1t 9ztmTMMrCGICac2DfbfF3ocmQmPrkVik3dhF98iFw8ciE5sAnuuHhZB26GuHGDdUcZ8yr0Om JaayDAAAAAAAAA== --------------ms050408060103040601010605-- 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 l66FoHrc011114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 08:50: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 l66FoH1r011113; Fri, 6 Jul 2007 08:50: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 ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l66FoGT3011107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-mta-filters@imc.org>; Fri, 6 Jul 2007 08:50:17 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 83B722ACAE; Fri, 6 Jul 2007 15:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6q4H-0000le-A1; Fri, 06 Jul 2007 11:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-mta-filters@imc.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-sieve-notify-08.txt Message-Id: <E1I6q4H-0000le-A1@stiedprstage1.ietf.org> Date: Fri, 06 Jul 2007 11:50:01 -0400 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF. Title : Sieve Extension: Notifications Author(s) : A. Melnikov, et al. Filename : draft-ietf-sieve-notify-08.txt Pages : 19 Date : 2007-07-06 Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method but it is expected that using existing instant messaging infrastructure such as XMPP, or SMS messages will be popular. This draft describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sieve-notify-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sieve-notify-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-07-06114933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sieve-notify-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sieve-notify-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-06114933.I-D\@ietf.org> --OtherAccess-- --NextPart-- 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 l662Job5033512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 19:19:50 -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 l662JoFN033511; Thu, 5 Jul 2007 19:19:50 -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 mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l662JkY9033503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-mta-filters@imc.org>; Thu, 5 Jul 2007 19:19:49 -0700 (MST) (envelope-from cyrus@daboo.name) Received: from [10.0.1.2] ([10.0.1.2]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l662JjDr032265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-mta-filters@imc.org>; Thu, 5 Jul 2007 22:19:45 -0400 Date: Thu, 05 Jul 2007 22:19:45 -0400 From: Cyrus Daboo <cyrus@daboo.name> To: SIEVE <ietf-mta-filters@imc.org> Subject: WGLC: draft-ietf-sieve-notify-xmpp-04.txt Message-ID: <3FBEC48D26F4672552BF342C@ninevah.local> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Hi folks, I am initiating a two week working group last call for the draft-ietf-sieve-notify-xmpp-04.txt document. Please review this and send any comments to the list. The last call will end at 5 pm EST on July 19th. -- Cyrus Daboo
- vacation and SMTP Dilyan Palauzov
- Re: vacation and SMTP Ned Freed