Wildcard / pattern-based command alias with virtual domains

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Wildcard / pattern-based command alias with virtual domains

Damon Miller
Hi all.  I've got a question specific to command aliasing in a virtual
domain environment and I can't seem to find any answers on the mailing
lists, groups, FAQs, etc.  Here's the situation:

I'm rolling out a hosted version of a popular help desk solution.  One
of its primary benefits is the use of email as a mechanism by which end
users can interact with the tool, e.g. open tickets, add comments, etc.
This is quite useful in that it does not require users to go to use an
unfamiliar web interface; they just send email, in other words.  I want
to use Postfix to facilitate this but I'm running into trouble when
setting up the command aliases used for it.

(As an aside, I'm also soliciting feedback from the help desk community
but I thought I might gain some useful insight from the Postfix
community, obviously focused on a more general use of the server in the
context of multiple domains and multiple command aliases.)

Setting the specific context aside for a moment, my basic goals are as
follows:

1.  Host multiple (virtual) domains through Postfix's excellent support
for this.

2.  Define wildcard or pattern-based command aliases to catch message of
the form "[hidden email]" which pass these messages
off to a backend processing script.

I'd like to use MySQL to store the actual aliases since I already have
database automation in place to handle this, but if I had to use a
regexp file it wouldn't be the end of the world.  What I very much want
to avoid is having to explicitly define multiple aliases per customer,
e.g.:

[hidden email] -> /opt/mail/msft.sh -target=support
[hidden email] -> /opt/mail/msft.sh -target=network

[hidden email] -> /opt/mail/nyse.sh -target=support
[hidden email] -> /opt/mail/nyse.sh -target=phones

I need something like this:

[hidden email] -> /opt/mail/handler.sh customer target

I couldn't find a way to do this using the traditional file-based
aliasing approach, so I tried regular expressions.  The latest attempt
was as follows:

/^(.*)-(.*)@helpdesk.com$/ "|/opt/mail/handler.sh $1 $2"

First I hit the "substitution is not allowed" problem which I
temporarily disabled with a quick edit to "dict_regexp.c".  (I realize
the check was there for security reasons and my long-term goal was not
to pass unvalidated arguments to scripts on the command-line.  I was
just trying to make something work as a proof of concept.)

Unfortunately, it appears that Postfix never attempted to execute the
command:

Jun 27 13:14:17 cent3 postfix/pickup[16662]: E44195072B: uid=0
from=<root>
Jun 27 13:14:17 cent3 postfix/cleanup[16668]: E44195072B:
message-id=<[hidden email]>
Jun 27 13:14:17 cent3 postfix/qmgr[16663]: E44195072B:
from=<[hidden email]>, size=362, nrcpt=1 (queue active)
Jun 27 13:14:17 cent3 postfix/local[16670]: E44195072B:
to=<|/opt/mail/handler.sh customer target@helpdesk. com>,
orig_to=<[hidden email]>, relay=local, delay=0,
status=bounced (unknown user: "|/opt/mail/handler.sh customer queue")

The substitution ultimately seemed to work, though the last line is a
bit confusing.  The problem is that instead of running the command
specified ("/opt/mail/handler.sh customer queue") it attempts to deliver
to an address with this name.

My first question is:  Does the "virtual_alias_maps" option not support
command execution?

If not, I suppose I'd ask how I could make the local aliases map do
this.  I actually tried that as well and quickly hit the "name must be
local" complaint, presumably wherein Postfix is telling me that a local
aliases file can't specify alias rules for non-local users.  So does
that mean it just won't be possible to accommodate a multi-tenant
environment which requires aliases command targets?  I can't imagine
this is true given the flexibility of Postfix.

As a more general request, if there's a more appropriate way to handle
requirements of this nature please let me know.  Not being a Postfix
expert, I may well be chasing something that can easily be implemented
in another fashion so I'd love to hear about it.

Thanks very much for any advice.

Regards,

Damon

--

Damon T. Miller
Director of Application Services
Thinking Phone Networks
[hidden email]
617-649-1388 (Office)