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

[Tero Kivinen <[e-mail]>]

Ned Freed writes:
> > > 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?
> 
> > 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.
> 
> 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... 

> > 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.
> 
> 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.
> 
> > Host B cannot know what policy host A has, thus it cannot restrict
> > operations.
> 
> 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.

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

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

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

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

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

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

True. 

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

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. 

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

Ok. 

> > 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.
> 
> Sieve implementations that operate at this point are in fact the exception,
> not the rule.

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. 

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

> > 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.
> 
> 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.
-- 
[e-mail]