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?