Subject: [sieve] Possible abuse of variables with vacation extension.

From: Stephan Bosch <[email-masked]>
Date: Mon, 24 Aug 2009 17:29:33 +0200

Hello,

I've been getting frustrated e-mails from users having lots of aliases 
for their mail account. They currently need to specify all these in the 
:addresses list of the vacation action. One of the solutions I proposed 
is querying the available (single-drop) aliases in the background, 
requiring the implementation of a background alias lookup. Thus far, I 
haven't gotten around to implementing this.

Today, however, I got an e-mail about an alternative 'solution' that 
works out of the box, but somehow it doesn't feel right. The proposed 
solution is the following:

require ["variables", "envelope", "vacation"];

if envelope :matches "to" "*" {
   set "envto" "${1}";
   vacation
   :addresses ["${envto}"]
   "vacation message here...";
}

This effectively circumvents the implicit delivery detection of the 
vacation action (RFC 5230 - section 4.5), with all the possible 
consequences. This is similar to the non-standard ' :addresses "*" ' 
proposal I got some time earlier.

The above raises the question whether it is a good idea to allow 
variable substitutions in the :addresses argument of the vacation 
action. I presume the :addresses argument is there for a good reason.

One of the nasty scenarios I can imagine is when recipients of a 
multi-drop alias (an ad-hoc mailing list) use this solution. An 
unfortunate sender could receive lots of redundant vacation replies if 
the list members are collectively on vacation.

Regards,

Stephan.

---

From: [email-masked]
Date: Mon, 24 Aug 2009 09:35:09 -0700 (PDT)

> :addresses list of the vacation action.

I have to say that sounds like an implementation issue more than anything else.

> One of the solutions I proposed

Or alternately, you can run all of the candidate addresses through the
alias process and see if any of them match the current recipient.

There are lots of ways to skin this particular cat.

> consequences. 

On the contrary, I'd say what this does is *implement* the check called for in
section 4.5. Point 1 on the list in that section is:

   1.  an email address known by the implementation to be associated
       with the recipient,

The envelope recipiet address is by definition "associated with the recipient".
As such, I believe it is entirely appropriate to build such a check in
to yor implementation so that there is no need to do it explicitly.

FWIW, our implementation definitely does this, and I cannot think of a single
case where it has been a problem.

Remember, the goal here is to see if the message was sent directly to the
current recipient. So the question is whether or not the address appears in one
of the recipient headers, not whether or not the address appears in the
envelope.

> This is similar to the non-standard ' :addresses "*" '

> action. I presume the :addresses argument is there for a good reason.

What you showed is IMO not abuse, but rather an attempt to work 
around an implementation limitation. OTOH, this would be abusive:

 if address :matches ["To","Cc","Bcc","Resent-to","Resent-cc","Resent-bcc"]
            "*" {
    set "headerto" "${1}";
    vacation
    :addresses ["${headerto}"]
    "vacation message here...";
 }

This completely defeats the required check.  But just because you can write
abusive scripts using the variable substituion facility is not in and of 
itself a reason to prohibit variable substitution in a particular context. For
that to be the case the abuse would either have to be very common in practice
or the utility of variable use in this context would have to be quite low
compared to the potential for abuse. I don't see either of those applying here.

Nor does blocking substitutions in :addresses solve the problem in any
meaningful way. Consider:

    deleteheader "to";
    addheader "to" "${1}";

I'm pretty sure this will defeat vacation checks completely in at least some
implementations, and it did it without using :addresses.

> multi-drop alias (an ad-hoc mailing list) use this solution.

Why would this case be a problem? I send a message to an autoforwarder that
forwards to multiple recipients. That means the address that's going to appear
in the message header is going to be that of the autoforwarder. THe
autoforwards does its  thing and the envelope recipient list is changed to the
contents of the autoforwarder. Now suppose one of those reicpienets does the
trick you describe above. The address that's in the headers isn't going to
match the one in the envelope so the check fails unless they say

   :addresses "autoforwoarderaddress"

as part of the vacation configuration, which is exactly the case this mechanism
is intended to deal with.

