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

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

2007-09-24 22:42:02

On Sat, 2007-09-22 at 22:13 +0100, Alexey Melnikov wrote:
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.

If this is correct behavior (thinking back again to the original
reference to .forward files), then my implementation is incorrect (it
tries to construct an envelope sender when one is not already present).

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.

+1

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:

Accordingly,
         ^^
  (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.

+1. (2) is a rather stern new requirement. It provides clarity on what
was meant by "Site- or implementation-defined limits on actions are
useful for this" in the original text. I don't see any problems with
this text myself, unless it precludes some other mechanisms that I
haven't thought about.

Aaron