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 :).
[..]
This effectively circumvents the implicit delivery detection of the
vacation action (RFC 5230 - section 4.5), with all the possible
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.
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.
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.
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..."; }
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 "*(_at_)examples(_dot_)com" ' 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.
One of the nasty scenarios I can imagine is when recipients of a
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.
If I am not mistaken (again), your solution using the header test would
work in this case.
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.)
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.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve