Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt

[Ned Freed <[e-mail]>]

> > As a specific example, I have
> > email accounts at Sun, on my home systems, Gmail, and a bunch of
> > other places.
> > All, I repeat _all_, of these services allow me to easily configure
> > autoforwarding to multiple destinations.

> Uh - you sure.

Yes, as a matter of fact I am sure. I try very hard not to make assertions
without the facts to back them up.

> I'm not aware how to make gmail go to multiple system

It's trivial. Hit the settings tab at the top right and then create two
filters. Use whatever critera you like and have one that forwards to address A
and the other to address B.  Before I included gmail in my response I tested
this with two non-gmail accounts I have elsewhere and gmail happily forwarded a
test message to both. No warnings, no problems, just two copies of the mail. I
just checked my account again just now and the both forwards are still in place
and working. Here's approximately what my settings page has to say about it:

  The following filters are applied to all incoming mail:		
  Matches: subject: vvv
  Do this: Forward to [e-mail]

  Matches: subject: vvv www
  Do this: Forward to [e-mail]

I can't really talk about the specific ISPs we have as customers and their
policies, but I can assure you gmail is not alone in offering this capability
to their users. To the extent offerings differ, the difference seems to be
whether or not users are allowed to configure custom filters at all, not
whether or not setups that allow custom filtering configuration can forward.
Hotmail, for example, effectively doesn't offer custom filter settings, so it
is hardly surprising that they don't offer forwarding.

> which is of course the important one because the others systems have
> relationships with you and other ways to secure things by causing bad
> consequences for you if you abuse the system.

I don't believe this is as much of a difference as you seem to think. Quite a
few of the cases of mailbombing I've seen have been disgruntled employees and
the like attacking their own company's systems. (AFAIK none of them involved
the use of sieve redirect, but that's really beside the point.) Apparently
nothing says "I quit" quite like a mailbox with 10 million pieces of hate mail
in it.

> > If memory serves, your suggested way to prevent it was to allow at
> > most one redirect operation to be done during the execution of a sieve
> > script.

> Well, what I have in my notes from the prague meeting was "Told them
> I was OK with SHOULD not redirect to more than one location outside
> the domain".

And I responded that I think that goes too far and isn't reasonable. In
particular, a SHOULD that fails to take into account that there are legitimate
use-cases for mutlple redirects makes the entire specification look incompetent
and serves to weaken the effectiveness of all the other advice we give.

> We may have different ideas about what domain means but
> roughly I would mean administrative domain - certainly I would call
> an enterprise or large bank one domain even thought they might have
> separate DNS domain names for different locations or something. You
> might use the term "onsite" where I used domain.

I don't think the restriction to a single domain, regardless of what domain
means, accomplishes nearly as much as you seem to think it does. Again, to the
extent mailbombing is an issue, in my experience it's as much of one within an
ADMD as outside of it. Perhaps more.

> > And you've been told that this is simply not acceptable - there are too
> > many use cases for forwarding email to two different places at once.

> Actually, I have received very little comment on if this is
> acceptable or not. I have mostly recieved something that loosely
> translated to "the WG disagrees with your discuss". I would be very
> happy to talk what my concerns are and have folks figure out if their
> is a solution that addresses them and still meets the bulk of users
> needs.

Then there has been a disconnect getting WG comments back to you. Several
comments were in fact made, including but not limited to one from me.

> > In fact this is an
> > incredibly common thing for people to do for all sorts of
> > legitimate reasons,
> > including but not limited to:

> I suspect what I had proposed meets all these use case but don't
> claim to really know. Glad to be educated.

OK, let's go down the list and see how ADMD restrictions fare:

> > (1) Making messages accessible in multiple ways, e.g. send one copy to
> >    my email account and another to my pager. Or voice mail. Or printer.
> >    Or FAX.

A very common case is for pager, fax, or voice mail services to be outsourced
to an external service provider. Often as not different people in the org will
use different providers for this stuff. This is especially true if we're
talking about a hosted setup. ADMD restriction cannot possibly work here.

> > (2) Secretaries who need copies of their boss's email.

ADMD restriction are mostly compatible with this use-case.

> > (3) Maintaining multiple mailboxes during a service transition
> > period. Or two pagers.

This would depend on the nature of the transition. I've seen transitions to
another ADMD as well as transitions within an ADMD. Domain restrictions are
problematic in this case.

> > (4) Making backup copies of mail to address reliability issues (IMO
> > this is not the best way to solve this problem but it is commonly done
> > this way regardless of what I think).

In many cases the entire point of doing this sort of thing, especially at the
user level, is to get a copy of your mail to a place that has separate
administative controls. ADMD restrictions would be hugely problematic
for this use-case.

> > (5) Making copies of stuff for law enforcement use (garden variety
> >    forwarding is a piss-poor way to implement this but it is nevertheless
> >    something people do fairly often).

> (uh, yah, laughing about how well this will meet some US Law
> enforcement requirements :-)

I can't get into details, but the truly amazing thing is that I've seen
situations where law enforcement _insisted_ on it being done this way  even
when a technically superior solution was available. (I'm actually writing a
response to a proposal that's basically a variant of this idea in  another
window.)

I don't actually know if the cases where this has been done involve forwarding
outside the ADMD or not. (To be honest, I try very hard to learn as little
about the operational details of interception activities as I possibly can.)
But given the complete lack of clue needed to even consider using this approach
I would not be at all surprised if such forwarding has been done in this case.

> > (6) Vacation-time forwarding of important messages to the "next
> > tier" of handlers.

This is usually done inside the ADMD but not always.

Tallying up, restricting autforwarding by domain didn't fare so well against
this list of use-cases. So we're talking about a mechanism that is ineffective
against a significant subset of actual attacks as well as being incompatible
with a lot of completely legitimate things people like to do.

Yet another problem with domain restrictions is that it is easy for them to
turn into a violation of the least astonishment principle. ADMD boundaries can
be complex - I've seen setups that consider thousands or tens of thousands of
domains as local - and asking users to understand complex boundaries is in
effect asking for a lot of support calls. And SPs will do almost anything to
lessen the number of support calls they get.

> ...

> I'm not surprised - this all seems very consistent with my
> discussions to these types of folks. I assume you also have the
> discussions with the people like Yahoo, MSN, gmail, around the
> policies they put in place to stop their servers from being used in
> DOS attacks?

The people I talk to tend to be large ISPs rather than these sorts of SPs, but
yes, we talk about DOS attacks a fair amount. However, the issue of the ISPs
own infrastructure being used in the ways you envision for DOS attacks has
almsot never come up, for the simple reason that it is not a significant issue
for them.

> I know I have been dragged into a few theses - can  you
> provide some insight around policies there?

OK, let's look at email DOS attacks in a bit more detail. Let's start with what
sounds like a silly question: What does an MTA do? The answer, of course, is
that it transfers messages around. It follows that if an MTA is good at its job
it has to be able to accept and process messages fairly quickly. And this is in
fact the case: It isn't at all difficult to get performance of 50
messages/second on a single box. With a little more effort you can kick things
up into the 500 messages/second realm (the main issue at this point is spam and
virus scanning performance) and MTAs have been built that can handle well over
2000 messages/second (at this point threads and filesystem performance become
the bottleneck, requiring a bunch of exotic tricks to deal with).

MTAs are also built defensively, and the primary defensive stategy is to try
and stop the bad stuff as close to the security perimeter as possible. The
further in stuff gets the more resources have to be expended dealing with it.
For example, when a user goes seriously over quota the best thing to do is turn
back mail with a 4yz (temporary) error, not accept it and hold it until they go
under quota again. Various rate limiting strategies are useful here as well and
in practice are widely deployed. So unless your attack has both a distributed
source and destination there's a very good chance it will be quickly detected
and blocked.

The bottom line is that modern MTAs are very good at handling lots legitimate
SMTP transactions and take all sorts of steps to prevent themselves from being
overwhelmed by too many of them. So attacking the email infrastructure by
performing lots of real transactions is in effect a frontal attack against the
most heavily fortified part of the entire system. This is not a recipe for
success.

So if frontal attacks don't work very well, what does? What we commonly see are
attacks on various server resources: Connections, threads, processes, memory
and disk. If an attacker can consume enough of some resource they can bring the
servers down or at least make them very slow. For example, one attack we saw a
while back was to send an infinitely long message - some MTAs buffer messages
in memory and done right this could consume all available swap space and hang
the server. Or there's the trick of opening lots of connections but never
sending any data. Or stopping in the middle of the transaction. (This one is
apparently popular right now - I have no idea why.) Or sending commands R E A L
L Y  S L O W L Y. Or attacking the network stack with malformed packets,
incomplete TCP exchanges, and so on. Or simply overwhelming the network itself
with data. Or causing the MTA to overlaod some  other service, e.g. kill the
directory server by sending lots of RCPT TOs and forcing lots of lookups. Or
exploiting some known flaw in a particular implementation, e.g. blowing a vital
cache by doing something to invalidate its content. The list is long, and if
the attacker is highly distributed some of these are very difficult to defend
against.

But now let's consider where autoforwarders fit into this attack tree. First of
all, since email is store and forward you cannot get an autoforwarder to
perform anything but an actual transaction, corresponding to a direct frontal
attack - exactly the attack MTAs are best at preventing. Even worse (for the
attacker), autforwarders don't provide an attacker with much flexibility in
terms of either distributing either the source or destination of the attack:
Automating account and filter creation is in most cases difficult if not
impossible, making the task of getting enough autoforwarders in place very time
consuming and error prone, and most autoforwarders, including Sieve redirect,
can only forward to a fixed set of destinations - the redirection cannot go to
an address that's pulled out of the message itself. (The sieve variables
extension changes this, but the topic at hand is what's possible in the Sieve
base specification, not what some extension allows.) Finally, the people who
offer autoforwarding as part of their service are as a general rule not morons
and will probably notice if a large volume of email starts coming in only to be
forwarded right back out.

The bottom line is that, your beliefs to the contrary notwithstanding,
autoforwarders just aren't that interesting of a tool for attackers. This has
been largely true throughout the history of email, and in the present world of
botnets it is more true than ever. The folks at Cloudmark (who know far more
about the attack landscape than I do) told me a couple of weeks ago that the
botnets out there are now so large that devastating results can be had even if
each infected system only sends out 5-6 messages a day. Given this why would
any attacker even bother making autoforwarders part of their attack toolkit?

> >> I believe that
> >> the IETF has clear consensus that it does not want to deploy
> >> technology that could trivially be used for large scale DOS and
> >> message amplification attacks with very little safeguards or
> >> traceable ways of dealing with this.
> >
> > This presupposes that there's a real risk here and that the necessary
> > safeguards are not in place. I don't believe either of these are true.

> So far no one as sent me any information arguing these are not true.

Say what? My responses have contained exactly this sort of information and
argument. And AFAICT you have yet to effectively refute a single point I have
made.

> > > Now my current judgement call is
> > > that this is in that category and could cause harm to the internet.

> > But we're not dealing with a new protocol with zero operational experience here
> > where such judgement calls are our only means of assessing possible risk.
> > Rather, we're not only dealing with a protocol that has signifcant deployment
> > and operational experience, we're talking about a particular feature that's
> > been an integrall part of email for decades and is accessible in all sorts of
> > ways besides Sieve.

> Sure - and clearly if it is not a problem, it is stopped somehow, I'm
> asking the Security section to provide some advice about how this is
> all stopped.

Leaving aside that this is a fairly significant change in position on your
part, the problem with this is that your reasoning rests on an unwarranted
assumption: That the reason it is not a problem is because people have taken
specific steps to prevent autoforwarder abuse. The fact of the matter is they
haven't done this. What has happened instead is that the myriad of other
measures people have taken to prevent attacks on the email infrastructure have
collectively managed to make autoforwarders a fairly uninteresting tool for
attackers.

> > First, nobody is claiming that autoforwarders cannot be used as an amplifying
> > component in various sorts of attacks. They can be used this way. This was true
> > for email decades before Sieve came along and it will continue to be true no
> > matter what we do in this document.

> yet somehow widespread message amplification attacks from email are
> mitigated to an currently acceptable level.

Yes, because the measures people take to defend against other, far more
pernicious attacks end up defending against autoforwarders vicariously.
Defending against mail loops, for example, does more to limit the effectiveness
of autoforwarders as an attack mechanism than any other step you can take. But
if you don't have reasonable loop detection in place you will quickly find that
autoforwarders are the least of your problems.

> > Second, nobody is claiming that script analysis can be used to prevent people
> > from abusing Sieve as part of such attacks. It simply cannot be done.

> agreed - let's make sure the draft does not suggest people do it

I have no problem with that.

> >    More generally, the days where email systems can get away without producing
> >    comprehensive logs and audit trails ended a long time ago. I have no idea
> >    what you're basing your assertions that such attacks would not be tracable
> >    in modern email systems, but it runs absolutely contrary to all of my
> >    recent experience.

> Certainly agree with you in enterprise case but in  a public provider
> such as yahoo, sure they have logs but they may not have any way to
> tying that to an actually human associated with the account.

But even if they had the information they still aren't going to go after most
abusers - law enforcement could not care less about this stuff and a civil suit
is way too much trouble for way too little gain. All they're going to do  is
shut down the account.

BTW, the same is often true in the enterprise case: If some guy uses a mailbomb
to say "I quit" the odds are pretty good the company will simply clean up the
mess and move on.

In any case, the point of having good logs is to be able to identify and stop
bad behavior. Catching and punishing the person responsible is a whole
different matter.

> This is great - few bits inline below...

> >    Allowing a single script to redirect to multiple destinations can be
> >    used as a means of amplifying the number of messages in an attack.
> >    Moreover, if loop detection is not properly implemented it may be possible
> >    to set up expontentially growing message loops. Acording, Sieve
> >    implementations:
> >
> >    (1) MUST implement facilities to detect and break message loops. See
> >        RFC 2821 section 6.2 for additional information on basic loop
> >        detection strategies.

> My discuss did not ask for this but it certainly seems like a good idea.

Alexey already pointed out that you did in fact ask for this.

> >
> >    (2) MUST provide the means for administrators to limit the ability of
> >        users to abuse redirect. In particular, it MUST be possible to
> >        limit the number of redirects a script can perform. Additionally,
> >        if no use cases exists for using redirect to to multiple destinations,
> >        this limit SHOULD be set to 1. Additional limits, such
> >        as the ability to restrict redirect to local users MAY also be
> >        implemented.

> We are very close here. If you changed the  "Additionally if no use
> cases exists for using redirect to to multiple destinations this
> limit SHOULD be set to 1." to "Scripts SHOULD be limited to at most
> one redirect that is not 'onsite'". And define onsite somewhere. I'd
> point out that this is a SHOULD not a MUST and that it could be
> ignored if people understood the security implications of what they
> were about to do. This could also possibly be coupled with idea after
> next point to explicitly allow multiple redirects in some cases.

My problem with this is that "onsite" or "within the domain" or whatever should
not be conflated with limiting the extent to which users are allowed to use
redirect. I actually think you have substantially weakened the impact of this
guidance by over-emphasizing domain restrictions.

> >    (3) MUST provide facilities to log use of redirect in order to facilitate
> >        tracking down abuse.

> I would ask if this mean that they MUST know what human the script
> was associated with. If yes, it is way beyond what I am asking for
> and if no then hard to see how it helps.

On the contrary, this is arguably the most useful advice we have to offer. Real
time as well as offline analysis of logs is in practice one of the primary
tools that's used to find and eliminate email abuse. We actually spend at least
as much time advising our large ISP customers on how to do this more
effectively than we do on how to set up rate limiting or any other sort of
defense. (And as I mentioned previously, our ISP customers have demonstrated no
interest whatsoever in administrative limits on redirect. And we'd know because
it turns out the limit option wasn't documented.)

> When I mentioned months ago
> I could imagine many ways to solve this, coupling this type of thing
> to the ability to do more than one redirect was one of the things
> that seemed like a possible solution (and corresponds to my
> understanding of at least some current deployments).

In conclusion, Alexey has proposed new text in a separate messagage which
I find completely acceptable. Please take a look at that and let's see
where we are.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7VIp3gc087941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2007 11:51:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7VIp3ZP087940; Fri, 31 Aug 2007 11:51:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7VIp2aj087931 for <[e-mail]>; Fri, 31 Aug 2007 11:51:02 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 31 Aug 2007 11:50:53 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 31 Aug 2007 11:50:41 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail], Lisa Dusseault <[e-mail]>, [e-mail], Philip Guenther <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 30 Aug 2007 19:37:03 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
In-reply-to: "Your message dated Wed, 29 Aug 2007 13:44:15 -0700" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; delsp=yes; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Cullen Jennings <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1188586254; h=Date:	 From:Subject:MIME-version:Content-type; b=Wmzqgd4++jype7zt2LNbf09gm XH2HmUqQ6aCs+VhhogSkarF0KClyrACudWrhwn6SFMUuWu/k9icjQeoydyDSA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > As a specific example, I have
> > email accounts at Sun, on my home systems, Gmail, and a bunch of
> > other places.
> > All, I repeat _all_, of these services allow me to easily configure
> > autoforwarding to multiple destinations.

> Uh - you sure.

Yes, as a matter of fact I am sure. I try very hard not to make assertions
without the facts to back them up.

> I'm not aware how to make gmail go to multiple system

It's trivial. Hit the settings tab at the top right and then create two
filters. Use whatever critera you like and have one that forwards to address A
and the other to address B.  Before I included gmail in my response I tested
this with two non-gmail accounts I have elsewhere and gmail happily forwarded a
test message to both. No warnings, no problems, just two copies of the mail. I
just checked my account again just now and the both forwards are still in place
and working. Here's approximately what my settings page has to say about it:

  The following filters are applied to all incoming mail:		
  Matches: subject: vvv
  Do this: Forward to [e-mail]

  Matches: subject: vvv www
  Do this: Forward to [e-mail]

I can't really talk about the specific ISPs we have as customers and their
policies, but I can assure you gmail is not alone in offering this capability
to their users. To the extent offerings differ, the difference seems to be
whether or not users are allowed to configure custom filters at all, not
whether or not setups that allow custom filtering configuration can forward.
Hotmail, for example, effectively doesn't offer custom filter settings, so it
is hardly surprising that they don't offer forwarding.

> which is of course the important one because the others systems have
> relationships with you and other ways to secure things by causing bad
> consequences for you if you abuse the system.

I don't believe this is as much of a difference as you seem to think. Quite a
few of the cases of mailbombing I've seen have been disgruntled employees and
the like attacking their own company's systems. (AFAIK none of them involved
the use of sieve redirect, but that's really beside the point.) Apparently
nothing says "I quit" quite like a mailbox with 10 million pieces of hate mail
in it.

> > If memory serves, your suggested way to prevent it was to allow at
> > most one redirect operation to be done during the execution of a sieve
> > script.

> Well, what I have in my notes from the prague meeting was "Told them
> I was OK with SHOULD not redirect to more than one location outside
> the domain".

And I responded that I think that goes too far and isn't reasonable. In
particular, a SHOULD that fails to take into account that there are legitimate
use-cases for mutlple redirects makes the entire specification look incompetent
and serves to weaken the effectiveness of all the other advice we give.

> We may have different ideas about what domain means but
> roughly I would mean administrative domain - certainly I would call
> an enterprise or large bank one domain even thought they might have
> separate DNS domain names for different locations or something. You
> might use the term "onsite" where I used domain.

I don't think the restriction to a single domain, regardless of what domain
means, accomplishes nearly as much as you seem to think it does. Again, to the
extent mailbombing is an issue, in my experience it's as much of one within an
ADMD as outside of it. Perhaps more.

> > And you've been told that this is simply not acceptable - there are too
> > many use cases for forwarding email to two different places at once.

> Actually, I have received very little comment on if this is
> acceptable or not. I have mostly recieved something that loosely
> translated to "the WG disagrees with your discuss". I would be very
> happy to talk what my concerns are and have folks figure out if their
> is a solution that addresses them and still meets the bulk of users
> needs.

Then there has been a disconnect getting WG comments back to you. Several
comments were in fact made, including but not limited to one from me.

> > In fact this is an
> > incredibly common thing for people to do for all sorts of
> > legitimate reasons,
> > including but not limited to:

> I suspect what I had proposed meets all these use case but don't
> claim to really know. Glad to be educated.

OK, let's go down the list and see how ADMD restrictions fare:

> > (1) Making messages accessible in multiple ways, e.g. send one copy to
> >    my email account and another to my pager. Or voice mail. Or printer.
> >    Or FAX.

A very common case is for pager, fax, or voice mail services to be outsourced
to an external service provider. Often as not different people in the org will
use different providers for this stuff. This is especially true if we're
talking about a hosted setup. ADMD restriction cannot possibly work here.

> > (2) Secretaries who need copies of their boss's email.

ADMD restriction are mostly compatible with this use-case.

> > (3) Maintaining multiple mailboxes during a service transition
> > period. Or two pagers.

This would depend on the nature of the transition. I've seen transitions to
another ADMD as well as transitions within an ADMD. Domain restrictions are
problematic in this case.

> > (4) Making backup copies of mail to address reliability issues (IMO
> > this is not the best way to solve this problem but it is commonly done
> > this way regardless of what I think).

In many cases the entire point of doing this sort of thing, especially at the
user level, is to get a copy of your mail to a place that has separate
administative controls. ADMD restrictions would be hugely problematic
for this use-case.

> > (5) Making copies of stuff for law enforcement use (garden variety
> >    forwarding is a piss-poor way to implement this but it is nevertheless
> >    something people do fairly often).

> (uh, yah, laughing about how well this will meet some US Law
> enforcement requirements :-)

I can't get into details, but the truly amazing thing is that I've seen
situations where law enforcement _insisted_ on it being done this way  even
when a technically superior solution was available. (I'm actually writing a
response to a proposal that's basically a variant of this idea in  another
window.)

I don't actually know if the cases where this has been done involve forwarding
outside the ADMD or not. (To be honest, I try very hard to learn as little
about the operational details of interception activities as I possibly can.)
But given the complete lack of clue needed to even consider using this approach
I would not be at all surprised if such forwarding has been done in this case.

> > (6) Vacation-time forwarding of important messages to the "next
> > tier" of handlers.

This is usually done inside the ADMD but not always.

Tallying up, restricting autforwarding by domain didn't fare so well against
this list of use-cases. So we're talking about a mechanism that is ineffective
against a significant subset of actual attacks as well as being incompatible
with a lot of completely legitimate things people like to do.

Yet another problem with domain restrictions is that it is easy for them to
turn into a violation of the least astonishment principle. ADMD boundaries can
be complex - I've seen setups that consider thousands or tens of thousands of
domains as local - and asking users to understand complex boundaries is in
effect asking for a lot of support calls. And SPs will do almost anything to
lessen the number of support calls they get.

> ...

