Subject: [secdir] Review of draft-freed-sieve-notary-07

From: Tero Kivinen <[email-masked]>
Date: Tue, 13 Apr 2010 16:31:02 +0300

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This draft provides two things. Firstly it will provide ability for
sieve email filtering program to see the delivery status notification
and deliver by information from the envelope. Secondly it allows
setting those same parameters when using sieve redirect action.

The first part does not have security issues, but the second might
have, as it causes delivery notify emails to be sent which were not
originally requested by the original author.

This can cause problems for the original sender, as he is now getting
the deliver status notifications which he has not requested. The draft
does not explictly specify, but I do assume that the sieve redirect
keeps the original sender intact, so the deliver status notification
messages are sent to the original author, not to the user doing the
redirect.

The number of delivery status notifications can be quite large,
especially if the ":bytrace" option of the redirect is used, as then
every single future step for email processing, will send "relayed"
status notification, and if there is for example mail loop or similar,
this can be several dozen of status notifications.

This should most likely be mentioned in the security considerations
section more clearly. The security considerations section do warn
about generating status notification, and says that

  "Sites which limit the ability to request success notifications will
   also need to restrict the ability to request them using the
   redirect-dsn extension."

but that does not help at all, as if the original senders site limits
the ability to request notifications, the host running sieve email
filter of the receiver might not have such restrictions, thus receiver
can enable them even when they were forbidden from the sender.

Also in section 5, it should be made clear that the "bytime" can also
be negative, if the bymode is "notify" and the message is already
pasts is notification time.

Section 5 also says that the "bytime" is "the initial integer part of
the delive-by extension", but then comments that deliver-by by-time is
decremented as message passes through the transport infrastructure.
This does not make it clear whether the sieve filtering system should
also decrement the number while message is waiting to be processed.
I.e. if message was received earlier, but it took some time before the
sieve email filter could be run on the message, should the "bytime" be
the original time from the smtp MAIL FROM BY= part, or whether it is
decremented.

Also the example in 5.1 is wrong, as it is only true if the sieve
filter is run exactly when the deliver-by expired. It should compare
whether the "bytime" is <= 0, not whether it is equal to 0 (note, that
if tye bymode is "return" then the "bytime" never should reach 0, as
at that point mail is returned to the sender.

In section 7 it should be made clear that ":bytime" parameter "<limit:
number>" can be negative too, but it seems that RFC 5228 specifies
that numbers can only be non-negative so I am not sure whether the
usage is correct or not. 
-- 
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Apr 2010 14:58:56 +0100

Hi Tero,
Thank you for the review.
In this message I am responding to the second part of your comments:

>pasts is notification time.
Agreed.

>the original time from the smtp MAIL FROM BY= part, or whether it is
I don't think it makes sense to decrement the by-time once the message 
is in the final delivery agent. Otherwise it might be hard to debug 
Sieve scripts making use of this extension.

>filter is run exactly when the deliver-by expired.
>
Good point.

>It should compare
Yes.
I would also note that the i;ascii-numeric comparator doesn't work with 
negative numbers.

>that numbers can only be non-negative so I am not sure whether the
I concur, this is a bug.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Apr 2010 17:49:40 +0300

> Sieve scripts making use of this extension.

What about if email is redirected again, then should the delay caused
by the Sieve script be taken into account?

I do not know whether the Sieve scripts are always run immediately
when the email comes in, or whether it is possible to queue the
messages during peak hours, and then run them through the Sieve
scripts later when the load peak causing servers to be overloaded is
over. In that case it might be useful to decrement the by-time, just
in case the message was something that deliver this if it can be
delivered before the 17:00, but after that return it back to the
sender, so he will know that he needs to call the user, as he knows
the user does not read his emails after that hour (which was one
reason for by-time). 

> I would also note that the i;ascii-numeric comparator doesn't work with 

Then you might want to express negative (i.e expired by-time) as
setting by-time to zero, but this should be mentioned in the draft.
Other option would be to use strings, I am not sure which one would
better fit to Sieve architecture.

-- 
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Apr 2010 17:05:27 +0100

Hi Tero,

>messages are sent to the original author, not to the user doing the
The answer to your question is "it depends on an implementation". The 
redirect action is defined in section 4.2 of RFC 5228, which says:

   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.  This last requirement is imposed to prevent
   loops in the case where a message is redirected to an invalid address
   when then returns a delivery status notification that also ends up
   being redirected to the same invalid address.

>this can be several dozen of status notifications.
Can you clarify what do you mean by "every single future step for email 
processing"?

My recollection is that for any given SMTP path from a sender to a 
recipient only a single "relay" DSN can be generated.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Apr 2010 17:14:17 +0100

Hi Tero,

>by the Sieve script be taken into account?
Yes, it might make sense to do that for redirect-deliverby.

(I was thinking about envelope-deliverby when I answered your question.)

>the user does not read his emails after that hour (which was one
I don't know of implementations that do the latter (off-peak 
processing), but this is certainly allowed. I.e. this is an 
implementation detail.
So yes, maybe it is worth discussing this in more details even for 
envelope-deliverby.

>setting by-time to zero, but this should be mentioned in the draft.
I thought about that as well. I agree.
I will wait for the author to suggest a fix to this.

>better fit to Sieve architecture.
Co-incidently I suggested that to the author during my AD review :-).

