Wietse Venema:
> Damian Lukowski:
>> Hi,
>>
>> is there a reason that tcp_table has the DICT_FLAG_PATTERN flag
>> instead of DICT_FLAG_FIXED? One could create more flexible transport
>> map chains if tcp_table was also queried for pure domains.
> Like pcre, regexp, and socketmap, tcp_table is queried only with
> the full search string. Substring matches can be done with regexp/pcre
> patterns, or with socketmap/tcp_table server code.
>
> Wietse
Hi,
I'm aware of this. However, consider a scenario we have today:
- an extensive hash table HT with pure domains and next hop information
- a tcp_table which:
-- may output varying next-hops for varying email addresses within the same
domain.
-- has "authoritative" next-hop knowledge for a set S of domains.
-- has non-authoritative, fallback next-hop knowledge for a set T of domains, T
disjoint S.
Next-hop information can be wrong for some domains of T.
- Domains from T are easily describable.
- HT and T are not disjoint.
- HT has correct information where the tcp_table would be wrong.
The problem is to eliminate wrong answers for domains from T.
Since the tcp_table is consulted with a full address, it can produce wrong
answers even if it is placed at the last position of transport_maps.
The first idea was to return 500 when queried for addresses whose domain is in
T.
In the next round, when Postfix queried for pure domains, it would find a hit
in HT and use this information. If there is no hit in HT, the tcp_table would
give fallback next-hop information for the domain. However, there is no next
round for the tcp_table as it is a PATTERN dictionary.
Possible solutions are:
1) transform HT into a regexp table which ignores the local part.
Performance would probably get much worse.
2) Parse HT within the tcp_table handler itself, in front of its current logic.
Performance would probably degrade a little, but it would be okay.
However, I would not like to duplicate program logic which is already in
Postfix.
3) Make tcp_table a FIXED dictionary, place it on the last position within
transport_maps,
and let it work as described above.
However, I don't know if a fixed tcp dictionary can cause problems.
Regards
Damian
