Subject: Re: Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt, take 2

From: Cullen Jennings <[email-masked]>
Date: Mon, 1 Oct 2007 08:50:08 -0400

On Sep 22, 2007, at 6:16 PM, Alexey Melnikov wrote:

> 1). This is really no brainer. Any deployed mail system should have  
> a way to disable accounts. I would suggest adding the following:
>
>  Sieve implementations MUST provide facilities to allow  
> administrators to disable accounts abusing scripts.
>
> Cullen, does this satisfy you?

Much of this thread is going in really the right direction but I do  
need to comment on this one as I don't think I ever said anything  
about being able to disable accounts. Of course I agree that  
disabling accounts is a good idea - it never crossed my mind that  
there might be any implementation that did not support this.

I suspect that a different things was being discussed that may have  
lead to this idea about disabling accounts. Lisa or Chris was  
explaining to me on one of the IESG calls that the ways you might  
deal with misuse of sieve scripts changed on if it was more of and  
enterprise style deployment or if it was that supported anonymous  
accounts such as yahoo. I think the relevant factor here was if the  
email account could be linked to a real human user thought I don't  
recall Lisa or Chris every agreeing with this and I have no idea if  
we are on the same page or not.

I am really lost on all the proposed changes and look forward to a  
new version of the draft to follow all the changes.

The idea of separating scripts into harmless, harmful, unsure is  
certainly an interesting path. It  was not obvious to me how to do  
this but it seems like if that advice is to restrict redirects to one  
from harmful and unsure scripts, that would address my concerns.  
Given that draft-ietf-sieve-variables-08 is approved, I suspect you  
would want to deal with variables when describing the script analysis.

PS. I'm glad to keep bouncing emails around but my offer stands to  
try some more interactive form of resolving this if people want to  
try and move faster.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 01 Oct 2007 14:20:25 +0100

> try some more interactive form of resolving this if people want to  

Arranging a phone call for so many parties involved just doesn't work.
I was available for a phone call last week, but it didn't happen. I am 
not available for the phone call this week. And I am on holidays for 3 
weeks starting from October 5th. So, we need to keep do this in email.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 01 Oct 2007 18:40:51 +0100

Ned Freed wrote:

> With all the back and forth on this I'm afraid I've lost track of the
> current set of proposed revisions. If you could send them to me I'll see
> about adding these points to them without getting into the issues Sieve
> variables raises.

Below:

In Section 1, 2nd paragraph, replace last sentence:
OLD:
  The base language is intentionally not Turing-complete: it provides no 
way to
  write a loop or a function and variables are not provided.
NEW:
 The base language was not designed to be Turing-complete: it does not have
 a loop command or function syntax.

In section 4.2, add a sentence to the end of 3rd paragraph:
OLD:
 The envelope sender address on the outgoing message is chosen by the
 sieve implementation.  It MAY be copied from the message being
 processed.
NEW:
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.

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 MUST 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 MUST provide means of limiting the number of redirects a
Sieve script can perform. See Section 10 for more details.

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. An ignored redirect MUST NOT cancel the 
implicit keep.

In section 10, replace 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:
 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 exponentially growing message loops. According,
 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 exist for using redirect 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.