Subject: A question/comment on the envelope test regarding envelope parts

From: Stephan Bosch <[email-masked]>
Date: Sun, 27 Jul 2008 23:22:07 +0200

Hello,

I am currently working towards the first release of a new Sieve 
implementation by doing an extensive standards compliance review of all 
that I've implemented thus far. Among others, I have one question about 
the envelope test that also has some relevance to the new notary 
extension that you are about to discuss in Dublin.

According to section 5.4 of the main Sieve specification (rfc5228), the 
envelope test can be extended with support for new envelope parts. The 
ones specified in that main document are both addresses and thus the 
ADDRESS-PART argument makes perfect sense. However, due to its 
extendability, I started wondering what would happen if one were to 
extend the envelope test with envelope parts that do not represent an 
address in the sense of rfc(2)822. Today I noticed that that is exactly 
what the notary extension does.

Currently, my implementation would mangle the non-address envelope part 
through the address part processing, which for instance for the :all 
address part tries to normalize the address to the string 
"local_part@domain" before string comparison. Given the fact that the 
rfc 5228 states that 'If an optional address-part is omitted, the 
default is ":all".' (section 2.7.4), there is (in my view) currently no 
standardized way around this problem.

The new notary draft does not mention the interaction with address parts 
either. In my opinion it would be best to prohibit the use of an 
ADDRESS-PART parameter for an envelope test that involves envelope parts 
that represent no addresses and let the matching act on unprocessed 
string values. At the very least I think that this issue needs to be 
dealt with explicitly in a future version of rfc 5228 and possibly also 
in the new notary specification.

In case I've missed something that voids this issue, any clarification 
is greatly appreciated.

Best regards,

--
Stephan Bosch
[email-masked]

---

From: Ned Freed <[email-masked]>
Date: Tue, 29 Jul 2008 18:51:43 -0700 (PDT)

> "local_part@domain" before string comparison.

AFAIK such normalization isn't called for anywhere in RFC 5228. Indeed, the RFC
goes out of its way to allow :all to be used to perform tests on syntactically
invalid envelope field values. So if your implementation attempts some sort of
normalization, fails, and ends up with something other than the original
string, I'd have to call that broken.

The only processing you're supposed to do is the removal of source routes from
fields that allow them. (It wouldn't hurt to clarify that this shouldn't change
a syntactically invalid stuff in the next revision.)

> Given the fact that the

I disagree. To the extent this is an issue, it is a consequence of an
implementation choice you made. That choice already isn't correct if it
prevents :all from being used with syntactically invalid addresses and it won't
be correct for the new fields the notary draft adds.

> string values.

Since :localpart or :domain make no sense on anything other than an address
field, this seems like a reasonable restriction to me.

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 30 Jul 2008 10:01:28 +0200

> string, I'd have to call that broken.
Agreed, I see that now, thanks.

Btw, I was also referring to the wrong RFC regarding the addresses :)
> field, this seems like a reasonable restriction to me.
Ok, I am glad that you agree.

Regards,

Stephan.

Date: Wed, 30 Jul 2008 10:01:28 +0200
From: Stephan Bosch <[email-masked]>
To: Ned Freed <[email-masked]>
CC: SIEVE <[email-masked]>
Subject: Re: A question/comment on the envelope test regarding envelope parts
Sender: [email-masked]

> string, I'd have to call that broken.
Agreed, I see that now, thanks.

Btw, I was also referring to the wrong RFC regarding the addresses :)
> field, this seems like a reasonable restriction to me.
Ok, I am glad that you agree.

Regards,

Stephan.

Date: Tue, 29 Jul 2008 18:51:43 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: A question/comment on the envelope test regarding envelope parts
To: Stephan Bosch <[email-masked]>
Cc: SIEVE <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

To: [email-masked]
From: Tony Finch <[email-masked]>
Subject: Re: Managesieve Reauthentification. Replication
Date: Mon, 28 Jul 2008 13:24:21 +0100
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> wrote:
>[email-masked] wrote:
>> Are there any reasons to include "Reauthentication is not supported by=20
>> ManageSieve protocol's profile of SASL.  I.e. after a successfully=20
>> completed AUTHENTICATE command, no more AUTHENTICATE commands may be=20
>> issued in the same session." in draft-martin-managesieve-10/2.1=20
>> AUTHENTICATE Command ?
>
>That makes it possible to drop privileges on authentication.

We have a distributed mail store, where each back-end Cyrus server hosts
a subset of the users, and front-end proxy servers direct connections
depending on the user that logs in. The proxy only needs to implement
enough POP/IMAP/managesieve to allow the user to log in, then it knows
the username and can find out which back-end server to connect to. After
a successful login the proxy just shovels bytes back and forth.

Reauthentication would require a much more complicated proxy.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FORTIES CROMARTY FORTH TYNE: EASTERLY 3 OR 4, INCREASING 5 OR 6 IN FORTIES AND
CROMARTY. SLIGHT OR MODERATE. THUNDERY SHOWERS, FOG BANKS. MODERATE,
OCCASIONALLY VERY POOR.

Date: Mon, 28 Jul 2008 12:50:43 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Managesieve Reauthentification. Replication
Sender: [email-masked]

=E4=C9=CC=D1=CE =F0=C1=CC=C1=D5=DA=CF=D7 writes:
> Hello Arnt,
>
> About reauthentification:
> > That makes it possible to drop privileges on authentication.
> Could you explain this with a little bit more words?

Dropping privileges means that the process voluntarily gives up the=20
rights to do something. In the case of managesieve, the server process=20
voluntarily gives up the ability to access or modify files belonging to=20
any user other than a specified one, and it cannot recover that ability=20
later.

This is often used to limit the effects of bugs, particularly security =
bugs.

Arnt

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Mon, 28 Jul 2008 12:28:18 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: Re: Managesieve Reauthentification. Replication
Sender: [email-masked]

Hello Arnt,

 > Why are these independent? Why would you want to have lots of
 > different user names and passwords for owner-N2, N2,
 > N2-unsub... etc?
 >
 > It seems to me that what you really want is an extended setactive
 > command or cross-user includes.

owner-N2 and N2-request are not users, but addresses. To upload scripts 
over managesieve it is not possible to give an address, one has first to 
authenticate and then username=address. The "username" does not have to 
belong to some user, as far as one authenticates with the "master user" 
who can install global and private scripts for other users. There is no 
password for the non-existent users N2-request, owner-N2. The latter are 
addresses.

N2 is a mailing list and in consequence the addresses owner-N2, 
N2-unsub... etc do exist. The scripts for that addresses do not have to 
be independent, it can be the same script, however this are different 
addresses, uncoupled from IMAP. Under this circumstances, the sieve 
interpretation has either to find out that owner-N2 and N2-request are 
supposed to have the same script (transited to imap terms, the addresses 
end in the same mailbox), or to install scripts for each user 
independently. In the latter case the sieve interpretation can consider 
the owner-N2, N2-request etc as normal recipients and obtain their 
scripts in the usual way. If the interpretation has to find out that 
owner-N2 and N2-request are related, then it is first more difficult (to 
integrate this information when uploading the script), and second the 
scripts for owner-N2, N2-request etc are supposed to coincide. This is 
not necessary.

About reauthentification:
 > That makes it possible to drop privileges on authentication.
Could you explain this with a little bit more words?

	Със здраве,
		Дилян

Arnt Gulbrandsen schrieb:
> 
> Another response, independent.
> 
> Дилян Палаузов writes:
>> If for some reason a lot of sieve scripts are generated and need to be 
>> uploaded, then the uploading application has to make several 
>> connections to the managesieve server (using the same master authname 
>> that can edit all scripts and different usernames). E.g. when the 
>> scripts for a mailing list N2 are generated, the users owner-N2@, N2@, 
>> N2-unsubscribe-request@, N2-subscribe-request@, N2-request@ need to be 
>> uploaded in different connections to the managesieve server.
> 
> Why are these independent? Why would you wat to have lots of different 
> user names and passwords for owner-N2, N2, N2-unsub... etc?
> 
> It seems to me that what you really want is an extended setactive 
> command or cross-user includes.
> 
> Arnt
> 

Date: Sun, 27 Jul 2008 23:33:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Managesieve Reauthentification. Replication
Sender: [email-masked]

Another response, independent.

=E4=C9=CC=D1=CE =F0=C1=CC=C1=D5=DA=CF=D7 writes:
> If for some reason a lot of sieve scripts are generated and need to be=20
> uploaded, then the uploading application has to make several=20
> connections to the managesieve server (using the same master authname=20
> that can edit all scripts and different usernames). E.g. when the=20
> scripts for a mailing list N2 are generated, the users owner-N2@,=20
> N2@, N2-unsubscribe-request@, N2-subscribe-request@, N2-request@ need=20
> to be uploaded in different connections to the managesieve server.

Why are these independent? Why would you wat to have lots of different=20
user names and passwords for owner-N2, N2, N2-unsub... etc?

It seems to me that what you really want is an extended setactive=20
command or cross-user includes.

Arnt

Date: Sun, 27 Jul 2008 23:29:21 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Managesieve Reauthentification. Replication
Sender: [email-masked]

=E4=C9=CC=D1=CE =F0=C1=CC=C1=D5=DA=CF=D7 writes:
> Are there any reasons to include "Reauthentication is not supported by=20
> ManageSieve protocol's profile of SASL.  I.e. after a successfully=20
> completed AUTHENTICATE command, no more AUTHENTICATE commands may be=20
> issued in the same session." in draft-martin-managesieve-10/2.1=20
> AUTHENTICATE Command ?

That makes it possible to drop privileges on authentication.

Arnt

Date: Sun, 27 Jul 2008 23:22:07 +0200
From: Stephan Bosch <[email-masked]>
To: SIEVE <[email-masked]>
CC: [email-masked]
Subject: A question/comment on the envelope test regarding envelope parts
Sender: [email-masked]

Hello,

Best regards,

--
Stephan Bosch
[email-masked]

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Sun, 27 Jul 2008 20:18:18 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: Managesieve Reauthentification. Replication
Sender: [email-masked]

Hello,

Are there any reasons to include "Reauthentication is not supported by 
ManageSieve protocol's profile of SASL.  I.e. after a successfully 
completed AUTHENTICATE command, no more AUTHENTICATE commands may be 
issued in the same session." in draft-martin-managesieve-10/2.1 
AUTHENTICATE Command ?

If for some reason a lot of sieve scripts are generated and need to be 
uploaded, then the uploading application has to make several connections 
to the managesieve server (using the same master authname that can edit 
all scripts and different usernames). E.g. when the scripts for a 
mailing list N2 are generated, the users owner-N2@, N2@, 
N2-unsubscribe-request@, N2-subscribe-request@, N2-request@ need to be 
uploaded in different connections to the managesieve server. This is 
less efficient than using the same managesieve connection and 
reauthenticating from time to time. Now imagine that one wants to 
regenrate the scripts for all lists on her server ... a lot of 
connections need to be established. (A mailing list needs sieve script 
that does SMTP rejects and hence saves one bounce at later time).

Moreover, if a domain has several MX DNS records, all scripts among the 
mail servers shall be consistent to some extend. It would be useful if 
the managesieve servers can use managesieve as protocol for replication 
among each other. This could be achieved if the LISTSCRIPT command (or a 
new command) can provide a timestamp when the script was uploaded. And 
one more command shall allow the master user (the one that can 
authenticate with different usernames) to list all users who have 
uploaded scripts and the timestamp when the user last changed his 
script. Going a step furhter, during the replication one server shall be 
able to request the list of the users who changed their scripts only 
after a given timestamp.

	Със здраве,
		Дилян

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email  Filtering: Reject and Extended Reject Extensions) to Proposed  Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Sun, 27 Jul 2008 05:02:56 -0700 (PDT)
Sender: [email-masked]

The IESG has received a request from the Sieve Mail Filtering Language 
WG (sieve) to consider the following document:

- 'Sieve Email Filtering: Reject and Extended Reject Extensions '
   <draft-ietf-sieve-refuse-reject-07.txt> as a Proposed Standard

This document has a normative reference to RFC 2033 which documents LMTP,
Local Mail Transfor Protocol.  Support for LMTP is not required for
servers supporting the mechanisms in this specification.  The 
procedure of RFC 3967 is applied in this last call to approve the 
downward reference. 

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-08-10. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-07.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13141&rfc_flag=0

Date: Sat, 26 Jul 2008 22:02:27 +0100
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Sender: [email-masked]

Ned Freed wrote:

>>I guess that one thing we're trying to work around is the fact that
>>systems that are the target of a notification message, and that might
>>pass it on to where it loops back around, can't be relied on to pass
>>whole headers, and so things like Received counting or looking at (e.g.)
>>"Delivered-To" can't be counted on as those fields might get stripped.
>>As might the original "Auto-Submitted" field, so this technique either
>>relies on this field being preserved, or on one of the downstream notifiers
>>or forwarders adding one of their own.  That all strikes me as kind of
>>shakey in addition to being a mis-use of this field.
>>    
>>
>Agreed. FWIW, my suggestion was to add a parameter to auto-submitted that
>uniquely identifies the auto-submitter so that that can be checked and loops
>detected that way. But this got shot down for some reason I no longer recall.
>  
>
I thought "owner-token" described in section 2.7.1 is your parameter?

Date: Wed, 23 Jul 2008 07:57:00 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: refuse/reject implementations?
To: Cyrus Daboo <[email-masked]>
Cc: IETF Sieve WG <[email-masked]>
Sender: [email-masked]

> Has anyone done a complete implementation of the current refuse-reject
> specification?

We have.

				Ned

Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked]
Date: Wed, 23 Jul 2008 12:43:11 +0200
Sender: [email-masked]

On Tue, 2008-07-22 at 21:31 -0400, Jeffrey Hutzelman wrote:
> Kjetil Torgrim Homme <[email-masked]> wrote:
> > I think I'd prefer if this trick wasn't mentioned explicitly, but yes, I
> > think that would be a valid implementation.  The draft says
> >
> >         The "Received:" fields from the triggering message MAY be
> >         retained in the notification message [...]
> >
> > and I personally would prefer it if implementations chose that route.
> 
> That seems problematic, if any of the servers mentioned in those headers 
> also appear on the path the notification takes and are using them to do 
> loop detection.

does anyone do this?  such a scheme will be wrought with false positives
in the presence of forwarding or even mailing lists, unless they expose
detailed recipient information, which would conflict with privacy
concerns.

> The notification, which in fact is a _new_ message, has 
> _not_ been received or processed by those servers.

its existence is a direct and automatic consequence of the original
message, so I don't think it is unreasonable to be able to trace it back
to the Prime Mover, as the ancient Greeks would say.

> What's the point of this?  Is it to drive the count of Received headers in 
> notifications up so high that they don't actually get through?

basically, yes :-)

seriously, the hop count limits are generally generous, so I don't think
this will be a problem in practice.  e.g., your server adds one
Received, and mine adds three.  Majordomo at IMC introduces 4 more hops,
which brings the total to 8.  that's a lot of lee-way for additional
forwarding servers.
-- 
regards,
Kjetil T.

Date: Tue, 22 Jul 2008 22:55:58 -0400
From: Cyrus Daboo <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: refuse/reject implementations?
Sender: [email-masked]

Hi,
Has anyone done a complete implementation of the current refuse-reject 
specification? I am working on the write-up for the IESG and I want to note 
if there are any implementations of this.

-- 
Cyrus Daboo

Date: Tue, 22 Jul 2008 16:51:40 -0600
From: Philip Guenther <[email-masked]>
To: =?KOI8-R?B?5MnM0c4g8MHMwdXaz9c=?= <[email-masked]>
cc: IETF Sieve WG <[email-masked]>
Subject: Re: redirect / ereject loops
Sender: [email-masked]

On Tue, 22 Jul 2008, ????? ???????? wrote:
> While you are talking about loops with "notify mailto", I would like to 
> ask you about loops with "redirect". I redirect the mail for my 
> university account to uni@mydomain, which has the following script:
> 
> if header :contains "X-Spam-Level" "+++++"
>         {
>                 redirect "me@mydomain";
>                 stop;
>         }
> 
> So, when a spam arrives, the responsibility for the mail is taken and 
> the mail is redirected to me@mydomain. In the past me@mydomain moved 
> such mails to INBOX.Spam, but recently I changed the script to
> 
> require ["ereject"];
> 
> if header :contains "X-Spam-Level" "+++++"
>         {
>         ereject "Your mail was evaluated as spam and was not delivered.
> However you can contact me at +49 721 755345(h) or +49 176 20700494(m).";
>         stop;
>         }
> 
> and ereject does SMTP reject.  Such redirecting script is also installed 
> for the postmaster@.

When you say "Such redirecting script", do you mean the one for 
uni@mydomain which uses redirect, or the one for me@mydomain which uses 
ereject?

> Now my question is, what happens with the spam 
> mail: it entered the system being accepted by uni@mydomain, but it 
> cannot end in a mailbox.

_That_ message, the one with "X-Spam-Level: +++++", can't, but the ereject 
*may* result in a new message, a DSN (aka "bounce").  Whether it does so 
depends on the configuration of the mydomain sieve implementation.

If the redirect just queues the redirected message without immediately 
trying to process it, then the ereject will result in a DSN coming back to 
the envelope sender of the redirect, which may be either uni@mydomain or 
the original envelope sender of the spam.

If the redirection is processed to completion, including the ereject by 
the target address, then the original redirect will fail, which will then 
result in the original message being delivered to uni@mydomain's INBOX 
(c.f., rfc 5228, section 2.10.6, particularly the last paragraph).

(Those are just two of the possible scenarios.  Staring a log files may 
give you ideas for other possibilities.)

> At the end it enters the postmaster mailbox, 
> bypassing somehow (to be figured out) the spam filter and growing to 
> 500k.

If the DSN went to the original envelope sender, it will may be rejected 
by the far end, in which case it's a "double bounce", which often go to 
postmaster by default.

For the postmaster account, ereject is just a Bad Idea.  Use discard.

Perform spam rejection early/at the edge: forwarding spam to some other 
account is just a problem waiting to happen.

 I have uploaded one such message at 
> https://mail.aegee.org/~didopalauzov/Automatically%20rejected%20mail.eml 
> .

Ha, nice.  Looks like a bounce loop all right.  Note that the sieve 
implementation there is violating the MIME spec by using multipart 
boundary strings that are present in the message being wrapped: 
"$pid/$host" ain't good enough.

Philip Guenther

Date: Tue, 22 Jul 2008 15:04:43 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: redirect / ereject loops
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Cc: IETF Sieve WG <[email-masked]>
Sender: [email-masked]

> While you are talking about loops with "notify mailto", I would like to
> ask you about loops with "redirect".

These are very different cases. Perhaps the biggest difference is that loop
detection via Received: fields is much easier with redirect since its the same
message rather than a different one.

> I redirect the mail for my
> university account to uni@mydomain, which has the following script:

> if header :contains "X-Spam-Level" "+++++"
>          {
>                  redirect "me@mydomain";
>                  stop;
>          }

> So, when a spam arrives, the responsibility for the mail is taken and
> the mail is redirected to me@mydomain. In the past me@mydomain moved
> such mails to INBOX.Spam, but recently I changed the script to

> require ["ereject"];

> if header :contains "X-Spam-Level" "+++++"
>          {
>          ereject "Your mail was evaluated as spam and was not delivered.
> However you can contact me at +49 721 755345(h) or +49 176 20700494(m).";
>          stop;
>          }

First of all, using any sort of SMTP level reject on an interior MtA is a bad
idea. The problem is once a message enters an administrative domain your
options narrow down to discarding it, delivering it, or returning a nondelivery
notification. The option of simply telling the outside sender the message was
rejected no longer exists, and that's the one case where ereject is useful.

Now, in this specific case, you have two sieves on different systems, the first
redirecting to the second and the second performing an ereject. What happens is
going to depend on what redirect did to the envelope from address. The
base Sieve specification allows substantial leeway here.

If it is left unchanged then the nondelivery notification will go back to the
(likely forged) original sender's address. And lo and behold you've just become
a blowback spam generator. But this is the result of improper use of ereject,
not a problem with redirect.

Alternately, the Sieve implementation could have changed the envelope from to
the owner of the Sieve script. In this case what should happen is that the
nondelivery notification will go to the Sieve owner, causing the script with
the redirect to be invoked again. If in the process the message has again been
checked for spam and has been judged to be spammy, the nondelivery notification
will then be redirected. But since the nondelivery notification is required to
have a blank envelope from address and redirect is forbidden from changing a
blank envelope from into a nonblank envelope from, when the ereject is reached
again this time it will cause the message to be silently discarded. So in this
case the message ends up getting silently dropped. And your ereject has turned
into a discard after taking several extra hops and comsuming a bunch more
resources.

It is also possible that wrapping the original spammy message inside a
nondelivery notification will prevent it from be found to be spammy a second
time. In this case the redirect won't trigger and the message will get
delivered on the first system. In this case your ereject led to a pointless
nondelivery notification being sent to someone.

One final possibility is that the Sieve implementation elected to put some
other address in the envelope from. In that case what happens would depend on
where that address leads, but once again you have a pointless nondelivery
notification being sent somehwere it's not needed.

The main takeaway here is that in no case is the use of ereject actually of
benefit.

> and ereject does SMTP reject. Such redirecting script is also installed
> for the postmaster@. Now my question is, what happens with the spam
> mail: it entered the system being accepted by uni@mydomain, but it
> cannot end in a mailbox.

Quite the contrary, depending on various factors it can easily end up in a
mailbox somewhere. See above.

> At the end it enters the postmaster mailbox,
> bypassing somehow (to be figured out) the spam filter and growing to
> 500k. I have uploaded one such message at
> https://mail.aegee.org/~didopalauzov/Automatically%20rejected%20mail.eml .

This shows that you have managed to create a notification loop. This in turn
means that something in your setup is not in compliance with the relevant
standards. More specifically, either (1) The SMTP client receiving the result
of the ereject is generating a nondelivery notification with a nonempty
envelope form - an egregious violation of several standards documents or (2)
Something along the path is filling in the empty envelope from - a violation of
the requirements in RFC 5228 section 4.2. My guess is it's (2) - this case is
exactly why the "don't muck with empty envelope froms" rule was imposed.

> Is this normal?

No. The only way this can happen is if there's breakage somewhere.

> Any ideas what to do?

Fix whatever is incompliant in your setup and reconsider your use of ereject
in this context.

				Ned

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Tue, 22 Jul 2008 23:33:51 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: redirect / ereject loops
Sender: [email-masked]

Hello,

While you are talking about loops with "notify mailto", I would like to 
ask you about loops with "redirect". I redirect the mail for my 
university account to uni@mydomain, which has the following script:

if header :contains "X-Spam-Level" "+++++"
         {
                 redirect "me@mydomain";
                 stop;
         }

So, when a spam arrives, the responsibility for the mail is taken and 
the mail is redirected to me@mydomain. In the past me@mydomain moved 
such mails to INBOX.Spam, but recently I changed the script to

require ["ereject"];

if header :contains "X-Spam-Level" "+++++"
         {
         ereject "Your mail was evaluated as spam and was not delivered.
However you can contact me at +49 721 755345(h) or +49 176 20700494(m).";
         stop;
         }

and ereject does SMTP reject. Such redirecting script is also installed 
for the postmaster@. Now my question is, what happens with the spam 
mail: it entered the system being accepted by uni@mydomain, but it 
cannot end in a mailbox. At the end it enters the postmaster mailbox, 
bypassing somehow (to be figured out) the spam filter and growing to 
500k. I have uploaded one such message at 
https://mail.aegee.org/~didopalauzov/Automatically%20rejected%20mail.eml .

Is this normal? Any ideas what to do?

	Със здраве,
		Дилян

Date: Tue, 22 Jul 2008 10:05:47 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
To: Jeffrey Hutzelman <[email-masked]>
Cc: Ned Freed <[email-masked]>, Mark E Mallett <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > P.S. I'm also quite worried given the reception the Sieve base got in
> > regards to the looping potential of redirect that this draft is going to
> > receive at least one DISCUSS vote from the IESG that's going to be very
> > difficult to satisfy.

> As noted above, I think this is very different from redirect, because we
> are generating a new message to a (presumably fixed) recipient, not
> forwarding or responding to an existing message.

FWIW, the Sieve variables extensions makes variable (in the sense that they
depend on the input message) possible. For example:

require ["notify", "mailto"];
if address :matches "from" "*" {
  notify :message "blah blah"
              :importance "3"
              "mailto:${1}";
}

However, given that addresses can be and sometimes are handled by the routing
fabric in fairly perverse ways, including various highly dynamic routing
schemes, I don't think this changes the situation much if at all.

				Ned

Date: Tue, 22 Jul 2008 08:04:34 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Ned Freed <[email-masked]>, Barry Leiba <[email-masked]>, Mark E Mallett <[email-masked]>
Sender: [email-masked]

