Hi Cullen,
Cullen Jennings wrote:
So what can we do? Well, I guess one option would be to try and make
the discussion of this a little more explicit in the document. How
about
adding something like this to the security considerations?
This is great - few bits inline below...
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 expontentially growing message loops. Acording, 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.
My discuss did not ask for this but it certainly seems like a good idea.
Actually it did:
Discuss [2007-05-10]:
The document says that one SHOULD do loop detection - I think it needs to point
at some advice that provided at least one way to implement loop detection at a
level of detail high enough that it is implementable.
and lack of the reference was a bug in the document.
[...]
(3) MUST provide facilities to log use of redirect in order to
facilitate
tracking down abuse.
I would ask if this mean that they MUST know what human the script
was associated with.
I don't think so. Existing mail systems log an email address or an
associated account name. This is sufficient to identify an account
causing mail abuse.
Even if the account provider has no information about the physical
person associated with the account, it has the ability to disable the
account to stop any abuse.
Alexey