> I'm not surprised - this all seems very consistent with my
> discussions to these types of folks. I assume you also have the
> discussions with the people like Yahoo, MSN, gmail, around the
> policies they put in place to stop their servers from being used in
> DOS attacks?

The people I talk to tend to be large ISPs rather than these sorts of SPs, but
yes, we talk about DOS attacks a fair amount. However, the issue of the ISPs
own infrastructure being used in the ways you envision for DOS attacks has
almsot never come up, for the simple reason that it is not a significant issue
for them.

> I know I have been dragged into a few theses - can  you
> provide some insight around policies there?

OK, let's look at email DOS attacks in a bit more detail. Let's start with what
sounds like a silly question: What does an MTA do? The answer, of course, is
that it transfers messages around. It follows that if an MTA is good at its job
it has to be able to accept and process messages fairly quickly. And this is in
fact the case: It isn't at all difficult to get performance of 50
messages/second on a single box. With a little more effort you can kick things
up into the 500 messages/second realm (the main issue at this point is spam and
virus scanning performance) and MTAs have been built that can handle well over
2000 messages/second (at this point threads and filesystem performance become
the bottleneck, requiring a bunch of exotic tricks to deal with).

MTAs are also built defensively, and the primary defensive stategy is to try
and stop the bad stuff as close to the security perimeter as possible. The
further in stuff gets the more resources have to be expended dealing with it.
For example, when a user goes seriously over quota the best thing to do is turn
back mail with a 4yz (temporary) error, not accept it and hold it until they go
under quota again. Various rate limiting strategies are useful here as well and
in practice are widely deployed. So unless your attack has both a distributed
source and destination there's a very good chance it will be quickly detected
and blocked.

The bottom line is that modern MTAs are very good at handling lots legitimate
SMTP transactions and take all sorts of steps to prevent themselves from being
overwhelmed by too many of them. So attacking the email infrastructure by
performing lots of real transactions is in effect a frontal attack against the
most heavily fortified part of the entire system. This is not a recipe for
success.

So if frontal attacks don't work very well, what does? What we commonly see are
attacks on various server resources: Connections, threads, processes, memory
and disk. If an attacker can consume enough of some resource they can bring the
servers down or at least make them very slow. For example, one attack we saw a
while back was to send an infinitely long message - some MTAs buffer messages
in memory and done right this could consume all available swap space and hang
the server. Or there's the trick of opening lots of connections but never
sending any data. Or stopping in the middle of the transaction. (This one is
apparently popular right now - I have no idea why.) Or sending commands R E A L
L Y  S L O W L Y. Or attacking the network stack with malformed packets,
incomplete TCP exchanges, and so on. Or simply overwhelming the network itself
with data. Or causing the MTA to overlaod some  other service, e.g. kill the
directory server by sending lots of RCPT TOs and forcing lots of lookups. Or
exploiting some known flaw in a particular implementation, e.g. blowing a vital
cache by doing something to invalidate its content. The list is long, and if
the attacker is highly distributed some of these are very difficult to defend
against.

But now let's consider where autoforwarders fit into this attack tree. First of
all, since email is store and forward you cannot get an autoforwarder to
perform anything but an actual transaction, corresponding to a direct frontal
attack - exactly the attack MTAs are best at preventing. Even worse (for the
attacker), autforwarders don't provide an attacker with much flexibility in
terms of either distributing either the source or destination of the attack:
Automating account and filter creation is in most cases difficult if not
impossible, making the task of getting enough autoforwarders in place very time
consuming and error prone, and most autoforwarders, including Sieve redirect,
can only forward to a fixed set of destinations - the redirection cannot go to
an address that's pulled out of the message itself. (The sieve variables
extension changes this, but the topic at hand is what's possible in the Sieve
base specification, not what some extension allows.) Finally, the people who
offer autoforwarding as part of their service are as a general rule not morons
and will probably notice if a large volume of email starts coming in only to be
forwarded right back out.

The bottom line is that, your beliefs to the contrary notwithstanding,
autoforwarders just aren't that interesting of a tool for attackers. This has
been largely true throughout the history of email, and in the present world of
botnets it is more true than ever. The folks at Cloudmark (who know far more
about the attack landscape than I do) told me a couple of weeks ago that the
botnets out there are now so large that devastating results can be had even if
each infected system only sends out 5-6 messages a day. Given this why would
any attacker even bother making autoforwarders part of their attack toolkit?

> >> I believe that
> >> the IETF has clear consensus that it does not want to deploy
> >> technology that could trivially be used for large scale DOS and
> >> message amplification attacks with very little safeguards or
> >> traceable ways of dealing with this.
> >
> > This presupposes that there's a real risk here and that the necessary
> > safeguards are not in place. I don't believe either of these are true.

> So far no one as sent me any information arguing these are not true.

Say what? My responses have contained exactly this sort of information and
argument. And AFAICT you have yet to effectively refute a single point I have
made.

> > > Now my current judgement call is
> > > that this is in that category and could cause harm to the internet.

> > But we're not dealing with a new protocol with zero operational experience here
> > where such judgement calls are our only means of assessing possible risk.
> > Rather, we're not only dealing with a protocol that has signifcant deployment
> > and operational experience, we're talking about a particular feature that's
> > been an integrall part of email for decades and is accessible in all sorts of
> > ways besides Sieve.

> Sure - and clearly if it is not a problem, it is stopped somehow, I'm
> asking the Security section to provide some advice about how this is
> all stopped.

Leaving aside that this is a fairly significant change in position on your
part, the problem with this is that your reasoning rests on an unwarranted
assumption: That the reason it is not a problem is because people have taken
specific steps to prevent autoforwarder abuse. The fact of the matter is they
haven't done this. What has happened instead is that the myriad of other
measures people have taken to prevent attacks on the email infrastructure have
collectively managed to make autoforwarders a fairly uninteresting tool for
attackers.

> > First, nobody is claiming that autoforwarders cannot be used as an amplifying
> > component in various sorts of attacks. They can be used this way. This was true
> > for email decades before Sieve came along and it will continue to be true no
> > matter what we do in this document.

> yet somehow widespread message amplification attacks from email are
> mitigated to an currently acceptable level.

Yes, because the measures people take to defend against other, far more
pernicious attacks end up defending against autoforwarders vicariously.
Defending against mail loops, for example, does more to limit the effectiveness
of autoforwarders as an attack mechanism than any other step you can take. But
if you don't have reasonable loop detection in place you will quickly find that
autoforwarders are the least of your problems.

> > Second, nobody is claiming that script analysis can be used to prevent people
> > from abusing Sieve as part of such attacks. It simply cannot be done.

> agreed - let's make sure the draft does not suggest people do it

I have no problem with that.

> >    More generally, the days where email systems can get away without producing
> >    comprehensive logs and audit trails ended a long time ago. I have no idea
> >    what you're basing your assertions that such attacks would not be tracable
> >    in modern email systems, but it runs absolutely contrary to all of my
> >    recent experience.

> Certainly agree with you in enterprise case but in  a public provider
> such as yahoo, sure they have logs but they may not have any way to
> tying that to an actually human associated with the account.

But even if they had the information they still aren't going to go after most
abusers - law enforcement could not care less about this stuff and a civil suit
is way too much trouble for way too little gain. All they're going to do  is
shut down the account.

BTW, the same is often true in the enterprise case: If some guy uses a mailbomb
to say "I quit" the odds are pretty good the company will simply clean up the
mess and move on.

In any case, the point of having good logs is to be able to identify and stop
bad behavior. Catching and punishing the person responsible is a whole
different matter.

> This is great - few bits inline below...

> >    Allowing a single script to redirect to multiple destinations can be
> >    used as a means of amplifying the number of messages in an attack.
> >    Moreover, if loop detection is not properly implemented it may be possible
> >    to set up expontentially growing message loops. Acording, Sieve
> >    implementations:
> >
> >    (1) MUST implement facilities to detect and break message loops. See
> >        RFC 2821 section 6.2 for additional information on basic loop
> >        detection strategies.

> My discuss did not ask for this but it certainly seems like a good idea.

Alexey already pointed out that you did in fact ask for this.

> >
> >    (2) MUST provide the means for administrators to limit the ability of
> >        users to abuse redirect. In particular, it MUST be possible to
> >        limit the number of redirects a script can perform. Additionally,
> >        if no use cases exists for using redirect to to multiple destinations,
> >        this limit SHOULD be set to 1. Additional limits, such
> >        as the ability to restrict redirect to local users MAY also be
> >        implemented.

> We are very close here. If you changed the  "Additionally if no use
> cases exists for using redirect to to multiple destinations this
> limit SHOULD be set to 1." to "Scripts SHOULD be limited to at most
> one redirect that is not 'onsite'". And define onsite somewhere. I'd
> point out that this is a SHOULD not a MUST and that it could be
> ignored if people understood the security implications of what they
> were about to do. This could also possibly be coupled with idea after
> next point to explicitly allow multiple redirects in some cases.

My problem with this is that "onsite" or "within the domain" or whatever should
not be conflated with limiting the extent to which users are allowed to use
redirect. I actually think you have substantially weakened the impact of this
guidance by over-emphasizing domain restrictions.

> >    (3) MUST provide facilities to log use of redirect in order to facilitate
> >        tracking down abuse.

> I would ask if this mean that they MUST know what human the script
> was associated with. If yes, it is way beyond what I am asking for
> and if no then hard to see how it helps.

On the contrary, this is arguably the most useful advice we have to offer. Real
time as well as offline analysis of logs is in practice one of the primary
tools that's used to find and eliminate email abuse. We actually spend at least
as much time advising our large ISP customers on how to do this more
effectively than we do on how to set up rate limiting or any other sort of
defense. (And as I mentioned previously, our ISP customers have demonstrated no
interest whatsoever in administrative limits on redirect. And we'd know because
it turns out the limit option wasn't documented.)

> When I mentioned months ago
> I could imagine many ways to solve this, coupling this type of thing
> to the ability to do more than one redirect was one of the things
> that seemed like a possible solution (and corresponds to my
> understanding of at least some current deployments).

In conclusion, Alexey has proposed new text in a separate messagage which
I find completely acceptable. Please take a look at that and let's see
where we are.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7UJ4M8x077152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2007 12:04:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7UJ4M9e077151; Thu, 30 Aug 2007 12:04:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7UJ4GAj077131 for <[e-mail]>; Thu, 30 Aug 2007 12:04:19 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Aug 2007 20:04:13 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Aug 2007 20:04:59 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Cullen Jennings <[e-mail]>
CC: Ned Freed <[e-mail]>, [e-mail], Lisa Dusseault <[e-mail]>, [e-mail], Philip Guenther <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Cullen,

Cullen Jennings wrote:

>> So what can we do? Well, I guess one option would be to try and make
>> the discussion of this a little more explicit in the document. How  
>> about
>> adding something like this to the security considerations?
>
> This is great - few bits inline below...
>
>>    Allowing a single script to redirect to multiple destinations  can be
>>    used as a means of amplifying the number of messages in an attack.
>>    Moreover, if loop detection is not properly implemented it may  be 
>> possible
>>    to set up expontentially growing message loops. Acording, Sieve
>>    implementations:
>>
>>    (1) MUST implement facilities to detect and break message loops.  See
>>        RFC 2821 section 6.2 for additional information on basic loop
>>        detection strategies.
>
> My discuss did not ask for this but it certainly seems like a good idea.

Actually it did:

Discuss [2007-05-10]:
 The document says that one SHOULD do loop detection - I think it needs to point
 at some advice that provided at least one way to implement loop detection at a
 level of detail high enough that it is implementable.

and lack of the reference was a bug in the document.

 [...]

>>    (3) MUST provide facilities to log use of redirect in order to  
>> facilitate
>>        tracking down abuse.
>
> I would ask if this mean that they MUST know what human the script  
> was associated with.

I don't think so. Existing mail systems log an email address or an 
associated account name. This is sufficient to identify an account 
causing mail abuse.
Even if the account provider has no information about the physical 
person associated with the account, it has the ability to disable the 
account to stop any abuse.

Alexey



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TKjuiG052555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 13:45:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7TKjtO7052554; Wed, 29 Aug 2007 13:45:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TKjs5q052546 for <[e-mail]>; Wed, 29 Aug 2007 13:45:55 -0700 (MST) (envelope-from [e-mail])
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 Aug 2007 13:45:54 -0700
X-IronPort-AV: i="4.19,323,1183359600";  d="scan'208"; a="518514518:sNHT98177446"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7TKjs67019748; Wed, 29 Aug 2007 13:45:54 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l7TKjeYb002708; Wed, 29 Aug 2007 20:45:41 GMT
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Impp: xmpp:[e-mail]
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail], Lisa Dusseault <[e-mail]>, [e-mail], Philip Guenther <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
Date: Wed, 29 Aug 2007 13:44:15 -0700
To: Ned Freed <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=26415; t=1188420354; x=1189284354; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Cullen=20Jennings=20<[e-mail]> |Subject:=20Re=3A=20Suggested=20changes=20to=20address=20Cullen's=20DISCU SS=20on=20draft-ietf-sieve-3028bis-12.txt |Sender:=20; bh=2dTbJ11BsgDI+HW6a+4TD+s11m2JvzHH06GBmpwsp54=; b=UO8YVj/xG7jWoLFCiMaNTpdmo/eT2fGBlA4DlrpUOwzA5TxMYqWN1AvVFfYq3neDc+98txbr lpRYQXzckme8EjtZ7L28pJoN7i6JBzLAeRgFUzahIVN+TCniu3lubsrh;
Authentication-Results: sj-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned, this is a very helpful email on moving things forward - thanks.  
If' you get to the bottom of this email, I would be fine with a very  
minor variant of what you are suggesting and I think it meets the use  
cases you brought and god to discuss changes if it does not resolve  
others that were not brought up.

On Aug 25, 2007, at 3:59 PM, Ned Freed wrote:

>> inline ...
>
>> On Aug 25, 2007, at 9:37 AM, Alexey Melnikov wrote:
>
>> > Cullen Jennings wrote:
>> >
>> > > I don't think that is really implementable advice - it basically
>> > > wishes the problem away.
>
> What advice are you talking about here? I see nothing in the  
> revised text that
> would argue for the sort of analysis of sieve scripts you're (quite  
> correctly)
> saying is impossible.

Uh  .. the text that say
    It is equally important that implementations sanity-check the user's
    scripts, and not allow users to create on-demand mailbombs.  For
    instance, an implementation that allows a user to redirect a message
    multiple times might also allow a user to create a mailbomb  
triggered
    by mail from a specific user.

but ignore this - lets move ton to how to fix instead of why I  
thought the draft suggested something impossible

>
>> > It is implementable, it applies to UIs and admin tools and many
>> > implementations already follow it.
>
>> So the topic I was questioning the implementability of is a program
>> that can look a series of sieve scripts across one or more email
>> servers and decide if the sieve scripts are capable of creating large
>> scale message amplification attacks.
>
> Sounds to me like you and Alexey are talking at cross purposes  
> here, but in
> regards to the question of whether what you're talking about is  
> implementable:
> It isn't, although not for the reasons you give.
>
> The main reason it is unimplementable is very simple: Email is an  
> Internet-wide
> service and no program can possibly have the administative access  
> to the entire
> Internet it would need to perform such a check. As a specific  
> example, I have
> email accounts at Sun, on my home systems, Gmail, and a bunch of  
> other places.
> All, I repeat _all_, of these services allow me to easily configure
> autoforwarding to multiple destinations.
Uh - you sure. I'm not aware how to make gmail go to multiple system  
which is of course the important one because the others systems have  
relationships with you and other ways to secure things by causing bad  
consequences for you if you abuse the system. But again, let's get to  
how to fix it which I think you and I are on roughly the same page.

> I will also point out that while
> several of these systems provide Sieve support, none of them  
> require the use of
> sieve for me to set up this sort of autoforwarding. (OK, to be fair  
> I have no
> idea what's underneath the hood at Gmail, but if the other aspects  
> of their
> filtering interface are any indication it is not Sieve-based.)
>
> To put this more concisely: It is clearly impossible to devine the  
> intent of an
> autoforwarder that is operating as part of a much larger web of  
> autoforwarders
> just by looking at it in isolation, and it is equally impossible to  
> assess the
> properties of other autoforwarders located in other administrative  
> domains. It
> follows that analyzing autoforwarders to prevent construction of  
> mail bombs is
> inherently unimplementable. (Believe it or not, some faciities in X. 
> 400
> actually depended on this being possible. You can probably guess  
> how well that
> worked out...)

Yes agree with all your analysis here/

>
>> The draft clearly does not
>> contain enough information to tell someone how to implement this and
>> personally I seriously doubt that it is possible due to the halting
>> problem.
>
> I believe my preceeding argument demonstrates that the question of  
> Sieve's
> Turing completeness is completely irrelevant to the matter at hand.
> Nevertheless, since several people apparently continue to think  
> this is an
> important point I will elaborate on it a little further.
>
> A Sieve in isolation is pretty clearly not Turing complete - no  
> real loops - so
> the at that level at least the halting problem doesn't enter into it.
>
> Now, Eric Rescorla once argued that Sieve should be considered  
> Turing complete
> because you could bounce a message back and forth between multiple  
> systems,
> using the message content to store the position on the tape.
>
> Even if you ignore the critical point that Sieve not being Turing  
> complete was
> always about whether or not a sieve script in isolation could cause  
> a infinite
> loop and wedge up your server and never about whether or not Sieve  
> could
> function as a component in a larger, Turing complete system, the  
> problem with
> this argument is that Recieved: field counting nails you pretty  
> quickly for
> regular messages, and once again you're left without the loop  
> construct you
> need to make it "work".
>
> This then leaves you with no alternative but to try and use other,  
> wierder
> sorts  of loops. The obvious one to try, and the one Eric proposed,  
> is what I
> call a "bounce loop": Redirect to a known-invalid address, get the  
> bounce back,
> redirect again, bounce again, etc. But bounce loops are only  
> possible if some
> agent in the path is willing to change the empty envelope from that  
> is required
> in the bounce message to refer to some other address in the  
> forwarding path.
> Without that happening a bounce cannot itself generate a bounce, so  
> the loop
> stops after at most two iterations.
>
> This last point actually raises a general issue for autoforwarders  
> - they MUST
> NOT override an empty envelope from because if they do they can  
> create bounce
> loops. (I note in passing that in practice this is almost always  
> happens
> accidentally, not intentionally. Nevertheless, it is a very real  
> problem that
> email systems have to deal with.) RFC 2821 should have made this a  
> requirement
> but didn't. I plan to raise this issue in the context of 2821bis  
> but I would
> not object to changing the closing text in section 4.2 of the Sieve  
> base
> specification to say:
>
>   The envelope sender address on the outgoing message is chosen by the
>   sieve implementation. It MAY be copied from the message being
>   processed. However, if the message being processed has an empty
>   envelope sender address the outgoing message MUST also have an
>   empty envelope sender address.
>
> More generally, one of the primary goals of the design of the email
> infrastructure is that _all_ autoforwarding loops, once underway,  
> can be
> detected and stopped. It is _not_ a design goal to prevent such  
> loops from
> being set up - any system that tried to enforce that would be much too
> restrictive.
>
> If follows that the ability to construct an undetectable loop means  
> there's a
> serius design or the implementation flaw that needs to be  
> corrected. But the
> fact that such flaws might enable Sieve to be Turing complete is  
> entirely
> trivial compared to the other serious issues undetectable loops raise.
>
> Getting back to the script complexity issue, since Sieve allows  
> arbitrary
> boolean expressions script analysis is pretty clearly equivalent to  
> the
> satisfiability problem, i.e. it's NP-complete, and that puts full  
> analysis of
> arbitrary sieves out of reach of anything short of a quantum  
> computer, which
> AFAIK means it effectively cannot be done. So that's another reason  
> why you're
> correct in saying this kind of analysis is impossible to perform on  
> Sieve
> scripts. But  since AFAICT nobody is proposing performing such an  
> analysis,
> this doesn't change anything.
>
>> Of course I suspect it is not possible because I am also
>> very incredulous of the WG's claim that sieve coupled with common
>> email systems is not turing complete.
>
> To be blunt, your incredulity fails to impress, let alone persuade.  
> If you
> believe such a thing is possible then prove it by giving the  
> details of how
> such a system could be built that doesn't depend on an  
> architectural flaw of
> some sort in email's design or implementation.
>
> I'm actually quite eager to be proved wrong on this since it will  
> necessarily
> expand my knowledge of what email systems are capable of. But I  
> require proof,
> not the handwaving I've seen so far.

Once again, I have only said I suspect it is turning complete not  
that I have proof of such. Anyway, we both agree this is irrelevant  
to resolving the problem.

