Subject: IESG comments on 3028bis

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 May 2007 22:43:43 +0100

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?

2). Cullen Jennings:
 >I see a serious problem with the allowing redirection to more than one 
users.
 >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. This is worse. It is also different than mailing lists which 
hopefully
 >have a consent mechanism. 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.

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.

Opinions?

===============
Also, Cullen has suggested to drop the text about CMU FLAME language. I 
welcome comments on this.

---

From: "Aaron Stone" <[email-masked]>
Date: Fri, 11 May 2007 22:16:46 -0000

On Fri, May 11, 2007, Alexey Melnikov <[email-masked]> said:

> 2). Cullen Jennings:
>  >I see a serious problem with the allowing redirection to more than 
>  >one users.
>  >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. This is worse. It is also
>  >different than mailing lists which hopefully have a consent mechanism.
>  >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.
> 

I like being able to place multiple redirects, and am using that
functionality myself to implement a blind reflector address. I thought the
only major concern was preventing a mail loop.

Hadn't .forward files allowed multiple redirects since just about forever?

Aaron

---

From: Michael Haardt <[email-masked]>
Date: Sat, 12 May 2007 00:45:52 +0200

> this issue is not specific to Sieve. Do I have this right?

Yes.

> [deleted]

> However the document should have a security consideration on this issue, 

Sorry? Sure, it's a way to shoot yourself in the foot, if you try to.
But at least traditional Unix forward mechanisms allowed that for ages,
and it never caused much grief, not even today.  I consider multiple
redirects to be an important feature, important enough that I would
ignore a SHOULD.

Btw, the language is not precise.  In general, you can't tell if multiple
addresses belong to multiple users.  But I guess "to more than one
address" was thought of. Tsts. ;) 

Michael

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 May 2007 15:06:15 -0700 (PDT)

> 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?

>  >I see a serious problem with the allowing redirection to more than one

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.

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

> However the document should have a security consideration on this issue,

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.

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

---

From: Tony Finch <[email-masked]>
Date: Sat, 12 May 2007 10:29:32 +0100

>Hadn't .forward files allowed multiple redirects since just about forever?

Yes, and it's really important functionality - in my environment it's common
for senior staff to have a couple of PAs who receive copies of their email.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FORTIES: EASTERLY BACKING NORTHERLY 4 OR 5, OCCASIONALLY 6, BECOMING CYCLONIC
FOR A TIME IN SOUTH. MODERATE, OCCASIONALLY ROUGH. RAIN OR SHOWERS. MODERATE
OR GOOD.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 13 May 2007 22:45:38 +0100

Ned Freed wrote:

> How about simply referencing RFC 2821 section 6.2?

A good idea indeed.

> Received: field counting is the best prqctice in this area, we have a 
> document that says as much so why

Either way I will keep arguing with Cullen that this is out of scope for us.

> understanding SMTP at the most fundamental level.

Thanks for the rest of your comment :-).
I will forward it to Cullen.