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.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majord...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