> Ned Freed writes, quoting Mark E. Mallett:
> >>  I don't think that "Auto-Submitted" is a strong indicator of a
> >>  non-notifiable message, and as I've said I can imagine cases where
> >>  it's just the opposite.
> >
> > Exactly. One of the main use cases we have for Sieve notify is  in
> > what I believe they call a "sensitive" environment - not cut off
> > completely from the rest of the world, but with strict rules about
> > what can and cannot cross boundaries. Since messages, including
> > various sorts of notifications, cannot leave this environment, the
> > goal is to generate notifications that basically say "there's
> > soemthing over here you need to look at" but which never say any more
> > than that and send those out. (Yes, I'm well aware of the potential
> > for traffic analysis here, but I'm not the one who designed or
> > specified any off this.) In this use case it is critically important
> > that all messages be able to generate such a notification. As for
> > loops, they cannot occur since these notification messages can only
> > leave, not reenter.

> Suppose there were some header field which carried enough identification
> to avoid loops. Perhaps a widely supported header field called
> "Message-Based-On:" with a list of message-ids. There isn't any such
> thing, but suppose there were.

Since message-ids are generated by clients they leak information about what
client someone uses. I don't know if such leakage is acceptable; I suspect not.

> IWould the rules of that sensitive prevent use of Message-Based-On?

My guess is yes.

> I have a feeling that the rules would forbid leaking those message-ids
> back out of the sensitive area. If that feeling is right, then there is
> a basic conflict between your customer's needs and the IESG/IETF rules.

I don't see it. AFAIK nobody is proposing using message-ids or any sort  of
information that originates with clients for this. And any identifier that
appears in an auto-submitted field is not comparabie, for several reasons:

(1) MUAs generate auto-submitted fields rarely, and in the cases where they
    do they aren't going to insert a parameter we have yet to specify.

(2) The internal MTAs that generate this paramster may do so using their own
    names, but those names are already present in other header fields in
    notifucations, so this leaks no additional information. It is already
    accepted that traffic analysis can be performed here.

(3) Even if for some reason we clients to be able to generate such a parameter,
    since this is a new parameter we can specify a one way hash scheme for
    it.

In any case, I only mentioned this proposal in passing; the addition of a new
header field to the trace header set is a fairly big deal and I'm not sure it
is warranted to solve this particular problem.

				Ned

From: IESG Secretary <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: WG Review: Recharter of Sieve Mail Filtering (sieve) 
reply-to: [email-masked]
Date: Tue, 22 Jul 2008 08:00:01 -0700 (PDT)
Sender: [email-masked]

A modified charter has been submitted for the Sieve Mail Filtering (sieve)
working group in the Applications Area of the IETF.  The IESG has not made
any determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list ([email-masked]) July 28, 2008.

Sieve Mail Filtering (sieve)
---------------------------------------------------
Last Modified: 2008-07-02

Current Status: Active Working Group

Chair(s):
  Cyrus Daboo <[email-masked]>
  Alexey Melnikov <[email-masked]>

Applications Area Director(s):
  Chris Newman <[email-masked]>
  Lisa Dusseault <[email-masked]>

Applications Area Advisor:
  Lisa Dusseault <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
Archive: http://www.imc.org/ietf-mta-filters/mail-archive/

Description of Working Group:

The SIEVE email filtering language is specified in RFC 5228,  
together with a number of extensions.

The SIEVE working group is being re-chartered to:

(1) Finish work on existing in-progress Working Group documents:

	(a) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
	(b) Edit header (draft-ietf-sieve-editheader-10.txt)
	(c) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
	(d) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

(2) Finalize and publish the following SIEVE extensions as proposed  
standards:

 	(a) iHave (draft-freed-sieve-ihave-02.txt)
 	(b) Notary (draft-freed-sieve-notary-01.txt)
 	(c) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
 	(d) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
 	(e) ManageSIEVE (draft-martin-managesieve-10.txt)
 	(f) RegEx (draft-ietf-sieve-regex-00.txt)
 	(g) Meta-data (draft-melnikov-sieve-imapext-metadata-04.txt)
 	(h) Include/multi-script (draft-daboo-sieve-include-05.txt)
 	(i) Address data (draft-melnikov-sieve-external-lists-01)

Additional drafts may be added to this list, but only via a charter
revision. There must also be demonstrable willingness in the SIEVE
development community to actually implement a given extension before
it can be added to this charter.

(3) Work on a specification to describe how EAI/IDN issues should be  
handled in SIEVE.

(4) Work on a "Benefits of SIEVE" guide for client and server  
vendors that:
 	(a) Describes the SIEVE protocol and its suite of extensions.
 	(b) Explains the benefits of server-side filtering in practical  
terms.
 	(c) Shows how client-side filtering can be migrated to SIEVE.

(5) Produce one or more informational RFCs containing a set of test  
scripts and test email messages that are to be filtered by the  
scripts, and the expected results of that filtering. This will serve  
as the basis of a interoperability test suite to help determine the  
suitability of moving the base specification and selected extensions  
to Draft status.

Goals and milestones:

July 2008:
Submit notify-mailto to IESG
Submit refuse-reject to IESG

August 2008:
Submit mime-loops to IESG
WGLC iHave

September 2008:
Submit iHave to IESG
WGLC Notary

October 2008:
WGLC sieve-in-xml
Submit Notary to IESG

November 2008:
Submit sieve-in-xml to IESG
WGLC ManageSIEVE

December 2008:
Submit ManageSIEVE to IESG
WGLC Notify-sip

January 2009:
Submit Notify-sip to IESG
WGLC Metadata

February 2009:
Submit Metadata to IESG
WGLC RegEx

March 2009
Submit RegEx to IESG
WGLC Include/multi-script

April 2009:
Submit Include/multi-script to IESG
WGLC external-lists

May 2009:
Submit external-lists to IESG
WGLC eai-issues

June 2009:
Submit eai-issues to IESG
WGLC benefits

July 2009:
Submit benefits to IESG
WGLC test-scripts

August 2009:
Submit test-scripts to IESG

Date: Tue, 22 Jul 2008 15:15:04 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Cc: Nigel Swinson <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

Nigel Swinson writes:
> So this whole discussion has made me very reluctant to go anywhere 
> near implementing sieve-notify-mailto, rather sticking to SMS 
> notifications and redirect if I can.

I wanted to do the same thing, but then I found out that the base notify 
document says you MUST implement mailto.

Arnt

X-Spam-Score-scoring_explanation:
X-Spam-Score-spf_status:
X-Spam-Score-Spamcatcher1: a7d1ebdfdca2baf9dc4e68c6d7702445
X-Spam-Score-Summary: 2,0,0,fdb3bdb5c82d7165,a0ea87fb493ec7f7,[email-masked],[email-masked]:[email-masked],RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1542:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2393:2553:2559:2562:2828:2892:2901:3027:3355:3740:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3876:3877:4250:5007:6114:6119:6248:6261:7903,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Barry Leiba" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Date: Tue, 22 Jul 2008 14:00:43 +0100
Sender: [email-masked]

> I'm looking for consensus on one of these:
>
> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.
>
> 2. The use cases for notifications on auto-submitted messages are 
> sufficiently important that the text should be changed.  [Please suggest 
> new text, in this case.]
>
> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
> should be changed to "SHOULD NOT", with some added text to explain the 
> danger very clearly.  [In this case, you can suggest text, or I'll craft 
> it.]
>
> Let's try to get clear consensus on this.  I propose that in the event of 
> no clear consensus, we have to go with (3).

I'm with option 3 just now.  My reasons, some of which have already been 
touched on:

I think the intent of sieve-notify was to do things like notify mobile 
devices, or at least devices with some limited resources that the user has 
more immediate access to.  Re-scanning the abstract seems to back this up. 
As such I think those devices are very unlikely to auto-reply to anything, 
or if they do, then it may not be until they make a connection and receive 
the notification, which would lead for a very slow mail loop.  But then what 
I think the intent of sieve-notify is, and what it'll get used for can of 
course be completely different.

Sieve-notify-mailto is therefore in some ways a poor fit with sieve-notify, 
cos the target could very very easily be capable and willing to auto-reply, 
in which case mail loops become much more likely and dangerous (hence we are 
having this discussion).  If the purpose of sieve-notify-mailto is to hide 
sensitive information from the inbound message, then I wonder if it's better 
handled by modifying redirect rather than piggy backing onto sieve-notify, 
then we're not adding to the existing mail loop concerns created by the use 
of redirect, and standard loop prevention mechanisms apply.  I think the use 
cases proposed to make folks vote for option 2 would be better handled by an 
alternative notification mechanism like SMS where no auto-reply is expected, 
and therefore there's a greatly reduced loop risk.  Option 1/3 both try to 
create a "no auto-repsonse" mimicing what is expected by the other 
sieve-notify mechanisms that it was originally designed for.

So this whole discussion has made me very reluctant to go anywhere near 
implementing sieve-notify-mailto, rather sticking to SMS notifications and 
redirect if I can.

Nigel 

Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Date: Tue, 22 Jul 2008 14:05:40 +0200
Sender: [email-masked]

On Tue, 2008-07-22 at 13:50 +0200, Arnt Gulbrandsen wrote:
> Kjetil Torgrim Homme writes:
> > Here's an alternative compromise: An implementation can not send a 
> > notification in response to a message with "Auto-submitted: !no" 
> > unless the number of Received headers in the notification messages is 
> > higher than in the original message.
> 
> You mean by generating dummy fields?
> 
> Received: by <host> (dummy inserted by sieve); <date>
> Received: by <host> (dummy inserted by sieve); <date>
> Received: by <host> (dummy inserted by sieve); <date>

I think I'd prefer if this trick wasn't mentioned explicitly, but yes, I
think that would be a valid implementation.  The draft says

        The "Received:" fields from the triggering message MAY be
        retained in the notification message [...]

and I personally would prefer it if implementations chose that route.

> I'm not in favour, but I can live with that too if that's what it takes 
> to get WG consensus, IESG blessing and an RFC.

ok.
-- 
regards,
Kjetil T.

Date: Tue, 22 Jul 2008 13:50:34 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Cc: Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

Kjetil Torgrim Homme writes:

> On Tue, 2008-07-22 at 12:47 +0200, Arnt Gulbrandsen wrote:
>>  These are two of the three (or four) options I'm aware of. The third 
>>  is to accept that mail loops happen, but make them less harmful by 
>>  slowing them down. A thousand messages per day isn't so bad, at 
>>  least not compared to 100,000.
>>
>>  It's also possible to combine. The document could say "If the 
>>  incoming message has an Auto-Submitted field, a return-path of <>, 
>>  or other signs that it was automatically generated, then the 
>>  outgoing notification MUST be delayed by at least two minutes", 
>>  with reference RFC 4865 informatively.
>
> This is just too ugly. Users will be forcing implementers to add an 
> override for this behaviour.

Sure. I'd make the period configurable in my own code, down to 1 second. 
What about it?

>>  I'm not really in favour of such a rule. I like the simple 
>>  Auto-Submitted rule. I'm just mentioning this since it is a 
>>  possibility, since we need to find some compromise rule that 
>>  everyone can live with, and this is an area we haven't discussed.
>
> Here's an alternative compromise: An implementation can not send a 
> notification in response to a message with "Auto-submitted: !no" 
> unless the number of Received headers in the notification messages is 
> higher than in the original message.

You mean by generating dummy fields?

I'm not in favour, but I can live with that too if that's what it takes 
to get WG consensus, IESG blessing and an RFC.

Arnt

Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Date: Tue, 22 Jul 2008 11:46:00 +0000
Sender: [email-masked]

> Ned Freed writes:
> > FWIW, my suggestion was to add a parameter to auto-submitted that 
> > uniquely identifies the auto-submitter so that that can be checked 
> > and loops detected that way. But this got shot down for some reason I 
> > no longer recall.

If we could trust that Auto-submitted doesn't get clobbered, it would
suffice to say that a message containing an "Auto-submitted:
auto-notified" header should be silently ignored.

Unfortunately, I don't think we can trust that Auto-submitted is truly
handled as a trace header (ie. multiple instance header) in the
multitude of homegrown applications out there sending automatic
responses.

On Tue, 2008-07-22 at 12:47 +0200, Arnt Gulbrandsen wrote:
> These are two of the three (or four) options I'm aware of. The third is 
> to accept that mail loops happen, but make them less harmful by slowing 
> them down. A thousand messages per day isn't so bad, at least not 
> compared to 100,000.
> 
> It's also possible to combine. The document could say "If the incoming 
> message has an Auto-Submitted field, a return-path of <>, or other 
> signs that it was automatically generated, then the outgoing 
> notification MUST be delayed by at least two minutes", with reference 
> RFC 4865 informatively.

This is just too ugly.  Users will be forcing implementers to add an
override for this behaviour.

> I'm not really in favour of such a rule. I like the simple 
> Auto-Submitted rule. I'm just mentioning this since it is a 
> possibility, since we need to find some compromise rule that everyone 
> can live with, and this is an area we haven't discussed.