>
>> Luckily I think that an
>> acceptable solution can be found without having a debate about basic
>> CS theory.
>
> I'm delighted to hear it.
>
>> > > More inline ...
>> > > On Aug 17, 2007, at 2:34 PM, Alexey Melnikov wrote:
>> > >
>> > >> Cullen, does the following address your DISCUSS?
>> > >>
>> > >> =============================
>> > >> In section 4.2, last paragraph:
>> > >>
>> > >> OLD:
>> > >>  Implementations SHOULD take measures to implement loop control,
>> > >>  possibly including adding headers to the message or counting
>> > Received
>> > >>  headers.  If an implementation detects a loop, it causes an  
>> error.
>> > >> NEW:
>> > >>  Implementations SHOULD take measures to implement loop control,
>> > >>  possibly including adding headers to the message or counting
>> > Received
>> > >>  headers as specified in section 6.2 of [SMTP].  If an
>> > >> implementation detects a loop, it causes an error.
>> > >>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > >>
>> > >> Add to the end of section 4.2 two new paragraphs:
>> > >>
>> > >>  Implementations SHOULD provide means of limiting the number of
>> > >> redirects a
>> > >>  Sieve script can perform.
>> > >
>> > > Well if it was the number of redirects SHOULD be limited to  
>> one it
>> > > would do it but as it is - not sure I see how it helps.
>> >
>> > Cullen, I told you before, there is very strong WG consensus to  
>> allow
>> > implementations to use more than one.
>> >
>> > Please see
>> > <http://www.imc.org/ietf-mta-filters/mail-archive/msg03601.html>  
>> and
>> > <http://www.imc.org/ietf-mta-filters/mail-archive/msg03599.html>.
>> >
>> > Now, if you have another suggestion how to address your issue, I  
>> would
>> > like to hear it.
>
>> I have given a simple and easy way to address it that seemed to also
>> work for the use cases that people told me about (I certainly admit I
>> don't know all the case).
>
> If memory serves, your suggested way to prevent it was to allow at  
> most one
> redirect operation to be done during the execution of a sieve script.

Well, what I have in my notes from the prague meeting was "Told them  
I was OK with SHOULD not redirect to more than one location outside  
the domain". We may have different ideas about what domain means but  
roughly I would mean administrative domain - certainly I would call  
an enterprise or large bank one domain even thought they might have  
separate DNS domain names for different locations or something. You  
might use the term "onsite" where I used domain.


> And
> you've been told that this is simply not acceptable - there are too  
> many use
> cases for forwarding email to two different places at once.

Actually, I have received very little comment on if this is  
acceptable or not. I have mostly recieved something that loosely  
translated to "the WG disagrees with your discuss". I would be very  
happy to talk what my concerns are and have folks figure out if their  
is a solution that addresses them and still meets the bulk of users  
needs.

> In fact this is an
> incredibly common thing for people to do for all sorts of  
> legitimate reasons,
> including but not limited to:

I suspect what I had proposed meets all these use case but don't  
claim to really know. Glad to be educated.

>
> (1) Making messages accessible in multiple ways, e.g. send one copy to
>    my email account and another to my pager. Or voice mail. Or  
> printer.
>    Or FAX.
> (2) Secretaries who need copies of their boss's email.
> (3) Maintaining multiple mailboxes during a service transition  
> period. Or
>    two pagers.
> (4) Making backup copies of mail to address reliability issues (IMO  
> this is
>    not the best way to solve this problem but it is commonly done  
> this way
>    regardless of what I think).
> (5) Making copies of stuff for law enforcement use (garden variety
>    forwarding is a piss-poor way to implement this but it is  
> nevertheless
>    something people do fairly often).

(uh, yah, laughing about how well this will meet some US Law  
enforcement requirements :-)

> (6) Vacation-time forwarding of important messages to the "next  
> tier" of
>    handlers.
>
> We have two large banks as customers, both with thousands of  
> employees. The
> American one is very well known - anyone who isn't a complete  
> hermit is
> guaranteed to be familiar with it. They have a very elaborate email  
> setup that
> routes mail through various analysis, categorization, and  
> compliance facilites.
> The outcome of these operations are then assessed with various  
> sieve scripts,
> which then use redirect and various other tools to alter message  
> routing. The
> ability to redirect to multiple addresses plays an important role  
> in all this.
>
> The other bank is European (and may be a household name there for  
> all I know)
> and their setup is even more relevant. They have basically used  
> Sieve to
> implement an elaborate workflow system. Some of their scripts use  
> redirect
> 10-20 times on a single message. The most interesting aspect of  
> their setup is
> that they have intentionally created loops all over the place. They  
> use various
> checks, some explicitly done in Sieve, some autogenerated in Sieve,  
> and others
> external to Sieve, to break the loops at exactly the right points.  
> This usage
> is way past what, say, .forward files can do. The proper  
> functioning of this
> setup is so important to them that no less than the CEO of the bank  
> has been
> known to "drop in" on technical discussions of various  
> implementation details.
> (And this is not hearsay - I'm speaking from direct personal  
> experience.)

>
> I could go on and give many more examples of use cases but  
> hopefully you've
> gotten the idea by now. The ability to autoforward to multiple  
> addresses is an
> essential feature - it has part of modern email effectively from  
> the beginning
> and without it Sieve simply doesn't have feature parity with other  
> message
> filtering facilities. In our case if we were to remove it our  
> customers would
> simply find a different vendor that doesn't impose such limits. As  
> for setting
> the default limit on redirect to 1, all that would accomplish for  
> us is to keep
> us all busy dealing with the resulting support calls.

I'm not surprised - this all seems very consistent with my  
discussions to these types of folks. I assume you also have the  
discussions with the people like Yahoo, MSN, gmail, around the  
policies they put in place to stop their servers from being used in  
DOS attacks? I know I have been dragged into a few theses - can  you  
provide some insight around policies there?

In understand that different things are used in different times - the  
goal of this document should be to produce something where the  
Security considerations are good enough not to cause serious harm.

>
>> However, let me be very clear - it is not
>> my job to find a solution that the WG likes to this.
>
> It is, however, your job to impose reasonable requirements. And IMO  
> you are not
> being reasonable here.

The solution would be discussion around understanding a set of  
reasonable requirements and feasible designs.

>
>> I believe that
>> the IETF has clear consensus that it does not want to deploy
>> technology that could trivially be used for large scale DOS and
>> message amplification attacks with very little safeguards or
>> traceable ways of dealing with this.
>
> This presupposes that there's a real risk here and that the necessary
> safeguards are not in place. I don't believe either of these are true.

So far no one as sent me any information arguing these are not true.

>
> The fact is Sieve and numerous other autoforwarding mechanisms are  
> already
> widely deployed without the limits you think are necessary and  
> curiously all of
> these serious flaws you see aren't being exploited.
>
> I dislike trotting out our own deployment statistics but it seems  
> now is the
> time for it. According various sources our product provides service  
> for well
> over 100 million mailboxes. A significant fraction of this total  
> provides end
> user access to set up sieves and our current default is to allow up  
> to 32
> redirects per sieve. As I pointed out in my original response, the  
> number of
> customers we've had that have reported problems with sieve redirect  
> and have
> needed to impose limits is exactly zero. And believe me when I say  
> that our
> customer base includes lots of people who aren't exactly shy about  
> reporting
> the least little thing that goes wrong.
>
>> Now my current judgement call is
>> that this is in that category and could cause harm to the internet.
>
> But we're not dealing with a new protocol with zero operational  
> experience here
> where such judgement calls are our only means of assessing possible  
> risk.
> Rather, we're not only dealing with a protocol that has signifcant  
> deployment
> and operational experience, we're talking about a particular  
> feature that's
> been an integrall part of email for decades and is accessible in  
> all sorts of
> ways besides Sieve.
Sure - and clearly if it is not a problem, it is stopped somehow, I'm  
asking the Security section to provide some advice about how this is  
all stopped.

>
>> You can convince me I am wrong about that - or you could find a way
>> of mitigating and reducing this risk - I can think of several and I
>> have suggested the one that I think is most likely to be acceptable
>> to the WG
>
> Given that limiting redirects to 1 is totally unacceptable I have  
> no idea
> what you are referring to here.
>
>> but I make no presumption that I would know what is the
>> best solution for this WG on this problem. I have made it clear what
>> the issues is, why I think a change is needed, this should not be  
>> hard.
>
> I don't think it should be hard either, but the talking at cross  
> purposes
> continues.
>
> So let me try one last time to cut through the misunderstandings.
>
> First, nobody is claiming that autoforwarders cannot be used as an  
> amplifying
> component in various sorts of attacks. They can be used this way.  
> This was true
> for email decades before Sieve came along and it will continue to  
> be true no
> matter what we do in this document.
yet somehow widespread message amplification attacks from email are  
mitigated to an currently acceptable level.

>
> Second, nobody is claiming that script analysis can be used to  
> prevent people
> from abusing Sieve as part of such attacks. It simply cannot be done.
agreed - let's make sure the draft does not suggest people do it

>

> So, since such attacks are inherently possible in the present email
> infrastructure no matter what we do or don't do in Sieve, the focus  
> has to be
> on detecting and stopping attacks. This is done by:
>
> (1) Making sure infinite loops can be detected and stopped. The  
> main risk is
>    that without comprehensive loop detection you can and will end  
> up with
>    exponentially growing message loops. I've seen such situations
>    arise and create literally 10s of millions of messages in a very  
> short
>    period of time.
>
>    Without a true loop the amplification potential of an  
> autoforwarder web is
>    bounded by the number of autoforwarders in the web multipied by   
> number of
>    redirects that are allowed per sieve. So the only way such a web  
> can be used
>    effectively is if you have the means to inject an endless stream  
> of messages
>    into it at some point. And that brings us to:
>
> (2) Rate limit message submission. If true loops aren't possible  
> something
>    somewhere has to act to generate the "signal" that is  
> "amplified". This
>    sort of behavior can be detected and blocked.
>
> (3) Administrative controls. The basic rule is don't allow users to  
> access
>    functionality they don't need. If there's never a need to use  
> redirect,
>    disable it entirely. If they only need to be able to do one  
> redirect
>    per sieve, only allow that. If they only need to be able to  
> redirect to
>    other users onsite, only allow that. If a class of messages  
> exists that
>    aren't supposed to be redirected, check for them and yell if a  
> redirect
>    is done. And so on. The list of possibilities here is very long.
>
> (4) Auditing and tracking. The aforementioned European bank has a  
> requirement
>    that every message carry a complete history of the redirection  
> that was
>    performed. They also require that all of this be derivable from  
> the logs.
>    And many of our other customers have similar requirements.
>
>    More generally, the days where email systems can get away  
> without producing
>    comprehensive logs and audit trails ended a long time ago. I  
> have no idea
>    what you're basing your assertions that such attacks would not  
> be tracable
>    in modern email systems, but it runs absolutely contrary to all  
> of my
>    recent experience.

Certainly agree with you in enterprise case but in  a public provider  
such as yahoo, sure they have logs but they may not have any way to  
tying that to an actually human associated with the account.

>
> Now, I will admit that the document doesn't cover a lot of this.  
> But there's a
> reason for that: Autofording to multiple address exists independent  
> of Sieve
> and as such is a general architectural issue for email, not one  
> specific to
> Sieve. It would be great if there was a document comparable to RFC  
> 3834 for
> autoforwarders but there isn't, and it is not within scope for this  
> WG to
> produce such a specification.
>

I really liked the above analysis - it's the most information I have  
received on this thread since I first read this document. Thank you.

> So what can we do? Well, I guess one option would be to try and make
> the discussion of this a little more explicit in the document. How  
> about
> adding something like this to the security considerations?

This is great - few bits inline below...

>
>    Allowing a single script to redirect to multiple destinations  
> can be
>    used as a means of amplifying the number of messages in an attack.
>    Moreover, if loop detection is not properly implemented it may  
> be possible
>    to set up expontentially growing message loops. Acording, Sieve
>    implementations:
>
>    (1) MUST implement facilities to detect and break message loops.  
> See
>        RFC 2821 section 6.2 for additional information on basic loop
>        detection strategies.
My discuss did not ask for this but it certainly seems like a good idea.

>
>    (2) MUST provide the means for administrators to limit the  
> ability of
>        users to abuse redirect. In particular, it MUST be possible to
>        limit the number of redirects a script can perform.  
> Additionally,
>        if no use cases exists for using redirect to to multiple  
> destinations,
>        this limit SHOULD be set to 1. Additional limits, such
>        as the ability to restrict redirect to local users MAY also be
>        implemented.
We are very close here. If you changed the  "Additionally if no use  
cases exists for using redirect to to multiple destinations this  
limit SHOULD be set to 1." to "Scripts SHOULD be limited to at most  
one redirect that is not 'onsite'". And define onsite somewhere. I'd  
point out that this is a SHOULD not a MUST and that it could be  
ignored if people understood the security implications of what they  
were about to do. This could also possibly be coupled with idea after  
next point to explicitly allow multiple redirects in some cases.

>
>    (3) MUST provide facilities to log use of redirect in order to  
> facilitate
>        tracking down abuse.
I would ask if this mean that they MUST know what human the script  
was associated with. If yes, it is way beyond what I am asking for  
and if no then hard to see how it helps. When I mentioned months ago  
I could imagine many ways to solve this, coupling this type of thing  
to the ability to do more than one redirect was one of the things  
that seemed like a possible solution (and corresponds to my  
understanding of at least some current deployments).

>
> I didn't include rate limiting on the list for several reasons: (1)  
> It's hard
> to get right and naive attempts to implement it can be very  
> dangerous. (2)
> There's no consensus on what best practices for it are and hence  
> any discussion
> of it is likely to rathole.
agree

>
> I would also suggest getting rid of the discussion about sanity- 
> checking since
> this discussion seems to indicate it is open to serious  
> misinterpretation.
agree

>
> Does any of this work for you? If it doesn't I'm frankly out of  
> ideas for how
> to resolve this.
This seems extremely close to fully resolving it. I think your  
suggestions are great and glad to have a dialog that suggests  
something to solve the issue.

>
> 				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TINjnf037829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 11:23:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7TINje1037827; Wed, 29 Aug 2007 11:23:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TINhCM037816 for <[e-mail]>; Wed, 29 Aug 2007 11:23:44 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 29 Aug 2007 19:23:40 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Aug 2007 19:24:27 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Sieve WG Chicago meeting minutes
Content-Type: multipart/mixed; boundary="------------020107020408000602000704"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Chairs apologies for being so late with this...


--------------020107020408000602000704
Content-Type: text/plain;
 name="sieve-ietf-69(chicago)-minutes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="sieve-ietf-69(chicago)-minutes.txt"

3028bis (base spec): blocked on Cullen's DISCUSS. Need to try to catch Cullen during the IETF week to discuss
 his issue.

Notify Mailto draft:

[14:18:01] <cyrus_daboo> discussion of auto-submitted in notify mailto and whether we need strong text about preventing loops.
[14:20:22] <aaronstone> (agree that notification messages should not trigger notifications)

Editheader:

[14:28:22] <cyrus_daboo> new draft addressing issues: some comments from Ned were addressed.
[14:28:45] <cyrus_daboo> We has a Sieve lunch yesterday. From the lunch we came up with some better restrictions
 on deletion of "trace" headers
[14:29:53] <aaronstone> so we'd write a discrete whitelist of headers?
[14:29:59] <cyrus_daboo> Issue as to whether there is a list of specific headers that can always be changed/removed.
[14:31:10] <cyrus_daboo> X- headers should not be specifically called out.
[14:32:52] <cyrus_daboo> Chris: some headers (general class) should be editable.
[14:34:28] <cyrus_daboo> So, must permit changes to Subject, security consideration about changes to "trace" headers,
 then implementation note about being wise to allow changing classification headers.
[14:35:38] <cyrus_daboo> Barry wants clarification of slide bullet points.
[14:36:06] <cyrus_daboo> Is deletion of received forbidden no matter what local policy is?
[14:36:08] <cyrus_daboo> Yes.
[14:36:58] <cyrus_daboo> Randy wants more detail on the language for implementation note.
 Not happy with the current proposal.
[14:37:48] <aaronstone> MUST allow: Subject. MUST NOT allow: Received. SHOULD allow: everything else, because
 we like editing headers. MAY disallow: anything else for site policy.
[14:38:59] <cyrus_daboo> Kurt - aren't there other reasons (e.g. privacy)?
[14:41:29] <cyrus_daboo> Part of the problem is the precision in noting which headers are trace or not.
[14:43:19] <randy> 2821/2822 identify trace headers: received and return-path
[14:44:06] <aaronstone> oh right - return-path. that'd be an evil one to modify.
[14:46:07] <cyrus_daboo> Jeff: is it only up to local policy to define this or can the Sieve implementation
 dictate that policy?
[14:46:16] <guenther> randy: it's not a closed set
[14:47:41] <cyrus_daboo> Pete: policy may dictate that nothing can be changed so why not leave it all to local policy.
[14:47:57] <aaronstone> If the script cannot depend on at least one field, then it kills the poor-man's variables
 possibility... so what?

Notify:
[14:49:47] <cyrus_daboo> Document is ready for IESG

Reject/refuse:
[14:50:56] <[e-mail]> Aaron Stone will co-edit the document and move it along.
[14:51:10] <[e-mail]> Two changes needed, per IETF67 consensus:
[14:51:23] <[e-mail]> 1. two actions: reject, ereject.
[14:51:32] <[e-mail]> 2. add more details on MDN/DSSN
[14:52:03] <aaronstone> I have my asbestos Inbox filter turned on, so I'm ready for the flood of comments
 from everyone about what else this should go into refuse-reject :-)

MIME loops:
[14:52:31] <cyrus_daboo> Remember its not just MIME loops anymore - a whole bunch of other MIME related things
[14:53:04] <cyrus_daboo> biggest change was pulling extract_text action out of the notify
[14:53:15] <cyrus_daboo> IANA considerations greatly expanded
[14:53:21] <cyrus_daboo> other minor tweaks
[14:54:05] <cyrus_daboo> discussion of extract_text: suggestion to extend body to do the same
[14:56:46] <cyrus_daboo> issue: does text about how to find the first text part need to be more detailed?
[14:58:22] <cyrus_daboo> Will do last call and comments on those can be included then.
[14:59:03] <cyrus_daboo> extract_text returns empty string if not used in the context of an iterator
[14:59:23] <cyrus_daboo> Philip wants an error instead
[14:59:48] <cyrus_daboo> Jeff: compile time error not runtime
[15:00:03] <cyrus_daboo> Alexey: boundary is somewhat grey between runtime and compile time errors
[15:00:55] <cyrus_daboo> Jeff: do the "find the first part" logic as the logic of the loop itself

Ned's Date: ready for last call. Alexey will shepherd.

Ned's iHave: more review please

Ned's Notary: new drafts - more review please.

Alexey's IMAP METADATA:
[15:06:04] <cyrus_daboo> Who is planning on implementing this?
[15:07:03] <cyrus_daboo> Extension includes tests for existence and :create option for fileinto.
[15:07:33] <cyrus_daboo> Open issue: server annotations
[15:07:44] <cyrus_daboo> List-extended?
[15:08:20] <cyrus_daboo> Probably not now can be done as another extension later

Alexey's External Lists:
[15:09:43] <cyrus_daboo> Now allows URLs as well as user tokens as list identifiers
[15:11:02] <cyrus_daboo> issues:
[15:11:14] <cyrus_daboo> how to handle server outage? runtime error?
[15:11:30] <aaronstone> clearly we need a try/catch at runtime.
[15:13:13] <aaronstone> i'm just reading this for the first time, and yes, an entire mailing list could be implemented.
 If you could write to the external list from sieve, then you can even handle the maintenance addresses like
 list-subscribe, list-remove.
[15:14:23] <aaronstone> What is a "real mailing list"? It's a program written in some language that re-sends messages
 to a list of addresses.
[15:21:23] <aaronstone> on the issue of LDAP result paging, i brought this up in prague: we don't want the ":list foo"
 to be evaluated strictly and result in a huge stringlist. rather, we would want the action to accept the :list foo
 and lazy evaluate it inside the action handler.
[15:21:24] <jhutz> sure, but is it really necessary to extend Sieve to the point where it can be used to write mailing
 list software? There are plenty of mailing list pakages out there today, none of which are written in sieve.
[15:21:41] <[e-mail]> It's not just for mailing lists.
[15:21:57] <[e-mail]> There are lots of good reasons a Sieve script should be able to access my "address book".
[15:22:10] <[e-mail]> Now, where might my address book reside?
[15:22:46] <jhutz> Barry, I think some of the other use cases you and Philip have presented are compelling.
 I just don't think "implement mailing lists" is.
[15:23:02] <jhutz> Actually, I'm curious as to where your address book resides.
[15:24:26] <aaronstone> I'm tempted to write a mailing list manager in Sieve now just to see what it looks like.
 It would need basically every major extension - editheader, date tests, variables, etc. per the ietf "running code"
 mantra, let's see what it looks like before we pass judgment. and yes, i do think its the most pedantic use case.
 As barry points out, there are lots of very reasonable use cases that are not crazy at all.
[15:29:12] <jhutz> I don't think a sieve-based mailing list manager would be very useful operationally. However,
 it certainly would excercise a lot of the language features and extensions, and that alone might make it a worthwhile
 endeavor.
[15:29:43] <randy> (You don't really need editheader if you want to do an smtp-expn style list)
[15:30:02] <[e-mail]> I agree with Jeff... While I can come up with some limited good uses of Sieve to fan out
 messages, I don't think we should design Sieve to support mailing list usage in general.

Barry's IMAP Sieve:
[15:36:38] <aaronstone> would we be comfortable lifting the restriction against running multiple scripts if there were
 some document explaining what happens? I recall this being something that has been discussed before and several
 implementations _do_ currently use more than one script run at different stages of message delivery.
[15:37:43] <aaronstone> this is good -- it gives a transition path away from ManageSieve towards script management
 via metadata.
[15:38:07] <jhutz> Where is that restriction expressed?
[15:38:36] <aaronstone> Barry just said it out loud, that it's in the new IMAP-Sieve draft.
[15:40:01] <jhutz> ... and now I can't find the draft :-(
[15:40:38] <aaronstone> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-03.txt
[15:49:29] <randy> My point is that if clients are generating the scripts, if there is only one script per mailbox,
 then clients will stomp all over each others' scripts
[15:49:36] <aaronstone> ok, sounds good, and an important point that we don't cause the lemonade people to throttle us.
[15:50:03] <randy> If we allow /client/<client-id> as an extra metadata entry under /IMAPSieve/Script, then each client
 can add its own script
[15:50:25] <randy> These subsequent scripts would be prohibited from doing operations such as Reject and FileInto
[15:51:09] <guenther> 1) if you have two phones, do they use the same client-id or different ones?
[15:53:43] <guenther> 2) if different, and one died, what would delete the scripts for the dead client?
[15:53:52] <randy> Depends on how the phone's client is written. Assuming it creates a script based on local user
 configuration, I'd say each client needs its own id
[15:55:13] <randy> Don't know how best to reap scripts for dead clients, but there are possible solutions based
 on age of last change and so forth
[15:55:59] <randy> But without per-client scripts, it's unclear how these scripts get created or used. It seems
 to be a per-user thing that can't be per-client
[15:56:10] <randy> Any client will stomp on the script for others

Other business:

Q: Sieve face-to-face interop in Greece this fall (hosted by University of Athens)?
A: Mostly silence in response
Q: Is online interop better?
A: People are more entusiastic about that, but still not clear how much support this idea has.

[15:53:32] <aaronstone> I'd definitely be at an online interop, and possibly at an in person.
[15:54:03] <aaronstone> I think this actually grows into a question of creating a basic interop script test suite.
[15:54:13] <aaronstone> oh, that's what Barry and Arnt have talked about.
[15:54:22] <aaronstone> huge +1 from me.

--------------020107020408000602000704--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RJwYxo027231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 12:58:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7RJwY1e027230; Mon, 27 Aug 2007 12:58:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7RJwN5b027186 for <[e-mail]>; Mon, 27 Aug 2007 12:58:32 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 84732 invoked by uid 101); 27 Aug 2007 15:58:22 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 27 Aug 2007 15:58:22 -0400
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-mime-loop
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Aug 20, 2007 at 06:25:04PM -0400, Mark E. Mallett wrote:
> 
> 
> I had intended to get some comments out before the last day (i.e.,
> before today) but haven't managed to organize my thoughts well enough.
> I'd like to get them out to the list in the next day or two.


I don't know why I'm having such a hard time with this set of comments,
but I've been fretting on it forever, it seems.  Forgive me that it's still
somewhat muddled, but it's going out now :)

Even though I have a bunch of comments, I do like what this is trying to
accomplish and I'll likely end up implementing it however it ends up.

Some general stuff first:

