2015-09-15 13:53 GMT+02:00 Mike Brudenell <mike.bruden...@york.ac.uk>:
> [snip]
> I can see why this might be useful — eg, an alias-based address <
> sa...@example.com> that fans email out to *N* recipients, but only returns
> an auto-reply ("Thank you for your enquiry…") from the <sa...@example.com>
> front-end address, and not from a Sales Team member who happens to be on
> holiday and set up an auto-reply: another team member will pick up the
> enquiry, so you don't want the customer being told Joe Bloggs is away and
> their enquiry won't be dealt with for a week or two.
>
> If this is indeed the enquiry maybe the real thing is to see if there's a
> tidier way of doing it. Here we'd have address go to a single shared
> mailbox, and have the team members access that mailbox to
> read/send/file/delete messages. That way everyone gets to see whether or
> not someone has already replied and what has been said so far.
Yes. This is the intended. If original rcpt was a "list", that is an alias with
multiple recipients (real accounts only, no recursive aliases), then never
send autoreplies from the backend "account", only from the "list" if it has
a autoreply configured.
If the original rcpt is instead an "alias", that is in my case a alias with a
single recipient, then only send autoreply from the final account if no
autoreply was sent from the alias...
For the logic here, I need access to the "tree" of recipients, and some
way to set a variable in routers (can perhaps be done from ${acl.. but
is this stored?
--
Bj(/)rnar
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
