Am Donnerstag, 21. April 2011, 14:13:49 schrieb Wietse Venema: > Dominik Schulz: > > 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. > > This is incorrect. As documented in transport(5) under TABLE SEARCH > ORDER, Postfix looks up user+extension@domain before user@domain. Yes, I've read and understood this. Why is my statement incorrect?
With "it should use .." I meant "I want Postfix to use ...".
I didn't want to imply that Postfix does something wrong.
> > 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.
>
> Your table does not satisfy Postfix requirements.
Well ... yeah. And Postfix does not satisfy my requirements in this case.
I'm not trying to be mean, I'd just like to use Postfix in way that's not the
regular use-case.
> All Postfix tables must return "not found" when an address does
> not exist. They must not return en empty string, or some other
> bogus result. Only "not found" is a valid result.
With "not found" you mean - in the case of SQL tables - zero rows, don't you?
This transport table does ineed return not found for "regular" addresses. Only
those special ones that have to be handled - in some cases - locally and in
others on a remote host are handled differently.
They return a valid local transport ('dovecot:') if the address is found in
the sql database and a default value ('smtp:[nexthop]' if not. This default
value is the nexthop mailserver. Postfix then uses recipient callout
verification to check if the recipient exists and accepts the mail only it he
does exist.
I've found a way to work around this issue by testing inside the SQL query if
the local part does contain the recipient delimiter but I'd still like to
suggest to provide an additional macro to make postfix even more flexible
without compromising its clean and appealing design.
>
> This is fundamental to how Postfix table lookups work, and this
> will not be changed.
I do not propose to change the way Postfix table lookups work!
What I did like to propose, even if it wasn't clear in my last mail, is to add
additional macros (or whatever you call the %-stuff) to allow more flexible
queries. That's all.
--
Mit freundlichen Grüßen / Best Regards
Dominik
signature.asc
Description: This is a digitally signed message part.