---

From: Ned Freed <[email-masked]>
Date: Fri, 16 Apr 2010 13:04:57 -0700 (PDT)

> originally requested by the original author.

THis really isn't the issue, or more precisely, if this is an issue warranting
such great concern this isn't the place to address it.

All this extension does is give a user access to existing site capabilities
through Sieve. If those capabilities are available, a user can use or abuse
them directly far more easily than they can through Sieve.

The only scenario where this presents an added exposure is one where these
capabilities can be accessed through Sieve but not through regular  submission
or SMTP. If such a setup were created, it would be a fairly wierd thing - so
wierd I really cannot see much point in worrying about it. But even so, this
particular case is specifically dealt with by the current security
considerations.

> keeps the original sender intact,

Sieve redirect is defined in RFC 5228 and it doesn't specify whether the
original address is used or the address of the Sieve owner. (What it does say
is that if the original message had an empty envelope from, any redirected
message must also have an empty envelope from. This prevents certain especially
pernicious loops from forming, but I don't see it as relevant to this
discussion.)

Considering redirect behavior further, it does raise an issue that needs to be
addressed in this document, but it's a usability issue, not a security issue.
Specifically, what does it mean to add a DSN request or activate deliverby
when you don't know where these notifications are going to go? This ruins
the usability of both redirect-dsn and redirect-deliverby. I therefore
propose adding the following text to redirect-dsn and similar text to
redirect-deliverby:

  RFC 5228 does not require any particular envelope sender address be associated
  with redirected messages. However, the redirect-dsn extension isn't terribly
  useful if the place where the delivery status notifications are sent isn't
  known. Accordingly, when either :notify or :ret is specified and the envelope
  sender address isn't empty, implementations MUST set the envelope sender
  address to the address of the sieve owner. 

> so the deliver status notification

That's one possible behavior, but if someone wants to create intentional
backscatter, it is far simpler to just connect to the submit port and say:

    MAIL FROM:<target>
    RCPT TO:<whoever> NOTIFY=SUCCESS,FAILURES
    DATA
    blah blah
    .

> this can be several dozen of status notifications.

The same arguments hold for DELIVERBY. If the extension is available, why
not just (ab)use it directly? Why bother with a convoluted path through
Sieve that will almost certainly leave a much bigger trail?

> can enable them even when they were forbidden from the sender.

You're missing the point. If the site restricts notification requests in some
way, e.g, you can only request a success notification if the envelope from is
local, then that restriction also needs to apply to redirect-dsn and
redirect-deliveryby, because if it doesn't you've left a hole someone could
exploit.

But if there is no such restriction, then it simply doesn't matter what
we do in Sieve, because nobody is going to bother using Sieve when direct
usage is simpler, easier and less likely to be detected.

> pasts is notification time.

Unfortunately, RFC 2852 predates the current thinking in email that there's
significant semantic difference between submission and relay. My understanding
of the purpose of negative by-times is that they are arrived at when a message
exceeds the time limit but still needs to be delivered. If there's a
justification for having a negative by-time on initial submission I haven't
heard it. In fact had RFC 2852 distinguished between submit and relay I suspect
it would have disallowed negative by-times in the submit case.

And since the use of this extension effectively means the message is being
resubmitted, I don't see any reason to allow negative by-times to be specified.
I do not feel strongly about this, however, so if others feel this should be
allowed I'll be happy to change it. (The other argument, and in my view more
reasonable, argument in favor of the change is that this would mean the
parameter would have to be a string rather than an counting number, and that
would allow variables to be used.)

> the original time from the smtp MAIL FROM BY= part, or whether it is

I first have to say that if the timing is so critical that this sort of thing
really matters, you're pretty much sunk before you start.  For better or worse
the DELIVERBY extension only applies while mail is in transit, and there's an
increasing amount of stuff that happens outside of this context (e.g.,
downloads from a POP3/IMAP4 server) that cannot be traced or "timed out").

And again, if this really bothers you, this draft is not the place to address
the issue.

Be that as it may, I actualy the the draft is pretty clear on this point. It
says:

  When these arguments are specified, they are used to construct the
  corresponding BY ESMTP MAIL FROM parameter. The :bytime value becomes
  the by-time, the :bymode becomes the by-mode value, and :bytrace
  sets the by-trace modifier.

I think this makes it clear the values are simply passed unchanged to the
SMTP/submit server. But if you want to suggest a specific change, that's fine.

> at that point mail is returned to the sender.

Yep, this is broken, and moreover the fix isn't that simple because
the i;ascii-numeric comparator only handles unsigned values.  I've updated the
text to address this issue.
 
> that numbers can only be non-negative so I am not sure whether the

That's only true if we decide to allow specification of negative values.
However, I did add a note saying that negative values cannot be specified.

Thanks for the comments - very useful. I'll post a revision once there's
agreement on the envelope sender text and whether or not to change :bytime.

				Ned

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 22 Apr 2010 12:13:42 +0300

>    being redirected to the same invalid address.

Ok. Then it might be good idea to mention this also in this document,
as it affects where the status notifications are going to, i.e. if
user decides he wants to request status notifications, he does not
know whether it goes to the original author or to his own address.

> recipient only a single "relay" DSN can be generated.

No. If I send email from my home machine to [email-masked] address,
and use the trace option of DELIVERYBY feature I will get one status
notification when my local machine takes email in and relays it to
iki.fi mail server. Then I get another status notification when the
iki.fi email-server gets message in and forwards it to iki.fi-spam
filter (this setting is per user setting and the spam processing is
done on the other machine). Then I get next one when the spam filter
machine is done running the spamassasin and forwards that email to my
real end delivery address (which in my case happens to be my home
machine kivinen.iki.fi). Then when my home machine gets the email
again now with envelope receiver of [email-masked] (as
rewritten by the iki.fi machines) it will send me the fourth trace
message.

So every single machine which relays the email sends the status
notification saying the email was relayed.

Now when I noticed there is such feature, I have found it quite useful
when debugging email problems.

I am one of the maintainers of the iki.fi, which provides permanent
email forwarding services, and quite often our members complain that
their emails does not get through, and now I have easy way of sending
one email with trace option and I can see from DSNs that the email
goes through iki.fi machines without delays and problems, and that the
email was delivered to the members next step machine (which usually
does not enable DELIVERYBY so I do not get any further reports).

So if someone enables trace option in the middle and then redirects
the email to forward then there might be several of those relayed
status notifications sent to either to the original author or to the
one running the sieve (depending which envelope sender the sieve
implementation used).

> >can enable them even when they were forbidden from the sender.

Ok, now this also makes bit more sense, as if the sieve implmentation
decides to rewrite the envelope sender then this restriction is
appropriate, but if it does not rewrite the envelope sender, then it
does not help, as the machine running sieve might not know the policy
required by the original senders machine, i.e. whether the original
sender was allowed to request those status notifications or not.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 22 Apr 2010 13:51:04 +0300

Ned Freed writes:
> The only scenario where this presents an added exposure is one where
> these capabilities can be accessed through Sieve but not through
> regular submission or SMTP. If such a setup were created, it would
> be a fairly wierd thing - so wierd I really cannot see much point in
> worrying about it. But even so, this particular case is specifically
> dealt with by the current security considerations.

This all depends what envelope sender is used for redirects. If
original author envelope sender is used, then normally there is no way
to enable sending deliver status notifications to the original sender
for email in transit, usually the original sender must request it.
This feature adds option to someone else to request them (but see the
text later about this).

>   RFC 5228 does not require any particular envelope sender address
>   be associated with redirected messages. However, the redirect-dsn
>   extension isn't terribly useful if the place where the delivery
>   status notifications are sent isn't known. Accordingly, when
>   either :notify or :ret is specified and the envelope sender
>   address isn't empty, implementations MUST set the envelope sender

This text will address the problem as after this it is not possible
for someone else to request status notification for original author,
i.e with this text added the problem mentioned earlier disappears. 

>     RCPT TO:<whoever> NOTIFY=SUCCESS,FAILURES

With trace option you get amplification factor, i.e. you only need
send one message and that can generate multiple messages back. 

> Sieve that will almost certainly leave a much bigger trail?

If the relayed status notifications go to the original author instead
of the sieve filter owner, then the attacker does not need to send
any emails, the victim attacks himself by sending email to attackers
address which will then add trace option to the email on the fly.

This attack goes away if status notifications always go to the sieve
owner.

> redirect-deliveryby, because if it doesn't you've left a hole someone could

Yes, I understood that, but depending what envelope sender is used for
those status notification there is ANOTHER problem.

Say host A limits DSN notification complately, i.e does not allow them
at all. Now host A user A sends email to user B on host B whose sieve
filter adds status notifications (as they are not restricted on host
B, only on host A) and the status notifications go to original author
A. Now host A user A will get status notifications even when the host
A policy forbid requesting them.

Host B cannot know what policy host A has, thus it cannot restrict
operations. Again this problem goes away if host B can only request
status notifications so they come to the host B envelope sender.

> Unfortunately, RFC 2852 predates the current thinking in email that
> there's significant semantic difference between submission and
> relay. My understanding of the purpose of negative by-times is that
> they are arrived at when a message exceeds the time limit but still
> needs to be delivered. If there's a justification for having a
> negative by-time on initial submission I haven't heard it. In fact
> had RFC 2852 distinguished between submit and relay I suspect it
> would have disallowed negative by-times in the submit case.

I do not thing this is relevant here.

> And since the use of this extension effectively means the message is
> being resubmitted, I don't see any reason to allow negative by-times
> to be specified.

