ietf-mta-filters
[Top] [All Lists]

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

2007-09-23 06:59:43

Ned Freed wrote:

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.

Here is the proposal Ned was referring to:

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.