How regular expression tables are processed by postfix
- I'm having some trouble setting up some virtual aliases. I guess I'll start by describing the larger problem I want to solve.I run multiple web applications on a development server and some of them have functionality which involves email. Occasionally I'll import production databases into these web applications in pursuit of some support issue or bug. Unfortunately, this makes it possible for automated processes or human error to trigger the sending of emails which should not be sent. For example, if one of my web applications sends a goodbye email to an user when they cancel their account, then when I delete their account on my development server, the server will send an email to that user, resulting in confusion and embarrassment.So my project of late has been to put in place measures which prevent things like this from happening. As part of the solution, I'd like to have Postfix, which handles all email being sent from my development server, redirect messages emitted by my applications to a local mailbox called Firehose, which I can then comfortably access in my favorite mail client thanks to Dovecot.The problem is that, like I said, Postfix handles all the email going out, and some of it actually is supposed to go to the original recipient. This is mainly email emitted by certain monitoring applications. Fortunately, it's really easy to figure out whether message should be let through or put in the Firehose, because any email that is supposed to really go out is only going to go to a small handful of addresses. All I need is a sort of whitelist.To accomplish the above, I'm trying to set up virtual aliasing. I've elected to use a POSIX regular expression table, which looks something like the below:
/notifier@dev1\.example\.com/ notify-list@.../.+@dev1\.example\.com/ a.person@...
/.*@.*/ firehose@localhostI take the virtual table and run it through postmap to obtain virtual.db. After doing that, the firehose regex seems to be first thing used. Messages sent to notifier@... go to the Firehose instead. If I remove the Firehose regex, then the notifier regex takes over, so I know there's nothing wrong with the expressions themselves, just the order in which they're used. This doesn't make sense to me because both regexp_table(5) and virtual(5) say that "Patterns are applied in the order as specified in the table, until a pattern is found that matches the search string."I see in regexp_table(5) that there are if conditionals, so I could use those to force an order if I really had to. But what if my whitelist needs to grow big? That would be a lot of ifs and endifs.Can anyone tell me if I'm misunderstanding something? Is there a way to control the order in which regular expressions are tested without using conditionals?Thanks very much,Daniel Flaum
- Daniel Flaum:
> /notifier@dev1\.example\.com/ notify-list@...As documented in virtual(5), virtual_alias_maps is expanded recursively
> /.+@dev1\.example\.com/ a.person@...
> /.*@.*/ firehose@localhost
(see WikiPedia for "recursion").
Therefore the wild-card rule at the end match all lookup results
from the first two rules.
Don't use wild-card rules.
As documented in regexp_table(5) and pcre_table(5), Postfix does
support conditional expressions.