Ned Freed wrote:
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.
Cullen wanted a specific reference.
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.
Indeed.
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
;-)
Yes, this is exactly what you've suggested.
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.
Good point.
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?
Ignore that, I don't remember which example I was talking about ;-)
(It is problematic to review RFC editor notes that were done a couple of
months ago)