Re: transport_maps lookup ordering
On Sat, 9 Nov 2013 08:54:40 +0530 tejas sarade tejas.a.sar...@gmail.com wrote: If lookup fails Postfix will use default transport. Sure but this is only _one_ hard-coded transport and not one I can dynamically change like in the tcp_table lookup. So it looks like as if the logic tries to minimize the lookup queries and expect all tables which are more than a key=value mapping knows with _one_ query if it is responsible or not. That means I can't use static hash tables for domains if I want to have a tcp table which gives me a default value if _no other hash based_ table has a domain hit. Correct me if I'm wrong. Simon On Nov 9, 2013 7:49 AM, Simon Effenberg sa...@schuldeigen.de wrote: wie...@porcupine.org schrieb: transport_maps are searched in the order as specified in main.cf. If it's not found in regexp:/etc/postfix/transport.exp, then the tcp map is queried. Wietse So this means that I cannot distinguish between x...@yyy.com and yyy.comlookups in the tcp table because I will only be queried with x...@yyy.com and yo the tcp table has to know all domains as well if it should be a last resort to all unknown domains in the transport file, right? Simon -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. --
Re: transport_maps lookup ordering
Simon Effenberg: On Sat, 9 Nov 2013 08:54:40 +0530 tejas sarade tejas.a.sar...@gmail.com wrote: If lookup fails Postfix will use default transport. Sure but this is only _one_ hard-coded transport and not one I can dynamically change like in the tcp_table lookup. So it looks like as if the logic tries to minimize the lookup queries and expect all tables which are more than a key=value mapping knows with _one_ query if it is responsible or not. That means I can't use static hash tables for domains if I want to have a tcp table which gives me a default value if _no other hash based_ table has a domain hit. Correct me if I'm wrong. transport_maps can use hash tables AND tcp tables. transport_maps queries each table in the specified order, and stops when a result is found. When no result is found, Postfix uses default_transport. Wietse-
Re: transport_maps lookup ordering
On Sat, 9 Nov 2013 07:54:30 -0500 (EST)
wie...@porcupine.org (Wietse Venema) wrote:
transport_maps can use hash tables AND tcp tables. transport_maps
queries each table in the specified order, and stops when a result
is found. When no result is found, Postfix uses default_transport.
Wietse-
I got this but so it's impossible to do something like that:
main.cf:
transport_maps = hash:/etc/postfix/transport, tcp:[127.0.0.1]:2527
transport:
@domain1.tld smtp:[internal.relay]
@domain2.tld smtp:[external.relay]
master.cf:
127.0.0.1:2527 inet n n n - 0 spawn
user=nobody argv=/etc/postfix/random.rb
random.rb:
#!/usr/bin/env ruby
TRANSPORTS = [ 'smtp1:', 'smtp2:', 'smtp3:' ]
while line = STDIN.readline
puts 200 #{TRANSPORTS[rand(TRANSPORTS.size)]}
end
If I'll try to send a mail to x...@domain1.tld this won't use
smtp:[internal.relay] but one of 'smtp1:', 'smpt2:' or 'smtp3:'
But that's what I don't want :)..
Simon
--
Re: transport_maps lookup ordering
On 11/9/2013 2:13 PM, Simon Effenberg wrote:
On Sat, 9 Nov 2013 07:54:30 -0500 (EST)
wie...@porcupine.org (Wietse Venema) wrote:
transport_maps can use hash tables AND tcp tables. transport_maps
queries each table in the specified order, and stops when a result
is found. When no result is found, Postfix uses default_transport.
Wietse-
I got this but so it's impossible to do something like that:
main.cf:
transport_maps = hash:/etc/postfix/transport, tcp:[127.0.0.1]:2527
transport:
@domain1.tld smtp:[internal.relay]
@domain2.tld smtp:[external.relay]
master.cf:
127.0.0.1:2527 inet n n n - 0 spawn
user=nobody argv=/etc/postfix/random.rb
random.rb:
#!/usr/bin/env ruby
TRANSPORTS = [ 'smtp1:', 'smtp2:', 'smtp3:' ]
while line = STDIN.readline
puts 200 #{TRANSPORTS[rand(TRANSPORTS.size)]}
end
If I'll try to send a mail to x...@domain1.tld this won't use
smtp:[internal.relay] but one of 'smtp1:', 'smpt2:' or 'smtp3:'
No. x...@domain1.tld matches the first line in /etc/postfix/transport.
You seem terminally confused about how maps are used.
Each map type has specific documentation on how it is queried, but no
map determines WHEN it is queried. You define that in transport_maps.
--
J.
Re: transport_maps lookup ordering
On Sat, 09 Nov 2013 14:21:51 +0100
Jeroen Geilman jer...@adaptr.nl wrote:
On 11/9/2013 2:13 PM, Simon Effenberg wrote:
On Sat, 9 Nov 2013 07:54:30 -0500 (EST)
wie...@porcupine.org (Wietse Venema) wrote:
transport_maps can use hash tables AND tcp tables. transport_maps
queries each table in the specified order, and stops when a result
is found. When no result is found, Postfix uses default_transport.
Wietse-
I got this but so it's impossible to do something like that:
main.cf:
transport_maps = hash:/etc/postfix/transport, tcp:[127.0.0.1]:2527
transport:
@domain1.tld smtp:[internal.relay]
@domain2.tld smtp:[external.relay]
master.cf:
127.0.0.1:2527 inet n n n - 0 spawn
user=nobody argv=/etc/postfix/random.rb
random.rb:
#!/usr/bin/env ruby
TRANSPORTS = [ 'smtp1:', 'smtp2:', 'smtp3:' ]
while line = STDIN.readline
puts 200 #{TRANSPORTS[rand(TRANSPORTS.size)]}
end
If I'll try to send a mail to x...@domain1.tld this won't use
smtp:[internal.relay] but one of 'smtp1:', 'smpt2:' or 'smtp3:'
No. x...@domain1.tld matches the first line in /etc/postfix/transport.
You seem terminally confused about how maps are used.
Each map type has specific documentation on how it is queried, but no
map determines WHEN it is queried. You define that in transport_maps.
That's not how it works in my 2.9 postfix version.. trivial-rewrite is
doing the following (regarding to -vv logs):
1. search for x...@domain1.tld
1. in transport which has NO match
2. asking the tcp_table which HAS a match
so this wouldn't work.. but if I would change the random.rb that is
only giving a 200 smtp{1..3}: if the request is for a domain and
not for the full email address the following will happen:
1. search for x...@domain1.tld
1. in transport which has NO match
2. asking the tcp_table which has NO match because it is a full
address
2. search for domain1.tld
1. in transport which HAS a match = correct transport is used
but now.. if I want to send a mail to y...@domain2013.tld this will
happen:
1. search for y...@domain2013.tld
1. in transport which has NO match
2. asking the tcp_table which has NO match because it is a full
address
2. search for domain2013.tld
1. in transport which has NO match
- now postfix is using the default_transport because tcp table is
only asked once and not a second time (see tcp_table(5))
So it looks not good for me, isn't it?
Simon
--
Re: transport_maps lookup ordering
On 11/09/2013 02:33 PM, Simon Effenberg wrote:
On Sat, 09 Nov 2013 14:21:51 +0100
Jeroen Geilman jer...@adaptr.nl wrote:
On 11/9/2013 2:13 PM, Simon Effenberg wrote:
On Sat, 9 Nov 2013 07:54:30 -0500 (EST)
wie...@porcupine.org (Wietse Venema) wrote:
transport_maps can use hash tables AND tcp tables. transport_maps
queries each table in the specified order, and stops when a result
is found. When no result is found, Postfix uses default_transport.
Wietse-
I got this but so it's impossible to do something like that:
main.cf:
transport_maps = hash:/etc/postfix/transport, tcp:[127.0.0.1]:2527
transport:
@domain1.tld smtp:[internal.relay]
@domain2.tld smtp:[external.relay]
master.cf:
127.0.0.1:2527 inet n n n - 0 spawn
user=nobody argv=/etc/postfix/random.rb
random.rb:
#!/usr/bin/env ruby
TRANSPORTS = [ 'smtp1:', 'smtp2:', 'smtp3:' ]
while line = STDIN.readline
puts 200 #{TRANSPORTS[rand(TRANSPORTS.size)]}
end
If I'll try to send a mail to x...@domain1.tld this won't use
smtp:[internal.relay] but one of 'smtp1:', 'smpt2:' or 'smtp3:'
No. x...@domain1.tld matches the first line in /etc/postfix/transport.
You seem terminally confused about how maps are used.
Each map type has specific documentation on how it is queried, but no
map determines WHEN it is queried. You define that in transport_maps.
That's not how it works in my 2.9 postfix version.. trivial-rewrite is
doing the following (regarding to -vv logs):
1. search for x...@domain1.tld
1. in transport which has NO match
2. asking the tcp_table which HAS a match
This is incorrect.
As documented:
*TABLE SEARCH ORDER*
With lookups from indexed files such as DB or DBM, or from
networked tables such as NIS, LDAP or SQL, patterns are
tried in the order as listed below:
/user+extension@domain transport/:/nexthop/
Deliver mail for/user+extension@domain/ through
/transport/ to/nexthop/.
/user@domain transport/:/nexthop/
Deliver mail for/user@domain/ through/transport/ to
/nexthop/.
* **domain transport**:**nexthop*
Deliver mail for/domain/ through/transport/ to/nex-/
/thop/.
/.domain transport/:/nexthop/
Deliver mail for any subdomain of/domain/ through
/transport/ to/nexthop/. This applies only when the
string*transport_maps
http://www.postfix.org/postconf.5.html#transport_maps* is not listed in the*par
http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains-*
*ent_domain_matches_subdomains
http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains*
configuration set-
ting. Otherwise, a domain name matches itself and
its subdomains.
*** /transport/:/nexthop/
The special pattern*** represents any address (i.e.
it functions as the wild-card pattern, and is
unique to Postfix transport tables).
@domain.tld will never match anything in transport(5).
Your transport map is incorrectly formed.
--
J.
Re: transport_maps lookup ordering
Sorry the mistake was only in my example.. pardon me. The transport file has no
@ prefix in my configuration. (And if I disable the tcp table the transport
file works like expected).
Jeroen Geilman jer...@adaptr.nl schrieb:
On 11/09/2013 02:33 PM, Simon Effenberg wrote:
On Sat, 09 Nov 2013 14:21:51 +0100
Jeroen Geilman jer...@adaptr.nl wrote:
On 11/9/2013 2:13 PM, Simon Effenberg wrote:
On Sat, 9 Nov 2013 07:54:30 -0500 (EST)
wie...@porcupine.org (Wietse Venema) wrote:
transport_maps can use hash tables AND tcp tables. transport_maps
queries each table in the specified order, and stops when a result
is found. When no result is found, Postfix uses default_transport.
Wietse-
I got this but so it's impossible to do something like that:
main.cf:
transport_maps = hash:/etc/postfix/transport,
tcp:[127.0.0.1]:2527
transport:
@domain1.tld smtp:[internal.relay]
@domain2.tld smtp:[external.relay]
master.cf:
127.0.0.1:2527 inet n n n - 0 spawn
user=nobody argv=/etc/postfix/random.rb
random.rb:
#!/usr/bin/env ruby
TRANSPORTS = [ 'smtp1:', 'smtp2:', 'smtp3:' ]
while line = STDIN.readline
puts 200 #{TRANSPORTS[rand(TRANSPORTS.size)]}
end
If I'll try to send a mail to x...@domain1.tld this won't use
smtp:[internal.relay] but one of 'smtp1:', 'smpt2:' or 'smtp3:'
No. x...@domain1.tld matches the first line in
/etc/postfix/transport.
You seem terminally confused about how maps are used.
Each map type has specific documentation on how it is queried, but
no
map determines WHEN it is queried. You define that in
transport_maps.
That's not how it works in my 2.9 postfix version.. trivial-rewrite
is
doing the following (regarding to -vv logs):
1. search for x...@domain1.tld
1. in transport which has NO match
2. asking the tcp_table which HAS a match
This is incorrect.
As documented:
*TABLE SEARCH ORDER*
With lookups from indexed files such as DB or DBM, or from
networked tables such as NIS, LDAP or SQL, patterns are
tried in the order as listed below:
/user+extension@domain transport/:/nexthop/
Deliver mail for/user+extension@domain/ through
/transport/ to/nexthop/.
/user@domain transport/:/nexthop/
Deliver mail for/user@domain/ through/transport/ to
/nexthop/.
* **domain transport**:**nexthop*
Deliver mail for/domain/ through/transport/ to/nex-/
/thop/.
/.domain transport/:/nexthop/
Deliver mail for any subdomain of/domain/ through
/transport/ to/nexthop/. This applies only when the
string*transport_maps
http://www.postfix.org/postconf.5.html#transport_maps* is not
listed in the*par
http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains-*
*ent_domain_matches_subdomains
http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains*
configuration set-
ting. Otherwise, a domain name matches itself and
its subdomains.
*** /transport/:/nexthop/
The special pattern*** represents any address (i.e.
it functions as the wild-card pattern, and is
unique to Postfix transport tables).
@domain.tld will never match anything in transport(5).
Your transport map is incorrectly formed.
--
J.
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: transport_maps lookup ordering
So has anybody an idea if I can get the functionallity I want? I know that I
could put all the logic from the hash table into the tcp table but that sounds
ugly..
Simon Effenberg sa...@schuldeigen.de schrieb:
Sorry the mistake was only in my example.. pardon me. The transport
file has no @ prefix in my configuration. (And if I disable the tcp
table the transport file works like expected).
Jeroen Geilman jer...@adaptr.nl schrieb:
On 11/09/2013 02:33 PM, Simon Effenberg wrote:
On Sat, 09 Nov 2013 14:21:51 +0100
Jeroen Geilman jer...@adaptr.nl wrote:
On 11/9/2013 2:13 PM, Simon Effenberg wrote:
On Sat, 9 Nov 2013 07:54:30 -0500 (EST)
wie...@porcupine.org (Wietse Venema) wrote:
transport_maps can use hash tables AND tcp tables. transport_maps
queries each table in the specified order, and stops when a
result
is found. When no result is found, Postfix uses
default_transport.
Wietse-
I got this but so it's impossible to do something like that:
main.cf:
transport_maps = hash:/etc/postfix/transport,
tcp:[127.0.0.1]:2527
transport:
@domain1.tld smtp:[internal.relay]
@domain2.tld smtp:[external.relay]
master.cf:
127.0.0.1:2527 inet n n n - 0 spawn
user=nobody argv=/etc/postfix/random.rb
random.rb:
#!/usr/bin/env ruby
TRANSPORTS = [ 'smtp1:', 'smtp2:', 'smtp3:' ]
while line = STDIN.readline
puts 200 #{TRANSPORTS[rand(TRANSPORTS.size)]}
end
If I'll try to send a mail to x...@domain1.tld this won't use
smtp:[internal.relay] but one of 'smtp1:', 'smpt2:' or 'smtp3:'
No. x...@domain1.tld matches the first line in
/etc/postfix/transport.
You seem terminally confused about how maps are used.
Each map type has specific documentation on how it is queried, but
no
map determines WHEN it is queried. You define that in
transport_maps.
That's not how it works in my 2.9 postfix version.. trivial-rewrite
is
doing the following (regarding to -vv logs):
1. search for x...@domain1.tld
1. in transport which has NO match
2. asking the tcp_table which HAS a match
This is incorrect.
As documented:
*TABLE SEARCH ORDER*
With lookups from indexed files such as DB or DBM, or from
networked tables such as NIS, LDAP or SQL, patterns are
tried in the order as listed below:
/user+extension@domain transport/:/nexthop/
Deliver mail for/user+extension@domain/ through
/transport/ to/nexthop/.
/user@domain transport/:/nexthop/
Deliver mail for/user@domain/ through/transport/ to
/nexthop/.
* **domain transport**:**nexthop*
Deliver mail for/domain/ through/transport/
to/nex-/
/thop/.
/.domain transport/:/nexthop/
Deliver mail for any subdomain of/domain/ through
/transport/ to/nexthop/. This applies only when the
string*transport_maps
http://www.postfix.org/postconf.5.html#transport_maps* is not
listed in the*par
http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains-*
*ent_domain_matches_subdomains
http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains*
configuration set-
ting. Otherwise, a domain name matches itself and
its subdomains.
*** /transport/:/nexthop/
The special pattern*** represents any address (i.e.
it functions as the wild-card pattern, and is
unique to Postfix transport tables).
@domain.tld will never match anything in transport(5).
Your transport map is incorrectly formed.
--
J.
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
gesendet.
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: transport_maps lookup ordering
Simon Effenberg:
On Sat, 9 Nov 2013 07:54:30 -0500 (EST)
wie...@porcupine.org (Wietse Venema) wrote:
transport_maps can use hash tables AND tcp tables. transport_maps
queries each table in the specified order, and stops when a result
is found. When no result is found, Postfix uses default_transport.
Wietse-
I got this but so it's impossible to do something like that:
main.cf:
transport_maps = hash:/etc/postfix/transport, tcp:[127.0.0.1]:2527
transport:
@domain1.tld smtp:[internal.relay]
@domain2.tld smtp:[external.relay]
If you want to send domain1.tld and domain2.tld to the internal
relay, then the correct syntax for a hash: map would be:
domain1.tld smtp:[internal.relay]
domain2.tld smtp:[external.relay]
master.cf:
127.0.0.1:2527 inet n n n - 0 spawn
user=nobody argv=/etc/postfix/random.rb
random.rb:
#!/usr/bin/env ruby
TRANSPORTS = [ 'smtp1:', 'smtp2:', 'smtp3:' ]
while line = STDIN.readline
puts 200 #{TRANSPORTS[rand(TRANSPORTS.size)]}
end
That randomly produces smtp1:, smtp2:, or smtp3: as response.
Wietse
Re: transport_maps lookup ordering
On Sat, 9 Nov 2013 15:30:10 -0500 (EST)
wie...@porcupine.org (Wietse Venema) wrote:
transport:
@domain1.tld smtp:[internal.relay]
@domain2.tld smtp:[external.relay]
If you want to send domain1.tld and domain2.tld to the internal
relay, then the correct syntax for a hash: map would be:
domain1.tld smtp:[internal.relay]
domain2.tld smtp:[external.relay]
yes sorry.. was only wrong in my head while writing this example. In my
real transport file it is correct (without the @).
master.cf:
127.0.0.1:2527 inet n n n - 0 spawn
user=nobody argv=/etc/postfix/random.rb
random.rb:
#!/usr/bin/env ruby
TRANSPORTS = [ 'smtp1:', 'smtp2:', 'smtp3:' ]
while line = STDIN.readline
puts 200 #{TRANSPORTS[rand(TRANSPORTS.size)]}
end
That randomly produces smtp1:, smtp2:, or smtp3: as response.
I know. But replace it with whatever logic you want as a last resort if
no other transport_map maps a _complete mail_ or a _domain_.
Simon
--
Re: transport_maps lookup ordering
Simon Effenberg:
If you want to send domain1.tld and domain2.tld to the internal
relay, then the correct syntax for a hash: map would be:
domain1.tld smtp:[internal.relay]
domain2.tld smtp:[external.relay]
yes sorry.. was only wrong in my head while writing this example. In my
real transport file it is correct (without the @).
OK, so this sends mail for these two domains to the internal relay.
All other destinations are passed to the TCP map.
master.cf:
127.0.0.1:2527 inet n n n - 0 spawn
user=nobody argv=/etc/postfix/random.rb
random.rb:
#!/usr/bin/env ruby
TRANSPORTS = [ 'smtp1:', 'smtp2:', 'smtp3:' ]
while line = STDIN.readline
puts 200 #{TRANSPORTS[rand(TRANSPORTS.size)]}
end
That randomly produces smtp1:, smtp2:, or smtp3: as response.
I know. But replace it with whatever logic you want as a last resort if
no other transport_map maps a _complete mail_ or a _domain_.
If you want the TCP map reply to depend on the result of ``line =
STDIN.readline'', then you need to write code that produces that
response.
As documented in transport(5), The special query for * asks for
a wild-card result. It does not matter for your configuration.
Also in transport(5):
TCP-BASED TABLES
This section describes how the table lookups change when lookups are
directed to a TCP-based server. For a description of the TCP
client/server lookup protocol, see tcp_table(5). This feature is not
available up to and including Postfix version 2.4.
Each lookup operation uses the entire recipient address once. Thus,
some.domain.hierarchy is not looked up via its parent domains, nor is
user+foo@domain looked up as user@domain.
Results are the same as with indexed file lookups.
Wietse
Re: transport_maps lookup ordering
Simon Effenberg: Hi, my transport_maps is: transport_maps = hash:/etc/postfix/transport, regexp:/etc/postfix/transport.exp, tcp:[127.0.0.1]:2527 I want to use the tcp as last resort lookup but I don't know in which order postfix is checking everything. transport_maps are searched in the order as specified in main.cf. If it's not found in regexp:/etc/postfix/transport.exp, then the tcp map is queried. Wietse
Re: transport_maps lookup ordering
wie...@porcupine.org schrieb: transport_maps are searched in the order as specified in main.cf. If it's not found in regexp:/etc/postfix/transport.exp, then the tcp map is queried. Wietse So this means that I cannot distinguish between x...@yyy.com and yyy.com lookups in the tcp table because I will only be queried with x...@yyy.com and yo the tcp table has to know all domains as well if it should be a last resort to all unknown domains in the transport file, right? Simon -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: transport_maps lookup ordering
If lookup fails Postfix will use default transport. On Nov 9, 2013 7:49 AM, Simon Effenberg sa...@schuldeigen.de wrote: wie...@porcupine.org schrieb: transport_maps are searched in the order as specified in main.cf. If it's not found in regexp:/etc/postfix/transport.exp, then the tcp map is queried. Wietse So this means that I cannot distinguish between x...@yyy.com and yyy.comlookups in the tcp table because I will only be queried with x...@yyy.com and yo the tcp table has to know all domains as well if it should be a last resort to all unknown domains in the transport file, right? Simon -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