Here's an alternative compromise:  An implementation can not send a
notification in response to a message with "Auto-submitted: !no" unless
the number of Received headers in the notification messages is higher
than in the original message.

-- 
regards,
Kjetil T.

Date: Tue, 22 Jul 2008 12:47:48 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Cc: Ned Freed <[email-masked]>, Barry Leiba <[email-masked]>, Mark E Mallett <[email-masked]>
Sender: [email-masked]

Ned Freed writes:
> FWIW, my suggestion was to add a parameter to auto-submitted that 
> uniquely identifies the auto-submitter so that that can be checked 
> and loops detected that way. But this got shot down for some reason I 
> no longer recall.
>
> I also object somewhat to copying Received: fields over that in fact 
> correspond to hops that a totally different message took. The 
> relationship between the notification message and the message that 
> triggered it is just too tenuous. This is a kluge, and IMO not a 
> terribly good one.

These are two of the three (or four) options I'm aware of. The third is 
to accept that mail loops happen, but make them less harmful by slowing 
them down. A thousand messages per day isn't so bad, at least not 
compared to 100,000.

It's also possible to combine. The document could say "If the incoming 
message has an Auto-Submitted field, a return-path of <>, or other 
signs that it was automatically generated, then the outgoing 
notification MUST be delayed by at least two minutes", with reference 
RFC 4865 informatively.

I'm not really in favour of such a rule. I like the simple 
Auto-Submitted rule. I'm just mentioning this since it is a 
possibility, since we need to find some compromise rule that everyone 
can live with, and this is an area we haven't discussed.

Arnt

Date: Tue, 22 Jul 2008 12:33:14 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Cc: Ned Freed <[email-masked]>, Barry Leiba <[email-masked]>, Mark E Mallett <[email-masked]>
Sender: [email-masked]

Ned Freed writes, quoting Mark E. Mallett:
>>  I don't think that "Auto-Submitted" is a strong indicator of a 
>>  non-notifiable message, and as I've said I can imagine cases where 
>>  it's just the opposite.
>
> Exactly. One of the main use cases we have for Sieve notify is  in 
> what I believe they call a "sensitive" environment - not cut off 
> completely from the rest of the world, but with strict rules about 
> what can and cannot cross boundaries. Since messages, including 
> various sorts of notifications, cannot leave this environment, the 
> goal is to generate notifications that basically say "there's 
> soemthing over here you need to look at" but which never say any more 
> than that and send those out. (Yes, I'm well aware of the potential 
> for traffic analysis here, but I'm not the one who designed or 
> specified any off this.) In this use case it is critically important 
> that all messages be able to generate such a notification. As for 
> loops, they cannot occur since these notification messages can only 
> leave, not reenter.

Suppose there were some header field which carried enough identification 
to avoid loops. Perhaps a widely supported header field called 
"Message-Based-On:" with a list of message-ids. There isn't any such 
thing, but suppose there were.

IWould the rules of that sensitive prevent use of Message-Based-On? I 
have a feeling that the rules would forbid leaking those message-ids 
back out of the sensitive area. If that feeling is right, then there is 
a basic conflict between your customer's needs and the IESG/IETF rules.

Arnt
(PS: Another, unrelated reply in a moment.)

Date: Mon, 21 Jul 2008 14:44:57 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
To: Mark E Mallett <[email-masked]>
Cc: Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Tue, Jul 15, 2008 at 10:17:32AM -0400, Barry Leiba wrote:

> > So, everyone: if you consider yourself an active participant, please
> > send a message to this mailing list within the next, say, week, stating
> > (briefly) your position on this.  There's no need for a lot of
> > explanation, because the reasons on both sides are clear.
> >
> > I'm looking for consensus on one of these:
> >
> > 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of
> > loops if we send notifications for auto-submitted messages -- is
> > sufficiently important that the current "MUST NOT" text should stay.
> >
> > 2. The use cases for notifications on auto-submitted messages are
> > sufficiently important that the text should be changed.  [Please suggest
> > new text, in this case.]
> >
> > 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT"
> > should be changed to "SHOULD NOT", with some added text to explain the
> > danger very clearly.  [In this case, you can suggest text, or I'll craft
> > it.]

> I can't find any camp to be in, but I feel that #2 is closest.

I'm in much the same position.

> I don't
> think that "Auto-Submitted" is a strong indicator of a non-notifiable
> message, and as I've said I can imagine cases where it's just the opposite.

Exactly. One of the main use cases we have for Sieve notify is  in what I
believe they call a "sensitive" environment - not cut off completely from the
rest of the world, but with strict rules about what can and cannot cross
boundaries. Since messages, including various sorts of notifications, cannot
leave this environment, the goal is to generate notifications that basically
say "there's soemthing over here you need to look at" but which never say any
more than that and send those out. (Yes, I'm well aware of the potential for
traffic analysis here, but I'm not the one who designed or specified any off
this.) In this use case it is critically important that all messages be able to
generate such a notification. As for loops, they cannot occur since these
notification messages can only leave, not reenter.

I could describe at least one other use-case where notifications cannot be
blocked by auto-submitted fields, but I think this makes the point.

> I guess that one thing we're trying to work around is the fact that
> systems that are the target of a notification message, and that might
> pass it on to where it loops back around, can't be relied on to pass
> whole headers, and so things like Received counting or looking at (e.g.)
> "Delivered-To" can't be counted on as those fields might get stripped.
> As might the original "Auto-Submitted" field, so this technique either
> relies on this field being preserved, or on one of the downstream notifiers
> or forwarders adding one of their own.  That all strikes me as kind of
> shakey in addition to being a mis-use of this field.

Agreed. FWIW, my suggestion was to add a parameter to auto-submitted that
uniquely identifies the auto-submitter so that that can be checked and loops
detected that way. But this got shot down for some reason I no longer recall.

I also object somewhat to copying Received: fields over that in fact correspond
to hops that a totally different message took. The relationship between the
notification message and the message that triggered it is just too tenuous.
This is a kluge, and IMO not a terribly good one.

> So I feel that it's important to make a note about loop prevention; that
> it's hard to do when it's a possibility that most header fields will get
> stripped; but that that doesn't make using "Auto-Submitted" any more
> palatable.  I wish I had text to propose, other than just a strong note
> that somehow detecting loops should be a priority of the implementor.

I tried writing text for this some time ago. Didn't get anything worth
posting.

> I also think that the "MUST NOT" under discussion is almost certain to
> be violated, so I would vote against that.

Our implementation is definitely one that's going to violate it, although we'll
probabky make the check configurable and have it default "on". We simply don't
have a choice here - too many important customers depend on this capability and
if we don't provide it I'm sure someone else will be happy to.

				Ned

P.S. I'm also quite worried given the reception the Sieve base got in regards
to the looping potential of redirect that this draft is going to receive at
least one DISCUSS vote from the IESG that's going to be very difficult to
satisfy.

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 21 Jul 2008 16:15:30 -0400
To: Barry Leiba <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Sender: [email-masked]

On Tue, Jul 15, 2008 at 10:17:32AM -0400, Barry Leiba wrote:

> So, everyone: if you consider yourself an active participant, please 
> send a message to this mailing list within the next, say, week, stating 
> (briefly) your position on this.  There's no need for a lot of 
> explanation, because the reasons on both sides are clear.
> 
> I'm looking for consensus on one of these:
> 
> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.
> 
> 2. The use cases for notifications on auto-submitted messages are 
> sufficiently important that the text should be changed.  [Please suggest 
> new text, in this case.]
> 
> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
> should be changed to "SHOULD NOT", with some added text to explain the 
> danger very clearly.  [In this case, you can suggest text, or I'll craft 
> it.]

I can't find any camp to be in, but I feel that #2 is closest.  I don't
think that "Auto-Submitted" is a strong indicator of a non-notifiable
message, and as I've said I can imagine cases where it's just the opposite.

I guess that one thing we're trying to work around is the fact that
systems that are the target of a notification message, and that might
pass it on to where it loops back around, can't be relied on to pass
whole headers, and so things like Received counting or looking at (e.g.)
"Delivered-To" can't be counted on as those fields might get stripped.
As might the original "Auto-Submitted" field, so this technique either
relies on this field being preserved, or on one of the downstream notifiers
or forwarders adding one of their own.  That all strikes me as kind of
shakey in addition to being a mis-use of this field.

So I feel that it's important to make a note about loop prevention; that
it's hard to do when it's a possibility that most header fields will get
stripped; but that that doesn't make using "Auto-Submitted" any more
palatable.  I wish I had text to propose, other than just a strong note
that somehow detecting loops should be a priority of the implementor.

I also think that the "MUST NOT" under discussion is almost certain to
be violated, so I would vote against that.

mm

Date: Mon, 21 Jul 2008 14:45:56 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Michael Haardt <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Sender: [email-masked]

--On Friday, July 18, 2008 02:57:09 PM +0200 Michael Haardt 
<[email-masked]> wrote:

>
>> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of
>> loops if we send notifications for auto-submitted messages -- is
>> sufficiently important that the current "MUST NOT" text should stay.
>
> I vote for this.  It's simple and effective, exactly how loop avoidance
> should be.

Shutting down the mail system would also be simple and effective.

Date: Fri, 18 Jul 2008 14:57:09 +0200
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.

I vote for this.  It's simple and effective, exactly how loop avoidance
should be.

Michael

Date: Thu, 17 Jul 2008 21:21:00 +0100
From: "Robert Burrell Donkin" <[email-masked]>
To: "Aaron Stone" <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: SIEVE <[email-masked]>
Sender: [email-masked]

On Mon, Jul 7, 2008 at 11:45 PM, Aaron Stone <[email-masked]> wrote:
> On Jul 7, 2008, at 3:29 PM, Robert Burrell Donkin wrote:
>
>>
>> On Mon, Jul 7, 2008 at 10:54 PM, Aaron Stone <[email-masked]> wrote:
>>>
>>> Wait, top-post here says, "is there a point to the discussion going on
>>> here?"
>>
>> i'm confused: which top post? this top post you're posting now? (or
>> another that gmail has helpfully hidden)
>
> My top post, i.e. this sub-thread.

thanks

>>> Are you suggesting that we not bring managesieve to publication as an
>>> RFC?
>>
>> if the aim is codification of existing practice then since i am not an
>> existing practioner of this particular protocol, how can i object?
>>
>> it's been made quite clear to me that this is the priority of this RFC
>> is not quality but compatibility
>
> Ok, cool.

in future, i'll save my criticisms for other forums and i'll try to
refrain from replying to flames

i did turn up some specific points when i looked through the draft.
FWIW here are some of them

> 1.2 Syntax
...
>   The BYE response may be used if the server wishes to close the
>   connection.  A server may wish to do this because the client was idle
>   for too long or there were too many failed authentication attempts.
>   This response can be issued at any time and should be immediately
>   followed by a server hang-up of the connection.  If a server has a
>   inactivity timeout resulting in client autologout it MUST be no less
>   than 30 minutes.

1. too verbose: the justification in secnd paragraph is not needed;

2. unclear: using 'MAY' makes the intent of the protocol unclear.
changing this to SHOULD would allow the client to infer abnormal
shutdown from it's absence.

3. the autologout timeout requirement is evil. this requirement gains
little from a client perspective (client needs to be able to cope
robustly with connection failures) at a high cost from the server
perspective (holding connections on the server limits scalability and
complicates implementation).

client agent identity and capabilities
----------------------------------------------------------

the draft lacks a mechanism which allows a client libraries to
identify themselves or their capabilities. if it were possible for
servers to identify clients then workarounds could be applied just for
particular clients with known bugs. as this draft stands, servers are
forced to apply workarounds for all clients. this (in turn) means the
de juru standard tends to drift from the de facto one.

BAD input
----------------

the draft does not indicate the right way to deal with input that
cannot be parsed. perhaps server SHOULD deal with malformed input by
issuing a BYE followed by an appropriate response code.

"newlines"
----------------

the specification mentions "newlines" in a couple of places. it would
be clearer to specify what's meant by this eg CRLF (if that's what's
meant).

>>> Are you suggested what we can do for a next-generation sieve management
>>> system?
>>
>> Alexey Melnikov's comments about a next generation protocol
>> compatiable with IMAP make a lot more sense to me. it seems to me that
>> an independent protocol would be much more widely useful if it did not
>> adopt the IMAP style.
>
> Yeah, I think so, too. Unless we exposed the protocol through IMAP somehow,
> which I'm still a fan of doing, if possible.

+1

i'm interested in this

> Thanks for clearing up the angle you're approaching this from.

i plan to use RESTful HTTP. i believe that approach has many
advantages over this draft and may encourage easier interoperability
amongst the general development community.

- robert