It might be needed if the sieve filter wants to preserve by-time
values given to it in the beginning. I do not know enough of Sieve to
know if it is possible, but one use could be using sieve to for
example limit the by-time to something, i.e. wants to make sure that
when email is redirected to cellular phone it is delivered before
certain time (for example before 22:00, because user does not want to
wake up when cellular phone beeps in the middle of night), unless the
email already had shorted by-time, in which case it wants to preserve
it.

In that case the by-time could be already negative when user redirects
the email.

Also I think the Sieve should be able to preserve by-time and envelope
sender when it redirects email, if it does not ADD new notifications.

I.e if someone sends email having by-time saying it needs to be
delivered during next hour, and the Sieve forwards it to the cellular,
it would be useful to keep that same time limit there, and it would
also be nice if the original author still gets the status
notifications he asked for.

If the sieve owner asks for additional notifications they should come
to sieve owner, not to the original author. 

> I first have to say that if the timing is so critical that this sort
> of thing really matters, you're pretty much sunk before you start.
> For better or worse the DELIVERBY extension only applies while mail
> is in transit, and there's an increasing amount of stuff that
> happens outside of this context (e.g., downloads from a POP3/IMAP4
> server) that cannot be traced or "timed out").

If the email is not yet delivered to the local mail box, but is
redirected to somewhere else by the Sieve then I do consider the email
to still be in transit, and the time used to run the Sieve should be
taken in to account. In most cases it does not really matter as
running it is very fast, but I think it still needs to be counted for.

> I think this makes it clear the values are simply passed unchanged
> to the SMTP/submit server. But if you want to suggest a specific
> change, that's fine.

I think RFC 2852 is very clear that you are supposed to convert that
DELTA time to absolute time upon receipt of email, and then convert it
back to delta time when you send email forward:

   A delta time is used so as to prevent problems associated with
   differences in system clocks between clients and servers.  Servers in
   receipt of a valid by-parameter are expected to convert the by-time
   into a locale-specific absolute time called the deliver-by-time.

   This is done by adding the by-time upon receipt to the current
   locale-specific time and thereby arriving at a locale-specific
   absolute time which is by-time seconds in the future or past,
   depending upon the arithmetic sign of by-time.  The message is then
   to be delivered by the deliver-by-time. 

Hmm.. actually it would be more accordingly to the RFC2852 to not give
out the delta time to Sieve, but instead the deliver-by-time (which is
locale-specific absolute time instead), and leave the processing of
negative and positive delta times for the email service instead of
Sieve filter.

This of course depends whether Sieve has time and date data format,
i.e. if those can be expressed in Sieve in a way where they can
processed. This would allow it easier to for example to set
delivery-by-time so that no email is delivered to your cellular phone
after certain time (i.e. it is bounced back if it is tried to deliver
after that).
-- 
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Apr 2010 12:31:14 +0100

Ned Freed wrote:
 [...]

>  address to the address of the sieve owner. 
This looks good to me, so I've entered 2 RFC Editor notes (one for 
redirect-dsn and a similar one for redirect-deliverby)

---

From: Ned Freed <[email-masked]>
Date: Thu, 22 Apr 2010 09:26:26 -0700 (PDT)

> This all depends what envelope sender is used for redirects.

Not really. Again, since regular submit/SMTP allows specification of *any*
envelope sender, and Sieve piggybacks off that capability, the only added
exposure this extension provides is if the restrictions on redirect are for
some reason less than what's on submit/SMTP itself. And that case is already
explicitly covered in the security considersions section.

> If

Sure there is. All I have to do is resubmit the message, specifying the
original sender but adding whatever NOTIFY options I choose. At most Sieve
offers a different way to get at this functionality; it doesn't offer the
functionality itelf.

> i.e with this text added the problem mentioned earlier disappears.

It prevents it from being done using Sieve, yes, but that's not the reason for
making the change and doesn't change the fact that the security issue you've
described does not exist in any meaningful sense.

> send one message and that can generate multiple messages back.

And the trace option is also available via submit/SMTP, so this is a
distinction without a difference.

> address which will then add trace option to the email on the fly.

Now please explain the significant advantage this provides to an attacker. It's
not like sending emails is hard.

> This attack goes away if status notifications always go to the sieve

Yes, but you have failed to make the case that this "attack" is worth worrying
about.

> those status notification there is ANOTHER problem.

A problem which the security considerations already address.

> A policy forbid requesting them.

In other words, this is a case where the Sieve policy for requesting DSNs is
more lenient that for submit/SMTP. I agree this is a security concern, which is
why the security considerations section of the document addresses it. It says:

  Sites which limit the ability
  to request success notifications will also need to restrict the ability
  to request them using the redirect-dsn extension.

> operations.

Not only can it know, it has to. This is what administrators are for - to
implement consistent policies across hosts.

And if you don't have consistent administrative policies for email handling the
set of issues we're discussing here are going to be the absolute least of your
problems.

> Again this problem goes away if host B can only request

