On Tue, Sep 25, 2007, Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> said:
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).
I understand that some implementations will have to change, but I'm prety
confident we need this requirement. I cannot cite problematic behavior
with Sieve redirect to back it up, but I have seen several cases of
bounce loops occur with other sorts of autoforwarding that does this.
This is less an issue with intentional attacks than it is with unintentional
loop creation. The common problematic case is where someone redirects their
mail unconditionally to some remote place while filling in their own address
in the envelope. Now suppose that remote address becomes invalid. The
DSN goes back and is redirected, but now it has a nonempty envelope from
so a loop forms.
I think by the time we're done with this section, we'll have written the
best practices document for forwarding mail :-) It's one of those things
where very specific guidance on edge cases is really important.
[snip]
(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.
I see it as setting a minimum that has to be there. I don't see how it could
prevent some mechanism we haven't thought of from being used.
To clarify what I wrote above ('this text' had the wrong antecedent), I
see no problems myself with the new text and I definitely appreciate the
guidance and direct statement of what was alluded to by the original text.
Aaron