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

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

2007-10-01 10:56:02

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.

<Prev in Thread] Current Thread [Next in Thread>