I think I'd like it a bit better if it didn't seem like this was about
loops with some mime stuff thrown in; rather that it be about mime stuff
with loops being one aspect of it.  I realize the title is "MIME part
tests, iteration, extraction, replacement and enclosure."  However the
introductory text is almost all about loops.  I think that the first
introductory text should bring up a new concept of selecting MIME parts,
and how selecting a MIME part affects various Sieve constructs.  e.g.
when a MIME part is selected, the action of header tests becomes
refocused to deal with the selected mime part's header instead of the
top-level message header.  This is a change: that concept is not really
present in the draft so far, but I think it adds consistency and
clarity.  This would not have to be repeated for every section that
introduces new tagged arguments for header tests, as it is (sort of)
now.  This sort of introduction could lead to clearer text in other
areas too; such text could assume that the reader was familiar with the
notion of a selected MIME part, and go from there.  Each section would
not, as it does now, have to describe the special case of what a sieve
command does when it's inside of a loop vs the special case of what it
does when it's not inside of a loop.  I'd much rather get rid of those
special case descriptions in favor of a description of what the command
does, period.

With the concept of a selected MIME part, I'd also prefer it if a loop
left the last matching MIME part selected, even outside of the loop
after the loop has executed.  This would require the addition of at
least one more SIEVE verb, one that reselects the entire message (goes
back to the top).  It would probably also require a clarification of how
nested loops interact when selecting MIME parts, and possibly the
introduction of a scoping construct that preserves the MIME part
selection outside of its block.

My implementation has its own way selecting and looping through MIME
parts, and I've found that one of the great benefits is being able to
locate a part and then leave the focus on that part.

More specific stuff about the draft:

> 3.  Sieve Loops
> 
>    The base Sieve language has no looping mechanism.  Given that
>    messages may contain multiple parts, in order to support filters that
>    apply to any and all parts, we introduce a new control command:
>    "for_every_part", which is an iterator that walks though every MIME
>    part of a message, including nested parts, and applies the commands
>    in the specified block to each of them.

Perhaps explicitly say that the walking of the MIME structure is
depth-first.  I can't really imagine any other order, but one never
knows.  And I must say.. one thing I have found useful is being able to
step through siblings without descending into child parts; I think
that's a significant lack here.


>    The iterator will start with
>    the first MIME part (as its current context) and will execute a
>    command block (Sieve commands enclosed by { ...}).

I would prefer "will start with the first child of the currently selected
message part (or MIME part)" perhaps with a reminder that initially
the "currently selected part" is the top-level message.  


> 
>    The iterator can be terminated prematurely by a new Sieve command,
>    "break".

This may be way too disruptive of a comment, but..  since the draft
provides for nested loops, perhaps some consideration should be given
for being able to break out of a particular level.  One failing in some
languages is a "break" that only applies to the immediately enclosing
scope.  One might, for example, have an optional tag on the
'for_every_part' and an optional matching tag on the "break":

    for_every_part "A" {
        for_every_part "B" {
	    if something
	        break "A";
        }
    }



>    "for_every_part" commands can be nested inside other "for_every_part"
>    commands.  When this occurs, the nested "for_every_part" iterates
>    over the MIME parts contained within the MIME part current being
>    targeted by the nearest enclosing "for_every_part" command.

Here one could simply say that it processes the message relative to
the currently selected MIME part.  This remains true regardless of
whether the loop is nested.


>    If that
>    MIME part is a terminal MIME part (i.e. does not contain other MIME
>    parts) then the nested "for_every_loop" is simply ignored.

Again, always true.


>    Sieve implementations MAY limit the number of nested loops that occur
>    within one another, however they MUST support at least one nested
>    loop inside another loop.

The way loops are defined in this draft, I'm trying to figure out what
nesting solves, and where the limit came from.  When the nesting came up
previously, I thought the concensus was to to make the maximum nesting
level implementation-defined, with a mandatory minimum nesting level of
1 (i.e., only one outer loop, no inner loops required).  I'm actually in
favor of nested loops, but I'm not sure how much sense they make when
you can't control the way the loops step through the parts, and when the
loop doesn't leave a particular part selected.  e.g. imagine a code
structure like this, only one that isn't so obviously made-up:

    if header :contenttype "content-type" "multipart/report" {
	for_every_child { # process the immediate children only
	    if header :contenttype "message/feedback-report" {
		# stuff here
	    }
	    elsif header :contenttype "text/plain" {
		# other stuff here
	    }
	    elsif header :contenttype "message/rfc822" {
		# Now descend into this and find a text/plain part
		for_every_part {
		    if header :contenttype "text/plain" {
			# ...
		    }
		}
	    }
	}
    }

(In my implementation I took the tack of adding a generic loop construct
and MIME part navigation primitives, which is a building-block approach
that I tend to favor.)


> 4.  Changes to Sieve tests
> 
>    This specification extends the base Sieve "header", "address" and
>    "exists" tests to support targeting those tests at a specific MIME
>    part or at all MIME parts in the enclosing scope.

As I mentioned, I think this would be better as part of introductory
text that talks about the notion of a currently selected message part.



> 4.1.  Test "header"
> 
>    The "header" test is extended with the addition of a new ":mime"
>    tagged argument, which takes a number of other arguments.
> 
>    Usage:  header [:mime] [:anychild] [MIMEOPTS]
>       [COMPARATOR] [MATCH-TYPE]
>       <header-names: string-list> <key-list: string-list>
> 
>    Usage:  The definition of [MIMEOPTS] is:
> 
>       Syntax: ":type" / ":subtype" / ":contenttype" /
>       ":param" <param-list: string-list>

First, I think that having ":mime" take another tagged argument as a
modifier is confusing and is inconsistent with other Sieve constructs.
Take the "relational" extension, for example.  It isn't:

     header :value :gt "some-header" "3"
but it's
     header :value "gt" "some-header" "3"

and if there's going to be a ":mime" option, I would think it would
emulate that kind of syntax.  Either way, it's unfortunate that ":mime"
here has completely different meaning that ":mime" as it already exists
elsewhere.  But really, I think this ":mime" and its tagged-option
arguments are superfluous.  I think that ":param" can do it all.  Let's
say that the presence of ":param" is only valid for a header field that
has a general metasyntax matching

     field-name:  some-fixed-values 0*<;name=value>

A ":param" option would take a string (or string list) as argument.  If
the string is non-empty, it selects the corresponding value matching the
name in the string.  If the string is empty, it selects the
"some-fixed-values" portion of the header field.  Thus one could say
this to look at the subtype of a "content-type" header:

    header :param "" :matches "content-type" "*/html"

and this to look at the "charset" paremeter of that same header:

    header :param "charset" :is "ISO-8859-1"

No need for :mime or other selectors, and this becomes more general,
to boot.



> 4.2.  Test "address"
> 
>    The "address" test is extended with the addition of a new ":mime"
>    tagged argument, which takes a number of other arguments.
> 
>    Usage:  address [:mime] [:anychild] [COMPARATOR]
>       [ADDRESS-PART] [MATCH-TYPE]
>       <header-list: string-list> <key-list: string-list>

I don't really get how :mime is relevant here.
Ditto with "exists"



> 5.  Action Replace
> 
>    Usage:  replace [:mime] [:subject string] [:from string]
>       <replacement: string>
> 
>    The "replace" command is defined to allow a MIME part to be replaced
>    with the text supplied in the command.
> 
>    When used in the context of a "for_every_part" iterator, the MIME
>    part to be replaced is the "current" MIME part.

Again, I would prefer that this just say that it addresses the currently
selected message part.  Then there is no need to talk about the distinction
between its use inside of or outside of a loop body.


>    If the entire message is being replaced, a ":subject" parameter
>    specifies a subject line to attach to the message that is generated.
>    UTF-8 characters can be used in the string argument; implementations
>    MUST convert the string to [RFC2047] encoded words if and only if
>    non-ASCII characters are present.  Implementations MUST preserve the
>    previous Subject header as an Original-Subject header.

And again, for consistency's sake, why not just make the :subject
parameter work (to modify the "Subject" header field within the currently
selected message part) whether it's a child part that's selected or
whether it's the top part that's selected.  Ditto ":from" .  And for
that matter, why are these needed at all, when ":mime" will do?


> 7.  Action extract_text
> 
>    Usage:  extract_text [MODIFIER] [":first" number] <varname: string>
> 
>    The extract_text action may be used within the context of a
>    "for_every_part" loop.  It stores at most :first bytes of the current
>    MIME body part in the variable identified by varname.  If the :first
>    parameter is not present, the whole content of the current MIME body
>    part is stored.  In either case the actually stored data MAY be
>    truncated to conform to implementation specific limit on variable
>    length and/or on MIME body part length.  QUESTION: What do we do if
>    the Content-Transfer-Encoding is anything other than 7bit?
> 
>    If extract_text is used outside the context of a "for_every_part"
>    loop, the action will set the variable identified by varname to the
>    empty string.

Why?

Again, I would prefer that this be defined to operate consistently,
acting on the currently selected MIME part regardless of whether it's
inside of a loop body.

Yours, slowly and tediously,
-mm-



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RF44Ex000840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 08:04:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7RF43JA000838; Mon, 27 Aug 2007 08:04:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RF407G000828 for <[e-mail]>; Mon, 27 Aug 2007 08:04:01 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 27 Aug 2007 16:03:58 +0100
Message-ID: <[e-mail]>
Date: Sun, 26 Aug 2007 17:49:01 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Aaron Stone <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Notify options and URI encoding
References: <1187700118.21144.48.camel@localhost>
In-Reply-To: <1187700118.21144.48.camel@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Aaron,
Sorry for the slow response.

Aaron Stone wrote:

>Hello notifiers,
>
>I re-read notify-08, and it jumped out at me that :options takes a
>stringlist argument! I had it in mind that it was a single string, so
>both :options and the method itself were equally good places for encoded
>parameters. I had a significant concern about the interpretation of
>something like:
>
>    notify "method:whatever&subject=foo ${evilvar}";
>
>where ${evilvar} might come directly from the message and might contain
>nefarious data. That concern has been reflected in the draft with the
>new :encodeurl variables parameter. But it's sort of a hack because
>we're looking at encoding in the first place. 
>
>I think that encoded parameters on the method name should be prohibited
>outright.
>
I think the WG failed to reach consensus on this point. That is why the 
document says that it is up to notification methods to define if URI 
parameters are allowed in :method. So, I would like to see a clear WG 
consensus before doing this change.

>All ad-hoc parameters should arrive via :options. That's what
>it's there for, right?
>
>    notify :options "subject=Hello this is the Subject"
>        "mailto:foo@bar";
>
>is much better than
>
>    notify "mailto:foo@bar&subject=Hello%20this%20is%20the%20Subject";
>
>Example 3 is particularly bad, starting with this variable:
>
>    set "notif_method"
>     "xmpp:[e-mail]?message;subject=SIEVE;body=You%20got%20mail";
>
>I think this should be re-written to show that :options is a string list
>and to reflect that encoding is done by the implementation:
>
One annoying side effect of this change would be the need to create a 
new IANA registry for options and populate it with various email headers 
(possibly specified in their own namespace, e.g. email.subject)

My reading of the WG consensus was that we don't need an IANA registry. 
Do you want to poll the WG regarding this issue?

>    set "notif_method" "xmpp:[e-mail]?message"
>    set "notif_subject" "SIEVE"
>    set "notif_body" "You've got mail"
>
>    ... tests in the example that override the defaults ...
>
>    notify :options [ "subject=${notif_subject}", "body=${notif_body}" ]
>        "${notif_method}";
>
>Suggested new text in the description of :options, Section 3.5:
>
>   Values may be URI-encoded and may be expanded from variables.
>   Therefore, notification methods MUST NOT perform full URI-decoding
>   of each option string, lest untrusted data contained in the variable
>   become indistinguishable from user-specified data.
>  
>
I am not sure I understand what is "full URI-decoding" and what is not.

>Security Considerations, this is from -08:
>
>   Implementations that construct URIs internally from various notify
>   parameters MUST make sure that all components of such URIs are
>   properly percent-encoded (see [URI]).  In particular this applies to
>   values of the :from and the :message tagged arguments and may apply
>   to the :options values.
>
>I think this is good, and we can drop Section 6, Modifier encodeurl,
>too, as :encodeurl is not needed if the process for assembling a URI is
>something like this (psuedo-perl):
>
I have to admit that I am still not sure how exactly Sieve notify is 
going to be used in real world. I would like to get some experience on that.

Considering that an implementation of Sieve Notify will have to have an 
URL-encoder, I don't think it would be much of a burden to expose it to 
Sieve script writers in the form of encodeurl modifier. So my personal 
preference is to keep it just in case.
Other opinions on this?

>    sub make_notify_uri( method, from, importance, options )
>        return error unless sanity_check( method )
>        uri = concat( method, "&from=", urlencode( from ) )
>        uri = concat( uri, "&importance=", urlencode( importance ) )
>        for each options
>            next unless (key, value) =~ /([:alnum:])=(.*)/
>            uri = concat( uri, "&", key, "=", urlencode( value ) )
>
>The two important factors here are disallowing encoded methods and being
>careful in how the option strings are split. I think that covers all of
>the potential encoding holes for passing data through.  
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7QINhCS094132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2007 11:23:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7QINheY094131; Sun, 26 Aug 2007 11:23:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7QINfPA094124 for <[e-mail]>; Sun, 26 Aug 2007 11:23:42 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 26 Aug 2007 11:23:36 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 26 Aug 2007 11:23:22 -0700 (PDT)
Cc: Alexey Melnikov <[e-mail]>, [e-mail], Lisa Dusseault <[e-mail]>, [e-mail], Philip Guenther <[e-mail]>
Message-id: <[e-mail]>
Date: Sat, 25 Aug 2007 15:59:06 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
In-reply-to: "Your message dated Sat, 25 Aug 2007 12:36:43 -0700" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; delsp=yes; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Cullen Jennings <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1188152615; h=Date:	 From:Subject:MIME-version:Content-type; b=OT8xf0rWOzOiILe8GBsaFSLdY wXJMF+nPqp4/vUKqpZRny26ZzW7kIQn7I8cwBhXA8DA6eoLn3KTst0E147rdg==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> inline ...

> On Aug 25, 2007, at 9:37 AM, Alexey Melnikov wrote:

> > Cullen Jennings wrote:
> >
> > > I don't think that is really implementable advice - it basically
> > > wishes the problem away.

What advice are you talking about here? I see nothing in the revised text that
would argue for the sort of analysis of sieve scripts you're (quite correctly)
saying is impossible.

> > It is implementable, it applies to UIs and admin tools and many
> > implementations already follow it.

> So the topic I was questioning the implementability of is a program
> that can look a series of sieve scripts across one or more email
> servers and decide if the sieve scripts are capable of creating large
> scale message amplification attacks.

Sounds to me like you and Alexey are talking at cross purposes here, but in
regards to the question of whether what you're talking about is implementable:
It isn't, although not for the reasons you give.

The main reason it is unimplementable is very simple: Email is an Internet-wide
service and no program can possibly have the administative access to the entire
Internet it would need to perform such a check. As a specific example, I have
email accounts at Sun, on my home systems, Gmail, and a bunch of other places.
All, I repeat _all_, of these services allow me to easily configure
autoforwarding to multiple destinations. I will also point out that while
several of these systems provide Sieve support, none of them require the use of
sieve for me to set up this sort of autoforwarding. (OK, to be fair I have no
idea what's underneath the hood at Gmail, but if the other aspects of their
filtering interface are any indication it is not Sieve-based.)

To put this more concisely: It is clearly impossible to devine the intent of an
autoforwarder that is operating as part of a much larger web of autoforwarders
just by looking at it in isolation, and it is equally impossible to assess the
properties of other autoforwarders located in other administrative domains. It
follows that analyzing autoforwarders to prevent construction of mail bombs is
inherently unimplementable. (Believe it or not, some faciities in X.400
actually depended on this being possible. You can probably guess how well that
worked out...)

> The draft clearly does not
> contain enough information to tell someone how to implement this and
> personally I seriously doubt that it is possible due to the halting
> problem.

I believe my preceeding argument demonstrates that the question of Sieve's
Turing completeness is completely irrelevant to the matter at hand.
Nevertheless, since several people apparently continue to think this is an
important point I will elaborate on it a little further.

A Sieve in isolation is pretty clearly not Turing complete - no real loops - so
the at that level at least the halting problem doesn't enter into it.

Now, Eric Rescorla once argued that Sieve should be considered Turing complete
because you could bounce a message back and forth between multiple systems,
using the message content to store the position on the tape.

Even if you ignore the critical point that Sieve not being Turing complete was
always about whether or not a sieve script in isolation could cause a infinite
loop and wedge up your server and never about whether or not Sieve could
function as a component in a larger, Turing complete system, the problem with
this argument is that Recieved: field counting nails you pretty quickly for
regular messages, and once again you're left without the loop construct you
need to make it "work".

This then leaves you with no alternative but to try and use other, wierder
sorts  of loops. The obvious one to try, and the one Eric proposed, is what I
call a "bounce loop": Redirect to a known-invalid address, get the bounce back,
redirect again, bounce again, etc. But bounce loops are only possible if some
agent in the path is willing to change the empty envelope from that is required
in the bounce message to refer to some other address in the forwarding path.
Without that happening a bounce cannot itself generate a bounce, so the loop
stops after at most two iterations.

This last point actually raises a general issue for autoforwarders - they MUST
NOT override an empty envelope from because if they do they can create bounce
loops. (I note in passing that in practice this is almost always happens
accidentally, not intentionally. Nevertheless, it is a very real problem that
email systems have to deal with.) RFC 2821 should have made this a requirement
but didn't. I plan to raise this issue in the context of 2821bis but I would
not object to changing the closing text in section 4.2 of the Sieve base
specification to say:

   The envelope sender address on the outgoing message is chosen by the
   sieve implementation. It MAY be copied from the message being
   processed. However, if the message being processed has an empty
   envelope sender address the outgoing message MUST also have an
   empty envelope sender address.

More generally, one of the primary goals of the design of the email
infrastructure is that _all_ autoforwarding loops, once underway, can be
detected and stopped. It is _not_ a design goal to prevent such loops from
being set up - any system that tried to enforce that would be much too
restrictive.

If follows that the ability to construct an undetectable loop means there's a
serius design or the implementation flaw that needs to be corrected. But the
fact that such flaws might enable Sieve to be Turing complete is entirely
trivial compared to the other serious issues undetectable loops raise.

Getting back to the script complexity issue, since Sieve allows arbitrary
boolean expressions script analysis is pretty clearly equivalent to the
satisfiability problem, i.e. it's NP-complete, and that puts full analysis of
arbitrary sieves out of reach of anything short of a quantum computer, which
AFAIK means it effectively cannot be done. So that's another reason why you're
correct in saying this kind of analysis is impossible to perform on Sieve
scripts. But  since AFAICT nobody is proposing performing such an analysis,
this doesn't change anything.

> Of course I suspect it is not possible because I am also
> very incredulous of the WG's claim that sieve coupled with common
> email systems is not turing complete.

To be blunt, your incredulity fails to impress, let alone persuade. If you
believe such a thing is possible then prove it by giving the details of how
such a system could be built that doesn't depend on an architectural flaw of
some sort in email's design or implementation.

I'm actually quite eager to be proved wrong on this since it will necessarily
expand my knowledge of what email systems are capable of. But I require proof,
not the handwaving I've seen so far.

> Luckily I think that an
> acceptable solution can be found without having a debate about basic
> CS theory.

I'm delighted to hear it.

> > > More inline ...
> > > On Aug 17, 2007, at 2:34 PM, Alexey Melnikov wrote:
> > >
> > >> Cullen, does the following address your DISCUSS?
> > >>
> > >> =============================
> > >> In section 4.2, last paragraph:
> > >>
> > >> OLD:
> > >>  Implementations SHOULD take measures to implement loop control,
> > >>  possibly including adding headers to the message or counting
> > Received
> > >>  headers.  If an implementation detects a loop, it causes an error.
> > >> NEW:
> > >>  Implementations SHOULD take measures to implement loop control,
> > >>  possibly including adding headers to the message or counting
> > Received
> > >>  headers as specified in section 6.2 of [SMTP].  If an
> > >> implementation detects a loop, it causes an error.
> > >>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >>
> > >> Add to the end of section 4.2 two new paragraphs:
> > >>
> > >>  Implementations SHOULD provide means of limiting the number of
> > >> redirects a
> > >>  Sieve script can perform.
> > >
> > > Well if it was the number of redirects SHOULD be limited to one it
> > > would do it but as it is - not sure I see how it helps.
> >
> > Cullen, I told you before, there is very strong WG consensus to allow
> > implementations to use more than one.
> >
> > Please see
> > <http://www.imc.org/ietf-mta-filters/mail-archive/msg03601.html> and
> > <http://www.imc.org/ietf-mta-filters/mail-archive/msg03599.html>.
> >
> > Now, if you have another suggestion how to address your issue, I would
> > like to hear it.