Actually, no, it doesn't. It may prevent the mechanism from being used to
create backscatter, but inconsistent administrative policies open the door to
all sorts of other bad behavior.

> I do not thing this is relevant here.

On the contrary, it's entirely relevant because what we have done by requiring
the resetting of the envelope sender is to effectively require that these
extended redirect be considered as a new submission, not a relay operation.

> email already had shorted by-time, in which case it wants to preserve > it.

The short answer is ths use-case you describe here really isn't feasible
in Sieve, for a bunch of different reasons.

THe longer answer is that this ends up being infeasible because:

(1) Sieve doesn't have enough numeric and time computation facilities to
    perform the sort of limit operation you describe.

(2) Even if you could do the calculation, or if, say, there was a related
    use-case where limiting the relative value made sense (I confess I cannot
    come up with one where it does), most Sieve implementations operate
    after final delivery, so copying deliver-by information doesn't really
    make sense.

(3) A script that does something like this really needs to know what
    sort of Sieve implementation it is dealing with before doing it. In
    particular, it needs to know if the Sieve is operating before or
    after final delivery. It turns out this can be determined, but it
    requires an additional extension - the environment extenion and the
    "phase" item, e.g.,

    "phase"   => The point relative to final delivery where the
                 Sieve script is being evaluated.  Possible values are
                 "pre", "during", and "post", referring respectively to
                 processing before, during, and after final delivery
                 has taken place.

(4) A script that tries to do this and doesn't check the phase could
    result in bad behavior.

I think all of this conspires to make this particular use-case one not worth
worrying about. But again, this isn't something I feel strongly about, so if
the consensus is to change it I will do so.

> In that case the by-time could be already negative when user redirects

Actually, no. In the use-case you describe, the goal is to prevent the phone
from ringing after a certain point. That implies that a by-mode of "R" has to
be used, which means no negative by-times are allowed.

Moreover, if the original mode was "R", you can copy over a shorter by-time.
But what happens if the mode is "N"? I think in that case you'd want to
ignore the original by-time in order to get sensible behavior.

All that said, this use-case makes me wonder if the real error here is that we
aren't providing a way to look at and set by-times as absolute, rather than
relative, time values.

> notifications he asked for.

That's totally outside the purview of this extension, which does not and cannot
deal with the unextended redirect case. Moreover, the lack of specificity about
when Sieve operates - which is both intentional and essential -  makes this a
very difficult question to address in ANY context. Just as one example, you
most certainly do NOT want to try and preserve these things if Sieve is
operating in a user agent weeks after final delivery - which is a perfectly
legitimate and  even common situation.

If this really concerns you, the place to address it is in the Sieve base
specification. Feel free to propose changes there if/when that specification is
revised.

> to sieve owner, not to the original author.

Agreed and already addressed.

> running it is very fast, but I think it still needs to be counted for.

Sieve implementations that operate at this point are in fact the exception,
not the rule.

> back to delta time when you send email forward:

Yes, I'm well aware of what it says, and why. I carpool to work every day with
the guy who wrote it. The reason for this text is so that implementations won't
carelessly lose track of some amount of elapsed time. But again, this only
works while messages are in transit. I'm not convinced there's an issue worth
addressing in the Sieve case.

> negative and positive delta times for the email service instead of

Given how Sieve is situated in regards to final delivery, I once again disagree
that RFC 2852 provides justification for such a change. THat said, I think the
change is worth considering for other reaons, first that Sieve is equipped to
deal with with absolute time values better than it is with relative ones, and
second, that there are quite a few reaonsable use-cases for setting an absolute
:by-time.

But this is a somwwhat complex topic, and this message is already very long, so
I'm going to defer discussing this to a separate message.

> after certain time (i.e. it is bounced back if it is tried to deliver

That's not going to be an easy effect to get, but more on that later.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 24 Apr 2010 14:44:43 -0700 (PDT)

> redirect-dsn and a similar one for redirect-deliverby)

Ggood. I dp think this has reached the point where a new draft is needed,
especially if  we also decide to pursue the whole absolute time thing.

				Ned

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Apr 2010 15:13:04 +0300

Ned Freed writes:
> Now please explain the significant advantage this provides to an
> attacker. It's not like sending emails is hard.

(This dicussion is mostly background stuff, and as the new text says
that redirect-deliverby uses Sieve owners address as envelope sender
address this does not really matter anymore as that alone solves the
attack.]

Sending emails is not hard, but I have understood that Sieve is
supposed to be something that can be safely enabled for any users even
when they do not have too much capabilities in the system.

For example lets say someone joins some mailing list and then make
Sieve filter that will redirect all mails from that mailing list
forward to some system using DELIVERBY with trace option. If those
status notifications (lets say there are for example 3 email hops
before the email reaches its final destination) go to the original
author, this one Sieve user has very easily generated (even perhaps by
accident) distributed attack against all mailing list users. Everybody
sending email to this list will get 3 DSN notifications back from some
hosts on the network which he does not have any idea why he is getting
them and unless he really knows how to read email Received headers etc
he does not even know who enabled the feature, i.e. who is doing the
attack.