Date: Thu, 17 Jul 2008 09:57:29 -0400
From: Cyrus Daboo <[email-masked]>
To: SIEVE <[email-masked]>
Subject: Agenda for Dublin
Sender: [email-masked]

Hi folks,
Alexey and I have put together the following agenda for the Dublin meeting. 
Are goal with this is to give time to discussing the set of documents that, 
according to our new proposed milestones, will be due for action over the 
period of time leading up to the next IETF meeting after Dublin.

We would appreciate document authors preparing slides or bullet points on 
the key issues and status of their documents for inclusion in the slides at 
the meeting, thanks.

In particular, would someone like to tackle the EAI Issues topic?

Agenda

Document status review                                  (10 mins)
WG Status review                                        (10 mins)

Notify Mailto (draft-ietf-sieve-notify-mailto-06.txt)   (10 mins)
Mime Loops (draft-ietf-sieve-mime-loop-05.txt)          (10 mins)

iHave (draft-freed-sieve-ihave-02.txt)                  (10 mins)
Notary (draft-freed-sieve-notary-01.txt)                (10 mins)
SIEVE in XML (draft-freed-sieve-in-xml-01.txt)          (10 mins)
ManageSIEVE (draft-martin-managesieve-10.txt)           (10 mins)

EAI Issues                                              (15 mins)
Benefits of SIEVE                                       (15 mins)
Test Scripts                                            (10 mins)

=================================================================

Total:                                                  120 mins

-- 
Cyrus Daboo

Date: Wed, 16 Jul 2008 10:08:36 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Sender: [email-masked]

Barry Leiba writes:
> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.

+1

> 2. The use cases for notifications on auto-submitted messages are 
> sufficiently important that the text should be changed.  [Please 
> suggest new text, in this case.]
>
> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
> should be changed to "SHOULD NOT", with some added text to explain 
> the danger very clearly.  [In this case, you can suggest text, or 
> I'll craft it.]

I could go along with that, assuming suitable wording, but I find it 
difficult to come up with such wording. IMO there is considerable value 
in having a really simple rule on Auto-Submitted and loops.

Arnt

Date: Tue, 15 Jul 2008 09:10:11 -0600
From: Peter Saint-Andre <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Alexey Melnikov wrote:
> 
> Barry Leiba wrote:
> 
>> I'm looking for consensus on one of these:
>>
>> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
>> loops if we send notifications for auto-submitted messages -- is 
>> sufficiently important that the current "MUST NOT" text should stay.
>>
>> 2. The use cases for notifications on auto-submitted messages are 
>> sufficiently important that the text should be changed.  [Please 
>> suggest new text, in this case.]
>>
>> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
>> should be changed to "SHOULD NOT", with some added text to explain the 
>> danger very clearly.  [In this case, you can suggest text, or I'll 
>> craft it.]
> 
> Now that you mention this I prefer SHOULD NOT.

So I take it that means:

    Implementations SHOULD NOT trigger notifications for messages
    containing "Auto-Submitted:" header fields with any value other than
    "No".

Then I assume we want to add a clause after that saying something like 
"because notifications triggered by such messages can result in mail loops."

/psa

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

--------------ms010802000104090205010308--

Date: Tue, 15 Jul 2008 15:49:24 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-mime-loop-05.txt
Sender: [email-masked]

Speaking as a WG participant:

The latest version looks good to me. A couple of new issues:

1).
 >Usage: foreverypart [":name" string] block

The document is silent on whether each name string should be unique or 
not. What should happen if 2 nested foreverypart loops use the same 
name: the inner loop's name hides the outer name or is this a runtime error?

2). I think the MIME Loops document should discuss implications on 
digital signatures. This issue came up during IESG review of several 
documents recently.

Date: Tue, 15 Jul 2008 15:42:15 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Sender: [email-masked]

Barry Leiba wrote:

> I'm looking for consensus on one of these:
>
> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.
>
> 2. The use cases for notifications on auto-submitted messages are 
> sufficiently important that the text should be changed.  [Please 
> suggest new text, in this case.]
>
> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
> should be changed to "SHOULD NOT", with some added text to explain the 
> danger very clearly.  [In this case, you can suggest text, or I'll 
> craft it.]

Now that you mention this I prefer SHOULD NOT.

Date: Tue, 15 Jul 2008 10:17:32 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Sender: [email-masked]

Alexey Melnikov said:
> Should a notification be generated if an Auto-Submitted header field 
> exists (apart from "no")?
> 
> Barry commented on this issue:
> 
> I still don't see clear support for changing this, and I still worry 
> that it's dangerous. There are certainly use cases for it, but since 
> this is a major way we're suggesting avoidance of notification loops, I 
> think it's a Very Bad Idea.
> 
> -08 still has the MUST NOT. I'd strongly prefer to leave it that way.
> 
> ===
> I tend to agree with Barry. I think the last round of discussion 
> suggested that the WG has no consensus on this issue. So my 
> recommendation is to leave the current text as is and publish the 
> document. *If* there is enough support later for allowing notifications 
> on notifications, the document can be revised(, or a small extension to 
> it can be published). But for now I think it is more important to 
> publish the document.

Despite my strong opinion on this point, I think it's not sufficient to 
say that if there's not a call to change it, the current "MUST NOT" text 
stays.  At one point we had some level of consensus for the current 
text, but there's been enough dissent that we explicitly need new consensus.

So, everyone: if you consider yourself an active participant, please 
send a message to this mailing list within the next, say, week, stating 
(briefly) your position on this.  There's no need for a lot of 
explanation, because the reasons on both sides are clear.

I'm looking for consensus on one of these:

1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
loops if we send notifications for auto-submitted messages -- is 
sufficiently important that the current "MUST NOT" text should stay.

2. The use cases for notifications on auto-submitted messages are 
sufficiently important that the text should be changed.  [Please suggest 
new text, in this case.]

3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
should be changed to "SHOULD NOT", with some added text to explain the 
danger very clearly.  [In this case, you can suggest text, or I'll craft 
it.]

Let's try to get clear consensus on this.  I propose that in the event 
of no clear consensus, we have to go with (3).

Barry

Date: Tue, 15 Jul 2008 07:49:41 -0600
From: Peter Saint-Andre <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Alexey Melnikov wrote:
> 
> [email-masked] wrote:
> 
>> 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-08.txt
>>     Pages           : 16
>>     Date            : 2008-07-09
>>
>> This document describes a profile of the Sieve extension for
>> notifications, to allow notifications to be sent by electronic mail.
>>  
>>
> Folks,
> I believe Barry addressed all outstanding issues with the document but one:
> 
> Should a notification be generated if an Auto-Submitted header field 
> exists (apart from "no")?
> 
> Barry commented on this issue:
> 
> I still don't see clear support for changing this, and I still worry 
> that it's dangerous. There are certainly use cases for it, but since 
> this is a major way we're suggesting avoidance of notification loops, I 
> think it's a Very Bad Idea.
> 
> -08 still has the MUST NOT. I'd strongly prefer to leave it that way.
> 
> ===
> I tend to agree with Barry. I think the last round of discussion 
> suggested that the WG has no consensus on this issue. So my 
> recommendation is to leave the current text as is and publish the 
> document. *If* there is enough support later for allowing notifications 
> on notifications, the document can be revised(, or a small extension to 
> it can be published). But for now I think it is more important to 
> publish the document.

+1

/psa

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

--------------ms010801050006020809000508--

Date: Tue, 15 Jul 2008 13:07:58 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt
Sender: [email-masked]

[email-masked] wrote:

>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-08.txt
>	Pages           : 16
>	Date            : 2008-07-09
>
>This document describes a profile of the Sieve extension for
>notifications, to allow notifications to be sent by electronic mail.
>  
>
Folks,
I believe Barry addressed all outstanding issues with the document but one:

 Should a notification be generated if an Auto-Submitted header field 
exists (apart from "no")?

Barry commented on this issue:

I still don't see clear support for changing this, and I still worry 
that it's dangerous. There are certainly use cases for it, but since 
this is a major way we're suggesting avoidance of notification loops, I 
think it's a Very Bad Idea.

-08 still has the MUST NOT. I'd strongly prefer to leave it that way.

===
I tend to agree with Barry. I think the last round of discussion 
suggested that the WG has no consensus on this issue. So my 
recommendation is to leave the current text as is and publish the 
document. *If* there is enough support later for allowing notifications 
on notifications, the document can be revised(, or a small extension to 
it can be published). But for now I think it is more important to 
publish the document.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-mime-loop-05.txt 
Date: Mon, 14 Jul 2008 14:15:02 -0700 (PDT)
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-05.txt
	Pages           : 19
	Date            : 2008-07-14

This document defines extensions to the Sieve email filtering
language to permit analysis and manipulation of the MIME body parts
of an email message.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-mime-loop-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Date: Fri, 11 Jul 2008 12:00:06 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: RFC 5260 on Sieve Email Filtering: Date and Index Extensions]
Sender: [email-masked]

--------------080003030500050706040609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

FYI.

--------------080003030500050706040609
Content-Type: message/rfc822;
 name="RFC 5260 on Sieve Email Filtering: Date and Index Extensions"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="RFC 5260 on Sieve Email Filtering: Date and Index Extensions"

To: [email-masked], [email-masked]
Subject: RFC 5260 on Sieve Email Filtering: Date and Index Extensions
From: [email-masked]
Date: Thu, 10 Jul 2008 16:03:10 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5260

        Title:      Sieve Email Filtering: Date and 
                    Index Extensions 
        Author:     N. Freed
        Status:     Standards Track
        Date:       July 2008
        Mailbox:    [email-masked]
        Pages:      13
        Characters: 25735
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-freed-sieve-date-index-12.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5260.txt

This document describes the "date" and "index" extensions to the
Sieve email filtering language.  The "date" extension gives Sieve the
ability to test date and time values in various ways.  The "index"
extension provides a means to limit header and address tests to
specific instances of header fields when header fields are repeated.  
[STANDARDS TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

--------------080003030500050706040609--

Date: Thu, 10 Jul 2008 22:54:21 +0100
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: [email-masked]
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Sender: [email-masked]

Mark E. Mallett wrote:

>I haven't done any managesieve work (other than read some earlier
>documents) but gave this a quick once-over for anything that might jump
>out anyway.  Nothing really did, other than some stuff calling for picky
>comments, so I'll make some :)
>
>Also, I'm a bit curious how there can be a last call (-like) when
>there are editorial questions embedded (that is, the things in '[[...]]').
>But this isn't a real last call, so I suppose that's the answer.
>  
>
This was primarily to motivate reviewers to express their opinion :-).

>I found some of the punctuation a little odd but I won't really go
>into that (much).
>
>With that..
>  
>
All fixed, thanks!

Date: Wed, 09 Jul 2008 15:19:19 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: avoid double vacation messages
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Cc: IETF Sieve WG <[email-masked]>
Sender: [email-masked]

> In my domain there are a lot of email addresses that are just redirects,
> and end in mailboxes in all possible external domains (like mails for
> [email-masked] are redirected to [email-masked] and [email-masked] is
> redirected to [email-masked]).

> I was thinking what will happen if a user configures a vacation service
> both on the redirecting server and on the server hosting her mailbox.
> Actually there is not so much to think - both servers will send a
> vacation reply.

This will only happen if something is broken or misconfigured - the "is
the recipient liested in the header" check should 
prevent the system hosting the mailbox from sending a vacation response.

Of course the user could specifically override this check with a :addresses
parameter specifying the address of the redirecting server. But that's then
a case of the user in effect saying that they want both repsonses sent.

Another potential issue is that redirection could potentially add a resent-to
field that would defeat the check. (This addition is optional in our
implementation at least.) But if that happens you now have an explicit
indicator of redirection you can test to see if you want the vacation message
sent.

> But my concerns are how to suppress the second vacation,
>   from the server hosting the mailbox, and indicate in the redirected
> message that a vacation response has been already sent for it.

It's supposed to happen automatically. See above.

				Ned

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Thu, 10 Jul 2008 00:05:47 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: avoid double vacation messages
Sender: [email-masked]

Hello,

In my domain there are a lot of email addresses that are just redirects, 
and end in mailboxes in all possible external domains (like mails for 
[email-masked] are redirected to [email-masked] and [email-masked] is 
redirected to [email-masked]).

I was thinking what will happen if a user configures a vacation service 
both on the redirecting server and on the server hosting her mailbox. 
Actually there is not so much to think - both servers will send a 
vacation reply. But my concerns are how to suppress the second vacation, 
  from the server hosting the mailbox, and indicate in the redirected 
message that a vacation response has been already sent for it.

Something like "Auto-Submitted: no; vacation sent" or "List-Id: <>" ? 
Better ideas?