Now, a more intesting question is whether or not this is abusive:

 if envelope :matches "orcpt" "rfc822;*" {
    set "origenvto" "${1}";
    vacation
    :addresses ["${origenvto}"]
    "vacation message here...";
 }

I can see this being abusive in some cases, in others, not. (It sort of depends
on to what extent you see autoforwarders as being mailing lists.)

> An

Not if the vacation check is properly implemented and the script isn't outright
abusive. See above. And in closing, I'll not that with the existance of the
notify extension, worrying about the effects of deliberately abusive scripts
just became a lot harder to justify, because the ways to abuse variables and
vacation pale in comparison to the ways you can abuse notify.

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Mon, 24 Aug 2009 21:31:01 +0200

Hi  Ned,

Ned Freed wrote:
>> One of the solutions I proposed is querying the available
>> (single-drop) aliases in the background, requiring the
>> implementation of a background alias lookup. Thus far, I haven't
>> gotten around to implementing this.
> 
> Or alternately, you can run all of the candidate addresses through
> the alias process and see if any of them match the current recipient.
That is similar to what I mention above.

> There are lots of ways to skin this particular cat.
I guess. Could you name a few more? Any suggestions are welcome :).

[..]
> On the contrary, I'd say what this does is *implement* the check
> called for in section 4.5. Point 1 on the list in that section is:
> 
> The envelope recipiet address is by definition "associated with the 
> recipient". As such, I believe it is entirely appropriate to build
> such a check in to yor implementation so that there is no need to do
> it explicitly.
> 
> FWIW, our implementation definitely does this, and I cannot think of
> a single case where it has been a problem.
Sorry, I am an idiot. Our implementation does this too. This example is
wrong (copy pasted from the suggestion), but I guess I and the person
who suggested it mean the same thing you mention below.

> Remember, the goal here is to see if the message was sent directly to
> the current recipient. So the question is whether or not the address
> appears in one of the recipient headers, not whether or not the
> address appears in the envelope.
Yes, definitely.

>> This is similar to the non-standard ' :addresses "*" ' proposal I
>> got some time earlier.
> 
> if address :matches
> ["To","Cc","Bcc","Resent-to","Resent-cc","Resent-bcc"] "*" { set
> "headerto" "${1}"; vacation :addresses ["${headerto}"] "vacation
> message here..."; }
> 
Yes, this is the correct implementation of a ' :addresses "*" '.

> This completely defeats the required check.  But just because you can
> write abusive scripts using the variable substituion facility is not
> in and of itself a reason to prohibit variable substitution in a
> particular context. For that to be the case the abuse would either
> have to be very common in practice or the utility of variable use in
> this context would have to be quite low compared to the potential for
> abuse. I don't see either of those applying here.

Ok, in that case it is pretty much the user's choice whether or not he 
wants to have the vacation extension refrain from replying to implicit 
deliveries. Then, maybe we should consider adding support for something 
like ' :addresses "*" ' or even ' :addresses "[email-masked]" ' in a 
next vacation RFC revision to make this a little easier to achieve. Or, 
maybe not.. it would break backwards compatibility. Perhaps an extension 
to vacation adding glob support...I don't know.

> Nor does blocking substitutions in :addresses solve the problem in
> any meaningful way. Consider:
> 
> if envelope :matches "to" "*" { deleteheader "to"; addheader "to"
> "${1}"; vacation "vacation message here..."; }
I agree, this (ab)use of the vacation action is hard to prevent; too 
many ways to circumvent things. BTW, why does the editheader extension 
require the vacation action to use the modified message and not the 
original one?

> I'm pretty sure this will defeat vacation checks completely in at
> least some implementations, and it did it without using :addresses.
True, although I haven't implemented editheader yet.

> Why would this case be a problem? I send a message to an
> autoforwarder that forwards to multiple recipients. That means the
> address that's going to appear in the message header is going to be
> that of the autoforwarder. THe autoforwards does its  thing and the
> envelope recipient list is changed to the contents of the
> autoforwarder. Now suppose one of those reicpienets does the trick
> you describe above. The address that's in the headers isn't going to 
> as part of the vacation configuration, which is exactly the case this
>  mechanism is intended to deal with.
If I am not mistaken (again), your solution using the header test would 
work in this case.

> if envelope :matches "orcpt" "rfc822;*" { set "origenvto" "${1}"; 
> vacation :addresses ["${origenvto}"] "vacation message here..."; }
> 
> I can see this being abusive in some cases, in others, not. (It sort
> of depends on to what extent you see autoforwarders as being mailing
> lists.)
Depends greatly on how large the list of mail-drops is for such a list. 
With < 10, I guess the problem is not that significant. And.. I guess 
larger ad hoc lists like this are a very bad idea anyway. In any case it 
can be surprising for the sender when he gets multiple responses.

>> An unfortunate sender could receive lots of redundant vacation
>> replies if the list members are collectively on vacation.
> 
> Not if the vacation check is properly implemented and the script
> isn't outright abusive. See above. And in closing, I'll note that with
> the existence of the notify extension, worrying about the effects of
> deliberately abusive scripts just became a lot harder to justify,
> because the ways to abuse variables and vacation pale in comparison
> to the ways you can abuse notify.
> 
True, although the number of notification recipients ought to be limited 
by the implementation.

I am not really opposed to users doing this kind of stuff, but I am 
always weary about strange scenarios I did not consider before and that 
are not mentioned in the specification. Obviously, the vacation action 
is designed to prevent replies to implicit deliveries and if users use a 
non-so-obvious way to circumvent it, there may be a problem. But, if the 
consensus is that this use of variables is not in fact abuse, I will 
leave the implementation as it is. In any case: it always good to 
consult the experts :)