Yes, the original attacker could do the same thing with procmail or
.forward and simple shell script, but I understood one of the reasons
for Sieve was that it was supposed to be safer for "normal" people to
use it and not cause problems, i.e. it is used in environments where
shell access is not provided.

Also as the distributed machines sending those DSN notifications are
real legal email servers which normally do process emails (in or out)
the original sender getting those DSN's does not want to filter them
out (or not even all DSN from them machines, as somethings he himself
might want to enable DSNs and get DSN reports back from those machines
too).

The problem is not very big, I agree, but if Sieve is supposed to be
system which can safely be given to the "normal" people who are not
allowed to get shell access to email systems, then this does offer
them new way of causing trouble and harm to other users (i.e. the
original sender). This is why I think it is issue which might need to
be mentioned here but as I said already the new text which says
redirect-deliverby uses Sieve owners address as envelope sender solves
all of this already as now Sieve owner can only attack himself... 

> In other words, this is a case where the Sieve policy for requesting
> DSNs is more lenient that for submit/SMTP. I agree this is a
> security concern, which is why the security considerations section
> of the document addresses it. It says:
> 
> Not only can it know, it has to. This is what administrators are for
> - to implement consistent policies across hosts.

Ok, do my home machine kivinen.iki.fi allow DSN or not? When I send
this email to you, is your Sieve filter allowed to add DSNs to this
email or not, i.e. do you know whether my outgoing email server
allowed me to enable DSNs or not.

In general case you do not. I have understood that Sieve is normally
run on the receiver end of the email, but perhaps I have misunderstood
that. The DSN policy is for the sender end of the email transmission.
Very often there is no common adminstration between the sender and the
receiver as people DO send cross-domain emails...

Again this point has also gone away now when the Sieve owner's address
is used as envelope sender as now the machine running Sieve can know
the policy to be used.

> On the contrary, it's entirely relevant because what we have done by
> requiring the resetting of the envelope sender is to effectively
> require that these extended redirect be considered as a new
> submission, not a relay operation.

Ok, that I can agree, but I assumed you were processing these two
issues independently and without the first change (i.e. the envelope
sender change) this would be different. 

>     perform the sort of limit operation you describe.

And there is not going to be extensions offering such features, like
adding and substracting integers and comparing them, and getting the
current time?

>     after final delivery, so copying deliver-by information doesn't really

For the user who is redirecting this to cellular phone it does make
sense. Lets say the email is about meeting that starts at 18:00, and
because of this the original deliver-by-time is 18:00, i.e. this email
is useless after that time. This email arrives to the users Sieve
filter at 14:44, and it is stored to users mail box, and the user's
Sieve filter wants to send a copy of that to cellular but add
additional limit that it cannot be send after 22:00 (just in case
there is some delays there), so user wants to add new deliver-by-time
that is going to be 22:00, but as the original had deliver-by-time of
18:00, it would be better to use shorter of those two as even when the
email is already delivered to the final destination (users mail box)
before the 18:00, the copy sent to be out usually has exactly same
meaningful time period as the original email. It does not help the
user to get that email to his cellular phone at 20:00 when the meeting
is already over. Because of this it does not really matter whether
this is final deliver or not as user still would have interest to use
the earlier of the two deliver-by-times.

(I used absolute deliver-by-time in the example above as it was easier
to explain using that, but of course the Sieve filter itself could as
easily use the delta time too.)

> be used, which means no negative by-times are allowed.

True. 

> ignore the original by-time in order to get sensible behavior.

Most likely. Or you just take shorter time and use R in that case too,
as if this is copy the email is already delivered to Sieve users mail
box, but this is for the Sieve user to decide. Of course all this is
also related to where the status notifications are sent. As with the
current change the status notifications are always sent to the Sieve
owner, so he most likely would be using R always in this setups as
this "cellular phone" is supposed to be the way to reach him more
quickly than from normal mail box, and N notifications does not really
offer any new information for him. 

> All that said, this use-case makes me wonder if the real error here
> is that we aren't providing a way to look at and set by-times as
> absolute, rather than relative, time values.

I actually start to feel that it might be better option. 

> That's totally outside the purview of this extension, which does not
> and cannot deal with the unextended redirect case. Moreover, the
> lack of specificity about when Sieve operates - which is both
> intentional and essential - makes this a very difficult question to
> address in ANY context. Just as one example, you most certainly do
> NOT want to try and preserve these things if Sieve is operating in a
> user agent weeks after final delivery - which is a perfectly

Ok. 

> Sieve implementations that operate at this point are in fact the exception,

So perhaps saying something that when Sieve is run as part of transit
then the delta time should be decremented. Btw, this will be
automatically taken account if the delta time is converted to absolute
deliver-by-time when the email is received and then back to delta time
when it is sent forward as part of relay. 

> Yes, I'm well aware of what it says, and why. I carpool to work
> every day with the guy who wrote it. The reason for this text is so
> that implementations won't carelessly lose track of some amount of
> elapsed time. But again, this only works while messages are in
> transit. I'm not convinced there's an issue worth addressing in the
> Sieve case.

