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.
I have to say that sounds like an implementation issue more than anything else.
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.
There are lots of ways to skin this particular cat.
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.
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 "*" '
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...";
}
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:
if envelope :matches "to" "*" {
deleteheader "to";
addheader "to" "${1}";
vacation
"vacation message here...";
}
I'm pretty sure this will defeat vacation checks completely in at least some
implementations, and it did it without using :addresses.
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.
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
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 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
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve