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.