On 4/21/2011 6:55 PM, Jeroen Geilman wrote:
On 04/21/2011 02:04 PM, Dominik Schulz wrote:
Hi,
I've got a rather complex Postfix setup and experiencing
some issues with
the handling of transport maps.
Short Story:
Postfix replaces %u by 'user+ext' when querying my transport
maps although
it should use 'user' instead. I'd like to have a way to tell
Postfix to
use only the part before the recipient_delimiter in this query.
Long Story:
My setup uses vitual users stored in a MySQL database,
recipient_delimiter=+ for VERP and some domains have users
as well handled
local as well as remote. Those domains are defined as
relay_domains
and a
MySQL-fed transport map determines the suitable transport
for each of
those domains users. For local users the transport
'dovecot:' for local
delivery with the dovecot lda is returned, for true remote
users the
appropriate next-hop in the form 'smtp:[nexthop]' is used.
Everything went well so far until I've tried to implement
VERP. Postfix
does not try any other combination than 'user+ext' for the
%u macro
because my transport is special crafted to return a default
value for
non-existing users, i.e. it can never fail.
As documented, "user" is tried if "user+extension" does not
yield a result.
You could easily add a static transport_maps entry AFTER your
mysql map, like so:
transport_maps = mysql:/etc/postfix/transport.cf,
static:smtp:[nexthop]
First, all normal map lookup keys will be tried, and then, if
there was no result, the static value is returned.
The best solution is to craft an sql lookup that doesn't
respond to addresses with extensions, or at least so the
catchall doesn't match extensions.