Thanks in advance for your opinion.

	Със здраве,
		Дилян

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-notify-mailto-08.txt 
Date: Wed,  9 Jul 2008 08:00:02 -0700 (PDT)
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-08.txt
	Pages           : 16
	Date            : 2008-07-09

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-sieve-notify-mailto-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Date: Wed, 9 Jul 2008 07:50:09 +0100
From: "Robert Burrell Donkin" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Jeffrey Hutzelman" <[email-masked]>, "Stephan Bosch" <[email-masked]>, SIEVE <[email-masked]>
Sender: [email-masked]

On 7/8/08, Alexey Melnikov <[email-masked]> wrote:
> Jeffrey Hutzelman wrote:
>
>> --On Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin
>> <[email-masked]> wrote:
>>
>>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[email-masked]> wrote:
>>>
>>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>>> <[email-masked]> wrote:
>>>
>>> <snip>
>>>
>>>>> it seems unfortunate that this means that a separate port is required
>>>>> for sieve management. a compatible extension to IMAP would allow sieve
>>>>> management using the same URI.
>>>>
>>>>
>>>> That makes the assumption that sieve scripts live only in IMAP servers,
>>>> which I don't think we want to do.
>>>
>>> not at all :-)
>>>
>>> the function contained in this protocol is really very trivial. i
>>> doubt that any implementator using a storage mechanism other than IMAP
>>> would bother creating an implementation rather than just reusing their
>>> preferred protocol at the application level. for example, HTTP is a
>>> well known protocol whose secruity characterics are know well
>>> understood. sieve maintainance using RESTful HTTP would be much
>>> simpler than creating an implementations of this novel protocol.
>>
>> Only if you have a web server and a bunch of related infrastructure
>> lying around.  If you're implementing sieve support in an MTA, such
>> that admins or even user can provide sieve scripts to be run as
>> incoming mail is being accepted (rather than waiting until it hits the
>> mail store), then you may not have the luxury of requiring people who
>> want to use the new feature to run web servers on their inbound MX's.
>
> Sun has implemented Sieve in SMTP server and are in the process of
> implementing ManageSieve protocol.
>

Still a classic mail server, though. Nothing more exotic.
Robert

Date: Tue, 08 Jul 2008 13:12:08 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: Robert Burrell Donkin <[email-masked]>, Stephan Bosch <[email-masked]>, SIEVE <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> --On Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin 
> <[email-masked]> wrote:
>
>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[email-masked]> wrote:
>>
>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>> <[email-masked]> wrote:
>>
>> <snip>
>>
>>>> it seems unfortunate that this means that a separate port is required
>>>> for sieve management. a compatible extension to IMAP would allow sieve
>>>> management using the same URI.
>>>
>>>
>>> That makes the assumption that sieve scripts live only in IMAP servers,
>>> which I don't think we want to do.
>>
>> not at all :-)
>>
>> the function contained in this protocol is really very trivial. i
>> doubt that any implementator using a storage mechanism other than IMAP
>> would bother creating an implementation rather than just reusing their
>> preferred protocol at the application level. for example, HTTP is a
>> well known protocol whose secruity characterics are know well
>> understood. sieve maintainance using RESTful HTTP would be much
>> simpler than creating an implementations of this novel protocol.
>
> Only if you have a web server and a bunch of related infrastructure 
> lying around.  If you're implementing sieve support in an MTA, such 
> that admins or even user can provide sieve scripts to be run as 
> incoming mail is being accepted (rather than waiting until it hits the 
> mail store), then you may not have the luxury of requiring people who 
> want to use the new feature to run web servers on their inbound MX's.

Sun has implemented Sieve in SMTP server and are in the process of 
implementing ManageSieve protocol.

Date: Tue, 08 Jul 2008 11:30:56 +0100
From: Alexey Melnikov <[email-masked]>
To: Stephan Bosch <[email-masked]>
CC: SIEVE <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Sender: [email-masked]

Stephan Bosch wrote:

> Hi Alexey,

Hi Stephan,

> Alexey Melnikov wrote:
>
>>> I thought the idea was to simply allow and ignore the '+' for legacy 
>>> implementations.
>>
>> ManageSieve was largely documenting Cyrus timsieved and timsieved 
>> never emitted "+" to clients.
>> If you know any server that emits non-synchronizing literals to 
>> clients, please let me know. But absent any evidence that this would 
>> break deployed servers, I would prefer to keep consistency with IMAP 
>> and timsieved.
>
> Ok, if I encounter any in the near future I will notify you.
>
>>> Strictly requiring it from clients seems cumbersome and will, to my 
>>> opinion,
>>> likely introduce even more incompatibilities. 
>>
>> As far as I know ManageSieve never allowed clients to send 
>> synchronizing literals (literals without +). timsieved allows for 
>> that (because it reuses IMAP parser), but I don't think it ever emits 
>> IMAP style "+ go ahead" back to clients. So it is not consistent with 
>> IMAP either.
>>
>> If people think that support for synchronizing literals in the 
>> direction from the client to the server is needed, I can add that. 
>> But I am not convinced that this is a problem either.
>
> I am not so much interested in the (IMAP) synchronizing semantics of 
> the '+' character. With version 08 of the managesieve specification 
> the '+' character was indicated as 'only allowed from clients' in the 
> comment somewhere in the ABNF. I am worried that some client 
> implementors have interpreted this as being optional and decided to 
> drop the '+' altogether.

Right. Description in -08 was an error on my part. As far as I am aware 
the ManageSieve protocol never allowed + to be optional.

> Now it is explicitly required from the clients, making such clients 
> fail (if they indeed exist, let's hope not).

If such broken clients exist, I hope that they would be found and fixed.

>>> I do like the new extensions you introduced. :) I'll thoroughly read 
>>> the
>>> new document in a few days to update my ManageSieve implementation.
>>
>> Sounds good to me :-).
>
> Ok, I did some preliminary implementation of the new commands. 
> Regarding the NOOP command I have only one (nitpicking) remark. The 
> managesieve specification explicitly lists which commands are valid 
> before authentication. However, by introducing extensions this becomes 
> a little more sketchy. The RENAMESCRIPT command is clearly not useful 
> before authentication. However, implementors with IMAP experience 
> might think of allowing NOOP before authentication, because in IMAP 
> the NOOP command  may be issued before authentication. I think it 
> cannot hurt to make explicit whether these new commands may be issued 
> before authentication.

Good point. I will clarify that.

> Other than that, I found a typo in section 1.3 in the TRYLATER 
> explanation: 'This response code only make sense when returned in a 
> NO/BYE response.'. You should add an 's' there somewhere.

Fixed, thanks.

Cc: SIEVE <[email-masked]>
From: Aaron Stone <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Date: Mon, 7 Jul 2008 15:45:54 -0700
Sender: [email-masked]

On Jul 7, 2008, at 3:29 PM, Robert Burrell Donkin wrote:

>
> On Mon, Jul 7, 2008 at 10:54 PM, Aaron Stone <[email-masked]>  
> wrote:
>> Wait, top-post here says, "is there a point to the discussion going  
>> on
>> here?"
>
> i'm confused: which top post? this top post you're posting now? (or
> another that gmail has helpfully hidden)

My top post, i.e. this sub-thread.

>
>> Are you suggesting that we not bring managesieve to publication as  
>> an RFC?
>
> if the aim is codification of existing practice then since i am not an
> existing practioner of this particular protocol, how can i object?
>
> it's been made quite clear to me that this is the priority of this RFC
> is not quality but compatibility

Ok, cool.

>
>> Are you suggested what we can do for a next-generation sieve  
>> management
>> system?
>
> Alexey Melnikov's comments about a next generation protocol
> compatiable with IMAP make a lot more sense to me. it seems to me that
> an independent protocol would be much more widely useful if it did not
> adopt the IMAP style.

Yeah, I think so, too. Unless we exposed the protocol through IMAP  
somehow, which I'm still a fan of doing, if possible.

Thanks for clearing up the angle you're approaching this from.

Aaron

Date: Mon, 7 Jul 2008 23:29:01 +0100
From: "Robert Burrell Donkin" <[email-masked]>
To: "Aaron Stone" <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: SIEVE <[email-masked]>
Sender: [email-masked]

On Mon, Jul 7, 2008 at 10:54 PM, Aaron Stone <[email-masked]> wrote:
> Wait, top-post here says, "is there a point to the discussion going on
> here?"

i'm confused: which top post? this top post you're posting now? (or
another that gmail has helpfully hidden)

> Are you suggesting that we not bring managesieve to publication as an RFC?

if the aim is codification of existing practice then since i am not an
existing practioner of this particular protocol, how can i object?

it's been made quite clear to me that this is the priority of this RFC
is not quality but compatibility

> Are you suggested what we can do for a next-generation sieve management
> system?

Alexey Melnikov's comments about a next generation protocol
compatiable with IMAP make a lot more sense to me. it seems to me that
an independent protocol would be much more widely useful if it did not
adopt the IMAP style.

- robert

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 7 Jul 2008 18:28:59 -0400
To: [email-masked]
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Sender: [email-masked]

I haven't done any managesieve work (other than read some earlier
documents) but gave this a quick once-over for anything that might jump
out anyway.  Nothing really did, other than some stuff calling for picky
comments, so I'll make some :)

Also, I'm a bit curious how there can be a last call (-like) when
there are editorial questions embedded (that is, the things in '[[...]]').
But this isn't a real last call, so I suppose that's the answer.

I found some of the punctuation a little odd but I won't really go
into that (much).

With that..

==========
1.3.  Response Codes:

   If this response code is returned in the OK response, it can mean
   that the user is near its quota or that the user exceeded its quota,
   but the server supports soft quotas.

Two things:  Here is one place where I think the punctuation affects
the meaning, in that "but the server supports soft quotas" seems to go
with both "near quota" and "exceeded quota" whereas it probably really
goes with the latter.  And, "soft quota" can be taken to mean something
specific, whereas I think really what is intended here is that the quota
has been exceeded but this is permitted.  (and are we calling users
"it"?)  Simply removing the comma might help, as would an alternative
such as:

   If this response code is returned in the OK response, it can mean
   that the storage is near its quota, or it can mean that the account
   exceeded its quota but that that condition is being allowed by the
   server.

==========
2.1 ...

   "Note that a failed NO response to the AUTHENTICATE command may
   contain one of the following response codes:" ...

a "failed NO response" strikes me as being a double negative.  Probably
just "a NO response" or one of the words in parens -- "a NO (failed)
response" or "a failed (NO) response".

==========
later in 2.1 ...

   "Another example demostrating use of SASL PLAIN mechanism under TLS."

spelling of "demonstrating"

==========
later in 2.1 ...
    "The following example demonstrate use of SASL "initial response"."

"demonstrates"

Yours,
mm

Cc: SIEVE <[email-masked]>
From: Aaron Stone <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Date: Mon, 7 Jul 2008 14:54:03 -0700
Sender: [email-masked]

Wait, top-post here says, "is there a point to the discussion going on  
here?"

Are you suggesting that we not bring managesieve to publication as an  
RFC?
Are you suggested what we can do for a next-generation sieve  
management system?
Some of both?

Aaron

On Jul 7, 2008, at 2:18 PM, Robert Burrell Donkin wrote:

>
> On Mon, Jul 7, 2008 at 10:06 PM, Aaron Stone <[email-masked]>  
> wrote:
>>
>> On Jul 7, 2008, at 1:40 PM, Robert Burrell Donkin wrote:
>>
>>>
>>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[email-masked]>  
>>> wrote:
>>>>
>>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>>> <[email-masked]> wrote:
>>>
>>> <snip>
>>>
>>>>> it seems unfortunate that this means that a separate port is  
>>>>> required
>>>>> for sieve management. a compatible extension to IMAP would allow  
>>>>> sieve
>>>>> management using the same URI.
>>>>
>>>> That makes the assumption that sieve scripts live only in IMAP  
>>>> servers,
>>>> which I don't think we want to do.
>>>
>>> not at all :-)
>>>
>>> the function contained in this protocol is really very trivial. i
>>> doubt that any implementator using a storage mechanism other than  
>>> IMAP
>>> would bother creating an implementation rather than just reusing  
>>> their
>>> preferred protocol at the application level. for example, HTTP is a
>>> well known protocol whose secruity characterics are know well
>>> understood. sieve maintainance using RESTful HTTP would be much
>>> simpler than creating an implementations of this novel protocol.
>>
>> There are at least a dozen client and server implementations of this
>> protocol that exist and interoperate and have been doing so for  
>> several
>> years, so on that issue your point is negated by fact.
>
> how many implementations are not IMAP servers?
>
>> Further, HTTP is dramatically more complicated than this protocol,  
>> and I
>> challenge the notion that its security is actually well understood  
>> enough to
>> be applied to other applications without some seriously thorough  
>> and careful
>> thinking. The only thing HTTP really buys you is the ability to re- 
>> use
>> existing HTTP server frameworks. This is generally not a benefit to  
>> authors
>> of email software, since most of us have already written our own  
>> server
>> frameworks for IMAP and SMTP and the like.
>
> yes but the point was predicated on the apparent requirement that this
> protocol should be usable beyond the community of email server
> creators. yes, anyone who's spent time writing email servers will be
> comfortable but that community is small. other users are likely to
> find it much easier to reuse an existing protocol.
>
> - robert
>