Not even those exceptional cases where Sieve is run as part of email
transit, not as part of final delivery?

> Given how Sieve is situated in regards to final delivery, I once
> again disagree that RFC 2852 provides justification for such a
> change. THat said, I think the change is worth considering for other
> reaons, first that Sieve is equipped to deal with with absolute time
> values better than it is with relative ones, and second, that there
> are quite a few reaonsable use-cases for setting an absolute
> :by-time.
> 
> But this is a somwwhat complex topic, and this message is already
> very long, so I'm going to defer discussing this to a separate
> message.

Ok.
-- 
[email-masked]

---

From: Ned Freed <[email-masked]>
Date: Tue, 27 Apr 2010 09:39:00 -0700 (PDT)

> when they do not have too much capabilities in the system.

Yes and no. Sieve is specifically designed so that users can be allowed to
access it directly without being able to cause adverse impact to the email
infrastructure. Just as one example, the language isn't directly
Turing-complete, so you cannot write infinite loops of the "10 goto 10" variety
in it that will compromise your server by sending it into an infinite
evaluation loop.

But this doesn't mean you can just provide full and unrestricted access to
every Sieve capability and not have any problems. And this is true even if
you're talking about Sieve as defined in the base specification with no
extensions at all. A compliant basic implementation will provide the redirect
action, and nothing prevents me from writing a Sieve containing 100,000
redirects, one right after another, one to each person I want to spam. So every
competent Sieve implementation limits the number of redirects a script can
perform, just as an SMTP server limits the number of recipients it will accept.
(The very close parallel between this case and success DSN/delivery case should
be noted.)

What most implementations do to address this is to limit the number of
redirects allowed in a single Sieve. Typically this limit is set to 5 or so,
but it really needs to be a configurable parameter because the needs of
different installations in this regard are very different.

Moreover, such issues aren't limited to the actions the scripts can take.
Consdier the Sieve body test. I can write something like this:

   require ["body", "variables"];
   if header :matches "from" "*a*" {if body :contains "${1}b${2}" {keep;}}
   if header :matches "from" "*b*" {if body :contains "${1}c${2}" {keep;}}
   if header :matches "from" "*c*" {if body :contains "${1}c${2}" {keep;}}
   ...

In other words, I can write a script that does an arbitrary number of body
searches where the strings being searched for are dependent on the input
message in a very complex way that prevents precomputation and therefore forces
the Sieve implementtion to perform an arbitrary number of searches of what
might easily be a very large amount of text. (Our implementation provides body
tests but without the ability to perform variable substititions in the pattern
in order to prevent this sort of thing from being done.)

What this all translates to is that proper implementation and configuration is
still essential. You cannot operate an email system without proper and
consistent configuration and the presence or absence of Sieve suppport doesn't
change this fact in any way. And while it is nice to talk about a world where
such careful configuration of services isn't necessary, email simply wasn't
designed that way and you cannot make this happen after the fact. (Indeed, I
doubt it would be possible even in a blank slate design, but email is so far
away from that it's pointless to even think about.)

> he does not even know who enabled the feature, i.e. who is doing the

And once again, contrast this with an attack where I simply do the same thing
by sending a bunch of messages to the SMTP server directly using a problem on
my desktop system. No need to wait for the list to cough up the messages, no
audit trail showing how I edited my Sieve to make this happen - something
that's going to be hard to claim a virus or bot did, no need to worry about the
necessary extensions being there, etc. etc.

Really, this whole line of argument of yours is at best like worrying about a
pinprick when there's a deep stab wound right next to it.

> shell access is not provided.

The difference between Sieve and procmail or .forward isn't that Sieve is
incapable of being abused. It's that Sieve is designed in such a way that you
can actually prevent various forms of abuse with proper implementation and
configuration. Procmail in particular is impossible to secure in a similar
fashion: It's regex-based and it's trivial to write regexes that will consume
vast amounts of CPU, and moreover you can construct problematic patterns where
their problematic nature is difficult if not imposisble to detect in advance,
it allows execution of arbirary shell scripts, no consideration was given to
the ecurity implications of the built in action set, etc. etc. etc.

It is fair to say that Sieve probably wouldn't exist had procmail been designed
with safe server-side operation in mind. But it wasn't.

> might want to enable DSNs and get DSN reports back from those machines

In almost every real world case it is going to be same set of servers the
user has direct access to.

> all of this already as now Sieve owner can only attack himself...

With all due respect, I think you're operating from a seriously outdated attack
tree here. The whole shell access on the server thing is only really relevant
these days because of the potential for local resource consumption and
privilege amplification attacks. The presence of a scriptable PC on almost
everyone's desk has eliminated the need for direct server access to perform
more general sorts of automated attacks. That's why the SMTP server has to be
properly secured irrespective of what Sieve does or doesn't allow, and the only
relevant case is where Sieve offers most access than regular SMTP does.

> allowed me to enable DSNs or not.

If the servers I have available to me don't allow me to make DSN requests, I
would not expect to be able to do it from Sieve either. Ditto for DELIVERBY.
And if this isn't true, we're back to the case explicitly covered in the
security consideations.

> that. The DSN policy is for the sender end of the email transmission.

The DSN policy on the sender end is irrelevant, because Sieve has no access to
that end of things. It has to submit the DSN request to the local submit
server; Sieve provides no means for the user to select the submit server
that's going to be used.

Come to think of it, this is another way where any potential vulnerability in
Sieve falls far short - if I want to I can usually bypass local admimistrative
policy entirely by submitting my message with the forged envelope sender
directly to a server in another administrative domain. There's no way to do
that in Sieve.

Again, Sieve acts a a proxy for the user, providing another means for the user
to send mail. If this alternative means of  sending mail is for whatever reason
more permissive to the point of allowing abuse the regular SMTP server does
not, that's a configuration problem that needs to be addressed.

> receiver as people DO send cross-domain emails...

Of course there isn't, but since the Sieve isn't operating in the sender's
administrative realm, it's irrelevant.

> is used as envelope sender as now the machine running Sieve can know

And again I assert that this supposed security never existed in the first
place.

> sender change) this would be different.