> I have given a simple and easy way to address it that seemed to also
> work for the use cases that people told me about (I certainly admit I
> don't know all the case).

If memory serves, your suggested way to prevent it was to allow at most one
redirect operation to be done during the execution of a sieve script. And
you've been told that this is simply not acceptable - there are too many use
cases for forwarding email to two different places at once. In fact this is an
incredibly common thing for people to do for all sorts of legitimate reasons,
including but not limited to:

(1) Making messages accessible in multiple ways, e.g. send one copy to
    my email account and another to my pager. Or voice mail. Or printer.
    Or FAX.
(2) Secretaries who need copies of their boss's email.
(3) Maintaining multiple mailboxes during a service transition period. Or
    two pagers.
(4) Making backup copies of mail to address reliability issues (IMO this is
    not the best way to solve this problem but it is commonly done this way
    regardless of what I think).
(5) Making copies of stuff for law enforcement use (garden variety
    forwarding is a piss-poor way to implement this but it is nevertheless
    something people do fairly often).
(6) Vacation-time forwarding of important messages to the "next tier" of
    handlers.

We have two large banks as customers, both with thousands of employees. The
American one is very well known - anyone who isn't a complete hermit is
guaranteed to be familiar with it. They have a very elaborate email setup that
routes mail through various analysis, categorization, and compliance facilites.
The outcome of these operations are then assessed with various sieve scripts,
which then use redirect and various other tools to alter message routing. The
ability to redirect to multiple addresses plays an important role in all this.

The other bank is European (and may be a household name there for all I know)
and their setup is even more relevant. They have basically used Sieve to
implement an elaborate workflow system. Some of their scripts use redirect
10-20 times on a single message. The most interesting aspect of their setup is
that they have intentionally created loops all over the place. They use various
checks, some explicitly done in Sieve, some autogenerated in Sieve, and others
external to Sieve, to break the loops at exactly the right points. This usage
is way past what, say, .forward files can do. The proper functioning of this
setup is so important to them that no less than the CEO of the bank has been
known to "drop in" on technical discussions of various implementation details.
(And this is not hearsay - I'm speaking from direct personal experience.)

I could go on and give many more examples of use cases but hopefully you've
gotten the idea by now. The ability to autoforward to multiple addresses is an
essential feature - it has part of modern email effectively from the beginning
and without it Sieve simply doesn't have feature parity with other message
filtering facilities. In our case if we were to remove it our customers would
simply find a different vendor that doesn't impose such limits. As for setting
the default limit on redirect to 1, all that would accomplish for us is to keep
us all busy dealing with the resulting support calls.

> However, let me be very clear - it is not
> my job to find a solution that the WG likes to this.

It is, however, your job to impose reasonable requirements. And IMO you are not
being reasonable here.

> I believe that
> the IETF has clear consensus that it does not want to deploy
> technology that could trivially be used for large scale DOS and
> message amplification attacks with very little safeguards or
> traceable ways of dealing with this.

This presupposes that there's a real risk here and that the necessary
safeguards are not in place. I don't believe either of these are true.

The fact is Sieve and numerous other autoforwarding mechanisms are already
widely deployed without the limits you think are necessary and curiously all of
these serious flaws you see aren't being exploited.

I dislike trotting out our own deployment statistics but it seems now is the
time for it. According various sources our product provides service for well
over 100 million mailboxes. A significant fraction of this total provides end
user access to set up sieves and our current default is to allow up to 32
redirects per sieve. As I pointed out in my original response, the number of
customers we've had that have reported problems with sieve redirect and have
needed to impose limits is exactly zero. And believe me when I say that our
customer base includes lots of people who aren't exactly shy about reporting
the least little thing that goes wrong.

> Now my current judgement call is
> that this is in that category and could cause harm to the internet.

But we're not dealing with a new protocol with zero operational experience here
where such judgement calls are our only means of assessing possible risk.
Rather, we're not only dealing with a protocol that has signifcant deployment
and operational experience, we're talking about a particular feature that's
been an integrall part of email for decades and is accessible in all sorts of
ways besides Sieve.

> You can convince me I am wrong about that - or you could find a way
> of mitigating and reducing this risk - I can think of several and I
> have suggested the one that I think is most likely to be acceptable
> to the WG

Given that limiting redirects to 1 is totally unacceptable I have no idea
what you are referring to here.

> but I make no presumption that I would know what is the
> best solution for this WG on this problem. I have made it clear what
> the issues is, why I think a change is needed, this should not be hard.

I don't think it should be hard either, but the talking at cross purposes
continues.

So let me try one last time to cut through the misunderstandings.

First, nobody is claiming that autoforwarders cannot be used as an amplifying
component in various sorts of attacks. They can be used this way. This was true
for email decades before Sieve came along and it will continue to be true no
matter what we do in this document.

Second, nobody is claiming that script analysis can be used to prevent people
from abusing Sieve as part of such attacks. It simply cannot be done.

So, since such attacks are inherently possible in the present email
infrastructure no matter what we do or don't do in Sieve, the focus has to be
on detecting and stopping attacks. This is done by:

(1) Making sure infinite loops can be detected and stopped. The main risk is
    that without comprehensive loop detection you can and will end up with
    exponentially growing message loops. I've seen such situations
    arise and create literally 10s of millions of messages in a very short
    period of time.

    Without a true loop the amplification potential of an autoforwarder web is
    bounded by the number of autoforwarders in the web multipied by  number of
    redirects that are allowed per sieve. So the only way such a web can be used
    effectively is if you have the means to inject an endless stream of messages
    into it at some point. And that brings us to:

(2) Rate limit message submission. If true loops aren't possible something
    somewhere has to act to generate the "signal" that is "amplified". This
    sort of behavior can be detected and blocked.

(3) Administrative controls. The basic rule is don't allow users to access
    functionality they don't need. If there's never a need to use redirect,
    disable it entirely. If they only need to be able to do one redirect
    per sieve, only allow that. If they only need to be able to redirect to
    other users onsite, only allow that. If a class of messages exists that
    aren't supposed to be redirected, check for them and yell if a redirect
    is done. And so on. The list of possibilities here is very long.

(4) Auditing and tracking. The aforementioned European bank has a requirement
    that every message carry a complete history of the redirection that was
    performed. They also require that all of this be derivable from the logs.
    And many of our other customers have similar requirements.

    More generally, the days where email systems can get away without producing
    comprehensive logs and audit trails ended a long time ago. I have no idea
    what you're basing your assertions that such attacks would not be tracable
    in modern email systems, but it runs absolutely contrary to all of my
    recent experience.

Now, I will admit that the document doesn't cover a lot of this. But there's a
reason for that: Autofording to multiple address exists independent of Sieve
and as such is a general architectural issue for email, not one specific to
Sieve. It would be great if there was a document comparable to RFC 3834 for
autoforwarders but there isn't, and it is not within scope for this WG to
produce such a specification.

So what can we do? Well, I guess one option would be to try and make
the discussion of this a little more explicit in the document. How about
adding something like this to the security considerations?

    Allowing a single script to redirect to multiple destinations can be
    used as a means of amplifying the number of messages in an attack.
    Moreover, if loop detection is not properly implemented it may be possible
    to set up expontentially growing message loops. Acording, Sieve
    implementations:

    (1) MUST implement facilities to detect and break message loops. See
        RFC 2821 section 6.2 for additional information on basic loop
        detection strategies.

    (2) MUST provide the means for administrators to limit the ability of
        users to abuse redirect. In particular, it MUST be possible to
        limit the number of redirects a script can perform. Additionally,
        if no use cases exists for using redirect to to multiple destinations,
        this limit SHOULD be set to 1. Additional limits, such
        as the ability to restrict redirect to local users MAY also be
        implemented.

    (3) MUST provide facilities to log use of redirect in order to facilitate
        tracking down abuse.

I didn't include rate limiting on the list for several reasons: (1) It's hard
to get right and naive attempts to implement it can be very dangerous. (2)
There's no consensus on what best practices for it are and hence any discussion
of it is likely to rathole.

I would also suggest getting rid of the discussion about sanity-checking since
this discussion seems to indicate it is open to serious misinterpretation.

Does any of this work for you? If it doesn't I'm frankly out of ideas for how
to resolve this.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7QBODIl060292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Aug 2007 04:24:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7QBODmT060291; Sun, 26 Aug 2007 04:24:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7QBOAh4060284 for <[e-mail]>; Sun, 26 Aug 2007 04:24:12 -0700 (MST) (envelope-from [e-mail])
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D61A74ACE0; Sun, 26 Aug 2007 13:24:08 +0200 (CEST)
Message-Id: <[e-mail]>
Date: Sun, 26 Aug 2007 13:25:06 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
Cc: Cullen Jennings <[e-mail]>, Alexey Melnikov <[e-mail]>, Philip Guenther <[e-mail]>, [e-mail], Lisa Dusseault <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7QBOCh4060286
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since loop detection is so hacky, I suggest the following to address 
magnification instead: If a sieve script/interpreter generates a new 
message (ie. without received fields), the message «SHOULD contain 
exactly one address in From, SHOULD have no Reply-To field and SHOULD 
have an Auto-Submitted field.».

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PJcBb0007698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 12:38:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7PJcBkh007697; Sat, 25 Aug 2007 12:38:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PJcAND007691 for <[e-mail]>; Sat, 25 Aug 2007 12:38:11 -0700 (MST) (envelope-from [e-mail])
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 25 Aug 2007 12:38:10 -0700
X-IronPort-AV: i="4.19,308,1183359600";  d="scan'208"; a="172788790:sNHT50396931"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7PJcAmJ004980; Sat, 25 Aug 2007 12:38:10 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l7PJc5l8017932; Sat, 25 Aug 2007 19:38:05 GMT
In-Reply-To: <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]>
Impp: xmpp:[e-mail]
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: <[e-mail]>, "Lisa Dusseault" <[e-mail]>, <[e-mail]>, "Philip Guenther" <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
Date: Sat, 25 Aug 2007 12:36:43 -0700
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3576; t=1188070690; x=1188934690; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Cullen=20Jennings=20<[e-mail]> |Subject:=20Re=3A=20Suggested=20changes=20to=20address=20Cullen's=20DISCU SS=20on=20draft-ietf-sieve-3028bis-12.txt |Sender:=20; bh=3FMgp5vsqZdg6itkChVUKyYysEDibpCof26mFfP3xEo=; b=MS8t6tE9o5sw0ZNtTxrcvBykN7n2gTFNt9L/ncolhzc304HZ3dOL0KfTJmdpiPxhTL2rVEth 0BDDeUboscZ8Uxp+BPeJ9Z/diQFJZAiL910HzYMFEkruxO9XOlj9yuhT;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

inline ...

On Aug 25, 2007, at 9:37 AM, Alexey Melnikov wrote:

> Cullen Jennings wrote:
>
> > I don't think that is really implementable advice - it basically
> > wishes the problem away.
>
> It is implementable, it applies to UIs and admin tools and many
> implementations already follow it.

So the topic I was questioning the implementability of is a program  
that can look a series of sieve scripts across one or more email  
servers and decide if the sieve scripts are capable of creating large  
scale message amplification attacks. The draft clearly does not  
contain enough information to tell someone how to implement this and  
personally I seriously doubt that it is possible due to the halting  
problem. Of course I suspect it is not possible because I am also  
very incredulous of the WG's claim that sieve coupled with common  
email systems is not turing complete. Luckily I think that an  
acceptable solution can be found without having a debate about basic  
CS theory.
>
> > More inline ...
> > On Aug 17, 2007, at 2:34 PM, Alexey Melnikov wrote:
> >
> >> Cullen, does the following address your DISCUSS?
> >>
> >> =============================
> >> In section 4.2, last paragraph:
> >>
> >> OLD:
> >>  Implementations SHOULD take measures to implement loop control,
> >>  possibly including adding headers to the message or counting  
> Received
> >>  headers.  If an implementation detects a loop, it causes an error.
> >> NEW:
> >>  Implementations SHOULD take measures to implement loop control,
> >>  possibly including adding headers to the message or counting  
> Received
> >>  headers as specified in section 6.2 of [SMTP].  If an
> >> implementation detects a loop, it causes an error.
> >>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>
> >> Add to the end of section 4.2 two new paragraphs:
> >>
> >>  Implementations SHOULD provide means of limiting the number of
> >> redirects a
> >>  Sieve script can perform.
> >
> > Well if it was the number of redirects SHOULD be limited to one it
> > would do it but as it is - not sure I see how it helps.
>
> Cullen, I told you before, there is very strong WG consensus to allow
> implementations to use more than one.
>
> Please see
> <http://www.imc.org/ietf-mta-filters/mail-archive/msg03601.html> and
> <http://www.imc.org/ietf-mta-filters/mail-archive/msg03599.html>.
>
> Now, if you have another suggestion how to address your issue, I would
> like to hear it.
>

I have given a simple and easy way to address it that seemed to also  
work for the use cases that people told me about (I certainly admit I  
don't know all the case). However, let me be very clear - it is not  
my job to find a solution that the WG likes to this. I believe that  
the IETF has clear consensus that it does not want to deploy  
technology that could trivially be used for large scale DOS and  
message amplification attacks with very little safeguards or  
traceable ways of dealing with this. Now my current judgement call is  
that this is in that category and could cause harm to the internet.  
You can convince me I am wrong about that - or you could find a way  
of mitigating and reducing this risk - I can think of several and I  
have suggested the one that I think is most likely to be acceptable  
to the WG but I make no presumption that I would know what is the  
best solution for this WG on this problem. I have made it clear what  
the issues is, why I think a change is needed, this should not be hard.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PHsKF5086002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 10:54:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7PHsKOm086001; Sat, 25 Aug 2007 10:54:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PHsJhO085993 for <[e-mail]>; Sat, 25 Aug 2007 10:54:20 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 25 Aug 2007 18:54:17 +0100
Message-ID: <[e-mail]>
Date: Sat, 25 Aug 2007 18:55:06 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Cullen Jennings <[e-mail]>
CC: Lisa Dusseault <[e-mail]>, Philip Guenther <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Cullen Jennings wrote:
>
>> I don't think that is really implementable advice - it basically  
>> wishes the problem away.
>
> It is implementable, it applies to UIs and admin tools and many

And it also applies to servers that allow uploading scripts, such as 
ManageSieve.

> implementations already follow it.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PGeCnl081117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 09:40:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7PGeCIH081116; Sat, 25 Aug 2007 09:40:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PGeCA8081110 for <[e-mail]>; Sat, 25 Aug 2007 09:40:12 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 25 Aug 2007 17:40:10 +0100
Message-ID: <[e-mail]>
Date: Sat, 25 Aug 2007 17:41:00 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-mime-loop
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Hi,
>
> This message officially starts the Sieve Working Group Last Call for
> the following document:
> SIEVE Email Filtering:  MIME part Tests, Iteration, Replacement and 
> Enclosure
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-03.txt>
>
> The Working Group Last Call for this document starts on August 6th and 
> will end on August 20th.
>
> Please send any comments to the Sieve mailing list or directly to me. 
> Please CC Tony Hansen <[e-mail]> and Cyrus Daboo 
> <[e-mail]> in the latter case. Reviews that found no issues 
> are also welcomed, so if you review the document and find it 
> acceptable, please let the mailing list/authors+me know as well.

The WGLC has ended it seems there are some remaining issues that need to 
be addressed before sending the document to IESG.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PGaY7l080967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 09:36:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7PGaYw3080966; Sat, 25 Aug 2007 09:36:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PGaYsQ080960 for <[e-mail]>; Sat, 25 Aug 2007 09:36:34 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 25 Aug 2007 17:36:32 +0100
Message-ID: <[e-mail]>
Date: Sat, 25 Aug 2007 17:37:21 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Cullen Jennings <[e-mail]>
CC: Lisa Dusseault <[e-mail]>, Philip Guenther <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cullen Jennings wrote:

> I don't think that is really implementable advice - it basically  
> wishes the problem away.

It is implementable, it applies to UIs and admin tools and many
implementations already follow it.

> More inline ...
> On Aug 17, 2007, at 2:34 PM, Alexey Melnikov wrote:
>
>> Cullen, does the following address your DISCUSS?
>>
>> =============================
>> In section 4.2, last paragraph:
>>
>> OLD:
>>  Implementations SHOULD take measures to implement loop control,
>>  possibly including adding headers to the message or counting Received
>>  headers.  If an implementation detects a loop, it causes an error.
>> NEW:
>>  Implementations SHOULD take measures to implement loop control,
>>  possibly including adding headers to the message or counting Received
>>  headers as specified in section 6.2 of [SMTP].  If an  
>> implementation detects a loop, it causes an error.
>>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Add to the end of section 4.2 two new paragraphs:
>>
>>  Implementations SHOULD provide means of limiting the number of  
>> redirects a
>>  Sieve script can perform.
>
> Well if it was the number of redirects SHOULD be limited to one it  
> would do it but as it is - not sure I see how it helps.

Cullen, I told you before, there is very strong WG consensus to allow
implementations to use more than one.

Please see
<http://www.imc.org/ietf-mta-filters/mail-archive/msg03601.html> and
<http://www.imc.org/ietf-mta-filters/mail-archive/msg03599.html>.

Now, if you have another suggestion how to address your issue, I would
like to hear it.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PGaNqo080947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 09:36:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7PGaN2x080946; Sat, 25 Aug 2007 09:36:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PGaMga080939 for <[e-mail]>; Sat, 25 Aug 2007 09:36:22 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 25 Aug 2007 17:36:20 +0100
Message-ID: <[e-mail]>
Date: Sat, 25 Aug 2007 17:37:09 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: Nomcom 2007-8: Please nominate candidates for IESG and IAB positions (Deadline: Sep 10, 2007)]
Content-Type: multipart/mixed; boundary="------------090601070206090404080405"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Please nominate good candidates for the Application Area. The more 
candidates, the better. If you happy with Lisa's performance as an Apps 
Area Director, please let the Nomcom know as well.


--------------090601070206090404080405
Content-Type: message/rfc822;
 name="Nomcom 2007-8: Please nominate candidates for IESG and IAB positions (Deadline:Sep 10, 2007)"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Nomcom 2007-8: Please nominate candidates for IESG and IAB positions (Deadline:Sep 10, 2007)"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine.isode.net (Isode M-Box/14.0v1) with LMTP; Thu, 23 Aug 2007 20:44:13 +0100 (BST)
Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]>;
          Thu, 23 Aug 2007 20:43:54 +0100
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IOIar-0002KX-NU; Thu, 23 Aug 2007 15:43:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IOIaq-0002KM-EG
	for [e-mail]; Thu, 23 Aug 2007 15:43:48 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOIao-0000JV-V7
	for [e-mail]; Thu, 23 Aug 2007 15:43:48 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l7NJhjH7026072
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 23 Aug 2007 12:43:45 -0700
Received: from [10.50.72.93] (qconnect-10-50-72-93.qualcomm.com [10.50.72.93])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l7NJhXlt027081
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 23 Aug 2007 12:43:34 -0700
Message-ID: <[e-mail]>
Date: Thu, 23 Aug 2007 12:43:32 -0700
From: Lakshminath Dondeti <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail], [e-mail]
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
Subject: Nomcom 2007-8: Please nominate candidates for IESG and IAB positions
 (Deadline: Sep 10, 2007)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/wgchairs>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/wgchairs>,
	<mailto:[e-mail]?subject=subscribe>
Errors-To: [e-mail]

Hi all,

We have received very few nominations at the moment and among those very 
few accepted.  If you have been thinking of nominating someone, please 
do so as soon as possible.  The deadline is Sep 10, 2007, but please 
nominate soon to give the candidates sufficient time to fill in the 
questionnaires.

Self nominations are permitted and encouraged.

Please nominate at

https://tools.ietf.org/group/nomcom/07/

or send an email to [e-mail] or to me [e-mail].

thanks,
Lakshminath


--------------090601070206090404080405--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7OMiA1V004849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 15:44:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7OMiA2K004848; Fri, 24 Aug 2007 15:44:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7OMi8nt004842 for <[e-mail]>; Fri, 24 Aug 2007 15:44:09 -0700 (MST) (envelope-from [e-mail])
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 24 Aug 2007 15:44:08 -0700
X-IronPort-AV: i="4.19,305,1183359600";  d="scan'208"; a="172691905:sNHT51170661"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7OMi8N7006165; Fri, 24 Aug 2007 15:44:08 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l7OMhvYb011232; Fri, 24 Aug 2007 22:43:58 GMT
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Lisa Dusseault <[e-mail]>, Philip Guenther <[e-mail]>, [e-mail], [e-mail]
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
Date: Fri, 24 Aug 2007 15:42:36 -0700
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2521; t=1187995448; x=1188859448; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Cullen=20Jennings=20<[e-mail]> |Subject:=20Re=3A=20Suggested=20changes=20to=20address=20Cullen's=20DISCU SS=20on=20draft-ietf-sieve-3028bis-12.txt |Sender:=20; bh=SnGbWBfB5kK8c1wMJ6XDvouZ5n6rVeDEstZgoD226kI=; b=cjSOgND38K+DpG+hqXOo5gyNMr0wsYTbIR3UIEAffXd4ny5W5ZeHa+/w5WCjMWUnGH2cPkB4 0dl4b/O6sNpyEtLsIZk3PaydENoNbO7/FGc9oqiqjrrq58ul0Epw1EzP;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I don't think that is really implementable advice - it basically  
wishes the problem away. More inline ...

On Aug 17, 2007, at 2:34 PM, Alexey Melnikov wrote:

> Cullen, does the following address your DISCUSS?
>
> =============================
> In section 4.2, last paragraph:
>
> OLD:
>  Implementations SHOULD take measures to implement loop control,
>  possibly including adding headers to the message or counting Received
>  headers.  If an implementation detects a loop, it causes an error.
> NEW:
>  Implementations SHOULD take measures to implement loop control,
>  possibly including adding headers to the message or counting Received
>  headers as specified in section 6.2 of [SMTP].  If an  
> implementation detects a loop, it causes an error.
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Add to the end of section 4.2 two new paragraphs:
>
>  Implementations SHOULD provide means of limiting the number of  
> redirects a
>  Sieve script can perform.

Well if it was the number of redirects SHOULD be limited to one it  
would do it but as it is - not sure I see how it helps.

>
>  Implementations MAY ignore a redirect action silently due to  
> policy reasons.
>  For example, an implementation MAY choose not to redirect to an  
> address that
>  is known to be undeliverable.
>
>
> In section 10, 2nd paragraph:
>
> OLD:
>  It is equally important that implementations sanity-check the user's
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  scripts, and not allow users to create on-demand mailbombs.  For
>         ^^^^^^^^^
>  instance, an implementation that allows a user to redirect a message
>  multiple times might also allow a user to create a mailbomb triggered
>  by mail from a specific user.  Site- or implementation-defined limits
>  on actions are useful for this.
>
> NEW:
>  Implementations SHOULD sanity-check the user's
>                  ^^^^^^
>  scripts. Implementations SHOULD NOT allow users to create on- 
> demand mailbombs.  For
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  instance, an implementation that allows a user to redirect a message
>  multiple times might also allow a user to create a mailbomb triggered
>  by mail from a specific user.  Site- or implementation-defined limits
>  on actions are useful for this.
>
> ============================
> Comments?
>
> The example that follows "MAY ignore redirect due to policy" seems  
> to be non-related to policy.
> Is extra wordsmithing needed here?
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LCeqwY053201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 05:40:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7LCeqZr053200; Tue, 21 Aug 2007 05:40:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LCepaX053193 for <[e-mail]>; Tue, 21 Aug 2007 05:40:51 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.146] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id EF84230CF; Tue, 21 Aug 2007 05:44:56 -0700 (PDT)
Subject: Notify options and URI encoding
From: Aaron Stone <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Content-Type: text/plain
Date: Tue, 21 Aug 2007 05:41:57 -0700
Message-Id: <1187700118.21144.48.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.2 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello notifiers,

I re-read notify-08, and it jumped out at me that :options takes a
stringlist argument! I had it in mind that it was a single string, so
both :options and the method itself were equally good places for encoded
parameters. I had a significant concern about the interpretation of
something like:

    notify "method:whatever&subject=foo ${evilvar}";

where ${evilvar} might come directly from the message and might contain
nefarious data. That concern has been reflected in the draft with the
new :encodeurl variables parameter. But it's sort of a hack because
we're looking at encoding in the first place. 

I think that encoded parameters on the method name should be prohibited
outright. All ad-hoc parameters should arrive via :options. That's what
it's there for, right?

    notify :options "subject=Hello this is the Subject"
        "mailto:foo@bar";

is much better than

    notify "mailto:foo@bar&subject=Hello%20this%20is%20the%20Subject";