Date: Mon, 7 Jul 2008 22:18:35 +0100
From: "Robert Burrell Donkin" <[email-masked]>
To: "Aaron Stone" <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: SIEVE <[email-masked]>
Sender: [email-masked]

On Mon, Jul 7, 2008 at 10:06 PM, Aaron Stone <[email-masked]> wrote:
>
> On Jul 7, 2008, at 1:40 PM, Robert Burrell Donkin wrote:
>
>>
>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[email-masked]> wrote:
>>>
>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>> <[email-masked]> wrote:
>>
>> <snip>
>>
>>>> it seems unfortunate that this means that a separate port is required
>>>> for sieve management. a compatible extension to IMAP would allow sieve
>>>> management using the same URI.
>>>
>>> That makes the assumption that sieve scripts live only in IMAP servers,
>>> which I don't think we want to do.
>>
>> not at all :-)
>>
>> the function contained in this protocol is really very trivial. i
>> doubt that any implementator using a storage mechanism other than IMAP
>> would bother creating an implementation rather than just reusing their
>> preferred protocol at the application level. for example, HTTP is a
>> well known protocol whose secruity characterics are know well
>> understood. sieve maintainance using RESTful HTTP would be much
>> simpler than creating an implementations of this novel protocol.
>
> There are at least a dozen client and server implementations of this
> protocol that exist and interoperate and have been doing so for several
> years, so on that issue your point is negated by fact.

how many implementations are not IMAP servers?

> Further, HTTP is dramatically more complicated than this protocol, and I
> challenge the notion that its security is actually well understood enough to
> be applied to other applications without some seriously thorough and careful
> thinking. The only thing HTTP really buys you is the ability to re-use
> existing HTTP server frameworks. This is generally not a benefit to authors
> of email software, since most of us have already written our own server
> frameworks for IMAP and SMTP and the like.

yes but the point was predicated on the apparent requirement that this
protocol should be usable beyond the community of email server
creators. yes, anyone who's spent time writing email servers will be
comfortable but that community is small. other users are likely to
find it much easier to reuse an existing protocol.

- robert

Cc: SIEVE <[email-masked]>
From: Aaron Stone <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Date: Mon, 7 Jul 2008 14:06:13 -0700
Sender: [email-masked]

On Jul 7, 2008, at 1:40 PM, Robert Burrell Donkin wrote:

>
> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[email-masked]>  
> wrote:
>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>> <[email-masked]> wrote:
>
> <snip>
>
>>> it seems unfortunate that this means that a separate port is  
>>> required
>>> for sieve management. a compatible extension to IMAP would allow  
>>> sieve
>>> management using the same URI.
>>
>> That makes the assumption that sieve scripts live only in IMAP  
>> servers,
>> which I don't think we want to do.
>
> not at all :-)
>
> the function contained in this protocol is really very trivial. i
> doubt that any implementator using a storage mechanism other than IMAP
> would bother creating an implementation rather than just reusing their
> preferred protocol at the application level. for example, HTTP is a
> well known protocol whose secruity characterics are know well
> understood. sieve maintainance using RESTful HTTP would be much
> simpler than creating an implementations of this novel protocol.

There are at least a dozen client and server implementations of this  
protocol that exist and interoperate and have been doing so for  
several years, so on that issue your point is negated by fact.

Further, HTTP is dramatically more complicated than this protocol, and  
I challenge the notion that its security is actually well understood  
enough to be applied to other applications without some seriously  
thorough and careful thinking. The only thing HTTP really buys you is  
the ability to re-use existing HTTP server frameworks. This is  
generally not a benefit to authors of email software, since most of us  
have already written our own server frameworks for IMAP and SMTP and  
the like.

Aaron

Date: Mon, 7 Jul 2008 22:00:42 +0100
From: "Robert Burrell Donkin" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Alexey Melnikov" <[email-masked]>, "Stephan Bosch" <[email-masked]>, SIEVE <[email-masked]>
Sender: [email-masked]

On Mon, Jul 7, 2008 at 9:46 PM, Jeffrey Hutzelman <[email-masked]> wrote:
> --On Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin
> <[email-masked]> wrote:
>
>> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[email-masked]> wrote:
>>>
>>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>>> <[email-masked]> wrote:
>>
>> <snip>
>>
>>>> it seems unfortunate that this means that a separate port is required
>>>> for sieve management. a compatible extension to IMAP would allow sieve
>>>> management using the same URI.
>>>
>>> That makes the assumption that sieve scripts live only in IMAP servers,
>>> which I don't think we want to do.
>>
>> not at all :-)
>>
>> the function contained in this protocol is really very trivial. i
>> doubt that any implementator using a storage mechanism other than IMAP
>> would bother creating an implementation rather than just reusing their
>> preferred protocol at the application level. for example, HTTP is a
>> well known protocol whose secruity characterics are know well
>> understood. sieve maintainance using RESTful HTTP would be much
>> simpler than creating an implementations of this novel protocol.
>
> Only if you have a web server and a bunch of related infrastructure lying
> around.

HTTP serving libraries of reasonable quality are common

> If you're implementing sieve support in an MTA, such that admins or
> even user can provide sieve scripts to be run as incoming mail is being
> accepted (rather than waiting until it hits the mail store), then you may
> not have the luxury of requiring people who want to use the new feature to
> run web servers on their inbound MX's.

opening a new port with a new protocol with unknown and untested
security characteristics sounds unlikely to fly to me. system admins
are much more likely to want to use FTP or HTTP for out-of-protocol
communication (but this is drifting OT)

> Now, I don't claim to be such an implementor, but I don't believe that HTTP
> is the answer to all protocol problems any more than HTML is the answer to
> all user interface problems.

IMO there are very good reasons why HTTP as a protocol has become
dominant (but that's drifting OT)

- robert

Date: Mon, 07 Jul 2008 16:46:53 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Stephan Bosch <[email-masked]>, SIEVE <[email-masked]>, [email-masked]
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Sender: [email-masked]

--On Monday, July 07, 2008 09:40:11 PM +0100 Robert Burrell Donkin 
<[email-masked]> wrote:

> On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[email-masked]> wrote:
>> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
>> <[email-masked]> wrote:
>
> <snip>
>
>>> it seems unfortunate that this means that a separate port is required
>>> for sieve management. a compatible extension to IMAP would allow sieve
>>> management using the same URI.
>>
>> That makes the assumption that sieve scripts live only in IMAP servers,
>> which I don't think we want to do.
>
> not at all :-)
>
> the function contained in this protocol is really very trivial. i
> doubt that any implementator using a storage mechanism other than IMAP
> would bother creating an implementation rather than just reusing their
> preferred protocol at the application level. for example, HTTP is a
> well known protocol whose secruity characterics are know well
> understood. sieve maintainance using RESTful HTTP would be much
> simpler than creating an implementations of this novel protocol.

Only if you have a web server and a bunch of related infrastructure lying 
around.  If you're implementing sieve support in an MTA, such that admins 
or even user can provide sieve scripts to be run as incoming mail is being 
accepted (rather than waiting until it hits the mail store), then you may 
not have the luxury of requiring people who want to use the new feature to 
run web servers on their inbound MX's.

Now, I don't claim to be such an implementor, but I don't believe that HTTP 
is the answer to all protocol problems any more than HTML is the answer to 
all user interface problems.

-- Jeff

Date: Mon, 7 Jul 2008 21:40:11 +0100
From: "Robert Burrell Donkin" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Alexey Melnikov" <[email-masked]>, "Stephan Bosch" <[email-masked]>, SIEVE <[email-masked]>
Sender: [email-masked]

On Mon, Jul 7, 2008 at 9:23 PM, Jeffrey Hutzelman <[email-masked]> wrote:
> --On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin
> <[email-masked]> wrote:

<snip>

>> it seems unfortunate that this means that a separate port is required
>> for sieve management. a compatible extension to IMAP would allow sieve
>> management using the same URI.
>
> That makes the assumption that sieve scripts live only in IMAP servers,
> which I don't think we want to do.

not at all :-)

the function contained in this protocol is really very trivial. i
doubt that any implementator using a storage mechanism other than IMAP
would bother creating an implementation rather than just reusing their
preferred protocol at the application level. for example, HTTP is a
well known protocol whose secruity characterics are know well
understood. sieve maintainance using RESTful HTTP would be much
simpler than creating an implementations of this novel protocol.

- robert

Date: Mon, 07 Jul 2008 22:36:47 +0200
From: Stephan Bosch <[email-masked]>
To: Aaron Stone <[email-masked]>
CC: SIEVE <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt (OT)
Sender: [email-masked]

Aaron Stone schreef:
> Hey, that's the same domain as in your email address! ;-)
> 
> Is your implementation now consistent with the document in question?
> 
Not quite, as I did not release any changes as of yet. My latest changes 
should bring it pretty close though. However, I still don't have a 
proper quota implementation (which i personally see as a requirement).

Regards,

Stephan.

Cc: SIEVE <[email-masked]>
From: Aaron Stone <[email-masked]>
To: Stephan Bosch <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt (OT)
Date: Mon, 7 Jul 2008 13:31:03 -0700
Sender: [email-masked]

Hey, that's the same domain as in your email address! ;-)

Is your implementation now consistent with the document in question?

On Jul 7, 2008, at 1:25 PM, Stephan Bosch wrote:

> Aaron Stone schreef:
>> On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:
>
>> managesieve for dovecot:
>> http://sinas.rename-it.nl/~sirius/
> Off topic: that url is old. :) The new url is:
>
> http://www.rename-it.nl/dovecot
>
> Regards,
>
> --
> Stephan Bosch
> [email-masked]

Date: Mon, 07 Jul 2008 22:25:34 +0200
From: Stephan Bosch <[email-masked]>
To: Aaron Stone <[email-masked]>
CC: SIEVE <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt (OT)
Sender: [email-masked]

Aaron Stone schreef:
> 
> On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:

> managesieve for dovecot:
> http://sinas.rename-it.nl/~sirius/
Off topic: that url is old. :) The new url is:

http://www.rename-it.nl/dovecot

Regards,

--
Stephan Bosch
[email-masked]

Date: Mon, 07 Jul 2008 16:23:01 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: Stephan Bosch <[email-masked]>, SIEVE <[email-masked]>, [email-masked]
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Sender: [email-masked]

--On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin 
<[email-masked]> wrote:

> i can see that's a tough choice: codification of existing (possibly
> dubious but at least well understood) practice verses the creation of
> a better protocol

The situation here is that we are standardizing a protocol which was 
already widely deployed.  In such cases, it is usually better to avoid 
breaking interoperability with the deployed base, especially if the 
deployment experience largely shows that the existing protocol works. 
Sometimes, there is no way to avoid making a backward-incompatible change 
to correct a problem, but I don't think this is such a case.

> it seems unfortunate that this means that a separate port is required
> for sieve management. a compatible extension to IMAP would allow sieve
> management using the same URI.

That makes the assumption that sieve scripts live only in IMAP servers, 
which I don't think we want to do.

-- Jeff

Cc: "Alexey Melnikov" <[email-masked]>, "Stephan Bosch" <[email-masked]>, SIEVE <[email-masked]>
From: Aaron Stone <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Date: Mon, 7 Jul 2008 13:20:03 -0700
Sender: [email-masked]

On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:

>
> On Mon, Jul 7, 2008 at 1:18 PM, Alexey Melnikov
> <[email-masked]> wrote:
>> Robert Burrell Donkin wrote:
>>
>>> On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <[email-masked]>
>>> wrote:
>>>
>>> <snip>
>>>
>>>>
>>>> Ok, I did some preliminary implementation of the new commands.  
>>>> Regarding
>>>> the
>>>> NOOP command I have only one (nitpicking) remark. The managesieve
>>>> specification explicitly lists which commands are valid before
>>>> authentication. However, by introducing extensions this becomes a  
>>>> little
>>>> more sketchy. The RENAMESCRIPT command is clearly not useful before
>>>> authentication. However, implementors with IMAP experience might  
>>>> think of
>>>> allowing NOOP before authentication, because in IMAP the NOOP  
>>>> command
>>>> may
>>>> be issued before authentication.
>>>>
>>>
>>> failing to allow NOOP as may be expected violates the principle of
>>> least surprise.
>>>
>>> is there any reason for this?
>>>
>>> in general, this protocol seems more than a little peculiar. it's
>>> close in syntax to IMAP but has enough differences for IMAP
>>> implementors to be surprised and confused by the differences.
>>>
>>> is there any reason for this choice?
>>>
>>
>> The protocol is trying to stay backward compatible with CMU  
>> implementation
>> (and there are many other client and server implementations that  
>> mimic it).
>> If I were to design a new protocol from scratch, I would have made  
>> it as
>> similar to IMAP as possible. But due to existing deployments, I  
>> don't think
>> this would be a good option.
>
> i can see that's a tough choice: codification of existing (possibly
> dubious but at least well understood) practice verses the creation of
> a better protocol

