Subject: vacation and SMTP

From: Dilyan Palauzov <[email-masked]>
Date: Thu, 19 Jul 2007 15:49:21 +0200

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

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Jul 2007 07:37:50 -0700 (PDT)

> 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

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.

> 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.

> 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

Cc: IETF Sieve <[email-masked]>
Date: Thu, 19 Jul 2007 07:37:50 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: vacation and SMTP
To: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

> 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

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.

> 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.

> 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

Date: Thu, 19 Jul 2007 15:49:21 +0200
From: Dilyan Palauzov <[email-masked]>
To: IETF Sieve <[email-masked]>
Subject: vacation and SMTP
Sender: [email-masked]

    Hello,

   EHLO
   250 OK
   MAIL FROM:<Petra>
   250 OK
   RCPT TO:<Carsten>

   Greetings,
     Dilyan

Date: Sun, 15 Jul 2007 14:55:53 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: "reject" and SMTP
Cc: Aaron Stone <[email-masked]>, Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

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

Subject: Re: "reject" and SMTP
From: Aaron Stone <[email-masked]>
To: Dilyan Palauzov <[email-masked]>
Cc: IETF Sieve WG <[email-masked]>
Date: Sat, 14 Jul 2007 19:11:48 -0700
Sender: [email-masked]

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 [email-masked] accepts the message and 
> [email-masked] 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 [email-masked] accepts the message while [email-masked]
rejects it. I would imagine that your example would conclude like this:

> C: mail from: [email-masked]
> S: 2.1.0 [email-masked]... Sender ok
> C: rcpt to: [email-masked]
> S: 2.1.5 [email-masked]... Recipient ok
> C: rcpt to: [email-masked]
> S: 2.1.5 [email-masked]... Recipient ok
> C: DATA
> C: That's all
> C: .
S: 250 OK
S: 215 Recipient <[email-masked]> OK
S: 571 Recipient <[email-masked]> 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

X-Mail-Sent-By-AEGEE.org-Account: Dilyan [email-masked]
Date: Sat, 14 Jul 2007 21:22:42 +0200
From: Dilyan Palauzov <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: "reject" and SMTP
Sender: [email-masked]

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: [email-masked]
S: 2.1.0 [email-masked]... Sender ok
C: rcpt to: [email-masked]
S: 2.1.5 [email-masked]... Recipient ok
C: rcpt to: [email-masked]
S: 2.1.5 [email-masked]... Recipient ok
C: DATA
C: That's all
C: .
S: ???
What shall the server answer, when [email-masked] accepts the message and 
[email-masked] does not (=makes sieve's refuse)?

Greetings,
Дилян

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-notify-mailto-04.txt 
Date: Thu, 12 Jul 2007 15:15:01 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-editheader-09.txt 
Date: Wed, 11 Jul 2007 15:15:02 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-sieve-mime-loop-03.txt 
Date: Mon, 09 Jul 2007 02:20:01 -0400
Sender: [email-masked]

--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,
[email-masked].
                                                                                           
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
[email-masked] 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:
        [email-masked].
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="[email-masked]"
                                                                                           
Content-Type: text/plain
Content-ID:     <[email-masked]>

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--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-notify-mailto-03.txt 
Date: Sun, 08 Jul 2007 17:15:02 -0400
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 06 Jul 2007 17:29:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-08.txt
Sender: [email-masked]

Peter Saint-Andre wrote:

>[email-masked] 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?

Date: Fri, 06 Jul 2007 10:06:34 -0600
From: Peter Saint-Andre <[email-masked]>
Organization: XMPP Standards Foundation
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-08.txt
Jabber-ID: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050408060103040601010605
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

[email-masked] 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

--------------ms050408060103040601010605--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-sieve-notify-08.txt 
Date: Fri, 06 Jul 2007 11:50:01 -0400
Sender: [email-masked]

--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
[email-masked] 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:
        [email-masked].
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="[email-masked]"
                                                                                           
Content-Type: text/plain
Content-ID:     <[email-masked]>

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--

Date: Thu, 05 Jul 2007 22:19:45 -0400
From: Cyrus Daboo <[email-masked]>
To: SIEVE <[email-masked]>
Subject: WGLC: draft-ietf-sieve-notify-xmpp-04.txt
Sender: [email-masked]

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