Example 3 is particularly bad, starting with this variable:

    set "notif_method"
     "xmpp:[e-mail]?message;subject=SIEVE;body=You%20got%20mail";

I think this should be re-written to show that :options is a string list
and to reflect that encoding is done by the implementation:

    set "notif_method" "xmpp:[e-mail]?message"
    set "notif_subject" "SIEVE"
    set "notif_body" "You've got mail"

    ... tests in the example that override the defaults ...

    notify :options [ "subject=${notif_subject}", "body=${notif_body}" ]
        "${notif_method}";

Suggested new text in the description of :options, Section 3.5:

   Values may be URI-encoded and may be expanded from variables.
   Therefore, notification methods MUST NOT perform full URI-decoding
   of each option string, lest untrusted data contained in the variable
   become indistinguishable from user-specified data.

Security Considerations, this is from -08:

   Implementations that construct URIs internally from various notify
   parameters MUST make sure that all components of such URIs are
   properly percent-encoded (see [URI]).  In particular this applies to
   values of the :from and the :message tagged arguments and may apply
   to the :options values.

I think this is good, and we can drop Section 6, Modifier encodeurl,
too, as :encodeurl is not needed if the process for assembling a URI is
something like this (psuedo-perl):

    sub make_notify_uri( method, from, importance, options )
        return error unless sanity_check( method )
        uri = concat( method, "&from=", urlencode( from ) )
        uri = concat( uri, "&importance=", urlencode( importance ) )
        for each options
            next unless (key, value) =~ /([:alnum:])=(.*)/
            uri = concat( uri, "&", key, "=", urlencode( value ) )

The two important factors here are disallowing encoded methods and being
careful in how the option strings are split. I think that covers all of
the potential encoding holes for passing data through.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7KMP73O071093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 15:25:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7KMP7jT071092; Mon, 20 Aug 2007 15:25:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7KMP5Xl071086 for <[e-mail]>; Mon, 20 Aug 2007 15:25:06 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 71930 invoked by uid 101); 20 Aug 2007 18:25:04 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 20 Aug 2007 18:25:04 -0400
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-mime-loop
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Aug 06, 2007 at 09:48:58AM +0100, Alexey Melnikov wrote:
> 
> Hi,
> 
> This message officially starts the Sieve Working Group Last Call for
> the following document: 
> 
> SIEVE Email Filtering:  MIME part Tests, Iteration, Replacement and 
> Enclosure
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-03.txt>
> 
> The Working Group Last Call for this document starts on August 6th and will 
> end on August 20th.

Hi,

I had intended to get some comments out before the last day (i.e.,
before today) but haven't managed to organize my thoughts well enough.
I'd like to get them out to the list in the next day or two.
Regardless, I don't think this is ready for last call yet.

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7IHNAeV010410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 10:23:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7IHNAOu010409; Sat, 18 Aug 2007 10:23:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7IHMmHa010390 for <[e-mail]>; Sat, 18 Aug 2007 10:23:09 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 18 Aug 2007 18:22:45 +0100
Message-ID: <[e-mail]>
Date: Sat, 18 Aug 2007 18:23:37 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: Cullen Jennings <[e-mail]>, Lisa Dusseault <[e-mail]>, Philip Guenther <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>> Cullen, does the following address your DISCUSS?
>
>> =============================
>> In section 4.2, last paragraph:
>
>> OLD:
>>   Implementations SHOULD take measures to implement loop control,
>>   possibly including adding headers to the message or counting Received
>>   headers.  If an implementation detects a loop, it causes an error.
>> NEW:
>>   Implementations SHOULD take measures to implement loop control,
>>   possibly including adding headers to the message or counting Received
>>   headers as specified in section 6.2 of [SMTP].  If an implementation
>
>>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   detects a loop, it causes an error.
>
> I can live with this, but I have to say I see it as Mostly Harmless: The
> previous text already prohibited removal of Received: fields so existing
> loop control mechanisms based on Received: line counting seem
> sufficient.

Cullen wanted a specific reference.

> I do note that neither the original text nor the new text are even 
> close to
> sufifcient ot deal with looping issues pertaining to the notify 
> extension. But
> we can deal with that issue in the notify specificaitons.

Indeed.

>> Add to the end of section 4.2 two new paragraphs:
>
>>   Implementations SHOULD provide means of limiting the number of 
>> redirects a
>>   Sieve script can perform.
>
> Given that this is essentially the fix I recommended I have no problem 
> with it
> ;-)

Yes, this is exactly what you've suggested.

>>   Implementations MAY ignore a redirect action silently due to policy 
>> reasons.
>>   For example, an implementation MAY choose not to redirect to an 
>> address that
>>   is known to be undeliverable.
>
> This, OTOH, is not an acceptable change. In particular, it is OK to 
> ignore a
> redirect if and only if such an ignored action no longer cancels the 
> implicit
> keep. (A redirect that's ignored and which cancels the implicit keep 
> could
> easily result in silent loss of mail.)
>
> I suggest adding one additional sentence:
>
>    An ignored redirect MUST NOT cancel the implicit keep.

Good point.

>> In section 10, 2nd paragraph:
>
>> OLD:
>>   It is equally important that implementations sanity-check the user's
>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   scripts, and not allow users to create on-demand mailbombs.  For
>>          ^^^^^^^^^
>>   instance, an implementation that allows a user to redirect a message
>>   multiple times might also allow a user to create a mailbomb triggered
>>   by mail from a specific user.  Site- or implementation-defined limits
>>   on actions are useful for this.
>
>> NEW:
>>   Implementations SHOULD sanity-check the user's
>>                   ^^^^^^
>>   scripts. Implementations SHOULD NOT allow users to create on-demand
>> mailbombs.  For
>>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   instance, an implementation that allows a user to redirect a message
>>   multiple times might also allow a user to create a mailbomb triggered
>>   by mail from a specific user.  Site- or implementation-defined limits
>>   on actions are useful for this.
>
> I have no problem with this change.
>
>> The example that follows "MAY ignore redirect due to policy" seems to be
>> non-related to policy.
>> Is extra wordsmithing needed here?
>
> I don't understand the point. You're proposing adding this text to the
> end of section 4.2, right? The only example in that section is the
> script that redirects everything but that would seem to appear in the
> middle rather than after this new text.
>
> What am I missing?

Ignore that, I don't remember which example I was talking about ;-)
(It is problematic to review RFC editor notes that were done a couple of 
months ago)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HMnGlK004742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 15:49:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HMnGIr004741; Fri, 17 Aug 2007 15:49:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HMnEe6004733 for <[e-mail]>; Fri, 17 Aug 2007 15:49:15 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 17 Aug 2007 15:49:10 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 17 Aug 2007 15:49:05 -0700 (PDT)
Cc: Cullen Jennings <[e-mail]>, Lisa Dusseault <[e-mail]>, Philip Guenther <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
Date: Fri, 17 Aug 2007 15:31:14 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
In-reply-to: "Your message dated Fri, 17 Aug 2007 22:34:16 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1187390949; h=Date:	 From:Subject:MIME-version:Content-type; b=fTFoJxZvrAT3YuGqXxNWmKjFf +ZhMPkwEO8k4KsOEBnfyf0nb8IubZWwZ+/tebrwmgnzvl7VJCaqQR1aza42aw==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Cullen, does the following address your DISCUSS?

> =============================
> In section 4.2, last paragraph:

> OLD:
>   Implementations SHOULD take measures to implement loop control,
>   possibly including adding headers to the message or counting Received
>   headers.  If an implementation detects a loop, it causes an error.
> NEW:
>   Implementations SHOULD take measures to implement loop control,
>   possibly including adding headers to the message or counting Received
>   headers as specified in section 6.2 of [SMTP].  If an implementation
> detects a loop, it causes an error.
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I can live with this, but I have to say I see it as Mostly Harmless: The
previous text already prohibited removal of Received: fields so existing
loop control mechanisms based on Received: line counting seem
sufficient.

I do note that neither the original text nor the new text are even close to
sufifcient ot deal with looping issues pertaining to the notify extension. But
we can deal with that issue in the notify specificaitons.

> Add to the end of section 4.2 two new paragraphs:

>   Implementations SHOULD provide means of limiting the number of redirects a
>   Sieve script can perform.

Given that this is essentially the fix I recommended I have no problem with it
;-)

>   Implementations MAY ignore a redirect action silently due to policy reasons.
>   For example, an implementation MAY choose not to redirect to an address that
>   is known to be undeliverable.

This, OTOH, is not an acceptable change. In particular, it is OK to ignore a
redirect if and only if such an ignored action no longer cancels the implicit
keep. (A redirect that's ignored and which cancels the implicit keep could
easily result in silent loss of mail.)

I suggest adding one additional sentence:

    An ignored redirect MUST NOT cancel the implicit keep.

> In section 10, 2nd paragraph:

> OLD:
>   It is equally important that implementations sanity-check the user's
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   scripts, and not allow users to create on-demand mailbombs.  For
>          ^^^^^^^^^
>   instance, an implementation that allows a user to redirect a message
>   multiple times might also allow a user to create a mailbomb triggered
>   by mail from a specific user.  Site- or implementation-defined limits
>   on actions are useful for this.

> NEW:
>   Implementations SHOULD sanity-check the user's
>                   ^^^^^^
>   scripts. Implementations SHOULD NOT allow users to create on-demand
> mailbombs.  For
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   instance, an implementation that allows a user to redirect a message
>   multiple times might also allow a user to create a mailbomb triggered
>   by mail from a specific user.  Site- or implementation-defined limits
>   on actions are useful for this.

I have no problem with this change.

> The example that follows "MAY ignore redirect due to policy" seems to be
> non-related to policy.
> Is extra wordsmithing needed here?

I don't understand the point. You're proposing adding this text to the
end of section 4.2, right? The only example in that section is the
script that redirects everything but that would seem to appear in the
middle rather than after this new text.

What am I missing?

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HMV5UE003199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 15:31:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HMV57a003198; Fri, 17 Aug 2007 15:31:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HMV3GP003191 for <[e-mail]>; Fri, 17 Aug 2007 15:31:04 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 17 Aug 2007 15:30:54 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 17 Aug 2007 15:30:50 -0700 (PDT)
Cc: Sam Hartman <[e-mail]>, Lisa Dusseault <[e-mail]>, Philip Guenther <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Fri, 17 Aug 2007 15:30:21 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Suggested changes to address Sam's DISCUSS on draft-ietf-sieve-3028bis-12.txt
In-reply-to: "Your message dated Fri, 17 Aug 2007 22:24:21 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1187389853; h=Date:	 From:Subject:MIME-version:Content-type; b=W8cQV/jf0M4GJBqJBYeMuE2X8 BBNHPjR8DmeBJWLuFPdFNYk9Lpx8Va5Y/jgN7E6lCX6Ri3qWH0VsXoJgw+Sxw==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I've suggested the following changes to Sam and Philip and they seemed
> to be Ok with them. I am resending them to the mailing list.

> =============
> I suggest to do the following changes to section 7 (they include some
> extra minor changes which I've noticed while checking RFC 4288 which
> replaced RFC 2048):

> OLD:
>   The [MIME] type for a Sieve script is "application/sieve".

>   The registration of this type for RFC 2048 requirements is updated as
>                                         ^^^^
>   follows:

>    Subject: Registration of MIME media type application/sieve

>    MIME media type name: application
>    ^^^^^^^^^^^^^^^
>    MIME subtype name: sieve
>    ^^^^^^^^^^^^

> NEW:
>   The [MIME] type for a Sieve script is "application/sieve".

>   The registration of this type for RFC 4288 requirements is updated as
>                                         ^^^^
>   follows:

>    Subject: Registration of MIME media type application/sieve

>    Type name: application
>    ^^^^
>    Subtype name: sieve
>    ^^^^^^^

> Replace
> OLD:
>    Author/Change controller:
>       See Editor information in this RFC.

> with
> NEW:
>    Author:
>       See Editor information in this RFC.

>    Change controller:
>       IESG
      
> Does this work for everybody?

Looks fine to me.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HLXRbM095702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 14:33:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HLXRbn095701; Fri, 17 Aug 2007 14:33:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HLXQYX095693 for <[e-mail]>; Fri, 17 Aug 2007 14:33:26 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 17 Aug 2007 22:33:23 +0100
Message-ID: <[e-mail]>
Date: Fri, 17 Aug 2007 22:34:16 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Cullen Jennings <[e-mail]>, Lisa Dusseault <[e-mail]>, Philip Guenther <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cullen, does the following address your DISCUSS?

=============================
In section 4.2, last paragraph:

OLD:
  Implementations SHOULD take measures to implement loop control,
  possibly including adding headers to the message or counting Received
  headers.  If an implementation detects a loop, it causes an error.
NEW:
  Implementations SHOULD take measures to implement loop control,
  possibly including adding headers to the message or counting Received
  headers as specified in section 6.2 of [SMTP].  If an implementation 
detects a loop, it causes an error.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Add to the end of section 4.2 two new paragraphs:

  Implementations SHOULD provide means of limiting the number of 
redirects a
  Sieve script can perform.

  Implementations MAY ignore a redirect action silently due to policy 
reasons.
  For example, an implementation MAY choose not to redirect to an 
address that
  is known to be undeliverable.


In section 10, 2nd paragraph:

OLD:
  It is equally important that implementations sanity-check the user's
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  scripts, and not allow users to create on-demand mailbombs.  For
         ^^^^^^^^^
  instance, an implementation that allows a user to redirect a message
  multiple times might also allow a user to create a mailbomb triggered
  by mail from a specific user.  Site- or implementation-defined limits
  on actions are useful for this.

NEW:
  Implementations SHOULD sanity-check the user's
                  ^^^^^^
  scripts. Implementations SHOULD NOT allow users to create on-demand 
mailbombs.  For
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  instance, an implementation that allows a user to redirect a message
  multiple times might also allow a user to create a mailbomb triggered
  by mail from a specific user.  Site- or implementation-defined limits
  on actions are useful for this.

============================
Comments?

The example that follows "MAY ignore redirect due to policy" seems to be 
non-related to policy.
Is extra wordsmithing needed here?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HLNWPw093862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 14:23:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HLNWuo093861; Fri, 17 Aug 2007 14:23:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HLNU0U093854 for <[e-mail]>; Fri, 17 Aug 2007 14:23:31 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 17 Aug 2007 22:23:28 +0100
Message-ID: <[e-mail]>
Date: Fri, 17 Aug 2007 22:24:21 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Sam Hartman <[e-mail]>, Lisa Dusseault <[e-mail]>
CC: Philip Guenther <[e-mail]>, [e-mail]
Subject: Suggested changes to address Sam's DISCUSS on draft-ietf-sieve-3028bis-12.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've suggested the following changes to Sam and Philip and they seemed 
to be Ok with them. I am resending them to the mailing list.
=============
I suggest to do the following changes to section 7 (they include some 
extra minor changes which I've noticed while checking RFC 4288 which 
replaced RFC 2048):

OLD:
  The [MIME] type for a Sieve script is "application/sieve".

  The registration of this type for RFC 2048 requirements is updated as
                                        ^^^^
  follows:

   Subject: Registration of MIME media type application/sieve

   MIME media type name: application
   ^^^^^^^^^^^^^^^
   MIME subtype name: sieve
   ^^^^^^^^^^^^

NEW:
  The [MIME] type for a Sieve script is "application/sieve".

  The registration of this type for RFC 4288 requirements is updated as
                                        ^^^^
  follows:

   Subject: Registration of MIME media type application/sieve

   Type name: application
   ^^^^
   Subtype name: sieve
   ^^^^^^^

Replace
OLD:
   Author/Change controller:
      See Editor information in this RFC.

with
NEW:
   Author:
      See Editor information in this RFC.

   Change controller:
      IESG
      
Does this work for everybody?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DDRwX0099658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 06:27:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DDRwkv099657; Mon, 13 Aug 2007 06:27:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DDRsNf099643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Aug 2007 06:27:58 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1IKZxY-00009K-Mm; Mon, 13 Aug 2007 15:27:52 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx4.uio.no) by mail-mx4.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1IKZxY-0000Iy-7C; Mon, 13 Aug 2007 15:27:52 +0200
Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.3.154]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.67) (envelope-from <[e-mail]>) id 1IKZxX-0000IH-VH; Mon, 13 Aug 2007 15:27:52 +0200
Subject: Re: Naming conventions for Sieve RFCs
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Nigel Swinson <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <[e-mail]>
Content-Type: text/plain
Date: Mon, 13 Aug 2007 15:27:48 +0200
Message-Id: <1187011668.15776.6.camel@oslhomkje>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=12.0, autolearn=disabled, none)
X-UiO-Scanned: A32973036C5B0BB17396BC3FF50D2B5F51B9F217
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 957 total 3220398 max/h 8345 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, 2007-08-12 at 11:13 +0100, Alexey Melnikov wrote:
> Nigel Swinson wrote:
> >RFC3894 Sieve Extension: Copying Without Side Effects. J. Degener.
> >     October 2004. (Format: TXT=9018 bytes) (Status: PROPOSED STANDARD)

> I can change the title, but I think that:
>  SIEVE Email Filtering Extension: Notifications
> 
> is slightly more informative than:
> 
>  SIEVE Email Filtering: Enotify Extension
> 
> (who would know that enotify is about notifications?)
> 
> Opinions?

I don't think it is necessary to use the capability string in the title,
cf. RFC 3894 above, but you need to write it differently so as not to
imply it, e.g. "Sieve Email Filtering: Extension for Notifications"

as previously stated, I prefer the title stays as "Sieve Extension:
Notifications".

-- 
kind regards,
Kjetil T. Homme
sysadmin R&D, FAST



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DAkaF2079508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 03:46:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DAkacL079507; Mon, 13 Aug 2007 03:46:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DAkZor079499 for <[e-mail]>; Mon, 13 Aug 2007 03:46:36 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 096920b0290732a5bcdb98fcb2170588
X-Spam-Score-Summary:  50,0,0,762ea742c844f198,c8077d8714ee5edb,[e-mail],,RULES_HIT:355:379:539:540:541:542:543:567:599:601:967:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1540:1587:1593:1594:1683:1711:1730:1747:1766:1792:2073:2075:2078:2393:2525:2559:2560:2561:2565:2570:2682:2685:2703:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3352:3865:3867:3868:3871:3872:3874:3934:3936:3938:3941:4250:5007:6261,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: windows-1252
X-Spam-Score: 5
Received: from nigelhome (unverified [10.42.40.207]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id <[e-mail]>; Mon, 13 Aug 2007 03:46:34 -0700
Message-ID: <010b01c7dd97$37ab4580$d201a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Alexey Melnikov" <[e-mail]>
Cc: <[e-mail]>
References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <[e-mail]>
Subject: Re: Naming conventions for Sieve RFCs
Date: Mon, 13 Aug 2007 11:46:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >http://tools.ietf.org/html/draft-ietf-sieve-variables
> >Sieve Extension: Variables
> >
> >
> Your proposal should work here.
>
> >http://tools.ietf.org/html/draft-ietf-sieve-notify-08
> >Sieve Extension: Notifications
> >
> >
> I can change the title, but I think that:
>  SIEVE Email Filtering Extension: Notifications
>
> is slightly more informative than:
>
>  SIEVE Email Filtering: Enotify Extension
>
> (who would know that enotify is about notifications?)
>
> Opinions?

I'd be happy with:

Sieve Email Filtering: Notifications

> >http://tools.ietf.org/html/draft-ietf-sieve-3431bis-04
> >Sieve Extension: Relational Tests
> >
> >
> The same problem as above here: I think "Relational Tests" is more
> informative that "Relational Extension"

I'd be happy with:

Sieve Email Filtering: Relational Tests

I don't care if it's SIEVE or Sieve, either, but think it better to be
consistent, and it isn't consistent out there at the moment.

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DAbp46078155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 03:37:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DAbp0c078154; Mon, 13 Aug 2007 03:37:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DAboOK078148 for <[e-mail]>; Mon, 13 Aug 2007 03:37:50 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: d68d6030af33380748eeb6ca5c5ed367
X-Spam-Score-Summary:  50,0,0,afe428f833d80fb4,c8077d8714ee5edb,[e-mail],,RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:967:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2393:2525:2559:2560:2561:2564:2682:2685:2828:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3353:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:5007:6117:6261,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
X-Spam-Score: 5
Received: from nigelhome (unverified [10.42.40.207]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id <[e-mail]>; Mon, 13 Aug 2007 03:37:45 -0700
Message-ID: <00c801c7dd95$fc551b10$d201a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Kjetil Torgrim Homme" <[e-mail]>
Cc: <[e-mail]>
References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <[e-mail]>
Subject: Re: Naming conventions for Sieve RFCs
Date: Mon, 13 Aug 2007 11:37:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Looking for a precedent from the existing RFCs we have:
> >
> > RFC3431 Sieve Extension: Relational Tests.
> > RFC3598 Sieve Email Filtering -- Subaddress Extension.
> > RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions.
> > RFC3894 Sieve Extension: Copying Without Side Effects.
> >
> > http://www.ietf.org/html.charters/sieve-charter.html lists the other
> > I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..."
has
> > the majority vote just now.
>
> it's odd to count unpublished drafts, IMHO.  I obviously prefer the
> shorter "Sieve extension".  But if you're looking at them, note the
> "Sieve notification" drafts -- they're not called "Sieve Email
> Filtering: mailto notification mechanism" etc.

I also prefer the "Sieve Extension:" prefix.  I agree the notification
drafts should also have a predictable prefix, but they seem to have that
already, so didn't bring it up.  Ideally I'd like them to also have the same
prefix as the "Sieve Extension:"s, perhaps with at additional prefix after
that.  However we obviously want to take care that any such prefix does not
become too long.

> > That means we should change these if possible:
> >
> > http://tools.ietf.org/html/draft-ietf-sieve-variables
> > Sieve Extension: Variables
>
> I would rather not put my name on a document which uses the misspelling
> "email", which is actually an old name for "enamel".  it should say
> "e-mail" or just "mail".

While that might be true and I don't care much either way, it sounds like a
fruitless battle.  Surely "email" is so embedded in the common consciousness
by now that it communicates the correct concept, and is that not the aim of
words?

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7D9Q6r6071321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 02:26:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7D9Q6lm071320; Mon, 13 Aug 2007 02:26:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7D9Q5lJ071314 for <[e-mail]>; Mon, 13 Aug 2007 02:26:05 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 13 Aug 2007 10:26:02 +0100
Message-ID: <[e-mail]>
Date: Sun, 12 Aug 2007 11:13:20 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Nigel Swinson <[e-mail]>
CC: [e-mail]
Subject: Re: Naming conventions for Sieve RFCs
References: <007f01c7db68$230c5140$d201a8c0@nigelhome>
In-Reply-To: <007f01c7db68$230c5140$d201a8c0@nigelhome>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nigel Swinson wrote:

>Did we decide on a naming convention for Sieve extensions?
>
I remember we've discussed this before, but I don't remember the outcome 
and I am offline at the moment.

>We seem to have
>either "Sieve Email Filtering: ..." or "Sieve Extension: ..." and I think it
>would be helpful to be consistent.  Looking for a precedent from the
>existing RFCs we have:
>
>RFC3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002.
>     (Format: TXT=12849 bytes) (Status: PROPOSED STANDARD)
>
>RFC3598 Sieve Email Filtering -- Subaddress Extension. K. Murchison.
>     September 2003. (Format: TXT=11151 bytes) (Status: PROPOSED STANDARD)
>
>RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. C.
>     Daboo. February 2004. (Format: TXT=17436 bytes) (Status: PROPOSED
>     STANDARD)
>
>RFC3894 Sieve Extension: Copying Without Side Effects. J. Degener.
>     October 2004. (Format: TXT=9018 bytes) (Status: PROPOSED STANDARD)
>
>http://www.ietf.org/html.charters/sieve-charter.html lists the other
>I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..." has
>the majority vote just now.  That means we should change these if possible:
>
>http://tools.ietf.org/html/draft-ietf-sieve-variables
>Sieve Extension: Variables
>  
>
Your proposal should work here.

>http://tools.ietf.org/html/draft-ietf-sieve-notify-08
>Sieve Extension: Notifications
>  
>
I can change the title, but I think that:
 SIEVE Email Filtering Extension: Notifications

is slightly more informative than:

 SIEVE Email Filtering: Enotify Extension

(who would know that enotify is about notifications?)

Opinions?

>http://tools.ietf.org/html/draft-ietf-sieve-3431bis-04
>Sieve Extension: Relational Tests
>  
>
The same problem as above here: I think "Relational Tests" is more 
informative that "Relational Extension"




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7C15LPM030212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 18:05:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7C15L3i030211; Sat, 11 Aug 2007 18:05:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7C15Jmw030205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 11 Aug 2007 18:05:21 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1IK1tP-0001ej-9A; Sun, 12 Aug 2007 03:05:19 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx6.uio.no) by mail-mx6.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1IK1tO-00085s-Un; Sun, 12 Aug 2007 03:05:19 +0200
Received: from kaksi.ifi.uio.no ([129.240.65.193]) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.67) (envelope-from <[e-mail]>) id 1IK1tO-00083U-Ra; Sun, 12 Aug 2007 03:05:18 +0200
Subject: Re: Naming conventions for Sieve RFCs
From: Kjetil Torgrim Homme <[e-mail]>
To: Nigel Swinson <[e-mail]>
Cc: [e-mail]
In-Reply-To: <007f01c7db68$230c5140$d201a8c0@nigelhome>
References: <007f01c7db68$230c5140$d201a8c0@nigelhome>
Content-Type: text/plain
Date: Sun, 12 Aug 2007 03:05:13 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.8, required=12.0, autolearn=disabled, AWL=0.163,UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 189D6C08A2CCC52F0C68B34FC2637EFA1038B30C
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -47 maxlevel 200 minaction 2 bait 0 mail/h: 10 total 3198372 max/h 8345 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2007-08-10 at 17:03 +0100, Nigel Swinson wrote:
> Did we decide on a naming convention for Sieve extensions?