Documenting what exists is the limit of what we can do with this  
document. The protocol itself is already implemented by several  
servers and clients and has good interoperability*. We need to freeze  
the current state and call it "version 1" before we start working on  
version 2.

* actually, I need to compare my implementation with the document  
that's been posted, because I recall at least two things that I  
followed drafts on but clients did not like, one was about response  
codes and another was about {number+} vs. {number}, but I don't  
remember exactly when and what those interop problems were. I do know  
that the clients in question changed to accommodate my server and not  
vice versa, because I was following the draft spec and they agreed.

Other server implementations I know about:

managesieve in dbmail (I wrote this one):
https://svn.ic-s.nl/svn/dbmail/trunk/dbmail/src/timsieve.c

managesieve for dovecot:
http://sinas.rename-it.nl/~sirius/

managesieve in citadel:
www.citadel.org

> it seems unfortunate that this means that a separate port is required
> for sieve management. a compatible extension to IMAP would allow sieve
> management using the same URI.

It's entirely possible that this is the future of sieve script  
management. I, for one, would really like to see sieve scripts exposed  
through some namespace within folder annotations. There are problems  
with that, though, and it's not going to be implemented everywhere  
tomorrow, if at all. So we need to finish documenting what we have  
that works for now.

Aaron

Date: Mon, 7 Jul 2008 20:27:59 +0100
From: "Robert Burrell Donkin" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Stephan Bosch" <[email-masked]>, SIEVE <[email-masked]>
Sender: [email-masked]

On Mon, Jul 7, 2008 at 1:18 PM, Alexey Melnikov
<[email-masked]> wrote:
> Robert Burrell Donkin wrote:
>
>> On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <[email-masked]>
>> wrote:
>>
>> <snip>
>>
>>>
>>> Ok, I did some preliminary implementation of the new commands. Regarding
>>> the
>>> NOOP command I have only one (nitpicking) remark. The managesieve
>>> specification explicitly lists which commands are valid before
>>> authentication. However, by introducing extensions this becomes a little
>>> more sketchy. The RENAMESCRIPT command is clearly not useful before
>>> authentication. However, implementors with IMAP experience might think of
>>> allowing NOOP before authentication, because in IMAP the NOOP command
>>>  may
>>> be issued before authentication.
>>>
>>
>> failing to allow NOOP as may be expected violates the principle of
>> least surprise.
>>
>> is there any reason for this?
>>
>> in general, this protocol seems more than a little peculiar. it's
>> close in syntax to IMAP but has enough differences for IMAP
>> implementors to be surprised and confused by the differences.
>>
>> is there any reason for this choice?
>>
>
> The protocol is trying to stay backward compatible with CMU implementation
> (and there are many other client and server implementations that mimic it).
> If I were to design a new protocol from scratch, I would have made it as
> similar to IMAP as possible. But due to existing deployments, I don't think
> this would be a good option.

i can see that's a tough choice: codification of existing (possibly
dubious but at least well understood) practice verses the creation of
a better protocol

it seems unfortunate that this means that a separate port is required
for sieve management. a compatible extension to IMAP would allow sieve
management using the same URI.

- robert

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, sieve mailing list <[email-masked]>, sieve chair <[email-masked]>
Subject: Protocol Action: 'Sieve Email Filtering: Editheader  Extension' to Proposed Standard 
Date: Mon,  7 Jul 2008 09:37:11 -0700 (PDT)
Sender: [email-masked]

The IESG has approved the following document:

- 'Sieve Email Filtering: Editheader Extension '
   <draft-ietf-sieve-editheader-11.txt> as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working
 
Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-11.txt

Technical Summary

The SIEVE editheader extensions provides a way for a SIEVE script to add
or remove top-level message headers in the message being processed. This
allows SIEVE to interact with other components in the mail delivery
system via information in message headers.

The extension defines an addheader action with the option to have the
header inserted at the start or end of the entire block of message
headers. Consideration is given to issues of header encoding and
possible length limits, as required by internet email standards.

The extension defines a deleteheader action which can optionally delete
all, the last, or a specific indexed header in the top-level message
headers.

The draft has a detailed description of how interactions with other
SIEVE extensions/actions are handled.

The security considerations section covers several identified security
concerns.

Working Group Summary

This document has been discussed and reviewed in the SIEVE Working Group.
There is strong consensus in the Working Group to publish this document
as a Proposed Standard.

The editheader extension was originally submitted as an individual
contribution in April 2003. The first revision involved some major
changes (one of which is discussed below) as suggested by feedback on
the list. Subsequent to that, only minor changes were done. Working
group last call was issued in March 2005 and a number of minor
clarifications and errors were fixed based on comments.

One issue which did arise during last call was that of the original
replaceheader action, which was dropped after the very first draft. That
received a fair amount of discussion at the time, and there was a
feeling that it was too complex. A number of people have expressed
disappointment that that action was not present in the draft during
last call. However, the original arguments against it were felt to still
be valid, and there was consensus that editheader should proceed without
this action.

Protocol Quality

A number of implementations of this extension have already been
developed and in some cases deployed. Most participants are eager to see
this spec published as an RFC.

Personal

Document Shepherd: Cyrus Daboo <mailto:[email-masked]>
AD: Lisa Dusseault <mailto:[email-masked]>

Note to RFC Editor

In Section 9, add a new paragraph after the first paragraph.

  This is the first Sieve extension to be standardized that allows
  alteration of messages being processed by Sieve engines.
  A Sieve script that uses Sieve tests defined in RFC 5228 [SIEVE],
  the editheader extension, and the redirect action back to the same user
  can keep some state between different invocations of the same script
  for the same message. But note that it would not be possible to 
  introduce an infinite loop using any such script, because each iteration

  adds a new Received header field, so email loop prevention described
  in RFC 2821 will eventually non deliver the message, and because
  the editheader extension is explicitly prohibited to alter or delete
  Received header fields (i.e. it can't interfere with loop prevention).

In Section 9, 3rd paragraph, add new material after the first sentence:

 Any change in a message content may interfere with digital
 signature mechanisms that include the header in the signed
 material.

NEW material:

   For example, changes to (or deletion/addition of) header fields
   included in the "SHOULD be included in the signature" list in
   section 5.5 of [RFC4871] can invalidate DKIM signatures. This also
   includes DKIM signatures that guaranty a header field absence.

   The editheader extension doesn't directly affect RFC 2822 header field

   signatures generated using S/MIME [RFC3851] or OpenPGP [RFC3156],
   because when S/MIME/OpenPGP is used to signed header fields, a copy
   of RFC 2822 header fields is included inside signed message/rfc822
   body part. However a software written to detect differences between
   the inner (signed) copy of header fields and the outer (modified
   by editheader) header fields might be affected by changes done by
   editheader.

OLD:
 However, implementations MUST NOT permit attempts to
 delete "Received" header fields and MUST permit both addition
 and deletion of the "Subject" header field.
NEW:
 However, implementations MUST NOT permit attempts to
 delete "Received" and "Auto-Submitted" header fields and MUST permit both
addition
                   ^^^^^^^^^^^^^^^^^^^^
 and deletion of the "Subject" header field.

Date: Mon, 07 Jul 2008 13:18:46 +0100
From: Alexey Melnikov <[email-masked]>
To: Robert Burrell Donkin <[email-masked]>
CC: Stephan Bosch <[email-masked]>, SIEVE <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Sender: [email-masked]

Robert Burrell Donkin wrote:

>On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <[email-masked]> wrote:
>  
>
><snip>
>  
>
>>Ok, I did some preliminary implementation of the new commands. Regarding the
>>NOOP command I have only one (nitpicking) remark. The managesieve
>>specification explicitly lists which commands are valid before
>>authentication. However, by introducing extensions this becomes a little
>>more sketchy. The RENAMESCRIPT command is clearly not useful before
>>authentication. However, implementors with IMAP experience might think of
>>allowing NOOP before authentication, because in IMAP the NOOP command  may
>>be issued before authentication.
>>    
>>
>
>failing to allow NOOP as may be expected violates the principle of
>least surprise.
>
>is there any reason for this?
>
>in general, this protocol seems more than a little peculiar. it's
>close in syntax to IMAP but has enough differences for IMAP
>implementors to be surprised and confused by the differences.
>
>is there any reason for this choice?
>  
>
The protocol is trying to stay backward compatible with CMU 
implementation (and there are many other client and server 
implementations that mimic it).
If I were to design a new protocol from scratch, I would have made it as 
similar to IMAP as possible. But due to existing deployments, I don't 
think this would be a good option.

Date: Mon, 7 Jul 2008 13:05:37 +0100
From: "Robert Burrell Donkin" <[email-masked]>
To: "Stephan Bosch" <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Cc: "Alexey Melnikov" <[email-masked]>, SIEVE <[email-masked]>
Sender: [email-masked]

On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <[email-masked]> wrote:

<snip>

> Ok, I did some preliminary implementation of the new commands. Regarding the
> NOOP command I have only one (nitpicking) remark. The managesieve
> specification explicitly lists which commands are valid before
> authentication. However, by introducing extensions this becomes a little
> more sketchy. The RENAMESCRIPT command is clearly not useful before
> authentication. However, implementors with IMAP experience might think of
> allowing NOOP before authentication, because in IMAP the NOOP command  may
> be issued before authentication.

failing to allow NOOP as may be expected violates the principle of
least surprise.

is there any reason for this?

in general, this protocol seems more than a little peculiar. it's
close in syntax to IMAP but has enough differences for IMAP
implementors to be surprised and confused by the differences.

is there any reason for this choice?

- robert

Date: Mon, 07 Jul 2008 10:21:36 +0200
From: Stephan Bosch <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: SIEVE <[email-masked]>
Subject: Re: Treat as a WGLC: draft-martin-managesieve-10.txt
Sender: [email-masked]

Hi Alexey,

Alexey Melnikov wrote:
>> I thought the idea was to simply allow and ignore the '+' for legacy 
>> implementations.
>>
> ManageSieve was largely documenting Cyrus timsieved and timsieved 
> never emitted "+" to clients.
> If you know any server that emits non-synchronizing literals to 
> clients, please let me know. But absent any evidence that this would 
> break deployed servers, I would prefer to keep consistency with IMAP 
> and timsieved.
Ok, if I encounter any in the near future I will notify you.
>> Strictly requiring it from clients seems cumbersome and will, to my 
>> opinion,
>> likely introduce even more incompatibilities. 
> As far as I know ManageSieve never allowed clients to send 
> synchronizing literals (literals without +). timsieved allows for that 
> (because it reuses IMAP parser), but I don't think it ever emits IMAP 
> style "+ go ahead" back to clients. So it is not consistent with IMAP 
> either.
>
> If people think that support for synchronizing literals in the 
> direction from the client to the server is needed, I can add that. But 
> I am not convinced that this is a problem either.
I am not so much interested in the (IMAP) synchronizing semantics of the 
'+' character. With version 08 of the managesieve specification the '+' 
character was indicated as 'only allowed from clients' in the comment 
somewhere in the ABNF. I am worried that some client implementors have 
interpreted this as being optional and decided to drop the '+' 
altogether. Now it is explicitly required from the clients, making such 
clients fail (if they indeed exist, let's hope not).
>> I do like the new extensions you introduced. :) I'll thoroughly read the
>> new document in a few days to update my ManageSieve implementation.
> Sounds good to me :-).
Ok, I did some preliminary implementation of the new commands. Regarding 
the NOOP command I have only one (nitpicking) remark. The managesieve 
specification explicitly lists which commands are valid before 
authentication. However, by introducing extensions this becomes a little 
more sketchy. The RENAMESCRIPT command is clearly not useful before 
authentication. However, implementors with IMAP experience might think 
of allowing NOOP before authentication, because in IMAP the NOOP 
command  may be issued before authentication. I think it cannot hurt to 
make explicit whether these new commands may be issued before 
authentication.

Other than that, I found a typo in section 1.3 in the TRYLATER 
explanation: 'This response code only make sense when returned in a 
NO/BYE response.'. You should add an 's' there somewhere.

Regards,

--
Stephan Bosch
[email-masked]