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

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

2007-08-17 16:01:24


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.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I can live with this, but I have to say I see it as Mostly Harmless: The
previous text already prohibited removal of Received: fields so existing
loop control mechanisms based on Received: line counting seem
sufficient.

I do note that neither the original text nor the new text are even close to
sufifcient ot deal with looping issues pertaining to the notify extension. But
we can deal with that issue in the notify specificaitons.

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.

Given that this is essentially the fix I recommended I have no problem with it
;-)

  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.

This, OTOH, is not an acceptable change. In particular, it is OK to ignore a
redirect if and only if such an ignored action no longer cancels the implicit
keep. (A redirect that's ignored and which cancels the implicit keep could
easily result in silent loss of mail.)

I suggest adding one additional sentence:

   An ignored redirect MUST NOT cancel the implicit keep.

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.

I have no problem with this change.

The example that follows "MAY ignore redirect due to policy" seems to be
non-related to policy.
Is extra wordsmithing needed here?

I don't understand the point. You're proposing adding this text to the
end of section 4.2, right? The only example in that section is the
script that redirects everything but that would seem to appear in the
middle rather than after this new text.

What am I missing?

                                Ned