I don't think so.  when I brought it up a couple of years ago, there
wasn't much interest in such nitpicking :-)

> We seem to have
> either "Sieve Email Filtering: ..." or "Sieve Extension: ..." and I think it
> would be helpful to be consistent.

I agree.

> Looking for a precedent from the existing RFCs we have:
> 
> RFC3431 Sieve Extension: Relational Tests.
> RFC3598 Sieve Email Filtering -- Subaddress Extension.
> RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions.
> RFC3894 Sieve Extension: Copying Without Side Effects.
> 
> http://www.ietf.org/html.charters/sieve-charter.html lists the other
> I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..." has
> the majority vote just now.

it's odd to count unpublished drafts, IMHO.  I obviously prefer the
shorter "Sieve extension".  But if you're looking at them, note the
"Sieve notification" drafts -- they're not called "Sieve Email
Filtering: mailto notification mechanism" etc.

> That means we should change these if possible:
> 
> http://tools.ietf.org/html/draft-ietf-sieve-variables
> Sieve Extension: Variables

I would rather not put my name on a document which uses the misspelling
"email", which is actually an old name for "enamel".  it should say
"e-mail" or just "mail".

-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7C0cQJ2027484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 17:38:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7C0cQmx027483; Sat, 11 Aug 2007 17:38:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7C0cO9M027475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 11 Aug 2007 17:38:25 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1IK1TK-000590-4D; Sun, 12 Aug 2007 02:38:22 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1IK1TJ-0006HS-Ic; Sun, 12 Aug 2007 02:38:21 +0200
Received: from kaksi.ifi.uio.no ([129.240.65.193]) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.67) (envelope-from <[e-mail]>) id 1IK1TJ-0006HL-Fd; Sun, 12 Aug 2007 02:38:21 +0200
Subject: Re: WGLC on draft-ietf-sieve-mime-loop
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Dilyan Palauzov <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Sun, 12 Aug 2007 02:38:15 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=12.0, autolearn=disabled, AWL=0.142,UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: DFE24077EFB3773455572370A6273637DEC8A2E7
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -48 maxlevel 200 minaction 2 bait 0 mail/h: 47 total 3198335 max/h 8345 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, 2007-08-11 at 10:54 +0100, Alexey Melnikov wrote:
> Dilyan Palauzov wrote:
> > If it is 8bit, we take the :first number characters (not bytes),
> 
> Actually 'octet' should be used, as 'character' might use one or more 
> octets, depending on charset.

please, no.  it's not good that you can't know if you get a garbage
value, ie. a truncated UTF-8 sequence or UCS-2, Big5, Shift-JIS or any
other character set encoding which uses multiple octets for a single
character.

3028 (and 3028bis) already has wording which says transcoding into UTF-8
SHOULD be supported.  it seems natural that this extension takes the
lead of [SIEVE] section 2.7.2.  I wouldn't mind it if this extension
*requires* support similar to what is described in the second paragraph:

      [...] Implementations convert text
      from header fields in all charsets [MIME3] to Unicode, encoded as
      UTF-8, as input to the comparator (see 2.7.3).  Implementations
      MUST be capable of converting US-ASCII, ISO-8859-1, the US-ASCII
      subset of ISO-8859-* character sets, and UTF-8.  Text that the
      implementation cannot convert to Unicode for any reason MAY be
      treated as plain US-ASCII (including any [MIME3] syntax) or
      processed according to local conventions. [...]

I can't see any advantage to allowing an implementation to cop out of
this -- it's not a very streneous requirement, and it would cause
interoperability problems if it is made a quality of implementation
issue.  remember that the eventual goal of IETF is to make e-mail pure
UTF-8, with as little extraneous protocol as possible.  we shouldn't add
non-i18n aware features now.

> >> :type, :subtype, :contenttype
> >
> > What is the obvious advantage of having them, compared to header 
> > :contains ? I mean, isn't 'header :contains "Content-Type" "text/"' as 
> > powerful,
> 
> If I remember correctly, the header test doesn't know anything about 
> header field structure, so it can match any of the Content-type parameters.

yes, consider
	Content-Type: image/jpeg; x-exif-data="context/something/other"

you could use :matches (since it is an anchored search), but it would
only work on the type, not the subtype.  e.g.

	header :matches "Content-Type" "*/plain"

wouldn't match

	Content-Type: text/plain; format="flowed"

and you can't easily fix the pattern to handle it.

however, I still don't see the need for all three, IMHO
just :contenttype is enough, and

	header :matches :contenttype "Content-Type" "text/*"

is as clear or maybe clearer than

	header :type "Content-Type" "text"

I am hard pressed to find a use for the :subtype test, too.

> In addition to the above, I think this is slightly easier to understand 
> 'header :contains "Content-Type" "text/"'

