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 :).
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.
> > 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.
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 *(_at_)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.
> 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 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.
>> 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.
Yes.
> 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.
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.
...
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 :)
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
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve