On Thu, Jan 29, 2009 at 2:04 AM, Victor Duchovni <victor.ducho...@morganstanley.com> wrote: > On Thu, Jan 29, 2009 at 01:37:01AM -0500, Dave wrote: > >> > No not "using generic", rather using a table that returns a fixed output >> > regardless of the input. The list of supported tables is still in the >> > same place, and looking through it top to bottom will quickly expose >> > the right table type for the job. >> > >> >> OK, let me guess... is it a static table? (I am guessing and I suppose I'll >> have to spend an hour testing by trial and error to find out because you >> choose not to give me a direct answer.) > > Yes. > >> What's with you guys on this list who have the answers yet are just handing >> out clues one by one and making me guess about the answer over the course of >> several email exchanges? Fortunately, there are some guys on this list that >> don't engage in those psychological games and I have greatly benefited from >> their help and I do appreciate it! > > When you arrive at the answer yourself, you not only have the answer, > but you have some intuition for why it is the right answer. The intuition > is a bit fuzzy at first, but it will get stronger in time. > > You're are perhaps beginning to grasp the indepdence of rewriting > features with their various lookup key orders and result formats from > the underlying table that maps the keys to values. > > At a high level, you choose the right rewriting feature to transform > message elemts at the right time. > > Once you know which feature to configure, you select a table that > maps one of the documented inputs (lookup keys) to the desired output > (result format). For this you choose the best table type and definition. > > Get familiar with a bunch of useful table types: > > - hash/btree/cdb > - ldap/pgsql/mysql > - regexp/pcre > - static > - ... > > Indepently get familiar with various address "rewriting" features documented > in ADDRESS_REWRITING_README: > > - virtual(5) > - transport(5) > - aliases(5) > - generic(5) > ... > > Each of these can use any of the table types, though some combinations are > silly (e.g. "hash" tables for header/body_checks) and others inadvisable > on high volume systems (transport(5)) via ldap/mysql/...) > > Over time the choice of lookup key documented by the rewriting feature > and mapping to apply to that key to yield the desired result will become > obvious, and you may find yourself answering questions along these lines > rather than asking them. > > Identifying the right sequence of rewrite features to achieve a given goal > takes experience and a broad understanding of the complete Postfix system. > Identifying the right table to perform a given mapping is easy you'll > learn this quickly. >
Case in point, the regex solution I suggested earlier is not the best way to return a single result for all inputs, but my limited experience kept me from knowing this. I knew one way to do it, but not the best way to do it. Victor's message intrigued me and prompted me to reread the documentation on table types. Now I understand exactly why this solution is better (and noticed some things I'd forgotten about other tables types too). Had he simply posted the config lines, I would not have learned this. I'd like to think that learning about regex tables will behoove the OP as well, they are quite handy in situations where they are appropriate.