I have no idea what this is supposed to mean.

> adding and substracting integers and comparing them, and getting the

Well, of course that's impossible to predict, but despite there being a huge
number of proposals for Sieve extensions, dozens of drafts, and many RFCs,
nobody has even suggested such a thing, let alone written up a draft. And we
appear to be coming to the end of Sieve extension work. So I think the odds of
it happening are pretty low.

That said, I think there may be a way to do this without arithmetic as long as
you can get the comoonents of the by-time in absolute form.

> sense.

I first note that the action of "redirect to cellular phone" is rarely if
even what's actually going on. And in this case it's an important distinction.

What actually occurs is that the message is sent to a submit server and back
out into the transport infrastructure. Eventually the message gets delivered to
a mailbox somewhere. And there it sits until the client polls and  finds the
message. The time spent waiting for that poll to occur is time that is not and
cannot be controlled by DELIVERBY.

Of course there are alternatives to polling. The standard ones are IMAP IDLE
and NOTIFY. But both IDLE and NOTIFY require that the client hold open a
connection to the server. That's highly problematic for cell phones so most of
them don't do it.

Absent IDLE or NOTIFY, you're left with nonstandard mechamisms. Unfortunately
most of this stuff is highly vendor-specific and what I little I do know about
it is covered by various nondisclosure agreements. But suffice it to say that
the availability of such capabilities is far from universal, and the quality of
the resulting services can vary considerably.

And even if the client is notified immediately, it may not for various
reasons be able to get at the message right away. And again, all of this
is happening outside of the supervisory control DELIVERBY provides.

Even if we assume none of these delays occur - and it's my current experience
that these days delays post final delivery are far more prevalent than
transport infrastructure delays - there's the question of intended semantics.
DELIVERBY can be used to say, "Deliver this message by such and such a time, if
not, give up". But why this is being done isn't part of the package. You may
infer that what the sender cared about was getting the message in front of the
recipient's eyes in a certain amount of time, but what if the goal was merely
to get the message into the recipient's mailbox before some deadline and the
sender could not care less if they have seen it or not? The protocol doesn't
let you make that distinction, and that makes willy-nilly copying of DELIVERBY
information acrsss resubmits problematic.

There's also the issue of Sieve NOTIFY. IF notify is available, not only can
you use it to send a notification about the message to the phone in a way that
avoids most if not all of these issues.

What you're left with is the case where (a) The sender's intentions are known
in advance, (b) DELIVERBY is unformly supported across both transports, (c)
Sieve and this particular extension are also supported on the initial delivery
server, and (d) Post-delivery delays are negligable, and (e) No better
alternative like Sieve notify are available. While I'm sure such situations
could exist, this is now a pretty esoteric case.

> Lets say the email is about meeting that starts at 18:00, and

I understand the use-case. What I'm saying is that it's a lot harder to
implement than you think. And while you can argue that it shouldn't be, the
real difficulties here have nothing to do with this extension.

> easily use the delta time too.)

As a practical matter, yes, but once you capture a relative time you're no
longer accounting for the time elapsed between when you captured it and when
you use it. Since one of the main points of Sieve is that all scripts can be
executed in negligable time, this is not a realistic concern, but there's still
a gap.

So really, the best way to do it is with an absolute time, which you need
anyway to perform the necessary comparisons.

> I actually start to feel that it might be better option.

It's a better option for several additional reasons, one being that this way
yuo can do much simoler and more obvious stuff like redirect a message that has
to be delivered before 10:00PM to do. That's impossible to do currently, but it
can be done if you have an absolute time argument variant on redirect.

> when it is sent forward as part of relay.

It's actually better for the reasons I gave above.

> transit, not as part of final delivery?

Not even then. See above for why this is a lot more esoteric than it first
appears.

				Ned