Thanks.

Regards,

Stephan.

---

From: [email-masked]
Date: Mon, 24 Aug 2009 14:49:49 -0700 (PDT)

> I guess. Could you name a few more? Any suggestions are welcome :).

Well, you could store the list of possible recipient addresses alongside
the sieve script, no need to look them up that way. Or you could squirrel
away the  list of possible addresses coincident with the alias processing
the MTA does.

The latter is what we do, more or less.

> to vacation adding glob support...I don't know.

I'm dubious we actually want to have "*", and even more dubious we'd be able to
get it approved. To be blunt, whether or not we can get stuff approved seems to
have less to do with an objective assessmenbt of risk, and more to do if the
people doing the reviewing have have personal bad experiences with whatever
we're trying to standardize. And since pretty much everyone has gotten unwanted
vacation messages ... anyway that's my explanation of why notify sails through
and vacation gets a lot more scrutiny.

That said, the idea of *@domain stuff might be worth considering for inclusion
in a future version. I'm curious as to what others think.. It would probably
demand a new require "vacation-wildcards" or something like that.

> require the vacation action to use the modified message and not the

I was thinking about that myself. Our implementation of vacation precomputes
the "is vacation going to happen for this recipient" flag and therefore doesn't
see such additions. Or deletions for that matter.

THis will need to be clarified in the future. I think the right thing to say is
that processors MAY ignore editheader additions and deletions as part of the
vacation recipient check.

> If I am not mistaken (again), your solution using the header test would

Yes.

> can be surprising for the sender when he gets multiple responses.

Yes, well, this gets us to a problem with AFAIK no good answers - for this
class of things that lie somewhere between a simple autoforwarder and a mailing
list, that is, they expand to a bunch of addresses but don't change the
envelope from, what's the right way to handle notifications and errors?

You can't send them to the list maintainer because there isn't one. Sending
them to the message originator can be cpnfusing, because they may not know
anything about the actual recipients and the chances they're in a position to
correct an error in the recipient list is really, really low.

FWIW, the way we handle this for errors is to report problems to the rest of
the recipients. But speaking from personal experience, this turns out to be a
major PITA to implement. But this doesn't address the vacation issue at all.

I have to say I think the real answer here is that this particular species of
email critter needs to join with the passenger pigeon and wooly mammoth. We
routinely tell customers who have set these up to switch them over to proper
mailing lists.

> ...

> leave the implementation as it is. In any case: it always good to

It's also always good to reconsider stuff we don't in the past in light
of new things. The interaction with envelope-dsn is a case in point - I sure
hadn't thought of that one until you brought this up.

				Ned