oh, we agree :-)
-- 
Kjetil T.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7BLw8Tc012547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 14:58:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7BLw8Y0012546; Sat, 11 Aug 2007 14:58:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from narn.hozed.org (narn.hozed.org [209.234.73.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7BLw63Z012537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 11 Aug 2007 14:58:07 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) (uid 1000) by narn.hozed.org with local; Sat, 11 Aug 2007 16:58:06 -0500 id 0000C422.46BE30EE.000029DE
Date: Sat, 11 Aug 2007 16:58:06 -0500
From: Troy Benjegerdes <[e-mail]>
To: [e-mail]
Subject: sieve-refuse-reject implementations?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Does anyone have an implementation of sieve-refuse-reject that can work
with Postfix, Courier-mta, or Exim?

I have been using courier-mta's localmailfilter 
( http://www.courier-mta.org/localmailfilter.html ) features to run
spamassassin at SMTP-time via maildrop, and I'd like to try to migrate
to something that uses SIEVE since I'd like to have someone other than
myself be able to use SMTP-time reject.


-- 
--------------------------------------------------------------------------
Troy Benjegerdes                'da hozer'                [e-mail]  

Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best answer:

"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's why
I draw cartoons. It's my life." -- Charles Shultz



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7BDHKYf064983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 06:17:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7BDHKA9064982; Sat, 11 Aug 2007 06:17:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7BDHJ0b064968 for <[e-mail]>; Sat, 11 Aug 2007 06:17:19 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 11 Aug 2007 14:17:16 +0100
Message-ID: <[e-mail]>
Date: Sat, 11 Aug 2007 10:54:24 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Dilyan Palauzov <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-mime-loop
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dilyan Palauzov wrote:

> Hello,
>
> > 7 Action extract_text
>
>> QUESTION: What do we do if the Content-Transfer-Encoding is anything 
>> other than 7bit?
>
> If it is 8bit, we take the :first number characters (not bytes),

Actually 'octet' should be used, as 'character' might use one or more 
octets, depending on charset.

> taking into account the "charset=" parameter of the Content-Type 
> header, when presented. If it is base64 or quoted-printable, we 
> convert it to 8bit and proceed as if it was 8bit. The same for binary,

Agreed.

> even if the result will be probably useless. (The useless results can 
> happen using base64, too, but the possibility is smaller)
>
>> :type, :subtype, :contenttype
>
> What is the obvious advantage of having them, compared to header 
> :contains ? I mean, isn't 'header :contains "Content-Type" "text/"' as 
> powerful,

If I remember correctly, the header test doesn't know anything about 
header field structure, so it can match any of the Content-type parameters.

> as 'header :type "Context-Type" "text"'?

In addition to the above, I think this is slightly easier to understand 
'header :contains "Content-Type" "text/"'

> If this was discussed already on this list, could you tell me the 
> starting date?





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AHBQdv065998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 10:11:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7AHBQHd065997; Fri, 10 Aug 2007 10:11:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AHBPSf065990 for <[e-mail]>; Fri, 10 Aug 2007 10:11:26 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with SMTP id B6D3D1EE1; Fri, 10 Aug 2007 10:14:29 -0700 (PDT)
Date: Fri, 10 Aug 2007 17:14:29 -0000
To: "Nigel Swinson" <[e-mail]>
Subject: Re: WGLC on draft-ietf-sieve-mime-loop
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.3
Message-ID: <[e-mail]>
In-Reply-To: <008c01c7db6b$f1933ad0$d201a8c0@nigelhome>
References: <[e-mail]>
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I like these edits a lot! +1 (with a very large value of 1).

One editing note, recall that RFC's should always use the Oxford comma in
lists of three items or more. I've noted two missing commas below. (Sorry,
this is uber-nit-picking; the RFC Editor should pick these up anyways.)

Aaron


On Fri, Aug 10, 2007, Nigel Swinson <[e-mail]> said:

> 
> WRT to: http://tools.ietf.org/html/draft-ietf-sieve-mime-loop-03 and some
> related discussion of http://tools.ietf.org/html/draft-ietf-sieve-body-06
> 
> Abstract
> 
> I don't think it's necessary to start the abstract by saying what can't be
> done with an existing standard.  By stating what this extension offers you
> implicitly propose that no other standard offers this.
> 
> -   The Sieve email filtering language has no way to examine individual
> -   MIME parts or any way to manipulate those individual parts.  However,
> -   being able to filter based on MIME content is important.  This
> -   document defines extensions for these needs.
> +   This document defines extensions to the Sieve email filtering language
> +   to permit analysis and manipulation of the MIME body parts of an email
> +   message.
> 
> 1.  Introduction
> 
> I don't think it's necessary to justify the current extension based on what
> other standards don't allow you to do.  Also while it might be helpful to
> refer to other related standards, it seems to just create headaches when you
> want to revise the standard later, so I'd suggest:
> 
> -   Sieve scripts are used to make decisions about the disposition of an
> -   email message.  The base Sieve specification,
> -   [I-D.ietf-sieve-3028bis], defines operators for looking at the
> -   message headers, such as addresses and the subject.  Other extensions
> -   provide access to the body of the message ([I-D.ietf-sieve-body]), or
> -   allow you to manipulate the header of the message
> -   ([I-D.ietf-sieve-editheader]).  But none of these extensions take
> -   into account that MIME messages ([RFC2045]) are often complex
>    MIME messages ([RFC2045]) are often complex
>    objects, consisting of many parts and sub-parts.  This extension
>    defines mechanisms for performing tests on MIME body parts, looping
>    through the MIME body parts, extracting information from a MIME body
>    part, changing the contents of a MIME body part, and enclosing the
> -   entire message with a wrapper.
> +  entire message within a wrapper.
> 
> 3.  Sieve Loops
> 
>    The base Sieve language has no looping mechanism.  Given that
>    messages may contain multiple parts, in order to support filters that
>    apply to any and all parts, we introduce a new control command:
>    "for_every_part", which is an iterator that walks though every MIME
>    part of a message, including nested parts, and applies the commands
>    in the specified block to each of them.  The iterator will start with
>    the first MIME part (as its current context) and will execute a
> -   command block (Sieve commands enclosed by { ...}).  Upon completion
> +   command block (Sieve commands enclosed by {...}).  Upon completion
>    of this command block, the iterator advances to the next MIME part
>    (as its current context) and executes the same command block again.
> 
> 
>    "for_every_part" commands can be nested inside other "for_every_part"
>    commands.  When this occurs, the nested "for_every_part" iterates
> -   over the MIME parts contained within the MIME part current being
> +   over the MIME parts contained within the MIME part currently being
>    targeted by the nearest enclosing "for_every_part" command.  If that
>    MIME part is a terminal MIME part (i.e. does not contain other MIME
>    parts) then the nested "for_every_loop" is simply ignored.
> 
> 4.1.  Test "header"
> 
>    The "header" test is extended with the addition of a new ":mime"
> -   tagged argument, which takes a number of other arguments.
> +   tagged argument and its associated options.
> 
>    Usage:  header [:mime] [:anychild] [MIMEOPTS]
>       [COMPARATOR] [MATCH-TYPE]
>       <header-names: string-list> <key-list: string-list>
> 
>    Usage:  The definition of [MIMEOPTS] is:
> 
>       Syntax: ":type" / ":subtype" / ":contenttype" /
>       ":param" <param-list: string-list>
> 
>    When the ":mime" tagged argument is present in the "header" test, it
> -   will parse the MIME header lines in a message so that tests can be
> +   will parse the MIME header lines in the message so that tests can be
>    performed on specific elements.
> 
> I don't think the section below reads well, as I think the list with
> introductory partial sentence construct should mean you can prefix each list
> item with the indroductory partial sentence and it still read well.  Below
> you'd end up with:
> 
> - If the ":anychild" tagged argument is NOT specified if used within the
> context of a "for_every_part" iterator, etc....
> - If the ":anychild" tagged argument is NOT specified if used outside the
> context of a "for_every_part" iterator, etc...
> 
> Also I think the behaviour should be explained when :anychild is used with
> for_every_part.
> 
> -   If the ":anychild" tagged argument is NOT specified:
> -
> -   o  If used within the context of a "for_every_part" iterator, the
> -      "header" test will examine the headers associated with the current
> -      MIME part context from the loop.
> -
> -   o  If used outside the context of a "for_every_part" iterator, the
> -      "header" test will examine only the outer, top-level, headers of
> -      the message.
> +   When used outside the context of a "for_every_part" iterator, and
> +   without an ":anychild" tagged argument, the "header" test will examine
> +   only the outer top-level RFC2822 headers of the message.
> +
> +   When used inside the context of a "for_every_part" iterator, and
> +   without an ":anychild" tagged argument, the "header" test will examine
> +   the headers associated with the current MIME part context from the loop.
> +
> -   If the ":anychild" tagged argument IS specified, the "header" test
> +  When used outside the context of a "for_every_part" iterator, and
> +  with an ":anychild" tagged argument, the "header" test
>    will examine all MIME body parts and return true if any of them
>    satisfies the test.
> +
> +  When used inside the context of a "for_every_part" iterator, and
> +  with an ":anychild" tagged argument, the "header" test will examine
> +  the current MIME part context and all it's nested MIME body parts,
> +  returning true if any of them satisfies the test.
> 
> 
>    Example:
> 
>    require ["mime", "fileinto"];
> 
> -   if header :mime :anychild :contenttype :comparator
> +   if header :mime :anychild :contenttype
>              "Content-Type" "text/html"
>    {
>        fileinto "INBOX.html";
>    }
> 
>    In this example, any message that contains any MIME part with a
>    content-type of "text/html" is saved to the mailbox "INBOX.html".
> 
> Reading over this again I don't think it's clear when you should use
> for_every_part, and when you should use :anychild.  I think we should offer
> an example that illustrates why we have both mechanisms.  Consider the
> question, "Which one of these should I use:
> 
>    if header :mime :anychild :contenttype :comparator
>              "Content-Type" "text/html"
>    { ... }
> 
> Or:
> 
>     for_every_part {
>        if header :mime :contenttype :comparator
>              "Content-Type" "text/html"
>        { ... }
>     }
> 
> Perhaps change the for_every_part example.  It had the same ":comparator"
> bug that the previous example had anyway.
> 
>    Example:
> 
>    require ["mime", "for_every_part", "fileinto"];
> 
>    for_every_part
>    {
> 
> +       if allof (
> -       if header :mime :param "filename" :comparator
> -          "Content-Disposition" "important"
> +      header :mime :param "filename" :contains
> +         "Content-Disposition" "important",
> +      header :mime :subtype "Content-Type" "pdf",
> +       size :over "100K")
>        {
>            fileinto "INBOX.important";
>            break;
>        }
>    }
> 
> -   In this example, any message that contains any MIME part with a
> -   content-disposition with a filename parameter containing the text
> -   "important" is saved to the mailbox "INBOX.important".
> 
> +    In this example, any message that contains a MIME part that
> +    has a content-disposition with a filename parameter containing the text
> +   "important", has a content-subtype of "pdf" and is bigger than 100 Kb
> +    is saved to the mailbox "INBOX.important".

needs a comma after "pdf".

> 
> 4.2.  Test "address"
> 
> I've tried and failed to find any specification on the "content-from"
> header.  Perhaps partially because googling for the term "content-from" is
> fairly unfruitful, and there's no mention in 2045.  So I'd suggest this
> section be dropped, or changed to reference where "content-from" is defined.
> I'm also not clear at all why you can't just use a vanilla address test.  ie
> why doesn't this work:
> 
>     if address :is :all "content-from" "[e-mail]"
> 
> I can understand utility in:
> 
>     if address :mime :anychild :is :all "content-from" [e-mail]
> 
> In which case I'd rather it was just:
> 
>     if address :anychild :is :all "content-from" [e-mail]
> 
> And the ":mime" be the way of accessing the type, subtype, parameters of
> those structured headers.
> 
> 4.3.  Test "exists"
> 
> Again I don't see why you couldn't just write:
> 
> if exists :anychild "content-md5"
> 
> 5.  Action Replace
> 
>    If the :mime parameter is not specified, the replacement string is a
> -   text/plain part.
> +   text/plain part in UTF-8.
> 
>    If the :mime parameter is specified, then the replacement string is,
>    in fact, a MIME entity as defined in [RFC2045] section 2.4, including
> + both MIME headers and content.
> -   both MIME headers and content.  If the optional :mime parameter is
> -   not supplied, the reason string is considered to be a UTF-8 string.
> 
> 6.  Action Enclose
> 
>    A new Sieve action command is defined to allow an entire message to
>    be enclosed as an attachment to a new message.  After enclosure,
>    subsequent actions affecting the message header or content use the
> -   newly create message instead of the original message; this means that
> +   newly created message instead of the original message; this means that
>    any use of a "replace" action or other similar actions should be
>    executed before the "enclose" action.
> 
> The text implies that enclose happens immediately, and therefore subsequent
> actions affecting the message header/content apply to the enclosing message,
> but then it goes on to say if there are multiple enclose actions, then it's
> only the last one that will win.  This means if I have an enclose action,
> I'll have to remember that the outer body part is the new "enclosing" body
> part, and should I get another enclose action then I should "replace" that
> enclosing body part rather than enclose the message yet again such that it
> has two layers of enclosing.
> 
> This sounds like a real hassle to implement for questionable utility, I'd
> rather two enclose actions just add two layers of enclosing mime structure
> and body text body parts be present.  Just like they would if the message
> goes through two separate Sieve scripts, both of which add an enclose.
> Either that or define that the enclose action should happen at the end of
> the script and therefore doesn't affect the mime structure during the
> existing processing (that might even be inside a for_every_part construct).
> I'd actually suggest we leave it to the implementation like we do for
> fileinto.  The implementation can choose to have the enclose happen
> immediately, or at the end.
> 
> 7.  Action extract_text
> 
> Shouldn't we leave this to the body test?  I know in section 5 of
> http://tools.ietf.org/html/draft-ietf-sieve-body-06 it says that we
> shouldn't set the match variables, but perhaps it should define an optional
> argument of :extracttext in the body spec to do this if we really wanted
> them.
> 
> 8.  Sieve Capability Strings
> 
> -   A Sieve implementation that defines the ":mime" tagged arguments to
> +  A Sieve implementation that defines the ":mime" tagged argument to
> +   the "header" test and the ":anychild" tagged argument to
>    the "header", "address" and "exists" commands will advertise the
>    capability string "mime".

Needs a comma after "address".

>    A Sieve implementation that defines the "extract_text" action will
>    advertise the capability string "extract_text".  Note that to be
>    useful, the "extract_text" action also requires the "variables"
> -   [I-D.ietf-sieve-variables] and "mime" capabilities.
> +   [I-D.ietf-sieve-variables] and "for_every_part" capabilities.
> 
> 9.1.  Example 1
> 
>    A Sieve script to replace all the Windows executable attachments in a
>    message would be:
> 
> This example isn't indented either and should be:
> 
>     require [ "for_every_part", "mime", "replace" ];
>     for_every_part
>     {
> -  if ( anyof (
> +  if anyof (
>              header :mime :contenttype :is "Content-Type" "application/exe",
>              header :mime :param "filename"
>                ["Content-Type", "Content-Disposition"] :matches "*.com" )
>       {
>         replace "Executable attachment removed by user filter";
>       }
>     }
> 
> 9.2.  Example 2
> 
>    A Sieve script to warn the user about executable attachment types
>    would be:
> 
>    require [ "for_every_part", "mime", "enclose" ];
> 
>    for_every_part
>    {
>      if header :mime :param "filename"
>         ["Content-Type", "Content-Disposition"] :matches
>           ["*.com", "*.exe", "*.vbs", "*.scr",
>            "*.pif", "*.hta", "*.bat", "*.zip" ]
>      {
>        # these attachment types are executable
> -       enclose :subject "Warning" "
> +      enclose :subject "Warning" text:
>    WARNING! The enclosed message contains executable attachments.
>    These attachments types may contain a computer virus program
> -   that can infect your computer and potentently damage your data
> +   that can infect your computer and potentently damage your data.
> 
>    Before clicking on these message attachments, you should verify
>    with the sender that this message was sent by them and not a
>    computer virus.
> -   ";
>     .
>        break;
>      }
>    }
> 
> 9.3.  Example 3
> 
>    A Sieve script to extract subject and text out of messages from the
> -   boss
>    boss:
> 
> 11.  Security Considerations
> 
>    The "enclose" action creates an entirely new message, as compared to
>    just redirecting or forwarding the existing message.  Therefore, any
>    site policies applicable to message submission should be enforced.
> -   site policies applicable to message submission should be enforced
> -   here.
> 
>    The looping specification specified here provides easier access to
>    information about the message contents, which may also be achieved
>    through other sieve tests.  This is not believed to raise any
>    additional security issues beyond those for the Sieve "envelope" and
> + "body" ([I-D.ietf-sieve-body]) tests.
> -   "body" tests.
> 
> Cheers
> 
> Nigel
> 
> 

-- 





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AGeJsR062810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 09:40:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7AGeJ1N062809; Fri, 10 Aug 2007 09:40:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AGeIhL062803 for <[e-mail]>; Fri, 10 Aug 2007 09:40:18 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 9e52fb333d7811c92572a55900992c6d
X-Spam-Score-Summary:  50,0,0,55ed4ed25f6ebb19,23ac6e436408ec99,[e-mail],,RULES_HIT:152:355:379:539:540:541:542:543:567:599:601:946:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1587:1593:1594:1676:1711:1730:1747:1766:1792:2073:2075:2078:2379:2393:2559:2560:2561:2562:2691:2693:2890:3027:3353:3865:3866:3867:3868:3869:3871:3872:3873:4042:5007:6118:6119:6261,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: utf-8
X-Spam-Score: 5
Received: from nigelhome (unverified [10.42.40.204]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id <[e-mail]>; Fri, 10 Aug 2007 09:40:13 -0700
Message-ID: <009601c7db6d$1ff9c7d0$d201a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Dilyan Palauzov" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: WGLC on draft-ietf-sieve-mime-loop
Date: Fri, 10 Aug 2007 17:40:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>  > 7 Action extract_text
>
> > QUESTION: What do we do if the Content-Transfer-Encoding is anything
other than 7bit?
>
> If it is 8bit, we take the :first number characters (not bytes), taking
into account the
> "charset=" parameter of the Content-Type header, when presented. If it is
base64 or
> quoted-printable, we convert it to 8bit and proceed as if it was 8bit. The
same for binary,
>  even if the result will be probably useless. (The useless results can
happen using base64,
> too, but the possibility is smaller)

I guess the reason this is a problem is if you hit some 10MB base64 encoded
attachment and are trying to extract the first 100 bytes.  You either have
to decode the whole 10MB, or write some picky code to extract as little text
as possible while decoding legal units of QP/base64 encoding.

With the body test we offer :raw :content :text to decide what kind of
transform is required, which is why I believe extract_text should be moved
to the body spec, and implemented through an optional argument to force the
setting of the match variables.

> > :type, :subtype, :contenttype
>
> What is the obvious advantage of having them, compared to header :contains
? I mean, isn't
> 'header :contains "Content-Type" "text/"' as powerful, as 'header :type
"Context-Type"
> "text"'? If this was discussed already on this list, could you tell me the
starting date?

It's a matter of precision of parsing.  Consider:

    header :contains "Content-Type" "text"

and

    header :type "Content-Type" "text"

Against this content-type header:

Content-Type: application/pdf;  name="presentationtext.pdf"

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AGVucD062193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 09:31:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7AGVubV062192; Fri, 10 Aug 2007 09:31:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AGVrKQ062185 for <[e-mail]>; Fri, 10 Aug 2007 09:31:55 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: d343d8b5356ea62ff9c9ddf4c33d15b1
X-Spam-Score-Summary:  50,0,0,8818a3ac00660dac,23ac6e436408ec99,[e-mail],,RULES_HIT:4:355:379:481:539:540:541:542:543:567:599:945:946:960:967:968:973:978:980:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1587:1588:1593:1594:1605:1730:1747:1766:1792:2073:2075:2078:2198:2199:2234:2393:2525:2553:2559:2560:2561:2568:2570:2627:2640:2682:2685:2692:2693:2703:2731:2828:2857:2859:2890:2892:2894:2901:2915:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3636:3657:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:4042:4250:4605:5007:6118:6119:6261,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
X-Spam-Score: 5
Received: from nigelhome (unverified [10.42.40.204]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 10 Aug 2007 09:31:46 -0700
Message-ID: <008c01c7db6b$f1933ad0$d201a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: WGLC on draft-ietf-sieve-mime-loop
Date: Fri, 10 Aug 2007 17:31:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

WRT to: http://tools.ietf.org/html/draft-ietf-sieve-mime-loop-03 and some
related discussion of http://tools.ietf.org/html/draft-ietf-sieve-body-06

Abstract

I don't think it's necessary to start the abstract by saying what can't be
done with an existing standard.  By stating what this extension offers you
implicitly propose that no other standard offers this.

-   The Sieve email filtering language has no way to examine individual
-   MIME parts or any way to manipulate those individual parts.  However,
-   being able to filter based on MIME content is important.  This
-   document defines extensions for these needs.
+   This document defines extensions to the Sieve email filtering language
+   to permit analysis and manipulation of the MIME body parts of an email
+   message.

1.  Introduction

I don't think it's necessary to justify the current extension based on what
other standards don't allow you to do.  Also while it might be helpful to
refer to other related standards, it seems to just create headaches when you
want to revise the standard later, so I'd suggest:

-   Sieve scripts are used to make decisions about the disposition of an
-   email message.  The base Sieve specification,
-   [I-D.ietf-sieve-3028bis], defines operators for looking at the
-   message headers, such as addresses and the subject.  Other extensions
-   provide access to the body of the message ([I-D.ietf-sieve-body]), or
-   allow you to manipulate the header of the message
-   ([I-D.ietf-sieve-editheader]).  But none of these extensions take
-   into account that MIME messages ([RFC2045]) are often complex
   MIME messages ([RFC2045]) are often complex
   objects, consisting of many parts and sub-parts.  This extension
   defines mechanisms for performing tests on MIME body parts, looping
   through the MIME body parts, extracting information from a MIME body
   part, changing the contents of a MIME body part, and enclosing the
-   entire message with a wrapper.
+  entire message within a wrapper.

3.  Sieve Loops

   The base Sieve language has no looping mechanism.  Given that
   messages may contain multiple parts, in order to support filters that
   apply to any and all parts, we introduce a new control command:
   "for_every_part", which is an iterator that walks though every MIME
   part of a message, including nested parts, and applies the commands
   in the specified block to each of them.  The iterator will start with
   the first MIME part (as its current context) and will execute a
-   command block (Sieve commands enclosed by { ...}).  Upon completion
+   command block (Sieve commands enclosed by {...}).  Upon completion
   of this command block, the iterator advances to the next MIME part
   (as its current context) and executes the same command block again.


   "for_every_part" commands can be nested inside other "for_every_part"
   commands.  When this occurs, the nested "for_every_part" iterates
-   over the MIME parts contained within the MIME part current being
+   over the MIME parts contained within the MIME part currently being
   targeted by the nearest enclosing "for_every_part" command.  If that
   MIME part is a terminal MIME part (i.e. does not contain other MIME
   parts) then the nested "for_every_loop" is simply ignored.

4.1.  Test "header"

   The "header" test is extended with the addition of a new ":mime"
-   tagged argument, which takes a number of other arguments.
+   tagged argument and its associated options.

   Usage:  header [:mime] [:anychild] [MIMEOPTS]
      [COMPARATOR] [MATCH-TYPE]
      <header-names: string-list> <key-list: string-list>

   Usage:  The definition of [MIMEOPTS] is:

      Syntax: ":type" / ":subtype" / ":contenttype" /
      ":param" <param-list: string-list>

   When the ":mime" tagged argument is present in the "header" test, it
-   will parse the MIME header lines in a message so that tests can be
+   will parse the MIME header lines in the message so that tests can be
   performed on specific elements.

I don't think the section below reads well, as I think the list with
introductory partial sentence construct should mean you can prefix each list
item with the indroductory partial sentence and it still read well.  Below
you'd end up with:

- If the ":anychild" tagged argument is NOT specified if used within the
context of a "for_every_part" iterator, etc....
- If the ":anychild" tagged argument is NOT specified if used outside the
context of a "for_every_part" iterator, etc...

Also I think the behaviour should be explained when :anychild is used with
for_every_part.

-   If the ":anychild" tagged argument is NOT specified:
-
-   o  If used within the context of a "for_every_part" iterator, the
-      "header" test will examine the headers associated with the current
-      MIME part context from the loop.
-
-   o  If used outside the context of a "for_every_part" iterator, the
-      "header" test will examine only the outer, top-level, headers of
-      the message.
+   When used outside the context of a "for_every_part" iterator, and
+   without an ":anychild" tagged argument, the "header" test will examine
+   only the outer top-level RFC2822 headers of the message.
+
+   When used inside the context of a "for_every_part" iterator, and
+   without an ":anychild" tagged argument, the "header" test will examine
+   the headers associated with the current MIME part context from the loop.
+
-   If the ":anychild" tagged argument IS specified, the "header" test
+  When used outside the context of a "for_every_part" iterator, and
+  with an ":anychild" tagged argument, the "header" test
   will examine all MIME body parts and return true if any of them
   satisfies the test.
+
+  When used inside the context of a "for_every_part" iterator, and
+  with an ":anychild" tagged argument, the "header" test will examine
+  the current MIME part context and all it's nested MIME body parts,
+  returning true if any of them satisfies the test.


   Example:

   require ["mime", "fileinto"];

-   if header :mime :anychild :contenttype :comparator
+   if header :mime :anychild :contenttype
             "Content-Type" "text/html"
   {
       fileinto "INBOX.html";
   }

   In this example, any message that contains any MIME part with a
   content-type of "text/html" is saved to the mailbox "INBOX.html".

Reading over this again I don't think it's clear when you should use
for_every_part, and when you should use :anychild.  I think we should offer
an example that illustrates why we have both mechanisms.  Consider the
question, "Which one of these should I use:

   if header :mime :anychild :contenttype :comparator
             "Content-Type" "text/html"
   { ... }

Or:

    for_every_part {
       if header :mime :contenttype :comparator
             "Content-Type" "text/html"
       { ... }
    }

Perhaps change the for_every_part example.  It had the same ":comparator"
bug that the previous example had anyway.

   Example:

   require ["mime", "for_every_part", "fileinto"];

   for_every_part
   {

+       if allof (
-       if header :mime :param "filename" :comparator
-          "Content-Disposition" "important"
+      header :mime :param "filename" :contains
+         "Content-Disposition" "important",
+      header :mime :subtype "Content-Type" "pdf",
+       size :over "100K")
       {
           fileinto "INBOX.important";
           break;
       }
   }

-   In this example, any message that contains any MIME part with a
-   content-disposition with a filename parameter containing the text
-   "important" is saved to the mailbox "INBOX.important".

+    In this example, any message that contains a MIME part that
+    has a content-disposition with a filename parameter containing the text
+   "important", has a content-subtype of "pdf" and is bigger than 100 Kb
+    is saved to the mailbox "INBOX.important".

4.2.  Test "address"

I've tried and failed to find any specification on the "content-from"
header.  Perhaps partially because googling for the term "content-from" is
fairly unfruitful, and there's no mention in 2045.  So I'd suggest this
section be dropped, or changed to reference where "content-from" is defined.
I'm also not clear at all why you can't just use a vanilla address test.  ie
why doesn't this work:

    if address :is :all "content-from" "[e-mail]"

I can understand utility in:

    if address :mime :anychild :is :all "content-from" [e-mail]

In which case I'd rather it was just:

    if address :anychild :is :all "content-from" [e-mail]

And the ":mime" be the way of accessing the type, subtype, parameters of
those structured headers.

4.3.  Test "exists"

Again I don't see why you couldn't just write:

if exists :anychild "content-md5"

5.  Action Replace

   If the :mime parameter is not specified, the replacement string is a
-   text/plain part.
+   text/plain part in UTF-8.

   If the :mime parameter is specified, then the replacement string is,
   in fact, a MIME entity as defined in [RFC2045] section 2.4, including
+ both MIME headers and content.
-   both MIME headers and content.  If the optional :mime parameter is
-   not supplied, the reason string is considered to be a UTF-8 string.

6.  Action Enclose

   A new Sieve action command is defined to allow an entire message to
   be enclosed as an attachment to a new message.  After enclosure,
   subsequent actions affecting the message header or content use the
-   newly create message instead of the original message; this means that
+   newly created message instead of the original message; this means that
   any use of a "replace" action or other similar actions should be
   executed before the "enclose" action.

The text implies that enclose happens immediately, and therefore subsequent
actions affecting the message header/content apply to the enclosing message,
but then it goes on to say if there are multiple enclose actions, then it's
only the last one that will win.  This means if I have an enclose action,
I'll have to remember that the outer body part is the new "enclosing" body
part, and should I get another enclose action then I should "replace" that
enclosing body part rather than enclose the message yet again such that it
has two layers of enclosing.

This sounds like a real hassle to implement for questionable utility, I'd
rather two enclose actions just add two layers of enclosing mime structure
and body text body parts be present.  Just like they would if the message
goes through two separate Sieve scripts, both of which add an enclose.
Either that or define that the enclose action should happen at the end of
the script and therefore doesn't affect the mime structure during the
existing processing (that might even be inside a for_every_part construct).
I'd actually suggest we leave it to the implementation like we do for
fileinto.  The implementation can choose to have the enclose happen
immediately, or at the end.

7.  Action extract_text

Shouldn't we leave this to the body test?  I know in section 5 of
http://tools.ietf.org/html/draft-ietf-sieve-body-06 it says that we
shouldn't set the match variables, but perhaps it should define an optional
argument of :extracttext in the body spec to do this if we really wanted
them.

8.  Sieve Capability Strings

-   A Sieve implementation that defines the ":mime" tagged arguments to
+  A Sieve implementation that defines the ":mime" tagged argument to
+   the "header" test and the ":anychild" tagged argument to
   the "header", "address" and "exists" commands will advertise the
   capability string "mime".

   A Sieve implementation that defines the "extract_text" action will
   advertise the capability string "extract_text".  Note that to be
   useful, the "extract_text" action also requires the "variables"
-   [I-D.ietf-sieve-variables] and "mime" capabilities.
+   [I-D.ietf-sieve-variables] and "for_every_part" capabilities.

9.1.  Example 1

   A Sieve script to replace all the Windows executable attachments in a
   message would be:

This example isn't indented either and should be:

    require [ "for_every_part", "mime", "replace" ];
    for_every_part
    {
-  if ( anyof (
+  if anyof (
             header :mime :contenttype :is "Content-Type" "application/exe",
             header :mime :param "filename"
               ["Content-Type", "Content-Disposition"] :matches "*.com" )
      {
        replace "Executable attachment removed by user filter";
      }
    }

9.2.  Example 2

   A Sieve script to warn the user about executable attachment types
   would be:

   require [ "for_every_part", "mime", "enclose" ];

   for_every_part
   {
     if header :mime :param "filename"
        ["Content-Type", "Content-Disposition"] :matches
          ["*.com", "*.exe", "*.vbs", "*.scr",
           "*.pif", "*.hta", "*.bat", "*.zip" ]
     {
       # these attachment types are executable
-       enclose :subject "Warning" "
+      enclose :subject "Warning" text:
   WARNING! The enclosed message contains executable attachments.
   These attachments types may contain a computer virus program
-   that can infect your computer and potentently damage your data
+   that can infect your computer and potentently damage your data.

   Before clicking on these message attachments, you should verify
   with the sender that this message was sent by them and not a
   computer virus.
-   ";
    .
       break;
     }
   }

9.3.  Example 3

   A Sieve script to extract subject and text out of messages from the
-   boss
   boss:

11.  Security Considerations

   The "enclose" action creates an entirely new message, as compared to
   just redirecting or forwarding the existing message.  Therefore, any
   site policies applicable to message submission should be enforced.
-   site policies applicable to message submission should be enforced
-   here.

   The looping specification specified here provides easier access to
   information about the message contents, which may also be achieved
   through other sieve tests.  This is not believed to raise any
   additional security issues beyond those for the Sieve "envelope" and
+ "body" ([I-D.ietf-sieve-body]) tests.
-   "body" tests.

Cheers

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AG4xKF058818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 09:04:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7AG4xMM058817; Fri, 10 Aug 2007 09:04:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AG4waF058807 for <[e-mail]>; Fri, 10 Aug 2007 09:04:58 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 7b242c29d8db285fa60d6e83aa9ba6d8
X-Spam-Score-Summary:  50,0,0,2e59e13e31d084cb,3662bc5a4cdaaf62,[e-mail],,RULES_HIT:355:379:539:540:541:542:543:567:945:967:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1587:1593:1594:1683:1711:1730:1747:1766:1792:2073:2075:2078:2393:2525:2553:2566:2682:2685:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3865:3867:3868:3869:3872:3874:3934:3936:3938:3941:5007:6117:6261,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: windows-1252
X-Spam-Score: 5
Received: from nigelhome (unverified [10.42.40.204]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 10 Aug 2007 09:04:31 -0700
Message-ID: <007f01c7db68$230c5140$d201a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Subject: Naming conventions for Sieve RFCs
Date: Fri, 10 Aug 2007 17:03:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Did we decide on a naming convention for Sieve extensions?  We seem to have
either "Sieve Email Filtering: ..." or "Sieve Extension: ..." and I think it
would be helpful to be consistent.  Looking for a precedent from the
existing RFCs we have:

RFC3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002.
     (Format: TXT=12849 bytes) (Status: PROPOSED STANDARD)

RFC3598 Sieve Email Filtering -- Subaddress Extension. K. Murchison.
     September 2003. (Format: TXT=11151 bytes) (Status: PROPOSED STANDARD)

RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. C.
     Daboo. February 2004. (Format: TXT=17436 bytes) (Status: PROPOSED
     STANDARD)

RFC3894 Sieve Extension: Copying Without Side Effects. J. Degener.
     October 2004. (Format: TXT=9018 bytes) (Status: PROPOSED STANDARD)

http://www.ietf.org/html.charters/sieve-charter.html lists the other
I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..." has
the majority vote just now.  That means we should change these if possible:

http://tools.ietf.org/html/draft-ietf-sieve-variables
Sieve Extension: Variables

http://tools.ietf.org/html/draft-ietf-sieve-notify-08
Sieve Extension: Notifications

http://tools.ietf.org/html/draft-ietf-sieve-3431bis-04
Sieve Extension: Relational Tests

Nigel





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76FthnK023041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 08:55:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l76FtgnI023040; Mon, 6 Aug 2007 08:55:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76Fte91023032 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 6 Aug 2007 08:55:42 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1II4vh-0007lB-9x; Mon, 06 Aug 2007 17:55:37 +0200
X-Mail-Sent-By-AEGEE.org-Account: Dilyan [e-mail]
Received: from [172.20.21.213] (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) (authenticated bits=0) by smtp.aegee.org (8.14.1/8.13.6) with ESMTP id l76Ftekh011637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 15:55:40 GMT
Message-ID: <[e-mail]>
Date: Mon, 06 Aug 2007 17:55:38 +0200
From: Dilyan Palauzov <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-ietf-sieve-mime-loop
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.91.1/3874/Mon Aug  6 00:38:49 2007 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

 > 7 Action extract_text

> QUESTION: What do we do if the Content-Transfer-Encoding is anything other than 7bit?

If it is 8bit, we take the :first number characters (not bytes), taking into account the 
"charset=" parameter of the Content-Type header, when presented. If it is base64 or 
quoted-printable, we convert it to 8bit and proceed as if it was 8bit. The same for binary,
 even if the result will be probably useless. (The useless results can happen using base64, 
too, but the possibility is smaller)

> :type, :subtype, :contenttype

What is the obvious advantage of having them, compared to header :contains ? I mean, isn't 
'header :contains "Content-Type" "text/"' as powerful, as 'header :type "Context-Type" 
"text"'? If this was discussed already on this list, could you tell me the starting date?

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

Alexey Melnikov wrote:
>
> Hi,
>
> This message officially starts the Sieve Working Group Last Call for
> the following document:
> SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and 
> Enclosure
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-03.txt>
>
> The Working Group Last Call for this document starts on August 6th and 
> will end on August 20th.
>
> Please send any comments to the Sieve mailing list or directly to me. 
> Please CC Tony Hansen <[e-mail]> and Cyrus Daboo 
> <[e-mail]> in the latter case. Reviews that found no issues 
> are also welcomed, so if you review the document and find it 
> acceptable, please let the mailing list/authors+me know as well.
>
> Thank you,
> Alexey, Sieve WG co-chairs
>
>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76EcYkt015538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 07:38:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l76EcYQL015537; Mon, 6 Aug 2007 07:38:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76EcX2i015528 for <[e-mail]>; Mon, 6 Aug 2007 07:38:34 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 6 Aug 2007 15:37:51 +0100
Message-ID: <[e-mail]>
Date: Mon, 06 Aug 2007 09:48:58 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: WGLC on draft-ietf-sieve-mime-loop
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

This message officially starts the Sieve Working Group Last Call for
the following document: 

SIEVE Email Filtering:  MIME part Tests, Iteration, Replacement and Enclosure
<http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-03.txt>

The Working Group Last Call for this document starts on August 6th and will end on August 20th.

Please send any comments to the Sieve mailing list or directly to me. Please CC Tony Hansen <[e-mail]> and Cyrus Daboo <[e-mail]> in the latter case. Reviews that found no issues are also welcomed, so if you review the document and find it acceptable, please let the mailing list/authors+me know as well.

Thank you,
Alexey, Sieve WG co-chairs