And you thought that this document was done ;-).
IESG didn't think so. Here are the two main issues:
1). Cullen Jennings:
>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.
I think this was discussed on the mailing list before and there was
consensus that this should be addressed in a separate document, because
this issue is not specific to Sieve. Do I have this right?
How about simply referencing RFC 2821 section 6.2? Received: field counting is
the best prqctice in this area, we have a document that says as much so why
spend time on further elaboration that is, among other things, pretty clearly
out of scope for this group?
2). Cullen Jennings:
>I see a serious problem with the allowing redirection to more than one
users.
I'm sorry, but this doesn't come close to passing the laugh test. To the extent
this is an issue it is in no way specific to Sieve redirect; there are lots of
different ways for users to use server-side resources to send mail to many
addresses at once. Not understanding this is nothing less than not
understanding SMTP at the most fundamental level.
>This allows a very high speed server in the center of the network to
perform a
>application of already large traffic. When filtering happens on an end
user
>email client it is no worse than what the client could do by just
sending new
>email.
Exactly, and all that takes in the most restrictive possible case is to specify
multiple recipients in a single message copy you submit to the server, letting
the server then perform the taks of splitting the message into multiple copies
and consuming its bandwidth as needed. The overhead of multiple RCPT TO
commands in SMTP is pretty negligable.
This is worse.
Not in practice it isn't, and it is pretty easy to understand why: Things like
spambots are written to depend on lowest-common demoninator facilities on the
part of their host systems. Sieve is not currently part of the LCD picture, and
even if it does become part of it access to it is unlikely to be regularized to
the point where it would make sense to try and exploit it. It is much easier to
exploit the abiltiy to simply submit a message to multiple addresses and have
the submission server expand it.
It is also different than mailing lists which hopefully
have a consent mechanism.
Nonsense. Many systems allow users to create server-side mailing lists and in
fact quite a few go so far as to strongly encourage such practices, if for no
other reason than to centralize list content and administration. Such systems
rarely if ever require recipient consent to be subscribed when it is the list
owner themselves doing the subscribing.
Here at Sun I routinely get added to mailing lists set up by random people - so
much so that the last time I checked I found my address on literally hundreds
of internal lists. (And while our own software has facilities for this Sun
actually uses an even less restrictive howe-grown thing called netadmin to do
this.) I suspect lots of other people can relate similar experiences.
Indeed, some systems allow dynamic mailing lists to be defined using LDAP URLs.
If the local user population is large it becomes a trivial matter to set up a
list with a couple of mouse clicks that is able to send mail to thousands of
people. Contrast this with the difficulty of creating a sieve with a huge list
of explicit addresses, especially if the only way you can do that is in a web
interface that requires multiple clicks per rule. (Lots of sieve-based systems
don't provide direct uploading of user-constructed sieves, managesieve
notwithstanding.)
I am proposing fixing this by saying that the limit on
number of redirects SHOULD be one and the times to ignore this SHOULD
are text environments and such.
Our implementation has a parameter to limit the number of redirects a sieve can
perform. It defaults to 32 and we have had customers who found this value to be
unacceptably low. On the flip side, I also cannot recall a case where a
customer has come to us complaining that the default of 32 was letting their
users abuse the system. Now, perhaps this is the one time where customers in
need without exception actually RFTMed and set this parameter rather than
asking us how to do it, but that seems a bit unlikely, especially since I just
googled the parameter name and it appears that it never made it into our
documentation! (Oops.)
In any case, I would have no objection to saying in section 4.2 that
implementations SHOULD provide a means of limiting the number of redirects a
sieve can perform. However, specifying that the default limit SHOULD be 1 is
quite simply absurd and would have the unavoidable effect of making the
specification itself look incompetent.
I've sent Cullen a reply saying that there are several implementation
that allow for multiple redirects.
However the document should have a security consideration on this issue,
if it doesn't already.
It's already there:
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.
Opinions?
===============
Also, Cullen has suggested to drop the text about CMU FLAME language. I
welcome comments on this.
I'm not sure what the logic is behind suggestions to remove such etiological
notes from our specifications, but I have to say I'm getting tired of it. I
think the history behind our specifications can provide important context and
insight. I for one have found such notes in other specifications to be quite
valuable.
It would be another matter entirely if the specification depended normatively
on understanding such a reference, but that's not the case. It also
would argue for replacing the reference with a local explanation rather than
simply deleting it.
One final point. It would be one thing if sieve was a brand-new specification
being issued for the first time. In such cases speculation and concerns about
potential security issues is arguably quite beneficial (although I have to say
that even in such cases I have not found the IETF's crystal ball to be all that
accurate).
But sieve is not new. It has been a proposed standard for over six years. It is
very widely deployed with quite a few implementations and is known to scale to
operate well on servers with very large user populations. It is therefore
possible to couter assertions of potential issues with information about actual
operational experience.
Ned